Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Leadership Without Management: Scaling Organizations by Scaling Engineers


Published on

My talk at Surge 2013. Video is at Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.

Published in: Technology, Business

Leadership Without Management: Scaling Organizations by Scaling Engineers

  1. Leadership Without Management: Scaling Organizations by Scaling Engineers SVP, Engineering Bryan Cantrill @bcantrill
  2. Software Engineering Middle Management: Toxin or Cancer? SVP, Engineering Bryan Cantrill @bcantrill
  3. Scaling an engineering organization • Adding an engineer to an organization has known drag: • Life-related problems (illness, life events, etc.) will grow linearly with people • Communication- and organization-related problems will grow non-linearly with people • The drag is embodied in Brooks’s Law: Adding people to a late software project only makes it later • Most thinking around scaling an organization seems to focus on reducing this drag — or coping with it • But exclusively thinking along these lines only makes sense if all software engineers are essentially equal!
  4. Software engineers are not equal • Software engineers are not equal; the best software engineers are (at least) an order of magnitude more productive than merely average engineers • Steve McConnell (author of Code Complete) has thoroughly researched this and calls it the “10X effect” — but even this likely understates the multiplier • While top software engineers are an order of magnitude more productive, they do not induce any more organizational drag that average engineers • Software engineering organizations scale an order of magnitude more effectively if they focus on growing with only top performers
  5. Exclusively top engineers? • Can one build an engineering organization that consists only of top engineers? • May sound like an obvious aspiration, but many organizations are not structured to do this: they either don’t attract top engineers — or repel them outright • What motivates superlative engineers? • What demotivates them? • How does one structure and operate an organization that consists only of top engineers? • And how does one find superlative engineers?
  6. Motivators • Above all else, engineers wish to make useful things • The biggest single motivator for superlative engineers is therefore mission — the “why” of an endeavor • The other primary motivators are team and technical problem — engineers are drawn to inspiring peers and hard problems • Assuming that engineers are compensated fairly, compensation is nearly always less important than mission, team and problem • Compensation is important, but focusing exclusively on compensation while neglecting the primary motivators will attract only those with the wrong motivations!
  7. Demotivators • If the mission, team and problem are compelling (and compensation is fair) top engineers will put up with an astonishing amount of organizational nonsense... • ...but there are demotivators that can become corrosive with respect to mission, team and problem • Many of these are structural — they can be avoided if one is aware of them • Ironically, engineering organizations seeking to “scale” are at the greatest risk for creating the structures that most profoundly demotivate software engineers!
  8. Demotivator: Formalized annual review • Feedback is essential, but formalized annual review is the wrong kind of feedback and at the wrong cadence • For top performers, this only serves to fixate on the unchangeable aspects of personality (e.g. too shy/not shy enough) instead of one’s technical achievements • And because formalized review carries a heavy burden, it often creates self-evaluation make-work for engineers, serving not only to demotivate but also to waste time • Not a radical opinion; annual performance review is one of Deming’s Seven Deadly Diseases of Management!
  9. Demotivator: Hierarchical titles • With the rise of the “dual ladder” that allowed engineers to advance without going into management, hierarchical titles were invented to denote engineering rank • e.g., “Member of technical staff” vs. “Staff engineer” vs. “Senior staff engineer” • But hierarchical titles create the N+1 Butt-head Problem: people will naturally find the biggest butt-head at the next higher rank, and be bummed out about them • Title promotions of others are reviled (“why not me?”); promotions of oneself are overdue (“about time!”) • Hierarchical titles are not uplifting — they’re corrosive
  10. Demotivator: Ranking • Forces an absolute ordering of engineer performance, with the “top” (~20%) rewarded, the “middle” (~70%) ignored and the “bottom” (~10%) terminated • Also known as “top grading” (Amazon), “stack ranking” (Microsoft), “rank-and-yank” (GE), “ranking- and-rating” (Intel) and — most gallingly — “individual dignity entitlement” (Motorola) • A team, organization or company tautologically cannot have more than a set percentage of top performers! • Self-fulfilling prophesy: if one has more than the set percentage of top performers, the lower-ranked top performers will do you the favor of leaving!
  11. Demotivator: Ranking, cont. • Ranking always starts harmlessly as an attempt to “quantify” and “standardize” performance to be able to allow a large organization to “level” compensation • But quotas quickly arise as a part of organizational jockeying: an organization won’t be permitted to have exclusively top performers by its rivals • Ranking creates the worst possible perverse incentives: avoid working with talented engineers and be sure you have some deadwood to throw into the lower ranks! • Ranking is organizational cancer
  12. Demotivator: Purple Robes Club • It may become tempting to establish a select group of engineers — often with adjectives like “distinguished” or “principal” or nouns like “architect” or “fellow” • This has all of the problems of ranking — but it’s even worse if this group is actually technically empowered • Having a select group hand down technical decisions is tremendously demotivating to younger talent • Standing “architectural review boards” are a variant of this!
  13. Demotivator: Non-technical management • Non-technical management can’t resist channeling Frederick Winslow Taylor: the fixation becomes on time- management above all else... • ...but those who have not developed software cannot possibly appreciate the degree of unknown unknowns in novel software development • Non-technical management can never understand the tradeoff that the unknowns imply: of functionality, quality and schedule, one may generally pick only two! • Non-technical management is a recipe for date-driven death marches, where “everyone” knows the schedule is unobtainable
  14. Demotivator: Ex-technical management • The most dangerous management is that which is formerly technical • They often retain the confidence of an engineer, but lose the humility that is forced upon an engineer who must get a complicated system to actually work • This can happen remarkably quickly — there is a natural bias to forget the horrors of software development • While it must be done carefully, it is essential that those in formalized leadership positions to continue to directly contribute technically — if only to maintain empathy!
  15. Demotivator: Inability to focus • Especially when one has a team with many superlative engineers, all of the world’s problems become tempting • It can be difficult to maintain focus; tempting to say “yes” to many different problems or opportunities • But focus is not what you do — it’s what you don’t do (if you haven’t yet, see Steve Jobs’ WWDC 1997 Keynote) • Focus cannot be mere rhetoric; at both the individual and organizational levels, must have the ability to say “no” (or “later”)
  16. Demotivator: Autocracy • Recall that superlative engineers are motivated primarily by mission — the “why” is essential • Appeals to authority will fail; “because I said so” (and its many variants) doesn’t actually work • Present engineers with problems, not solutions — even if those problems are organizational or economic • When starting with the problem, a consensus-based decision is nearly always possible among right-thinking engineers...
  17. Demotivator: Shilly-shallying • … but decision making can become too consensus based — there might not be consensus on some issues • Right-thinking engineers fail to achieve consensus for one of two reasons: • The issue is small and boils down to personal style: a decision either needs to be made, or different styles need to be accommodated • There is insufficient data on either side of an issue: need to either gather more data, or pick a path that forecloses the least number of options • The one thing not to do: endless meetings!
  18. Software engineering leadership • The best software engineers — at every level of experience and across personality types — are also natural leaders • Software engineering is an act of divining structure from chaos to chart a path through the unknown: every line of code is a business decision • Recognizing that software engineers are natural leaders changes the way we organize them • One need not have middle management; a flat structure with open communication and flexible teams allows software engineers’ natural leadership to develop
  19. Finding superlative engineers • Three ways to find superlative engineers: • The engineers that have worked with you or your team in the past and are known to be good • Talented, promising university graduates • Individuals in the community who join or work on the open source projects that your team leads • None of these is deterministic; you should work on all three fronts all the time • Open source is your farm system; use it!
  20. Further reading • The Soul of a New Machine by Tracy Kidder • The Rickover Effect: How One Man Made a Difference by Theodore Rockwell • Flight: My Life in Mission Control by Chris Kraft • Skunk Works: A Personal Memoir of My Years of Lockheed by Ben Rich • Empires of Light: Edison, Tesla, Westinghouse, and the Race to Electrify the World by Jill Jonnes