SlideShare ist ein Scribd-Unternehmen logo
1 von 20
Downloaden Sie, um offline zu lesen
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

Weitere ähnliche Inhalte

Was ist angesagt?

Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey Results
Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey ResultsHands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey Results
Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey ResultsStefan Wolpers
 
Continuous Improvement
Continuous ImprovementContinuous Improvement
Continuous ImprovementAllan Berry
 
Introduction to Agile software testing
Introduction to Agile software testingIntroduction to Agile software testing
Introduction to Agile software testingKMS Technology
 
Time Management
Time ManagementTime Management
Time ManagementASIT
 
How to Run a Value Stream Mapping (VSM) Workshop
How to Run a Value Stream Mapping (VSM) WorkshopHow to Run a Value Stream Mapping (VSM) Workshop
How to Run a Value Stream Mapping (VSM) WorkshopAbraic, Inc.
 
Training - Introducing Agile, Lean and Kanban
Training - Introducing Agile, Lean and KanbanTraining - Introducing Agile, Lean and Kanban
Training - Introducing Agile, Lean and KanbanSudipta Lahiri
 
Business process mapping
Business process mappingBusiness process mapping
Business process mappingNiyati Mehta
 
Agile Framework
Agile FrameworkAgile Framework
Agile FrameworkSubbuiyer
 
Automating With Excel An Object Oriented Approach
Automating  With  Excel    An  Object  Oriented  ApproachAutomating  With  Excel    An  Object  Oriented  Approach
Automating With Excel An Object Oriented ApproachRazorleaf Corporation
 
Getting Things Done Final Submission Group 7
Getting Things Done Final Submission Group 7Getting Things Done Final Submission Group 7
Getting Things Done Final Submission Group 7Sameer Mathur
 
Lean A3 Report for Planning Downtime Elimination
Lean A3 Report for Planning Downtime EliminationLean A3 Report for Planning Downtime Elimination
Lean A3 Report for Planning Downtime EliminationRodrigo André Marques
 
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...DATAVERSITY
 
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)TKMG, Inc.
 
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...Value Stream Transformation: Achieving Excellence through Leadership Alignmen...
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...TKMG, Inc.
 

Was ist angesagt? (20)

Time management
Time managementTime management
Time management
 
Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey Results
Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey ResultsHands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey Results
Hands-on Agile: Agile Maturity—Fad, Trend or Holy Grail—Survey Results
 
Continuous Improvement
Continuous ImprovementContinuous Improvement
Continuous Improvement
 
Introduction to Agile software testing
Introduction to Agile software testingIntroduction to Agile software testing
Introduction to Agile software testing
 
Time Management
Time ManagementTime Management
Time Management
 
Effective Scrum
Effective ScrumEffective Scrum
Effective Scrum
 
Prioritization
PrioritizationPrioritization
Prioritization
 
How to Run a Value Stream Mapping (VSM) Workshop
How to Run a Value Stream Mapping (VSM) WorkshopHow to Run a Value Stream Mapping (VSM) Workshop
How to Run a Value Stream Mapping (VSM) Workshop
 
Training - Introducing Agile, Lean and Kanban
Training - Introducing Agile, Lean and KanbanTraining - Introducing Agile, Lean and Kanban
Training - Introducing Agile, Lean and Kanban
 
Business process mapping
Business process mappingBusiness process mapping
Business process mapping
 
Agile Framework
Agile FrameworkAgile Framework
Agile Framework
 
Automating With Excel An Object Oriented Approach
Automating  With  Excel    An  Object  Oriented  ApproachAutomating  With  Excel    An  Object  Oriented  Approach
Automating With Excel An Object Oriented Approach
 
Sprint review and Retrospective
Sprint review and RetrospectiveSprint review and Retrospective
Sprint review and Retrospective
 
Getting Things Done Final Submission Group 7
Getting Things Done Final Submission Group 7Getting Things Done Final Submission Group 7
Getting Things Done Final Submission Group 7
 
Ways To Improve Personal Productivity
Ways To Improve Personal ProductivityWays To Improve Personal Productivity
Ways To Improve Personal Productivity
 
