Most engineering managers inherit a delivery problem and reach for a process fix. More standups, tighter estimates, a new board. In my experience running a team of twelve at LeLaboDigital across engineering, AI, and delivery, the process is almost never the bottleneck. The bottleneck is that nobody can say, out loud and without hedging, what “done” means for the thing they are working on right now.
The symptom is estimation, the cause is ambiguity
When estimates are consistently wrong in one direction, the instinct is to add a buffer. That treats the symptom. Estimates drift because the work was described in terms of an outcome nobody had decomposed — “integrate the payment provider,” “make the dashboard faster,” “add Arabic support.” Each of those hides a different amount of unknown, and the person estimating is guessing at the size of the unknown rather than the size of the work.
The fix that actually moved our numbers was not a better estimation ritual. It was refusing to accept a ticket into a sprint until someone could state the acceptance condition as something observable. Not “the dashboard is faster” but “the operations view renders under two seconds with a year of data on a mid-range Android device.” That single sentence does more for predictability than any velocity chart.
Ambiguity compounds in multilingual and multi-market work
This gets sharper in the markets we deliver into. A feature that is trivially “done” in English is frequently not done in Arabic: layout direction flips, name fields stop being safely splittable, sort order stops matching what a user expects, and date handling picks up a second calendar. If the acceptance condition says “add Arabic support,” the team will ship something that renders Arabic characters and call it complete, because that is the only unambiguous reading available to them.
We now write acceptance conditions per direction, not per feature. It looks like more work upfront. It is dramatically less work than discovering at UAT that a form validates Latin-script names only.
AI raises the cost of vague requirements
The same principle applies to the AI work we do, and the stakes are higher. An automation that is 90 percent correct is not 90 percent done — it is a system that now needs a human review step, an escalation path, and a way to measure the ten percent. If the requirement was “automate ticket triage,” none of that got planned for. If it was “route eighty percent of inbound tickets to the correct queue, with everything below a confidence threshold going to a human and logged for review,” the actual shape of the work is visible before anyone writes code.
Teams adopting AI tooling tend to underestimate this by a wide margin. The model is the easy part. Defining what an acceptable failure looks like, and who catches it, is the engineering.
What this looks like in practice
Three habits, in order of how much they changed things for us:
- Acceptance conditions are observable or the ticket does not start. If you cannot describe how you would demonstrate it, you cannot estimate it.
- Unknowns get their own timebox. A spike is a legitimate unit of work with a deliverable — a decision — not a failure to plan.
- The person doing the work writes the condition, and someone else confirms they would recognise it. This catches the cases where two people have been using the same word for different things, which is most of them.
None of this is novel. It is the unglamorous half of engineering management: making sure that the thing everyone believes they agreed on is actually the same thing. Process frameworks are easy to adopt and easy to perform. Clarity is neither, which is why it stays scarce, and why it is usually where the leverage is.