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!
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
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 ﬁnd superlative engineers?
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!
(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!
annual review is the wrong kind of feedback and at the wrong cadence • For top performers, this only serves to ﬁxate 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!
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 ﬁnd 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
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-fulﬁlling prophesy: if one has more than the set percentage of top performers, the lower-ranked top performers will do you the favor of leaving!
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
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!
Winslow Taylor: the ﬁxation 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
which is formerly technical • They often retain the conﬁdence 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!
team with many superlative engineers, all of the world’s problems become tempting • It can be difﬁcult 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”)
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...
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 insufﬁcient 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!
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 ﬂat structure with open communication and ﬂexible teams allows software engineers’ natural leadership to develop
• 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!
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