The instinct with a data platform is to go to the technology office. It is a technology product, they own the technology, so that is the door.
It is the wrong door, and the reason is structural rather than political.
Enabler, gate, rarely buyer
A CIO's mandate is to make the organisation's technology work. That mandate includes saying no to things that will not integrate, will not comply, or cannot be supported — which makes the office a genuine gate you must clear.
What it usually does not include is a budget line for solving another division's operational problem. So when you open there, the honest response you get is some version of: this looks good, go and talk to the business, and if they want it, bring it back to us.
That is not an obstruction. It is an accurate description of how the decision works. But it costs you a cycle, and you arrive at the business as someone the technology office sent, rather than as someone who understands their problem.
We have had exactly this happen with a CIO we had good access to. Access was never the issue. The CIO simply did not have the decision, and said so.
Start where it hurts
The alternative is to find the person whose week is worse because of the problem, and start there.
That person can describe the pain without being prompted. They can tell you what it costs. And crucially, they usually have — or can reach — a budget attached to fixing it, because operational pain is what operational budgets exist for.
Once they want it, the technology conversation happens anyway. But it happens with the business standing behind it, which converts the technology office from a gate into an implementation partner. Same people, same concerns, completely different meeting.
Do not skip the gate
The failure mode on this side is equally real, and I have seen it sink work that had genuine business support.
If you build a relationship with a sponsor and never bring the technology office in, you will meet them eventually — at the point where the thing needs to be integrated, secured, hosted and supported. They will have legitimate objections nobody has addressed, and they will be entitled to feel they were routed around. That is an expensive way to make an enemy of the people you now need.
The sequence that works: start at the pain, involve the technology office early as a partner rather than as an approver, and let the sponsor be the one asking for it. Not business-only. Business-first.
Qualify the sponsor, not just the problem
A good problem with a weak sponsor produces a well-scoped engagement that never gets funded. This is worth being systematic about.
The fourth row is the one people skip, and it is the observed way this work most often dies.
We watched a genuinely good provincial data platform stop existing when the team behind it moved on. Not because it failed. Because it was carried by specific people, and when they left there was nobody whose job it was to keep it alive. The system did not break; it just quietly stopped being anyone's.
That risk is not eliminated by doing better work. It is reduced by insisting, early, that the capability has an institutional owner and not just a champion — a named role responsible for it, documentation that assumes the current team is gone, and ideally a second person in the client who understands why it exists.
Ask, in the first month: if you moved to another department next year, who would own this? If the honest answer is nobody, you have found the largest risk in the engagement, and it is not technical.
On sponsor timelines
Executives have terms, review cycles and targets, and those shape what they will back. A sponsor two years into a five-year mandate will fund foundational work. A sponsor with eight months left will fund something visible.
This is worth understanding without being sour about it. It is not a corruption of the process — it is how anyone behaves when they are accountable for results within a window. The practical consequence is that your sequencing should match your sponsor's horizon: with a short-horizon sponsor, front-load something demonstrable and get the foundational work funded on the back of it. Fight that and you will lose to it.
The thing you are actually selling
One reframe that has changed how these conversations go for us.
You are not selling a data platform. You are selling the ability to walk into a difficult meeting already knowing what is happening in your own operation — before the questions start, not after.
That is a real and specific need for anyone accountable to an oversight body, a board, or a portfolio committee. It is felt keenly and regularly. And it maps exactly onto what a working data foundation provides, which means you can describe the outcome entirely in their language and never say the word "lakehouse".
The architecture conversation comes later, and by then they want it.
How CloudNala can help
Most of the value we add early in these engagements is not technical. It is working out who actually owns the pain, whether they can fund it, what their timeline really is, and who will still be there in two years. Getting that map right before the architecture is drawn has more effect on whether the work survives than any design decision we make afterwards.
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