Are two heads better than one? The Team Productivity Simulator
You have five people and five projects. Give everyone their own, or put two people on each of the bigger ones and let one person take the smallest? Pairs lose some time to talking, maybe 15β20%, but they also review each other, cover for each other and catch each other's mistakes. So who ships first? This simulator plays out hundreds of possible futures, complete with sick days, interruptions, missed estimates, different ways of working and AI, using numbers from published research.
π― What we mean by a pair: two people building the same thing together, splitting the work, talking it through and reviewing each other's changes. Not two people sharing one keyboard (that's pair programming, from Extreme Programming).
Crunching hundreds of futuresβ¦
π’ The office floor
A replay of one typical future (the middle one). Watch for sick days, stalled projects, bug fixing and launches.
π Progress over time
The line is the typical outcome; the shaded band covers 80% of futures.
π Projects shipped
Projects released over time in the typical future. Shipping something early means value starts arriving sooner.
ποΈ Who worked on what, when
When each project started and shipped in the typical future. Hover to see stalls and how many people worked on it.
π² How sure are we?
How the results spread across every simulated future.
βοΈ How much talking can pairs afford?
We slide the coordination tax from 0% to 50%. Watch where the lines cross: that's where the winner flips.
π© Where the time went
Every person-day lands in exactly one bucket. Meetings on the calendar and ad-hoc conversations are counted separately.
Show every bucket as a table
π DORA-style delivery metrics
Rough estimates worked out from the simulation, graded roughly against the DORA 2024 tiers. How we work these out
π€ AI or no AI?
Each scenario with and without AI. Bars are the typical result; whiskers cover P10βP85.
πͺοΈ What actually matters?
We push each assumption to the low and high end of what's plausible, one at a time. β οΈ means it can flip the answer.
π§ Myth vs. data
π Time buckets, defined
The buckets don't overlap and always add up to 100% of everyone's time. That's what keeps the comparison fair.
π¬ Method & sources
How the model works
- We simulate the team one working day at a time, hundreds of times over, with random sick days, interruptions and estimate misses (a Monte Carlo simulation). Charts show the typical (median) result with a P10βP90 band. The random seed is saved in the link, so anyone you share it with sees the same numbers.
- A pair is two people building the same thing: splitting the work, talking it through and reviewing each other. It isn't two people at one keyboard. Pair-programming studies are the closest measurement we have, so they set the starting point for the coordination tax.
- Real effort is the estimate times a random (lognormal) overrun. Sickness comes in 1β3 day bouts, and a project with nobody in stalls.
- The coordination tax only applies when two or more people work on the same project that day. In return, they review each other's work as they go, already knowing the code.
- Work done alone needs a reviewer from another project. Their time comes out of everyone else's day, plus extra time to get into an unfamiliar project and back into their own (counted as context switching). The change also waits for that reviewer, which adds to lead time.
- With AI, everyone writes more code, so there's more to review: the extra review lands on solo work's reviewers and on pairs alike, and the wait for a reviewer grows with it.
- The quality score (our tie-breaker) turns the simulated change failure rate into 0β100: 100 at 0%, 0 at DORA's low-tier 40%. Gaps under 2 points are treated as noise.
- Rework comes after "done". There's less of it when two people share the work (rubber ducking and reviewing as they go), more or less with AI depending on the profile, and more when a way of working finds bugs late.
- Value only counts once a project is released, on the scenario's release schedule: several times a day for Kanban, every sprint for Scrum, every PI for SAFe, quarterly for Waterfall.
- People who finish pick up the next project. If there isn't one, they join the project with the most work left, start slow while they get up to speed, and add coordination for everyone already on it (Brooks). In "What ships in N months", teams that finish pick up new projects of a similar size.
- DORA panel (rough estimates):
- Work is split into ~2 person-day items, and deploys follow the release schedule.
- Lead time = time to build an item + waiting for review + waiting for the next release.
- Change failure rate β rework rate, nudged up for bigger releases.
- Recovery time is a baseline per way of working, longer when only one person knows the code.
This is a model, not a crystal ball. Use it to find out which assumptions your decision hinges on, then go and measure those in your own team.
Sources
Want this for your team?
Mossa Labs helps engineering leaders measure what matters, from DORA to team topology to AI adoption, and turn it into decisions.