Leadership Without Management: Scaling Organizations by Scaling Engineers SVP, Engineering [email protected] Bryan Cantrill @bcantrill

Software Engineering Middle Management: Toxin or Cancer? SVP, Engineering [email protected] Bryan Cantrill @bcantrill

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!

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

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?

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!

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!

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!

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

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!

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

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!

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

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!

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”)

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...

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!

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

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!

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