Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Leadership Without Management: Scaling Organizations by Scaling Engineers

Bryan Cantrill
September 13, 2013
64

Leadership Without Management: Scaling Organizations by Scaling Engineers

Bryan Cantrill

September 13, 2013
Tweet

Transcript

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide