Confession: I believe in superstar Engineers.

Nowadays, given the Agile emphasis on Team, reliance on Superstars seems to be roughly as fashionable as fat ties. Embracing inequality of production can also be perceived as nave by the folks paying their salaries (why pay the big dollars in the Silicon Valley when engineers can be had for $8K in Malaysia?). But, while one can debate whether a great engineer is worth 100x, 10x or 5x a mediocre one, all I know is that great software requires superstars on board. Still, for all their worth (in fact, precisely because of their disproportionate ability to create value), Ive learned recently that superstars are poster children for the #1 problem plaguing every development team: Queues. At KANA, weve gradually been applying the theory of constraint management to manufacturing software. Lean Thinking tells us that getting better means attacking the choke points, the throttles, inhibiting Scrum team velocity. Leans power is founded on reimagining the software process, leaving behind the primitive notion of development as agriculture (where every engineer is like an acre of land and the job is to drive up yield per acre), substituting a mental model of manufacturing (where shippable software is an assembled output derived from many people with discrete skills contributing a piece of the finished whole). The agricultural model posits a darn good reason to hire superstars: the best engineers have high yields. The Lean Model, by contrast, tends to focus managerial energy not on strength but on weakness. By definition, a theory of constraints is a theory of the weakest link. Intuitively, focusing on shortage has managerial appeal. If we have disproportionate serverside engineers, our schedule becomes dependent on the capacity of front-end engineers. If we lack QA resources, our velocity is dictated by the pace of testing. If a team lacks design skills, our choke point tends to be architects. And so on Lean Thinking translates intuitive grasp of scarcity into the sterner stuff of science. Suppose we visualize each individual on the development team as a machine. Like assembly line machines, these human machines arent undifferentiated. Each is fit for purpose. A Toyota line consists of stamping machines and welding stations and on and on. The completed car is touched by many devices, each possessing a skill and a capacity. A Development Factory similarly manufactures working code by leveraging different talents: DBAs, Build engineers, UX, Product Owners, black-box testers, automation engineers, documentation writers, and on and on. Lean Thinking is about organizing the assembly line of capabilities (human or machine) to take optimum advantage of the available units of production, eradicating the wastefulness of waiting to be used (aka queuing). As we focus on Lean, Im learning that this common-sense, almost simple-minded, idea shouldnt be underestimated. When applied systematically to the factory floor, the discipline of Lean created a revolution in manufacturing, making a science of Supply Chain Management, shifting wealth.

How does Toyota identify the choke points on the factory floor? You look for queues. Where ever work in progress (the unfinished Toyotas) is stacking up, waiting on a machine, you have a throttle. Re-route the line, add more of the needed machines, increase throughput at that station by adding attendant/workers: the Lean manager focuses on the weakest link in the production chain, thereby unclogging the line and increasing flow. How do you identify throttle points in software velocity? You look for queues. The essence of Agile Lean is queue management. User stories are the cars. The product backlog is the set of orders, waiting to be fulfilled. Work in progress is the user stories burning down. Scrum teams, surrounded by the complete set of engineering resources, are the production factories in our supply chain. People are code-generating engines, bringing their unique skills and talents to forging working code. In the lean model, each person has a queue, which is the work awaiting burn. To get better and go faster, you identify and assist the people with out-sized queues, just as Toyota focuses on adding capacity where the line is queued behind a particular machine. Good stuff, for sure. But, like so many ideas that analogize machines and people, I believe a bear-trap lies hidden in the neatness of Lean. People possess two, queue-creating drives not shared by machines. People desire successful careers, and successful careers emanate from specialization and talent development. And, people have the capacity and desire to groom their own queues, working, consciously or unconsciously, to obscure the true throttles in the software assembly line. You probably have found that Agile exalts generalization. Agile guru after guru preaches the doctrine of fungible team members, advocating that every engineer pull backlog work indiscriminately. Generalism is great, and I think management should pay some price to combat over-specialization. But, pragmatic Agilists will recognize that good technical folks resist over-generalization. Expertise matters. Applications, nowadays, stand atop a significant pyramid of other peoples software, on multiple layers of core capability, from operating systems to DBs to UI frameworks to compilers to integration standards. An engineers self-development requires becoming deeply knowledgeable on a select portfolio of these standards. Knowledge is another (kinder and I would claim more accurate) name for specialization. To say this in economic terms, smart engineers manage the portfolio of their expertise precisely as venture capitalists manage their portfolio of companies. No intelligent VC would scatter their money and attention across too many bets; failure to focus and specialize is the surest way to guarantee failure. Still, the gurus are right: specialization makes queue management hard, building the barriers that build queues. Acknowledging the value of specialized knowledge means embracing a more complex model of queue management. The need for specialization manufactures only modest havoc compared to the ability of people to interfere with their queues. On a factory floor, when a machine cant keep up, work queues in front of THAT machine. On a development team, when the team cant keep up, work queues in front of your superstars. Think about it this way: whats the logical

move for a developer under pressure? Most seek assistance from the most knowledgeable person around. Top engineers have the broadest spectrum of expertise, a high desire to take on new challenges and superior problem-solving capacity. This troika translates into enormous demand for their involvement, and consequently, at least at KANA, we find the biggest queues in front of the biggest producers. Paradoxically, in the dynamic assembly line of the dev team, the managerial hunt for the weak link in the production chain typically detours thru the Superstar queue. Lean Thinking reveals why superstars are so incredibly valuable: their core worth lies not in their capacity to write more code, but in their ability to attack blockages in flow, moving from trouble point to trouble point and attacking the hard, risky tasks. In so doing, they themselves become the bottleneck. The assembly line model provides cogent confirmation of our intuition that deeply knowledgeable and talented engineers are invaluable. Lean Thinking helps us to find the waste that is blocking the flow of working code. The red flag that identifies blockage is the queue. On development teams, in contrast to factories, the biggest queues tend to be associated with our strongest performers