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