Team Performance

What it actually means

Team performance sounds like a question about speed. How much does the team get done, and how quickly? That is half of it. The other half is whether the speed survives contact with reality: someone resigns, someone burns out, someone is on a flight with no Wi-Fi when the thing they alone understand breaks.

So the accountability is two things at once. Throughput, which is how much working software the team turns out over a given week. And resilience, which is whether that throughput holds when a person leaves the room. A growing company needs both. Plenty of founders only discover they were missing the second one on the morning it costs them.

Here is the trap. The faster a small team moves, the more tempting it is to let one strong engineer carry everything. They are good, they are quick, they say yes, and the work flows through them. For a while it looks like excellent performance. What you are actually watching is a single point of failure being loaded up, one task at a time, until it is holding the whole product on its back.

The failure mode: bus factor of one

The phrase is grim on purpose. Bus factor of one means exactly one person can keep a critical thing running, and if that person is hit by a bus, the thing stops. You do not need an actual bus. A resignation, a sabbatical, a competing offer, two weeks of flu, a baby. Any of them will do.

You can recognise the pattern without reading a line of code. Every awkward question routes to the same name. Deploys wait for one calendar. Nobody else can explain how billing works, or why the nightly job runs at 2am, or what that one environment variable does. The team has a hero, and the hero is tired.

Hero culture feels like strength from the outside. Inside, it is fragility wearing a cape. The hero becomes a bottleneck because everything needs their sign-off, then a flight risk because they are doing the work of three people, then, eventually, an outage, because they finally took the holiday they were owed and the thing they alone understood fell over while they were gone.

The other half of this failure mode is hiring that never closes. The founder's instinct, when the hero is drowning, is to hire more people. Reasonable. The problem is timing. Hiring is slow, and it has been getting slower. Greenhouse's benchmark data puts the average time-to-fill at 59.7 days in 2025, up from 43.6 days in 2022, a rise of about 37% (Greenhouse). That figure is all roles combined, not engineering specifically, and senior technical roles tend to sit at the long end of any such range. So call it two months at a minimum to even sign someone, before they have written anything you can ship, and before anyone has shown them where the bodies are buried.

Two months is a long time to keep a tired person upright. And a wrong hire under that pressure does not save you. You pay the first-year salary, the ramp time, and then, if it does not work, the cost of unwinding it and starting the search again. Nobody has a clean, citable dollar figure for that, and you should distrust anyone who quotes you one to two decimal places. The point stands without the number: a rushed senior hire to relieve a bus-factor problem can deepen the problem instead of fixing it.

What reliable execution looks like

Good team performance is boring to watch, which is the whole idea. Work moves through more than one pair of hands. Knowledge lives in places other than someone's head. The team's output this week looks a lot like its output last week, and you can plan around that.

The mechanism that gets you there is the same one this book keeps returning to: the task. When work is broken into small, scoped, verifiable units, no single task is large enough to belong to only one person forever. Each task carries its own context. Each one is reviewed by someone who did not write it. That review is not bureaucracy. It is the cheapest insurance you will ever buy against bus factor, because the reviewer learns the thing too, just by checking the work.

Look at the difference in a single ticket. A vague instruction concentrates knowledge in whoever happens to pick it up. A scoped task spreads it, because the context is written down where the next person can read it.

TASK-318  ·  Add per-seat billing to the admin dashboard

Context:    Customers on the Team plan are billed per active seat.
            The current dashboard shows a flat plan price only.
            Seat counts already exist in the `subscriptions` service;
            this task surfaces them, it does not change billing logic.

Scope:      - Show current seat count and per-seat price on the billing page
            - Recalculate the displayed total when seats change
            - Out of scope: invoicing, proration, anything that writes to Stripe

Definition  - Billing page shows seats x price = total, matching the
of done:      subscriptions service for three test accounts
            - Reviewed by someone who did not write it
            - Notes added to the billing section of the team wiki

Acceptance: Founder/PM can open the billing page for a Team-plan
            account and read the correct per-seat total without asking
            an engineer what it means.

Notice what that ticket does to key-person risk. The context is on the page, not in a head. The "reviewed by someone who did not write it" line forces a second person to understand it. The wiki note means a third can find it in six months. None of that is heroics. It is just work shaped so that knowledge has somewhere to go other than one overloaded brain.

Throughput follows from the same discipline. You measure it in finished tasks, not heroic weeks, so a fast fortnight from one exhausted person no longer reads as health. You watch how concentrated the work is: if every task in a fortnight has the same name on it, that is a number trending the wrong way, and you can see it before it becomes an outage. Part IV turns both of these into KPIs you can read on one page, cycle time per task and a measure of key-person concentration. For now, the point is that performance you can rely on is performance that does not depend on any one person staying.

Where this lands

This is the gap a title rarely closes on its own. Putting "Head of Engineering" on an org chart does not by itself spread knowledge across the team, balance the load, or close a two-month hire. Those are execution outcomes. They come from how the work is shaped and run, day to day, not from the seniority of the person nominally in charge of it.

Dev on Demand is built around the unit that does the spreading. Work arrives as tasks, each one scoped, delivered, and approved before the next begins, with the context written down rather than carried in one person's memory. Add a second stream when you need more throughput and the work keeps flowing, because it was never bottlenecked through a single hero to start with. We will come back to the full case in Part IV. The mechanism is the point here: throughput you can count on, without betting the company on one person's continued good health.

A team that ships fast and never stops still has to keep what it shipped running, which is the next accountability: operational reliability.