Consensus breaks before the team does

I watched two teams hit the same wall from opposite directions.

On the first, the PM started deciding unilaterally, not as a philosophy but out of necessity, because the work was arriving faster than any meeting could absorb it. That team shipped faster than any other in the org. Morale got complicated: some engineers loved the speed, others felt sidelined, and both groups were telling the truth.

On the second, they tried to hold consensus at the accelerated pace, lasted about six weeks, and then the engineers started making product calls in Slack threads the PM never saw.

Two teams, two choices. One outcome worth having.

The claim

Consensus is a serial process running on top of a parallelised implementation layer.

It works when decisions come in days or weeks and you have time to socialise an idea. It cannot keep pace with a cycle that goes from spec to production in ninety minutes, and no framework fixes that, because the constraint is social bandwidth rather than decision quality. You can't run a better meeting your way out of the fact that there's a meeting.

Either one person decides or nobody does.

The second team proves the second half. They didn't keep consensus so much as lose it quietly and replace it with something worse: decisions made by whoever was awake in the thread, with no owner and no record. That is what "nobody decides" looks like in practice. Not paralysis. Drift.

This was always the rule

The rule is old. What changed is that it stopped being optional. My default was already one accountable person, fast, for reversible calls, with consensus reserved for one-way doors. The ratio is what moved. When a prototype takes twenty minutes and a flag can turn it off in seconds, nearly everything becomes a two-way door, the share of decisions that deserve a room shrinks to almost nothing, and the few left deserve a written doc and a real argument (not a Slack poll).

It's also the thing I've watched break first as organisations grow. Not communication, not quality. Decision speed, even with good people already in the room. Keeping speed at scale was always mostly about protecting who gets to decide, and agents just compressed a decade of scaling pain into a quarter.

The morale bill is real

I don't want to wave away the first team's problem.

Engineers who felt sidelined weren't being precious. They had been part of the decision before and now they weren't, and nobody told them that was the new deal, so they found out by watching it happen. That's fixable, and the fix isn't a return to consensus. Share the constraint, not just the outcome. Say why the call got made the way it did, what the pressure was, and what would change it, because people can reason about a decision when they know what you were working against. Handed only the result, all they can do is receive it. Receiving is what makes someone feel managed rather than trusted.

Disagree and commit still works at this pace, as long as the commit half is explicit and the disagree half has somewhere to go that isn't a private thread.

Follow the logic further

Push it far enough and you reach an uncomfortable destination. If AI handles implementation, assists with prioritisation, and consensus is too slow for the pace of decisions, the optimal unit of software production is not a cross-functional team. It's one person with a fleet of agents, holding the vision, making the calls and directing execution at production scale. I keep seeing early versions: a designer shipping a full production feature front to back with no engineer involved, a PM building and deploying an internal tool over a weekend.

The cross-functional squad was designed for a world where those skills had to live in different people. I still believe in the product trio as the right answer to the feature factory. Those boundaries are dissolving fast, though, and assuming the team structure of 2020 survives to 2030 feels like denial.

I haven't concluded the solo operator is the destination, only that it's where the logic points. Worth sitting with before you design your next org chart.

Then what is a PM for

The PM role today is defined by understanding what customers need and deciding what to build. If AI handles the second and increasingly assists with the first, through automated research and feedback synthesis, I genuinely don't know what a product manager is for.

Taste, maybe. Or desire.

Not "what should we build" but "what do we want to exist in the world." No model can answer that, because it requires wanting something, and wanting is the one capability AI doesn't have. Maybe that's enough. I'm not sure "the person who wants things" is a job description that survives a reorg.

It does line up with the first team, though. The PM who decided unilaterally wasn't doing the old job faster, they were doing a different job: holding a view of what should exist and being willing to be wrong about it out loud. Closer to the solo operator than to the PM on the org chart.

What I'd do on Monday

Name the decider for every live workstream. One person, written down where the team can see it.

Sort the decisions coming at that person into the few that are one-way doors and the many that aren't. The one-way doors get a doc and a real argument, and everything else gets a call, a sentence explaining why, and a flag.

Then go looking for the Slack threads. If product calls are being made where the owner can't see them, you're already running the second team's experiment and just haven't noticed the six weeks are up.