Leadership Without Management: Scaling Organizations by Scaling Engineers

Transcript

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

   View Slide

2. Software Engineering
   Middle Management:
   Toxin or Cancer?
   SVP, Engineering
   bryan@joyent.com
   Bryan Cantrill
   @bcantrill
   

   View Slide

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!
   

   View Slide

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
   

   View Slide

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?
   

   View Slide

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!
   

   View Slide

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!
   

   View Slide

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!
   

   View Slide

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
   

   View Slide

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!
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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

    View Slide

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

    View Slide

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!
    

    View Slide

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
    

    View Slide

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!
    

    View Slide

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
    

    View Slide