Leadership · Review
One person owns the outcome. The team owns the solution.
Most stalled work I’ve seen wasn’t blocked by anything hard. A dependency on another squad wasn’t followed up. A decision sat unresolved for a week. Everyone assumed someone else was handling the next step. The team was responsible for delivery, and nobody was clearly accountable for the outcome.
James Stanier’s Put a name on it is about exactly that gap.
What Stanier argues
As organisations flatten, and as AI absorbs more coordination work, projects drift. His fix is named ownership: every project belongs to one named person, visible to everyone. Not a team, and not a manager. The engineer who does the work and can answer detailed questions about it.
The idea isn’t new. Apple called them directly responsible individuals, and Amazon has single-threaded leaders. What makes his version useful is the operating detail from his own company: each owner posts a short written update every week (status, progress, risks, asks, and a link to the real work), leaders read every one, and there are standing office hours where leaders pull owners in or owners push for help.
He’s also honest about the cost. The owner’s job gets bigger: they build, talk to senior stakeholders and make trade-off calls. Less experienced engineers need coaching to do that, not shielding from it. And when a project goes wrong, managers have to back the owner and fix the system, or people learn to hide bad news.
Where I agree
Accountability needs a name. “The team owns it” is a fine statement about quality and a weak one about delivery. When a project crosses technical boundaries or depends on another squad, a shared sense of responsibility tends to dissolve at exactly the point where someone needs to chase, decide or escalate.
Where I’d adjust it
Stanier writes from a product company where the named engineer can own most of the decisions. In an enterprise team, a project usually involves several engineers, a Product Owner, QA and often another squad. So I’d put it this way:
Individual accountability, without individualising the work.
One person owns the outcome. The team owns the quality of the solution.
Named ownership shouldn’t mean one engineer does everything, or carries the blame when something goes wrong. It means one person is accountable for driving the work from start to finish, and has the authority to make decisions, escalate blockers, coordinate dependencies and ask others for help.
It also helps to be explicit about who owns what, because in practice these boundaries are rarely written down:
| Role | Owns |
|---|---|
| Product Owner | Priorities and the business outcome |
| Lead Engineer | Technical direction, engineering quality, and the conditions for the team to deliver |
| Named owner | End-to-end delivery of one project: decisions, dependencies, follow-through |
| The team | The quality of what ships |
The trap for leads
Without a named owner, the gap usually gets filled by whoever has the broadest context. Often that’s the lead. I’ve found myself stepping in to coordinate, resolve blockers or make decisions because I could see more of the picture.
That works in the short term. Over time it creates a dependency on one person, slows everything down to the speed of that person’s calendar, and takes away the situations where other engineers learn to lead. The lead becomes the person who keeps every project moving, instead of building a team where engineers can drive projects themselves.
What naming an owner won’t fix
This is the part I’d add to Stanier’s piece. A name on a project doesn’t fix unclear priorities, insufficient capacity, or dependencies outside the owner’s control. If those problems exist, making one engineer accountable for them is just a more polite way of assigning blame.
Those are organisational constraints, and they’re the lead’s job. The owner drives the project. The lead removes the things no owner can remove.
How I’m going to test it
I’m going to try this, starting with one clearly defined project rather than a new process for everyone.
The named owner will be responsible for:
- understanding the expected outcome and success criteria
- driving technical decisions and coordinating implementation
- identifying risks and surfacing cross-team dependencies early
- following up on open decisions and blockers
- communicating progress, and escalating when needed
- making sure the work is tested, delivered and followed through after release
My part is to give them the context, the authority to decide, and support, without taking ownership back the moment the project gets difficult.
At the end of the project I’ll look at four things: were dependencies raised earlier, were decisions made faster, was delivery more predictable, and did the engineer become more independent? It works if the team can drive a project end to end with less intervention from me, at the same quality and delivery standards.
I’ll write up what actually happened, including what didn’t work.