Will Larson
Engineering leader and writer; wrote An Elegant Puzzle, Staff Engineer and The Engineering Executive's Primer, and blogs at Irrational Exuberance.
Will Larson did not write this page. What is this?
It collects the places they publish and what they have said there, each linked to the source. They have no account here. Is this you? Claim it, correct it, or ask us to remove it from ppll.
Where they publish
Blog Irrational Exuberance His blog on engineering strategy, management and infrastructure. Has a feed.
Recent
- Trying the Software factory pattern. 20 Sept 2026 One of the interesting challenges of the AI ecosystem in 2026 is that new, effective patterns emerge faster than I can adopt them. I’ll find a handful, get back to work, and realize a month later that I’d mi…
- Roadmap decisions rather than dates. 11 Aug 2026 One thing that bothered me about Imprint’s product after joining was our lack of passkey support. Passkey support is a rare opportunity to increase resiliency to phishing attacks while simultaneously reducing logi…
- Middle management roles are also a trap. 8 Aug 2026 Six years ago, I wrote Tech Lead Management roles are a trap. My argument then was that TLM roles present themselves as easier than moving into a full management role, but the tension between doing the software engineer…
Show 8 more
- Generated and suppressed demand. 11 Jul 2026 Eight years ago, I wrote about my theory of restoring struggling teams, which came down to four steps: A team is falling behind if each week their backlog is longer than the week before. Solve by hiring more. A team is…
- Make no assumptions. 11 Jul 2026 I’ve recently been thinking a lot about the concept of “soil horizons”, which is the idea that there are many distinct layers of soil, from topsoil all the way down to bedrock, which all combine into a…
- Revised rules of engineering leadership. 15 Jun 2026 From early 2014 through late 2020, I was working in hypergrowth environments, which are challenging, but also educational. The most valuable feature of hypergrowth is that your mistakes reveal themselves next month rath…
- Early and late-stage hypergrowth. 27 Apr 2026 Last week, a colleague asked why I’d hired an additional new leader onto an important area rather than expanding an existing leader’s scope to incorporate that area as well. The existing leader was a known q…
- Agents as scaffolding for recurring tasks. 12 Apr 2026 One of my gifts/curses is an endless fixation with how processes can be optimized. For a brief moment early in my career, that was focused on improving how humans collaborate, but that quickly switched to figuring out h…
- The agentic passive voice. 29 Mar 2026 At some point, you will have learned about the passive voice, where the actor in a sentence is unclear. For example, my software didn’t compile. That’s a good example of the passive voice. However, you might…
- Judgment and creativity are all you need. 11 Mar 2026 When I joined Imprint a little less than a year ago, our deploys were manual, requiring close human attention to complete. Our database migrations were run manually, too. Developing good software is very possible in tho…
- Refactoring internal documentation in Notion 5 Feb 2026 In our latest developer productivity survey, our documentation was the area with the second most comments. This is a writeup of the concrete steps I took to see how much progress one person could make on improving the o…
Link verified 20 Sept 2026. Recent items update automatically from the channel.
Beliefs
Korrents What they believe 11 beliefs, 1 changed mind — each backed by an exact quote.
Each is a — compiled by korrents.com, not by them: the one-line wordings are korrents', the quotes are theirs.
Recent
A sustainable on-call rotation needs seven or eight engineers.
Oncall rotations want 8 engineers. For production oncall responsibilities, I’ve found that two-tier 24/7 support requires eight folks.
Sizing engineering teams. Said 14 Jul 2018
An engineering manager should support six to eight engineers: fewer and they drift into being a tech lead, more and they can only be a coach.
Managers 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. Said 14 Jul 2018
A group of fewer than four people is not a team: it behaves like a set of individuals, and a single departure knocks it back into maintenance.
Small 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. Said 14 Jul 2018
Show 8 more
New teams should be budded off an existing team grown deliberately large, never created empty and staffed afterwards.
To 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. Said 14 Jul 2018
Innovation tends to come from slack time away from firefighting, not from being fully utilized.
In 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. Said 17 Jun 2018
A team that is falling behind can only be fixed by hiring more people; no amount of process or patience will move it.
When 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. Said 17 Jun 2018
Fixing an understaffed team by moving people off other teams does not work, because people are not fungible and the argument inevitably turns political.
People 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. Said 17 Jun 2018
Spreading scarce hiring evenly across every team that needs it is indecision dressed as fairness; staff one team to health at a time.
Many 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. Said 17 Jun 2018
A team should grow in bursts followed by periods of consolidation, because continuous hiring never lets it gel.
Adding 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. Said 17 Jun 2018
Organisational fixes are slow because they have to drain years of accumulated state, and that same slowness is what makes them durable once they take.
This 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. Said 17 Jun 2018
Past a certain hiring rate the marginal value of another engineer falls towards nothing, because training and interviewing consume the engineers you already have.
this 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.
Productivity in the age of hypergrowth. Said 10 Oct 2016
Beliefs others hold too
A sustainable on-call rotation needs seven or eight engineers. 2 hold this
Oncall rotations want 8 engineers. For production oncall responsibilities, I’ve found that two-tier 24/7 support requires eight folks.
Sizing engineering teams. Said 14 Jul 2018
Innovation tends to come from slack time away from firefighting, not from being fully utilized. 2 hold this
In 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. Said 17 Jun 2018
What is a korrent?
A korrent is a belief a person has stated in their own words: one sentence stating the claim, backed by a quote and a source, kept at korrents.com.
Under a name here, the quoted block is what they actually said. The korrent beneath it is the claim those words support, in korrents' wording — tap it to see the record, its source, and who else holds it.
Nobody here wrote their own korrents. They are compiled from public statements, and a person can change their mind, which is recorded too.
About the English under a post
Some people here publish in a language other than English. Where they do, this site shows a machine translation beneath the post, in this typeface — the site's own, not theirs.
The post itself is never changed, moved or hidden: what is set in the serif above is exactly what the person published, and it is what to quote them on. A translation can be wrong in ways that matter, especially about tone.
Only the post's own words are translated. A quoted post, a linked article and a belief on korrents.com are left in their original language.