On the Structure of Delivery — A Column from Maycon Santos
A feature can ship on time and still not be what you agreed to build. Governance and execution are two separate systems — and most teams run them as one.
“A feature shipped on the day we promised it. In review, two of us realized we had built slightly different things, and neither was quite what the ticket described.”
Nobody had missed a deadline. We had spent the whole sprint executing against a decision that kept moving while we worked.
It Is Not a Communication Problem, It Is Two Systems Run as One
It is tempting to call that a communication problem, or a discipline problem, and to fix it with more standups and a stricter definition of ready. That is the wrong diagnosis. What actually happened is that two different systems were collapsed into one. There is the decision about what we are building, and there is the work that turns that decision into software. Those are not the same activity, and they are not meant to move at the same speed. The decision is governance. The work is execution. When both live in the same place, the same Slack thread, the same ticket, the same hallway conversation, the decision stays editable at exactly the moment it most needs to hold still.
The gap is the space between what was agreed and what was executed, and most teams cannot see it because nothing in their tooling marks where the agreement ends and the building begins. The ticket says one thing. The thread under it refines that thing three times over two days. The pull request implements a fourth version that lives only in one engineer’s head. Every step felt reasonable. No one decided to drift. But by the time the work reaches review, you are not verifying that execution matched the decision. You are reconciling several decisions that were never recorded as decisions at all.
The Decision Becomes a Suggestion in the Thread It Lives In
I have watched this happen on teams that were, by every visible measure, doing things right. Requirements were written. Tickets were groomed. People talked constantly. The talking was the problem. In most engineering organizations, the place where decisions are actually made is indistinguishable from the place where work is discussed. A governance decision, the kind that is supposed to stay fixed for the duration of the sprint, gets made in a thread, and then the same thread keeps going, and the decision quietly becomes a suggestion. Nobody reopened it on purpose. It was simply never closed, because the channel it lives in has no way to close anything.
Watch how it plays out across a single sprint. On Monday the team agrees on the shape of a feature. On Tuesday someone raises a reasonable edge case in the thread, and the shape shifts a little to take it in. On Wednesday a second engineer, deep in the code, makes a judgment call the thread never covered, because the thread had gone quiet and the work could not wait. By Thursday the design is, in practice, three revisions past what anyone agreed to, and none of those revisions exists anywhere you could point to. On Friday it ships, on time, and it is genuinely unclear whether it is correct, because there is no longer a stable definition of correct to check it against.
By the time it reaches review, the review itself has quietly changed jobs. It is supposed to check the work against the decision. Instead it becomes an archaeology session: people reconstructing, from the diff and their own memory, what the decision must have been, and negotiating a new one on the spot to make the work acceptable. The team is good at this, and that is the trap. A team skilled at reconciling drift can absorb an enormous amount of it before anyone names it a problem, which means the gap can run wide for a long time while every standup still reports green.
So the cost arrives late, and it arrives as rework. The feature that shipped on time gets half-rebuilt the following week, because the version that reached production was the fourth informal revision and the stakeholder wanted the second. The estimate was never wrong. The thing being estimated changed after the estimate was given. And this is the part that compounds: it does not happen once. It happens a little every sprint, on every piece of work where the deciding and the building share a room, until a real share of the team’s capacity is going to reconcile what was agreed with what was made, every cycle, as a standing tax.
“The decision is governance.
The work is execution.”
Here is what most of the current conversation about this misses, because it is busy talking about AI writing buggy code or needing better prompts. The real shift is that AI made execution nearly free, and a free execution layer moves faster than informal governance can track. When an engineer working with AI produces in an afternoon what used to take three days, the work races ahead of the decision instead of waiting on it. More gets built against agreements that were never pinned down. The gap does not close. It widens, sprint after sprint, faster than any thread can keep up with.
That is a diagnosis of absent structure, not of AI, and the distinction is the whole point. When the decision is fixed before the work starts, cheap execution becomes the best thing that can happen to you. Every unit of nearly free building lands on a decision that holds, and the leverage compounds instead of scattering across four revisions. Structured AI is not the slow option. It is AI aimed at a target that is not moving while you fire at it.
Stop Asking If the Team Is Fast, Ask Where the Fixed Decisions Live
So if you lead delivery, the question to stop asking is whether the team is executing fast enough. Speed was rarely the real constraint, and AI has made it less of one. The question to start asking is whether you can tell, at any given moment, which decisions are allowed to move and which are not, and where the ones that are not allowed to move actually live. If the honest answer is that they live in the same threads where the work gets discussed, then you do not have a governance layer. You have a conversation that occasionally produces decisions and then keeps editing them. The fix is not more process layered on top of the work. It is giving the decisions a place to go and stop moving, kept separate from the place where the building happens.
On time was never the hard part. The hard part is knowing whether what shipped is still what you agreed to build.
The Decision Kept Moving While We Built It
On the Structure of Delivery — A Column from Maycon Santos
A feature can ship on time and still not be what you agreed to build. Governance and execution are two separate systems — and most teams run them as one.
“A feature shipped on the day we promised it. In review, two of us realized we had built slightly different things, and neither was quite what the ticket described.”
Nobody had missed a deadline. We had spent the whole sprint executing against a decision that kept moving while we worked.
It Is Not a Communication Problem, It Is Two Systems Run as One
It is tempting to call that a communication problem, or a discipline problem, and to fix it with more standups and a stricter definition of ready. That is the wrong diagnosis. What actually happened is that two different systems were collapsed into one. There is the decision about what we are building, and there is the work that turns that decision into software. Those are not the same activity, and they are not meant to move at the same speed. The decision is governance. The work is execution. When both live in the same place, the same Slack thread, the same ticket, the same hallway conversation, the decision stays editable at exactly the moment it most needs to hold still.
The gap is the space between what was agreed and what was executed, and most teams cannot see it because nothing in their tooling marks where the agreement ends and the building begins. The ticket says one thing. The thread under it refines that thing three times over two days. The pull request implements a fourth version that lives only in one engineer’s head. Every step felt reasonable. No one decided to drift. But by the time the work reaches review, you are not verifying that execution matched the decision. You are reconciling several decisions that were never recorded as decisions at all.
The Decision Becomes a Suggestion in the Thread It Lives In
I have watched this happen on teams that were, by every visible measure, doing things right. Requirements were written. Tickets were groomed. People talked constantly. The talking was the problem. In most engineering organizations, the place where decisions are actually made is indistinguishable from the place where work is discussed. A governance decision, the kind that is supposed to stay fixed for the duration of the sprint, gets made in a thread, and then the same thread keeps going, and the decision quietly becomes a suggestion. Nobody reopened it on purpose. It was simply never closed, because the channel it lives in has no way to close anything.
Watch how it plays out across a single sprint. On Monday the team agrees on the shape of a feature. On Tuesday someone raises a reasonable edge case in the thread, and the shape shifts a little to take it in. On Wednesday a second engineer, deep in the code, makes a judgment call the thread never covered, because the thread had gone quiet and the work could not wait. By Thursday the design is, in practice, three revisions past what anyone agreed to, and none of those revisions exists anywhere you could point to. On Friday it ships, on time, and it is genuinely unclear whether it is correct, because there is no longer a stable definition of correct to check it against.
By the time it reaches review, the review itself has quietly changed jobs. It is supposed to check the work against the decision. Instead it becomes an archaeology session: people reconstructing, from the diff and their own memory, what the decision must have been, and negotiating a new one on the spot to make the work acceptable. The team is good at this, and that is the trap. A team skilled at reconciling drift can absorb an enormous amount of it before anyone names it a problem, which means the gap can run wide for a long time while every standup still reports green.
So the cost arrives late, and it arrives as rework. The feature that shipped on time gets half-rebuilt the following week, because the version that reached production was the fourth informal revision and the stakeholder wanted the second. The estimate was never wrong. The thing being estimated changed after the estimate was given. And this is the part that compounds: it does not happen once. It happens a little every sprint, on every piece of work where the deciding and the building share a room, until a real share of the team’s capacity is going to reconcile what was agreed with what was made, every cycle, as a standing tax.
AI Made Execution Free, and Free Execution Outruns Informal Governance
Here is what most of the current conversation about this misses, because it is busy talking about AI writing buggy code or needing better prompts. The real shift is that AI made execution nearly free, and a free execution layer moves faster than informal governance can track. When an engineer working with AI produces in an afternoon what used to take three days, the work races ahead of the decision instead of waiting on it. More gets built against agreements that were never pinned down. The gap does not close. It widens, sprint after sprint, faster than any thread can keep up with.
That is a diagnosis of absent structure, not of AI, and the distinction is the whole point. When the decision is fixed before the work starts, cheap execution becomes the best thing that can happen to you. Every unit of nearly free building lands on a decision that holds, and the leverage compounds instead of scattering across four revisions. Structured AI is not the slow option. It is AI aimed at a target that is not moving while you fire at it.
Stop Asking If the Team Is Fast, Ask Where the Fixed Decisions Live
So if you lead delivery, the question to stop asking is whether the team is executing fast enough. Speed was rarely the real constraint, and AI has made it less of one. The question to start asking is whether you can tell, at any given moment, which decisions are allowed to move and which are not, and where the ones that are not allowed to move actually live. If the honest answer is that they live in the same threads where the work gets discussed, then you do not have a governance layer. You have a conversation that occasionally produces decisions and then keeps editing them. The fix is not more process layered on top of the work. It is giving the decisions a place to go and stop moving, kept separate from the place where the building happens.
On time was never the hard part. The hard part is knowing whether what shipped is still what you agreed to build.
Get new insights when we publish them
Receba novos insights quando publicarmos