Leadership Without Management: Scaling Organizations by Scaling Engineers
Upcoming SlideShare
Loading in...5
×
 

Leadership Without Management: Scaling Organizations by Scaling Engineers

on

  • 44,205 views

My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.

My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.

Statistics

Views

Total Views
44,205
Views on SlideShare
42,559
Embed Views
1,646

Actions

Likes
139
Downloads
353
Comments
11

27 Embeds 1,646

https://twitter.com 728
http://emba.mybeebac.com 177
http://emba2.mybeebac.com 173
http://www.redditmedia.com 143
https://my.zyncro.com 101
http://www.bwigg.com 88
http://www.scoop.it 76
http://www.waffleme.com 39
http://emba.beechannels.com 29
http://dromologue.com 27
http://lvh.me 24
https://www.xing.com 7
http://moderation.local 6
https://binc.bloomfire.com 6
https://www.linkedin.com 3
http://translate.googleusercontent.com 2
http://kmlshopping.com 2
http://new-twinspace.etwinning.net 2
http://www.onlydoo.com 2
https://www.google.co.il 2
https://web.tweetdeck.com 2
http://gazeta.yandex.ru 2
https://www.rebelmouse.com 1
http://tweetedtimes.com 1
http://iblunk.com 1
http://dooshr.com 1
http://www.linkedin.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

110 of 11 Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • For those that dislike the youtube sidebars, here is the quietube link.

    http://quietube6.com/v.php/http://www.youtube.com/watch?v=bGkVM1B5NuI
    Are you sure you want to
    Your message goes here
    Processing…
  • The slides are the Rated G version of the video of this presentation, which is now online: http://www.youtube.com/watch?v=bGkVM1B5NuI
    Are you sure you want to
    Your message goes here
    Processing…
  • @patscherer Glad you liked it! And yes, you're (definitely) right about working two jobs -- and somewhat incompatible ones at that. What I would say in response is that the presence of one job (technical contribution) keeps the demands of the second one ('people manager') to a minimum. No one has less tolerance for BS make-work than someone with something else to do! Even so, I don't deny that this is (1) hard and (2) rife with failure modes. (In particular, you always have to be ready to table technical work to deal with HR issues.) Speaking of which, my build is done -- back to work! ;)
    Are you sure you want to
    Your message goes here
    Processing…
  • My english is not good, but I want to say 'thank you'
    Are you sure you want to
    Your message goes here
    Processing…
  • Josh - you can find some great articles by Deming and more modern articles in the Agile community which address the issues of ranking your question about what to do instead. Ranking creates a competitive environment that tends to undermine cooperation. There is also an issue that the criteria for ranking is frequently unclear and managed unevenly. For example, one department may have all poor performers while another has all top performers. If a company had a policy of cutting the bottom 10% of each department, which department would you choose to work in? If you had an influence on hiring, would you hire someone with greater skills to your own or lesser skills? I've witnessed companies deteriorate in this way due to the stack ranking practice.

    There are many alternatives. One is to establish clear criteria for individual and team success that will motivate the behaviors you want to cultivate. Another is to build accountability to the team through team goals and team rewards and leave out individual appraisals..
    Are you sure you want to
    Your message goes here
    Processing…

110 of 11

Post Comment
Edit your comment

    Leadership Without Management: Scaling Organizations by Scaling Engineers Leadership Without Management: Scaling Organizations by Scaling Engineers Presentation Transcript

    • Leadership Without Management: Scaling Organizations by Scaling Engineers SVP, Engineering bryan@joyent.com Bryan Cantrill @bcantrill
    • Software Engineering Middle Management: Toxin or Cancer? SVP, Engineering bryan@joyent.com Bryan Cantrill @bcantrill
    • 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!
    • 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
    • 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?
    • 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!
    • 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!
    • 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!
    • 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
    • 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!
    • 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
    • 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!
    • 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
    • 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!
    • 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”)
    • 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...
    • 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!
    • 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
    • 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!
    • 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