Lean A3 Report for Planning Downtime Elimination
Lean A3 Report for Planning Downtime EliminationLean A3 Report for Planning Downtime Elimination
Lean A3 Report for Planning Downtime Elimination
 
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...
DAS Slides: Building a Data Strategy - Practical Steps for Aligning with Busi...
 
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)
Value Stream Analysis: Beyond the Mechanics - Part 2 (Mapping Execution)
 
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...Value Stream Transformation: Achieving Excellence through Leadership Alignmen...
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...
 
Lean Process Improvement Techniques
Lean Process Improvement TechniquesLean Process Improvement Techniques
Lean Process Improvement Techniques
 

Andere mochten auch

Down Memory Lane: Two Decades with the Slab Allocator
Down Memory Lane: Two Decades with the Slab AllocatorDown Memory Lane: Two Decades with the Slab Allocator
Down Memory Lane: Two Decades with the Slab Allocatorbcantrill
 
Oral tradition in software engineering: Passing the craft across generations
Oral tradition in software engineering: Passing the craft across generationsOral tradition in software engineering: Passing the craft across generations
Oral tradition in software engineering: Passing the craft across generationsbcantrill
 
The State of Cloud 2016: The whirlwind of creative destruction
The State of Cloud 2016: The whirlwind of creative destructionThe State of Cloud 2016: The whirlwind of creative destruction
The State of Cloud 2016: The whirlwind of creative destructionbcantrill
 
Corporate Open Source Anti-patterns
Corporate Open Source Anti-patternsCorporate Open Source Anti-patterns
Corporate Open Source Anti-patternsbcantrill
 
Papers We Love: Jails and Zones
Papers We Love: Jails and ZonesPapers We Love: Jails and Zones
Papers We Love: Jails and Zonesbcantrill
 
The Container Revolution: Reflections after the first decade
The Container Revolution: Reflections after the first decadeThe Container Revolution: Reflections after the first decade
The Container Revolution: Reflections after the first decadebcantrill
 
Debugging (Docker) containers in production
Debugging (Docker) containers in productionDebugging (Docker) containers in production
Debugging (Docker) containers in productionbcantrill
 
CTO vs. VP of Engineering
CTO vs. VP of EngineeringCTO vs. VP of Engineering
CTO vs. VP of Engineeringbcantrill
 
Pixar's 22 Rules to Phenomenal Storytelling
Pixar's 22 Rules to Phenomenal StorytellingPixar's 22 Rules to Phenomenal Storytelling
Pixar's 22 Rules to Phenomenal StorytellingGavin McMahon
 
The Business State of Node.js 2015
The Business State of Node.js 2015The Business State of Node.js 2015
The Business State of Node.js 2015Joe McCann
 
Engineering Leadership - Vision 101
Engineering Leadership - Vision 101Engineering Leadership - Vision 101
Engineering Leadership - Vision 101Rich Rogers
 
The Peril and Promise of Early Adoption: Arriving 10 Years Early to Containers
The Peril and Promise of Early Adoption: Arriving 10 Years Early to ContainersThe Peril and Promise of Early Adoption: Arriving 10 Years Early to Containers
The Peril and Promise of Early Adoption: Arriving 10 Years Early to Containersbcantrill
 
The DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps PlaybookThe DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps Playbookbcantrill
 
node.js and Containers: Dispatches from the Frontier
node.js and Containers: Dispatches from the Frontiernode.js and Containers: Dispatches from the Frontier
node.js and Containers: Dispatches from the Frontierbcantrill
 
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013Dan Milstein
 
Scaling techniques (unit iv) shradha
Scaling techniques (unit iv)   shradhaScaling techniques (unit iv)   shradha
Scaling techniques (unit iv) shradhaShilpi Vaishkiyar
 

Andere mochten auch (20)

Down Memory Lane: Two Decades with the Slab Allocator
Down Memory Lane: Two Decades with the Slab AllocatorDown Memory Lane: Two Decades with the Slab Allocator
Down Memory Lane: Two Decades with the Slab Allocator
 
Oral tradition in software engineering: Passing the craft across generations
Oral tradition in software engineering: Passing the craft across generationsOral tradition in software engineering: Passing the craft across generations
Oral tradition in software engineering: Passing the craft across generations
 
The State of Cloud 2016: The whirlwind of creative destruction
The State of Cloud 2016: The whirlwind of creative destructionThe State of Cloud 2016: The whirlwind of creative destruction
The State of Cloud 2016: The whirlwind of creative destruction
 
