The Team That Has to Ask

Here is a team I have met a great many times, in different industries and under different names.

They are good. That is worth saying first, because when things move slowly the team is usually the first thing anyone questions. They know their part of the system better than anybody else, they ship reliably, and given a clear answer on Monday they would have something working by Thursday.

What they do not have is the answer.

So the question goes out. To a product owner, who takes it to a stakeholder. Or to a forum that meets on Wednesdays. Or to a genuinely helpful person in the business who genuinely has four other things on. It comes back in a few days, occasionally a few weeks, sometimes subtly changed by the journey — because the person who eventually answered was not the person who originally asked, and something got smoothed over on the way.

Meanwhile the team works on something else, because they are professionals and there is always something else. Nobody logs the wait. On paper they are fully utilized, which is among the more misleading numbers an organization collects about itself.

Ask anyone involved and they will describe a perfectly functioning arrangement. There is a process for questions. It has an owner. It usually works. And the thing that was supposed to take a week has taken a month, without a single person doing anything other than their job properly.

What that team has is everything needed to build, inside the boundary, and nothing needed to decide. The boundary was drawn around the work rather than around the judgement, and the two are not in the same place.

And there is a specific reason this keeps happening, which most of the advice about team design steps around.

Almost every model in this space was written for technology teams, and it shows in one way: the business perspective enters as a role rather than as authority. A product owner. A stakeholder. Someone who represents.

Representation is the problem, not the solution.

A team with a technical product owner has somebody who can prioritize, translate and negotiate, and who cannot answer the question that actually blocks the work: should we do this at all, and what happens to the customer if we get it wrong? That answer lives elsewhere, so the team asks, and waits, and the handover the boundary was drawn to remove reappears wearing a different job title.

It is worth being exact about what such a person can and cannot hold, in the terms Everything Was Green sets out. A technical product owner can own the output — the right thing gets built, correctly, in a sensible order, at a decent pace. That is real and it is not nothing.

What they cannot own is the outcome, because owning an outcome means being answerable for whether the person on the other end ended up better off, and that requires the standing to say we should not build this and be believed. A representative does not have that standing. It is not a competence problem and no amount of seniority in the role fixes it — the authority sits with whoever the representative is representing.

So the team has an owner for the half that was never in doubt, and none for the half that decides whether any of the work mattered.

A team built around a capability needs someone in it who can decide about that capability — not describe what the deciders want. Someone whose judgement about the domain is trusted, who carries the consequences, and who does not have to check.

The clearest version of this I’ve seen wasn’t a technology team at all. A finance team wanted printouts — numbers checked by hand, line by line, against another set of numbers. It worked, in the sense that errors were caught, and it also meant a group of capable people spent days every month doing something a machine could do in seconds, because the people who understood what the checks were for and the people who could automate them were in different parts of the organization, talking through requirements documents.

One person from finance moved. Not as a stakeholder consulted at milestones — close enough to be asked a question and answer it the same hour. The printouts went away. Most of the manual validation became automatic. Quality went up, because once the checks were automatic the team could afford to run more of them than anyone would ever have done by hand.

Nothing else changed. No new technology. No new process. No reorganization. One handover disappeared, and the friction it had been generating, quietly, every week, went with it.

That is what “delivering to the business” actually costs. It sounds like good service. In practice it describes a structural boundary — a specification at one end, an acceptance at the other, and a gap in the middle where nobody truly owns whether the outcome solves the problem it was meant to solve. Both sides can perform perfectly and still deliver something nobody needed.

A team made up only of builders can build almost anything. But it cannot decide very much.

Which is why the teams that worked were never made only of builders.

The finance story above is one example, and the room in Nobody Could Say Management Put Me Here is the other. Neither produced a development team with a stakeholder attached. Both produced something we ended up calling a business product team — business people, developers and operations in the same team, building the thing and running it, and answerable for the outcome rather than for the handover.

The industry name closest to it is BizDevOps, and the name matters less than what it removes. DevOps closed the gap between building and running, which was a real and expensive gap. It left the older one untouched: the gap between deciding what is worth building and building it. A team that builds and operates but still receives its requirements has closed one seam and kept the one that costs more.

None of that is a bigger team. It is usually the same headcount with a different composition — one or two of the builders replaced by the people who would otherwise have been on the other end of the specification. Which is a harder conversation than adding a product owner, because somebody has to give up a person they consider too valuable to embed.

Staffing a team this way is harder than staffing it with a product owner, which is precisely why most organizations don’t. It requires giving up a person the business considers too valuable to embed in one team. And it converts the most expensive recurring handover in the organization into a conversation across a desk, which is a good return for a decision that costs no headcount.

The test is simple enough to run this week. Take a team and ask what they had to escalate last month. If any of it was a question about the domain rather than about money or headcount, the team is arranged around the work but not around the decision.

A team you have to interrupt someone else to run is not a team. It’s a queue with a name.

What moves this is not a better process for questions, which is what gets tried and which makes the queue tidier rather than shorter. It is moving one person — the one whose judgement the team keeps waiting on — inside the line, and then letting them decide without checking. That is a staffing decision rather than a process one, and it costs somebody a person they consider too valuable to embed. Nothing else I have tried converts a recurring handover into a conversation across a desk.

Cultivating this: Drawing the Line Around a Team, in Part III.