Will Larson
Engineering executive who has led infrastructure and engineering organisations at Stripe, Calm, Carta and Imprint, and previously at Uber and Digg. Author of "An Elegant Puzzle", "Staff Engineer", "The Engineering Executive’s Primer" and "Crafting Engineering Strategy". Writes about organisational design at lethain.com.
Will Larson did not write this page.
We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.
Filter All topics · Newest first
-
Their wordsManagers should support 6-8 engineers. This gives them enough time for active coaching, coordinating and furthering their team’s mission by writing strategies, leading change, and so on.
↗Sizing engineering teams.lethain.com 1st of 5 in this piece
-
Their wordsOncall rotations want 8 engineers. For production oncall responsibilities, I’ve found that two-tier 24/7 support requires eight folks.
↗Sizing engineering teams.lethain.com 2nd of 5 in this piece
-
Their wordsSmall teams (<4) are not teams. I’ve sponsored quite a few 1-2 person teams, and each time I’ve regretted it. To repeat: I have regretted it every single time.
↗Sizing engineering teams.lethain.com 3rd of 5 in this piece
-
Their wordsTo create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five. Never create empty teams.
↗Sizing engineering teams.lethain.com 5th of 5 in this piece
- 4 weeks earlier
-
Their wordsWhen falling behind, the system fix is to hire more people until the team moves into treading water.
↗Staying on the path to high performing teams.lethain.com 1st of 6 in this piece
-
Their wordsPeople are not fungible, and generally folks end up in useful places, so I’m skeptical of reassigning existing folks to drive optimality.
↗Staying on the path to high performing teams.lethain.com 2nd of 6 in this piece
-
Our reading
Innovation tends to come from slack time away from firefighting, not from being fully utilized.
Their wordsIn this case, it’s to maintain enough slack in your team’s schedule that the team can build quality into their work, and operating continuously in innovation, and avoid backtracking.
↗Staying on the path to high performing teams.lethain.com 3rd of 6 in this piece
-
Their wordsThis is because systems accumulate months or years of state, and you have to drain that all away. Conversely, the same properties that make them slow to fix make them extremely durable once in effect!
↗Staying on the path to high performing teams.lethain.com 4th of 6 in this piece
-
Their wordsMany folks try to move all teams at the same time, peanut buttering their limited resources, but resist that indecision-framed-as-fairness: no one getting anything is not a fair outcome.
↗Staying on the path to high performing teams.lethain.com 5th of 6 in this piece
-
Their wordsAdding new folks to a team disrupts that team’s gelling process, so I’ve found it much easier to have rapid growth periods for any given team followed by consolidation/gelling periods where the team gels.
↗Staying on the path to high performing teams.lethain.com 6th of 6 in this piece
- 20 months earlier
-
Their wordsthis is where the oft raised concern that hiring is slowing us down comes from: at high enough rates, the marginal added value of hiring gets very slow, especially if your training process is weak.