Corporate Open Source Anti-patterns
Corporate Open Source Anti-patternsCorporate Open Source Anti-patterns
Corporate Open Source Anti-patterns
 
Papers We Love: Jails and Zones
Papers We Love: Jails and ZonesPapers We Love: Jails and Zones
Papers We Love: Jails and Zones
 
The Container Revolution: Reflections after the first decade
The Container Revolution: Reflections after the first decadeThe Container Revolution: Reflections after the first decade
The Container Revolution: Reflections after the first decade
 
Debugging (Docker) containers in production
Debugging (Docker) containers in productionDebugging (Docker) containers in production
Debugging (Docker) containers in production
 
CTO vs. VP of Engineering
CTO vs. VP of EngineeringCTO vs. VP of Engineering
CTO vs. VP of Engineering
 
Pixar's 22 Rules to Phenomenal Storytelling
Pixar's 22 Rules to Phenomenal StorytellingPixar's 22 Rules to Phenomenal Storytelling
Pixar's 22 Rules to Phenomenal Storytelling
 
The Business State of Node.js 2015
The Business State of Node.js 2015The Business State of Node.js 2015
The Business State of Node.js 2015
 
Engineering Leadership - Vision 101
Engineering Leadership - Vision 101Engineering Leadership - Vision 101
Engineering Leadership - Vision 101
 
The Peril and Promise of Early Adoption: Arriving 10 Years Early to Containers
The Peril and Promise of Early Adoption: Arriving 10 Years Early to ContainersThe Peril and Promise of Early Adoption: Arriving 10 Years Early to Containers
The Peril and Promise of Early Adoption: Arriving 10 Years Early to Containers
 
The DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps PlaybookThe DIY Punk Rock DevOps Playbook
The DIY Punk Rock DevOps Playbook
 
node.js and Containers: Dispatches from the Frontier
node.js and Containers: Dispatches from the Frontiernode.js and Containers: Dispatches from the Frontier
node.js and Containers: Dispatches from the Frontier
 
Scaling
ScalingScaling
Scaling
 
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013
How to Run a Post-Mortem (With Humans, Not Robots), Velocity 2013
 
Scaling techniques (unit iv) shradha
Scaling techniques (unit iv)   shradhaScaling techniques (unit iv)   shradha
Scaling techniques (unit iv) shradha
 
Measurement levels
Measurement levelsMeasurement levels
Measurement levels
 
Agile Experience Design Framework
Agile Experience Design FrameworkAgile Experience Design Framework
Agile Experience Design Framework
 
Access by Default
Access by DefaultAccess by Default
Access by Default
 

Ähnlich wie Leadership Without Management: Scaling Organizations by Scaling Engineers

Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Codemotion
 
Should the CTO be coding?
Should the CTO be coding?Should the CTO be coding?
Should the CTO be coding?JoshuaHoffman32
 
Conquering Chaos: Helix & DevOps
Conquering Chaos: Helix & DevOpsConquering Chaos: Helix & DevOps
Conquering Chaos: Helix & DevOpsPerforce
 
Startup Operating Systems
Startup Operating SystemsStartup Operating Systems
Startup Operating SystemsDean Haritos
 
The Lean Enterprise
The Lean EnterpriseThe Lean Enterprise
The Lean EnterpriseRyan Dorrell
 
2017 VMUG UserCon Presentation (IT Culture & DevOps)
2017 VMUG UserCon Presentation (IT Culture & DevOps)2017 VMUG UserCon Presentation (IT Culture & DevOps)
2017 VMUG UserCon Presentation (IT Culture & DevOps)Jon Hildebrand
 
Agile Experience In Complex Projects
Agile Experience In Complex ProjectsAgile Experience In Complex Projects
Agile Experience In Complex ProjectsBorys Lebeda
 
Scale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlScale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlAtlassian
 
How to shine in a Tech DD
How to shine in a Tech DDHow to shine in a Tech DD
How to shine in a Tech DDChris Philipps
 
Leading Software Development Teams
Leading Software Development TeamsLeading Software Development Teams
Leading Software Development TeamsArno Huetter
 
From Technical Debt to Technical Health
From Technical Debt to Technical HealthFrom Technical Debt to Technical Health
From Technical Debt to Technical HealthDeclan Whelan
 
