The residency question described earlier in this series was stuck for weeks. Everyone involved was capable and available. The decision was genuinely important and nobody was avoiding it.
It was stuck because of how it had been written down.
The same decision, twice
The first framing is accurate. Every term in it is correct, and a cloud architect would understand it immediately and have an opinion.
It is also unanswerable by the person who needed to answer it, because it asks about regions, deployment types and quota models — and their authority is not over any of those things. Their authority is over what the organisation is prepared to spend and what risk it is prepared to carry. Framed the first way, the honest response from a decision-maker is to ask someone technical, which returns the decision to the people who raised it, and the loop closes with nothing decided.
The second framing asks about data handling and cost. That is squarely within their authority. It got answered in a meeting.
Nothing about the underlying choice changed between those two rows. The architecture, the trade-off and the consequences were identical. Only the language moved — and the language was the blocker the whole time.
Why technical people get this wrong
Not carelessness. Two honest instincts, both misfiring.
The first is precision. Technical people are trained that vagueness causes defects, so removing the specifics feels like introducing error. But precision about the wrong dimension is not precision. Naming a deployment SKU when the question is "does this commit us to a standing monthly cost" is precise about something irrelevant to the decision.
The second is deference. Presenting options without a recommendation feels appropriately humble — the decision is theirs, so here are the facts. In practice a menu without a recommendation reads as "I have not thought about this enough to have a view," and it puts the burden of synthesis on the person with the least context. It is the fastest way to end a meeting without a decision.
The one-page options paper
What worked was a single page, written for someone who will read it once, between two other meetings.
The choice, in plain language, with no product names in the sentence. If the sentence cannot be written without naming a service, it has not been reframed yet.
The options — two or three, never seven — each with what it costs and what it commits the organisation to. Cost qualitatively is fine: "a standing monthly commitment" versus "billed on use" is enough to decide on.
The recommendation, stated outright. Ours, with the reasoning in one line. This is the part technical people resist and it is the part that converts a discussion into a decision.
The one question only they can answer. Usually there is exactly one. In our case: does this service handle personal information? Everything else follows from it. Isolating that question is most of the work.
The owner and the date. A decision without a named owner and a date does not get made; it gets deferred by default, invisibly, until someone notices the schedule has absorbed it.
Give the chair a recommendation, not a discussion
One practical note that made a disproportionate difference.
When someone else is chairing the meeting where a decision needs to land, hand them a crisp recommendation beforehand rather than a balanced overview. A chair with a recommendation can put a proposition to the room and get agreement or objection. A chair with a balanced overview can only open a discussion, and discussions about technical trade-offs among non-technical people expand rather than converge.
This is not manipulation. The chair remains free to reject the recommendation — and occasionally should. But there is a large difference between a meeting that starts from a proposal and a meeting that starts from a blank page, and the second one rarely ends in a decision.
Name the decision, the owner and the date
Most decisions that "get stuck" were never actually put to anyone. They were raised, discussed, understood to be important, and left in a state where no specific person owed a specific answer by a specific day.
So the minimum viable version of everything above, if you take nothing else: write down what is being decided, who decides it, and when. Then put it somewhere both organisations can see. A remarkable proportion of delivery risk on regulated programmes is decision latency rather than technical difficulty, and decision latency responds well to being made visible.
The part of the job nobody trains you for
Half of senior technical delivery is translation. Not simplification — translation. The distinction matters: simplification removes detail and usually removes the substance with it. Translation keeps the substance and changes the frame, from the dimensions engineers reason about to the dimensions decision-makers have authority over.
Getting this right is not a soft skill sitting alongside the technical work. On a regulated programme it is frequently the difference between shipping and not, because the technical work was never the blocker. The clearer you make the choice, the faster it gets made.
How CloudNala can help
A good deal of what we do on public-sector and enterprise engagements is this translation — taking a decision that has stalled in technical framing and putting it in front of the right person as a one-page choice they can actually make. It sounds like a small thing next to architecture and delivery. On the programmes we have worked, it has moved more schedule than any engineering decision we made.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za