In an interview, I got the standard question “How did you rescue a project that got off-track?”  I gave my answer, presenting it as me guiding the engineering team to work together to achieve the solution. Then the question was rephrased as “But how did you, just you yourself, solve this problem?”

Interviewers ask the questions they need to determine candidate fit, of course.  But I am uncomfortable with that framing because for me, as a fundamental principle of software development:

The unit of software delivery is the team.

This isn’t just my heresy – Dave Farley, Charity Majors, Bob Marshall, Russ Miles, Tim Ottinger and Daniel Terhorst-North, have all made this point (citations with links below).

This means I don’t want to be the superhero who single-handedly saves the day. That’s lonely and boring and doesn’t scale. I want to be the person who works with teams collaboratively and builds solutions together. That’s not only much more fun (and therefore more sustainable), it also scales much better.

I heard the term “continuous learning” recently for the first time in a very long time and I want that, too. I want to work with teams that are learning and sharing together and enjoying it.

For that to be possible, I need a company that agrees that the unit of software delivery is the team, and that therefore doesn’t incentivize based on individual performance metrics because (as both common sense and Bob Marshall’s article cited below show) that disincentivizes teamwork: why work as a team if it’s a zero-sum game, and if one person wins everyone else loses? I want a company that incentivizes teamwork, not just with words – saying “we value teamwork” but not doing anything else differently is not enough – but in its behaviour and structures.

This isn’t just good for the individuals, it creates better results for companies as well. Setting up a system where people want to work together unlocks superpowers.

As Russ Miles puts it, better than I could:

The Foreman’s eyes narrowed. “Teams cannot be rewarded. Only individuals can be compared.”

“And that,” Case said, “is why you will never have sustainable excellence. Only exhausted saints and fragile miracles.”

The Lone Genius, who had been scowling, suddenly spoke with a hint of panic. “But… if we do it together,” he said, “then I am not special.”

Case looked at him with something almost kind. “You might become something better,” she said. “Kind, and helpful.”

I want the sustainable excellence. I want the kindness and helpfulness. I want the company that recognizes that the unit of software delivery is the team.

(Added because it’s 2026: but doesn’t AI make all that irrelevant? Separate topic, but no, it doesn’t. More on that in a bit.)

Appendices:

What, No Developer Performance Metrics At All?

Kent Beck, in his great talk The Forest & The Desert Are Parallel Universes, talks about how developer performance metrics can be useful when they’re used for self-awareness and learning at the individual or team level. We tried this experiment, what happened? You’ll want metrics for that. You don’t want them surfaced to upper management if management is going to use them to punish people for trying experiments (which result in learnings which may well speed everyone up later, but that doesn’t show up in this week’s metrics). Beck in his own words:

“In the Forest, metrics are a vehicle for self-awareness and learning and improvement. I as an individual developer am curious how many minutes a day do I spend coding? Where does my time go? How much do I spend debugging? How much do I spend on different kinds of development tasks? On design? On testing? On tooling? On teaching other people?

“Fabulous resource for me as a developer to learn about my own craft.

“The team together can collect metrics and understand how they’re doing. Hey, we tried this experiment. Did things get better?

“Metrics are fantastic, all of that data is fantastic, in a Forest context, as a means for learning. […]

“In the Forest, we deal with that by not having visibility of metrics at a higher level than they’re collected. So if a team collects metrics, the team can see them, but the director can’t see them individually. […] 

“So metrics in the Forest are a means for self-awareness and learning, and metrics in the Desert are a means of pressure and control. With all of the unanticipated undesired consequences that brings with it.”

More Famous People Saying “The Unit of Software Delivery Is the Team”

Dave Farley and Steve Smith [link]:

Smith: And yet we know that the most effective unit of delivery is a team.
Farley: Yep.
[caption: The Most Effective Unit of Delivery for Software Is Still a Team]

Charity Majors [link]:

