Steering with a lag
October 2026 · leadership, complexity, systems
You run a team of 16 people who pair, so every two of them finish a unit of work a week. Work arrives at 8 units a week and the backlog holds at a healthy month’s worth. Then the work picks up, and once a month you decide whether to hire, move people to another team, or leave things as they are.
Two things lag behind you: the backlog report you get is a month old, and anyone you hire joins two months after you decide.
Month 1 of 12
- Work arriving: 8 units a week (two people do 1)
- Backlog a month ago: 32 units (healthy is 32, a month of work)
- Team: 16 now, 0 on the way
New hires join 2 months after you decide. People you move to another team go at the end of the month. Someone leaves every 2 months.
When the report keeps getting worse, hiring more each month feels like the responsible thing to do. But last month’s hires haven’t arrived yet, and the report hasn’t caught up with them either, so you hire again for the same gap. When they all land, the team is far bigger than the work, you move people off, and the same thing happens in reverse. It’s the trap the beer game is famous for.
The manager you’re compared with follows one rule: work out how many people the work needs, then subtract the team you have and everyone already on the way. They still run behind for months, since nobody joins sooner than two months, but they never act twice on the same old news.
Deciding once a month adds a lag of its own, because whatever you notice has to wait for the next decision.
The model is deliberately simple: everyone is equally productive from day one, nobody needs onboarding, and the work never changes shape. Real lags are longer and messier, which makes counting what’s already coming matter even more.