The Content Revolution: Managing the Move to a CCMS
The Content Revolution: Managing the Move to a CCMSThe Content Revolution: Managing the Move to a CCMS
The Content Revolution: Managing the Move to a CCMSIXIASOFT
 
How to hire and keep engineers happy public
How to hire and keep engineers happy publicHow to hire and keep engineers happy public
How to hire and keep engineers happy publicPiaw Na
 
Perspectives on salesforce architecture Forcelandia talk 2017
Perspectives on salesforce architecture   Forcelandia talk 2017Perspectives on salesforce architecture   Forcelandia talk 2017
Perspectives on salesforce architecture Forcelandia talk 2017Steven Herod
 
VMUG UserCon Presentation for 2018
VMUG UserCon Presentation for 2018VMUG UserCon Presentation for 2018
VMUG UserCon Presentation for 2018Jon Hildebrand
 
Tech Leads: What is it, do I want it and how to get there
Tech Leads: What is it, do I want it and how to get thereTech Leads: What is it, do I want it and how to get there
Tech Leads: What is it, do I want it and how to get thereYuval Kesten
 

Ähnlich wie Leadership Without Management: Scaling Organizations by Scaling Engineers (20)

Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 
Should the CTO be coding?
Should the CTO be coding?Should the CTO be coding?
Should the CTO be coding?
 
Conquering Chaos: Helix & DevOps
Conquering Chaos: Helix & DevOpsConquering Chaos: Helix & DevOps
Conquering Chaos: Helix & DevOps
 
Lec 19
Lec 19Lec 19
Lec 19
 
Startup Operating Systems
Startup Operating SystemsStartup Operating Systems
Startup Operating Systems
 
The Lean Enterprise
The Lean EnterpriseThe Lean Enterprise
The Lean Enterprise
 
2017 VMUG UserCon Presentation (IT Culture & DevOps)
2017 VMUG UserCon Presentation (IT Culture & DevOps)2017 VMUG UserCon Presentation (IT Culture & DevOps)
2017 VMUG UserCon Presentation (IT Culture & DevOps)
 
Agile Experience In Complex Projects
Agile Experience In Complex ProjectsAgile Experience In Complex Projects
Agile Experience In Complex Projects
 
Scale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing ControlScale at Reddit: Triple Your Team Size Without Losing Control
Scale at Reddit: Triple Your Team Size Without Losing Control
 
How to shine in a Tech DD
How to shine in a Tech DDHow to shine in a Tech DD
How to shine in a Tech DD
 
Leading Software Development Teams
Leading Software Development TeamsLeading Software Development Teams
Leading Software Development Teams
 
From Technical Debt to Technical Health
From Technical Debt to Technical HealthFrom Technical Debt to Technical Health
From Technical Debt to Technical Health
 
Suresh babu
Suresh babuSuresh babu
Suresh babu
 
Computing DevOp Summit
Computing DevOp SummitComputing DevOp Summit
Computing DevOp Summit
 
The Content Revolution: Managing the Move to a CCMS
The Content Revolution: Managing the Move to a CCMSThe Content Revolution: Managing the Move to a CCMS
The Content Revolution: Managing the Move to a CCMS
 
How to hire and keep engineers happy public
How to hire and keep engineers happy publicHow to hire and keep engineers happy public
How to hire and keep engineers happy public
 
october_webinar_project_slides.PDF
october_webinar_project_slides.PDFoctober_webinar_project_slides.PDF
october_webinar_project_slides.PDF
 
Perspectives on salesforce architecture Forcelandia talk 2017
Perspectives on salesforce architecture   Forcelandia talk 2017Perspectives on salesforce architecture   Forcelandia talk 2017
Perspectives on salesforce architecture Forcelandia talk 2017
 
VMUG UserCon Presentation for 2018
VMUG UserCon Presentation for 2018VMUG UserCon Presentation for 2018
VMUG UserCon Presentation for 2018
 
Tech Leads: What is it, do I want it and how to get there
Tech Leads: What is it, do I want it and how to get thereTech Leads: What is it, do I want it and how to get there
Tech Leads: What is it, do I want it and how to get there
 

Mehr von bcantrill