Individual engineers don’t own software. Teams own software. The smallest unit of software ownership and delivery is the engineering team. … as soon as you’re planning for the survival of a company that’s supposed to extend years into the future, the ownership needs to get handed over to a team. Individual engineers get sick, go on vacation, leave the company: it should not risk the business every time this happens.

Bob Marshall [link]:

1. Individual Performance Metrics in a Team Sport

Most organisations evaluate developers on their personal contribution to the team’s output. Lines of code. Commits. Tickets closed. ‘Their’ features shipped.

You can NEVER reward solo performance and expect team behaviour.

When promotion, bonuses, and performance reviews depend on demonstrating individual achievement, teammates become competitors. Helping someone else succeed actively harms one’s own metrics. Knowledge hoarding becomes rational. Taking credit becomes essential.

The system demands antisocial behaviour.

As Deming (2000) observed, the system in which people work accounts for 90-95% of performance. Yet we persist in evaluating and rewarding individuals as if they operate in isolation.Tim Ottinger [link]: 

This is why we measure *team* velocity in *completed capabilities* and also delivery frequency. …

This is why we want achievement, not individual “productivity.”

This is why it’s teams, not individuals.

Russ Miles [link]:

“It is amazing what you can accomplish if you do not care who gets the credit.”

– Harry S. Truman

… 

Productivity leaned in, voice honeyed and lethal. “If you pair,” she said, “who gets credit? Who gets promoted? Who is accountable?”

Case answered, “The team.”

It sounded simple. It sounded obscene.

The Foreman’s eyes narrowed. “Teams cannot be rewarded. Only individuals can be compared.”

“And that,” Case said, “is why you will never have sustainable excellence. Only exhausted saints and fragile miracles.”

The Lone Genius, who had been scowling, suddenly spoke with a hint of panic. “But … if we do it together,” he said, “then I am not special.”

Case looked at him with something almost kind. “You might become something better,” she said. “Kind, and helpful.”

…

Milo frowned. “But pairing and mobbing do cost something.”

“Of course,” Case said. “They cost the illusion of individual heroism. They cost the comfort of hiding. They cost the ability to pretend you understand when you don’t.”

She took a sip.

“And in exchange,” she added, “they buy you something rare in this industry: a team that can think and build together quickly without fear. And if you want to see high performance, that is what it can look like.”

Tim Ottinger [link]: 

This is why we measure *team* velocity in *completed capabilities* and also delivery frequency. …

This is why we want achievement, not individual “productivity.”

This is why it’s teams, not individuals.

The Outcome Engineering Manifesto [link]:

03
The Teamwork
No More Single Player Mode

Chat is a bottleneck, not an API. Whether humans or agents, outcome engineering is a team sport.

Daniel Terhorst-North [link]:

we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics.

Which brings me to Tim. Tim’s score was consistently zero. Zero! Not just low, or trending downwards, but literally zero. Week after week, iteration after iteration. Zero points for Tim.

Well Tim clearly had to go. This was the manager’s conclusion, and he asked me to make the necessary arrangements to have Tim removed and replaced by someone who actually delivered, you know, stories.

And I flatly refused. It wasn’t even a hard decision for me, I just said no.

You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses.

With seniors it was more like co-creating or sparring; bringing different worldviews to bear on a problem, to produce something better than either of us would have thought of on our own. Tim is a heck of a programmer, and you always learn something pairing with him.

Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.

I explained all this to the manager and invited him to come by and observe us working from time to time. Whenever he popped by, he would see Tim sitting with someone different, working on “their” thing, and you could be sure that the quality of that thing would be significantly better, and the time to value significantly lower—yes, you can have better and faster and cheaper, it just takes discipline—than when Tim wasn’t pairing with people.

In the end we kept Tim, and we quietly dropped the individual productivity metrics in favour of team accountability, where we tracked—and celebrated—the business impact we were delivering to the organization as a high-performing unit.