Who Gets to Decide What “Good Enough” Means?
ENGINEERING NOTES / JUDGEMENT & RESPONSIBILITY
Sharad Chandel · 13 October 2026 · 8 min read
“Good enough” sounds like a judgement about quality. But before accepting it, I want to know who gets the benefit of stopping, who inherits the unfinished work, and whether those people had any say. A compromise can be sensible and still be unfairly distributed.
Imagine a team preparing to launch a reporting tool. This is a hypothetical example, but the decision is familiar. The numbers are correct, the main screens work, and the deadline is close. One awkward case remains: failed imports require someone to identify the missing records and upload them again.
The sponsor sees a useful product ready to release. The engineer sees a recovery process that needs work. The operations team sees another manual task. The user sees a report they cannot entirely trust without asking someone to check it.
All four can be describing the same system accurately. Asking whether it is “good enough” will not resolve the disagreement until we explain what each person is being asked to accept.
01 / The cost does not disappear when we stop building
There is a reasonable argument for shipping. Automating every unusual case could delay something people need. A manual recovery process might be proportionate to a small pilot. Waiting for a cleaner design could cost more than handling a few failures.
But calling the remaining work minor does not make it minor for the person doing it.
Suppose the launch saves development time because operations will reconcile failed imports. The total effort may still fall. That would be a real improvement. Or the same effort may simply move into someone else’s working day, where it becomes less visible to the project.
I would want to distinguish those outcomes before celebrating the saving. Does the team taking on the work have capacity? Can they recognise the failure? Are they authorised to stop the rollout if it becomes unmanageable?
If the answer is that they will somehow cope, we have left part of the estimate unfinished.
This is where “good enough” becomes more than a technical judgement. It allocates time, inconvenience, uncertainty, and sometimes blame. The decision might still be right, but the allocation deserves to be named.
02 / Having expertise is different from having the final say
Engineers should be able to explain what can fail, how likely we think it is, and what recovery would involve. That does not mean engineering should decide every acceptable compromise.
An engineer may prefer a cleaner architecture whose benefits do not justify another month of work. A user may reasonably prefer an imperfect tool today to the spreadsheet they currently struggle with. The person funding the project has to consider needs the implementation team may not see.
I do not think “the experts should decide” is a sufficient answer. Expertise helps us understand consequences. Authority determines which consequences we accept. Those roles can overlap, but they are different responsibilities.
Google’s guidance on implementing service-level objectives offers a useful example. It calls for stakeholder approval of reliability objectives, agreement from those responsible for delivering them, and an owner empowered to make trade-offs. That is one practical way of connecting a technical target with a business decision.
It does not settle whose priorities should prevail. It does make the decision harder to hide inside a number.
For our reporting tool, someone still needs the final say. I would expect that person to hear the recovery estimate, understand the operational burden, and explain why the benefit justifies proceeding. A senior title can establish decision authority. It cannot substitute for that explanation.
03 / The people paying may be absent
The uncomfortable case is when the person accepting the compromise is insulated from its consequences.
A manager approves the deadline, while another team handles the exceptions. A buyer signs off on the product, while employees navigate the awkward workflow. A team accepts a maintenance burden that a future colleague will inherit.
None of these arrangements is automatically wrong. Organisations need delegated decisions. We cannot ask every future user to attend a release meeting.
But we should be careful about treating the absence of objection as agreement. Someone may not know the decision is happening. They may understand the problem but lack the authority to challenge it. Or they may have learned that raising a concern creates work for them without changing the outcome.
In the hypothetical rollout, I would ask operations to demonstrate the recovery process before approving it. Not because a demonstration guarantees success, but because it makes the burden tangible. A task described as “just re-uploading” may involve finding the failure, checking for duplicates, coordinating with users, and confirming the report is complete.
We also need to examine who experiences the failures. A small overall error rate could be acceptable if inconvenience is occasional and widely spread. The same rate could be much harder to defend if one group repeatedly receives a broken experience.
An average can describe performance while leaving an important question unanswered: acceptable for which people, doing which work?
04 / Refusing the compromise also has a cost
It would be easy to stop here and argue that every affected person deserves a veto. I do not think that would produce better decisions.
Waiting can impose its own burden. Users keep doing manual work. A team spends its remaining budget on edge cases and loses the capacity to deliver something more valuable. An insistence on protecting everyone from inconvenience can preserve an existing situation that is already inconvenient.
The engineer asking for more time should therefore face the same scrutiny as the sponsor asking to launch. What specific improvement will the delay buy? Who benefits? What happens while we wait? Is there a smaller change that reduces the most serious risk?
Nor does bearing a cost automatically make someone the best person to decide. An operations team may understandably want no additional work, while a limited pilot produces benefits that justify some effort. Their burden should influence the decision without necessarily controlling it.
The distinction I would make is between being heard and having a veto. We need enough participation to understand the consequences, then a clear owner who can decide and remain accountable.
Some boundaries also need to be set before the deadline becomes urgent. A team can choose to defer a convenience feature. It should not casually redefine a required safeguard as optional because the schedule is tight. Decide which requirements are negotiable while there is still room to think.
05 / “For now” needs an ending
A compromise can be justified at launch and become unreasonable later.
Manual recovery might work for a small pilot. If usage grows, the same process could consume a large part of someone’s week. If nobody is responsible for reviewing it, the original approval continues to do work long after its assumptions have expired.
“For now” needs conditions attached.
For the reporting tool, I would write down the expected recovery burden, who owns it, and what would trigger reconsideration. We might review after the pilot, or sooner if failed imports exceed the team’s agreed capacity. The exact threshold needs evidence from the actual system; inventing a precise number would not make the decision more rigorous.
Google’s example error-budget policy illustrates this broader idea in reliability work: it specifies actions when reliability falls outside the agreed budget and provides an escalation route for disagreement. My takeaway is that an accepted compromise should have consequences when its assumptions stop holding.
Those consequences require resources. A promise to revisit manual recovery means little if the responsible team cannot get development time. The person approving the compromise should also explain how fixing it will compete with the next urgent request.
06 / A decision we can explain to the person inheriting it
I would still launch imperfect systems. Useful work rarely arrives with every uncertainty resolved, and a demand for perfection can become a comfortable way to avoid choosing.
But I would want “good enough” to come with a short explanation: what we are accepting, who benefits, who bears the remaining cost, and what would make us change our minds.
That explanation will not make every decision fair. It will expose some decisions that only looked economical because another person’s time was missing from the calculation. It may also show that an improvement we wanted is less urgent than we thought.
The person deciding should have the authority to make the trade-off, the information to understand it, and responsibility for what follows. The people affected need a way to make the consequences visible, including after the decision has been made.
Before calling something good enough, I would ask whether I could explain the choice honestly to the person who will inherit the unfinished work.
Would I still defend this compromise if its remaining cost landed on my desk?
07 / References
SHARAD CHANDEL
Engineering Lead · Platform, Data & ML