The document discusses scaling engineering organizations by focusing on high-performing engineers and the demotivators that can arise in such environments, including formalized reviews, hierarchical titles, and non-technical management. It emphasizes that top engineers are driven more by mission and team dynamics than by compensation, and highlights the importance of supportive organizational structures. Furthermore, it offers strategies for attracting and retaining top talent while advocating for a flat organizational structure that allows engineers to lead naturally.

1. Leadership Without
Management:
Scaling Organizations by
Scaling Engineers
SVP, Engineering
bryan@joyent.com
Bryan Cantrill
@bcantrill

2. Software Engineering
Middle Management:
Toxin or Cancer?
SVP, Engineering
bryan@joyent.com
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