Predicting the Present
Predicting the PresentPredicting the Present
Predicting the Presentbcantrill
 
Sharpening the Axe: The Primacy of Toolmaking
Sharpening the Axe: The Primacy of ToolmakingSharpening the Axe: The Primacy of Toolmaking
Sharpening the Axe: The Primacy of Toolmakingbcantrill
 
Coming of Age: Developing young technologists without robbing them of their y...
Coming of Age: Developing young technologists without robbing them of their y...Coming of Age: Developing young technologists without robbing them of their y...
Coming of Age: Developing young technologists without robbing them of their y...bcantrill
 
I have come to bury the BIOS, not to open it: The need for holistic systems
I have come to bury the BIOS, not to open it: The need for holistic systemsI have come to bury the BIOS, not to open it: The need for holistic systems
I have come to bury the BIOS, not to open it: The need for holistic systemsbcantrill
 
Towards Holistic Systems
Towards Holistic SystemsTowards Holistic Systems
Towards Holistic Systemsbcantrill
 
The Coming Firmware Revolution
The Coming Firmware RevolutionThe Coming Firmware Revolution
The Coming Firmware Revolutionbcantrill
 
Hardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden AgeHardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden Agebcantrill
 
Tockilator: Deducing Tock execution flows from Ibex Verilator traces
Tockilator: Deducing Tock execution flows from Ibex Verilator tracesTockilator: Deducing Tock execution flows from Ibex Verilator traces
Tockilator: Deducing Tock execution flows from Ibex Verilator tracesbcantrill
 
No Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's LawNo Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's Lawbcantrill
 
Andreessen's Corollary: Ethical Dilemmas in Software Engineering
Andreessen's Corollary: Ethical Dilemmas in Software EngineeringAndreessen's Corollary: Ethical Dilemmas in Software Engineering
Andreessen's Corollary: Ethical Dilemmas in Software Engineeringbcantrill
 
Visualizing Systems with Statemaps
Visualizing Systems with StatemapsVisualizing Systems with Statemaps
Visualizing Systems with Statemapsbcantrill
 
Platform values, Rust, and the implications for system software
Platform values, Rust, and the implications for system softwarePlatform values, Rust, and the implications for system software
Platform values, Rust, and the implications for system softwarebcantrill
 
Is it time to rewrite the operating system in Rust?
Is it time to rewrite the operating system in Rust?Is it time to rewrite the operating system in Rust?
Is it time to rewrite the operating system in Rust?bcantrill
 
dtrace.conf(16): DTrace state of the union
dtrace.conf(16): DTrace state of the uniondtrace.conf(16): DTrace state of the union
dtrace.conf(16): DTrace state of the unionbcantrill
 
The Hurricane's Butterfly: Debugging pathologically performing systems
The Hurricane's Butterfly: Debugging pathologically performing systemsThe Hurricane's Butterfly: Debugging pathologically performing systems
The Hurricane's Butterfly: Debugging pathologically performing systemsbcantrill
 
Papers We Love: ARC after dark
Papers We Love: ARC after darkPapers We Love: ARC after dark
Papers We Love: ARC after darkbcantrill
 
Principles of Technology Leadership
Principles of Technology LeadershipPrinciples of Technology Leadership
Principles of Technology Leadershipbcantrill
 
Zebras all the way down: The engineering challenges of the data path
Zebras all the way down: The engineering challenges of the data pathZebras all the way down: The engineering challenges of the data path
Zebras all the way down: The engineering challenges of the data pathbcantrill
 
Platform as reflection of values: Joyent, node.js, and beyond
Platform as reflection of values: Joyent, node.js, and beyondPlatform as reflection of values: Joyent, node.js, and beyond
Platform as reflection of values: Joyent, node.js, and beyondbcantrill
 
Debugging under fire: Keeping your head when systems have lost their mind
Debugging under fire: Keeping your head when systems have lost their mindDebugging under fire: Keeping your head when systems have lost their mind
Debugging under fire: Keeping your head when systems have lost their mindbcantrill
 

Mehr von bcantrill (20)

Predicting the Present
Predicting the PresentPredicting the Present
Predicting the Present
 
Sharpening the Axe: The Primacy of Toolmaking
Sharpening the Axe: The Primacy of ToolmakingSharpening the Axe: The Primacy of Toolmaking
Sharpening the Axe: The Primacy of Toolmaking
 
