Who writes the spec decides who runs engineering
Authority in software has always sat with whoever made the last irreversible decision. That used to be the person typing. It is moving to the person who wrote the criteria, and most organisations have not noticed they are reassigning power.
Every organisation has a formal answer to who decides how the system works and an actual answer. The formal answer involves architecture forums and a decision record template. The actual answer, for the last thirty years, has been the person at the keyboard at 4pm on a Thursday.
Not because engineers were seizing power. Because most decisions in software are too small to escalate and too consequential to be arbitrary, and the only person present when they arrive is the one implementing. Should this be idempotent. What happens on partial failure. Is this field nullable. Nobody scheduled those decisions. They got made because someone had to type something.
My position is that this authority is moving, quietly and without anyone acknowledging it, to whoever writes the acceptance criteria. And most organisations are handing that job to whoever is least busy, which is an extraordinary way to reassign control of your system.
Authority follows the last irreversible decision
The general rule is that power in any production process sits with whoever makes the last decision that is expensive to reverse.
In classic software delivery, that was implementation. Product could specify a feature, but a hundred sub-decisions inside it were made at the keyboard, and reversing them meant another engineer, another sprint, another argument. So the implementer had real authority regardless of the org chart, and everyone knew it, which is why good product managers spent their energy on relationships with engineers rather than on documents.
When a competent agent implements from criteria, that changes. The implementation stops being the place where the hundred decisions get made, because the agent will make them from whatever it was given, instantly, and regenerate them differently if the criteria change. Implementation becomes cheap to redo. The criteria become the expensive-to-reverse artefact, because changing them means re-arguing intent with the people who agreed it.
The last irreversible decision moved upstream. Authority follows it. That is not a preference, it is mechanics.
Which is why “the PM writes the criteria” is the wrong answer
The tempting conclusion is that this is a promotion for product management. It is not, and treating it as one is how the practice fails.
A product manager who writes “the API should be resilient to upstream failure” has not made the decision. They have deferred it, in language that sounds like a requirement. The agent will then make it, and now the decision has been made by something with no accountability at all, which is worse than either candidate.
The decision about retry semantics requires knowing what the upstream provider actually does, what the current error budget looks like, and what happened the last time this was tuned. That knowledge sits with engineers. Handing criteria authorship wholesale to product does not move the decision to product, it moves it to nobody.
The opposite failure is just as common. Engineering writes the criteria alone, and they encode what is convenient to build. “Returns the first 100 results” is a perfectly checkable criterion and may be a product decision that nobody made deliberately.
The actual answer is unglamorous
Criteria should be authored by whoever holds the consequence of getting it wrong, with the other party in the room.
That is not a fudge, it is a test you can apply per criterion. Who gets paged if this is wrong? Who has the conversation with the customer? Whoever that is should be the author of that line, and the other should be present to say “that is not how the system works” or “that is not what the customer meant”.
In practice that means refinement stops being a sizing ceremony and becomes an authoring session, which is a substantial change in what that hour is for and who needs to be in it.
Product alone
Criteria that are checkable but wrong about the system. Latency targets nobody costed, error semantics that ignore the upstream contract.
Engineering alone
Criteria that encode what is convenient. Real decisions about behaviour made silently because they looked technical.
Neither, in practice
Vague criteria from whoever had time, decisions made by the implementer with no record. The most common state.
Both, per line
Author is whoever holds the consequence. The other objects in the room, before it binds anything.
What this does to the org chart, honestly
If criteria authorship is the control point, then the job titles that matter are the ones that write criteria, and the influence of titles that only implement will decline. That is uncomfortable and I do not think it is avoidable.
But the conclusion people jump to, that engineering loses and product wins, is wrong. What actually happens is that the senior engineer’s job changes shape rather than shrinking. The staff engineer who used to exercise authority by writing the tricky part now exercises it by writing the constraints on the tricky part, and reaches more of the system by doing so. The person who loses is the one whose entire contribution was throughput of implementation, and that is the same person the entry-level market is already signalling about.
Entry-level developer postings are down roughly 40 percent, though the picture is not uniform: some large enterprises increased junior hiring while startups cut it. My read of that split is that the enterprises are hiring for the criteria-and-review skill and can afford to train it, and the startups are optimising for immediate throughput. I think the enterprises are making the better bet, and I hold that loosely.
Where this breaks down
Agents are not yet reliable enough for implementation to be a commodity. My whole argument rests on implementation becoming cheap to redo. For a large class of work it is not, and a senior engineer still makes decisions at the keyboard that no criteria anticipated. Where that is true, authority has not moved and pretending it has produces criteria that are ignored.
Committee authorship is a real risk. “Both parties in the room, per line” is how you get a two-hour refinement for a three-day ticket. The overhead is genuine and there is a volume of work where the correct answer is that one person writes it in four minutes and nobody reviews it.
The reviewer may still hold the real veto. A reviewer can reject anything, and in organisations where review is genuinely strong, that is where power sits regardless of who wrote the criteria. I would answer that the LinearB benchmarks suggest review is weakening rather than strengthening under volume, but in a team that has held the line, my mechanics argument is weaker.
Titles do not map to consequence cleanly. “Whoever holds the consequence” sounds crisp and dissolves in a matrix organisation where the person paged reports to a different director than the person who promised the customer. The test is good, the org may not let you apply it.
This can be used badly. An executive who reads this and concludes that engineering should stop deciding things has misread it in a way that will cost them their best engineers. The argument is that authority moves upstream, not that it moves away from engineering.
The takeaway
Authority in software follows the last decision that is expensive to reverse, and that decision moved from implementation to specification. Whoever writes the criteria is deciding how the system behaves, whether or not that is in their job description.
The answer is not to give the job to product or to engineering wholesale. It is to author each criterion where the consequence lands, with the other party present to object before it binds.
If you take one thing into next week: look at your last sprint’s tickets and write down who actually typed the acceptance criteria. If the answer is “whoever had a gap in their calendar”, you have already delegated the design of your system and you did it by accident.