Leadership Without Management:Scaling Organizations by Scaling EngineersSVP, 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