Coming of Age: Developing young technologists without robbing them of their y...
Coming of Age: Developing young technologists without robbing them of their y...Coming of Age: Developing young technologists without robbing them of their y...
Coming of Age: Developing young technologists without robbing them of their y...
 
I have come to bury the BIOS, not to open it: The need for holistic systems
I have come to bury the BIOS, not to open it: The need for holistic systemsI have come to bury the BIOS, not to open it: The need for holistic systems
I have come to bury the BIOS, not to open it: The need for holistic systems
 
Towards Holistic Systems
Towards Holistic SystemsTowards Holistic Systems
Towards Holistic Systems
 
The Coming Firmware Revolution
The Coming Firmware RevolutionThe Coming Firmware Revolution
The Coming Firmware Revolution
 
Hardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden AgeHardware/software Co-design: The Coming Golden Age
Hardware/software Co-design: The Coming Golden Age
 
Tockilator: Deducing Tock execution flows from Ibex Verilator traces
Tockilator: Deducing Tock execution flows from Ibex Verilator tracesTockilator: Deducing Tock execution flows from Ibex Verilator traces
Tockilator: Deducing Tock execution flows from Ibex Verilator traces
 
No Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's LawNo Moore Left to Give: Enterprise Computing After Moore's Law
No Moore Left to Give: Enterprise Computing After Moore's Law
 
Andreessen's Corollary: Ethical Dilemmas in Software Engineering
Andreessen's Corollary: Ethical Dilemmas in Software EngineeringAndreessen's Corollary: Ethical Dilemmas in Software Engineering
Andreessen's Corollary: Ethical Dilemmas in Software Engineering
 
Visualizing Systems with Statemaps
Visualizing Systems with StatemapsVisualizing Systems with Statemaps
Visualizing Systems with Statemaps
 
Platform values, Rust, and the implications for system software
Platform values, Rust, and the implications for system softwarePlatform values, Rust, and the implications for system software
Platform values, Rust, and the implications for system software
 
Is it time to rewrite the operating system in Rust?
Is it time to rewrite the operating system in Rust?Is it time to rewrite the operating system in Rust?
Is it time to rewrite the operating system in Rust?
 
dtrace.conf(16): DTrace state of the union
dtrace.conf(16): DTrace state of the uniondtrace.conf(16): DTrace state of the union
dtrace.conf(16): DTrace state of the union
 
The Hurricane's Butterfly: Debugging pathologically performing systems
The Hurricane's Butterfly: Debugging pathologically performing systemsThe Hurricane's Butterfly: Debugging pathologically performing systems
The Hurricane's Butterfly: Debugging pathologically performing systems
 
Papers We Love: ARC after dark
Papers We Love: ARC after darkPapers We Love: ARC after dark
Papers We Love: ARC after dark
 
Principles of Technology Leadership
Principles of Technology LeadershipPrinciples of Technology Leadership
Principles of Technology Leadership
 
Zebras all the way down: The engineering challenges of the data path
Zebras all the way down: The engineering challenges of the data pathZebras all the way down: The engineering challenges of the data path
Zebras all the way down: The engineering challenges of the data path
 
Platform as reflection of values: Joyent, node.js, and beyond
Platform as reflection of values: Joyent, node.js, and beyondPlatform as reflection of values: Joyent, node.js, and beyond
Platform as reflection of values: Joyent, node.js, and beyond
 
Debugging under fire: Keeping your head when systems have lost their mind
Debugging under fire: Keeping your head when systems have lost their mindDebugging under fire: Keeping your head when systems have lost their mind
Debugging under fire: Keeping your head when systems have lost their mind
 

Kürzlich hochgeladen

Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesThousandEyes
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServiceRenan Moreira de Oliveira
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?SANGHEE SHIN
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdfJamie (Taka) Wang
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceMartin Humpolec
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum ComputingGDSC PJATK
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIUdaiappa Ramachandran
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataSafe Software
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.francesco barbera
 

Kürzlich hochgeladen (20)

Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyesHow to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
How to Effectively Monitor SD-WAN and SASE Environments with ThousandEyes
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your Salesforce
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum Computing
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AI
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.
 

Leadership Without Management: Scaling Organizations by Scaling Engineers

  • 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