Two engineering teams in the same company were handed similar projects in the same quarter. Both had capable people, similar tooling and the same deadline. One team shipped quietly, a day early. The other shipped three weeks late, after a month of weekend work. People like to say the difference was talent or luck. When you compare how each team treated their delivery plan, a simpler explanation appears. One team planned with delivery buffers. The other planned with none. Here is a side-by-side look at both, told through the people who lived it.
Meet the two teams
Team Tight was proud of its discipline. Its lead had come from a consultancy where utilisation was everything, and he believed an empty calendar slot was a failure of planning. Every sprint was filled, every handoff scheduled for the very next morning, and the release date was set by working backwards from the contract.
Team Roomy looked, from the outside, a little less ambitious. Its lead had once been burned by a failed go-live and had developed a habit: after any dependency on another team or an external party, she left a gap. She called these gaps “air”. Her board showed them as grey rows, and a note at the top said grey rows were not to be filled.
Round one: the first surprise
In week three, both teams hit the same problem. A shared test environment was unavailable for two days because another group had taken it for a performance run.
For Team Tight, this was a crisis. Testing could not start, so the work scheduled behind it slid. Developers moved to side tasks, but those tasks were not planned, and the team lost most of the two days to context switching. For Team Roomy, the same outage landed in a grey row. Testing moved two days into the gap and everything downstream kept its date. The lead told the team about it in the daily meeting, noted that half of one gap was spent, and moved on.
Round two: the approval
The second surprise came in week six, when a security review took longer than expected. Team Tight had slotted it for a single day. The reviewer was away, so it took six. By then, the team had already booked its deployment window and had to forfeit it, pushing the release to the next window two weeks later.
Team Roomy had assumed that reviews like this one often slip and had set aside several days. Their review finished within the gap. They kept their deployment window.
Round three: the pressure to cut
This is where the comparison becomes uncomfortable. A senior manager looked at Team Roomy’s plan and asked why there were so many grey rows. A tighter plan, he suggested, would show commitment. Team Roomy’s lead answered with a table from her own log: for each of the last four releases, how many days of slack had been consumed and what would have happened without them. The manager read it twice and went away. The grey rows stayed.
Team Tight, on the other hand, had no such log. It had a story about heroics. The heroics were real, and so was the burnout. Two people left the following quarter.
Side by side
- Handling of dependencies: Tight treated them as tasks. Roomy treated them as risks and placed gaps after them.
- Visibility: Tight hid padding inside estimates, then removed it under pressure. Roomy showed buffers as separate rows that anyone could see.
- Response to delay: Tight re-planned from scratch. Roomy drew on a named gap and carried on.
- Cost of slack: Roomy’s plan looked about a week longer on paper. Tight’s looked shorter and ended three weeks longer.
- Team health: Roomy’s people kept their weekends. Tight’s did not.
Does the pattern hold in specialised work?
You might think this applies only to ordinary software, but specialised work shows the same effect. Machine learning delivery, for instance, depends on data availability, training runs and model reviews, each of which can slip. Material like an account of how MLOps speeds up machine learning deployments shows how much coordination sits between a trained model and a live one, and a practical roadmap for data scientists and engineering teams adopting MLOps lays out stages that benefit from deliberate gaps. In every case, the joins between stages, not the stages themselves, set the real delivery date.
What the comparison does not prove
It is worth being fair. A buffer will not save a team with a bad scope or an unclear goal. It will not help if people consume the gaps without noticing. And a plan stuffed with too much slack can lull a team into a leisurely pace that wastes actual capacity. The comparison above shows a pattern, not a law, and the two teams differed in other ways too.
Still, in the cases where slack is the missing ingredient, the difference is hard to miss. If you find yourself with a plan that looks perfect and keeps failing, the likelier culprit is a lack of room around the joins, not a lack of effort.
Beyond the office
The same contrast shows up in personal plans. Anyone who has organised a trip abroad for care knows how many dependencies exist: appointments, flights, visas, paperwork, lodging. A person comparing facilitators might land on a medical tourism service whose website is arranged by country, with hospital and doctor listings and an appointment request page. Planning that journey the Roomy way means spare days around the flights and an allowance for documents to arrive late. To be clear, this concerns logistics alone; medical questions belong to qualified professionals.
Which team would you rather join?
Ask people this question and most answer Team Roomy immediately. Yet when they build their own plans, many still behave like Team Tight. The pull is understandable: a tight plan feels responsible, and a gap feels like waste. The evidence from these two teams points the other way.
If you want to move toward the Roomy approach without a dramatic reform, begin small. Add one named gap after the single riskiest dependency in your next plan. Track whether it is used. Show the result to whoever asks why the plan has an empty row. One success tends to buy a second, and in a quarter or two the grey rows become part of how your team works.