They Don’t Want Control, They Want Technology That Works
Business demands to sign off every technology change after repeated failures are armor, not policy. The business does not want control, it wants technology that reliably works. A CIO rebuilds trust by acknowledging the past, demonstrating competence through hard calls, sharing personal exposure to risk, and telling the truth consistently even when the news costs something to say.
How CIOs Rebuild Trust After Repeated Technology Failure
1. The symptom, and what sits underneath it
When you walk into a technology area that has lived through repeated instability, failed projects and a long run of operational incidents, you will very often find the business insisting on signing everything off. Every release, every change and every meaningful decision has to cross the desk of a senior leader who has far better things to do with their time. It is tempting to read that as control for its own sake, or as bureaucracy that has been allowed to calcify, but in an environment with a long history of failure that reading is usually wrong, and acting on it tends to make things worse.
The people asking to approve everything are rarely difficult people. More often they have been hurt, repeatedly and over a long period, by the very thing you are now asking them to trust again. Years of unreliable technology is not one bad incident that you recover from and move past, but a pattern of being caught out again and again, often without warning and without any clear explanation of what went wrong, and nobody thinks calmly about what would fix the problem while the damage is still arriving.
It also matters who absorbs the damage. When something breaks, the business leader is usually the one standing in front of clients, and the reputational cost lands on them personally rather than on the technology organization working behind the scenes. They are also the ones who have to win new business, which means selling the company with confidence, and it is very difficult to sell confidence in something you privately do not trust.
Seen from that position, wanting to approve everything is armor rather than policy. In most cases they are not opposed to change; they are opposed to the kind of change that has hurt them before and that they have every reason to expect will hurt them again, and approvals are simply the only lever they have found that offers any sense of protection. That is the distinction this guide rests on: in most of these environments you are not dealing with a control problem, but with a trust problem wearing control’s clothes, although some of the controls you find will still be worth keeping once trust returns, which section 7 comes back to.
2. The recovery paradox
The organizations most frightened of technology change are often the ones that need the most of it. Recovering from a badly broken environment usually requires substantial change to systems, architecture, processes, controls, skills and ways of working, and you cannot stabilize something by freezing it in place when the thing you would be freezing is what broke in the first place. The business wants less change because change is what has hurt them, while you need more change than usual to fix what is hurting them, and both positions are entirely reasonable from where each side is standing.
You cannot practically ask a senior business leader to personally approve every technology change, because it will not scale and it will exhaust everyone involved, but you also cannot dismiss what is driving the request. Both responses fail in the same way, because they treat the sign off habit as the problem to be solved when it is really a symptom pointing at the real one.
3. What they need to see first: competence and accountability
Before anything else, take the most affected business leader aside, and then each of the other key stakeholders in turn, and acknowledge what they have lived through, not as a management technique but because it is true, and because being heard is usually what has been missing from their experience of technology leadership. Then show them two things together, because either one on its own is unlikely to shift anything.
The first is competence. They need to see that you and the people you bring in know what you are doing, that you are willing to make hard calls including decommissioning things and taking considered risks, and that you understand things will sometimes go wrong however carefully you plan. Confidence without a track record is just noise to someone who has heard confident promises before and watched them fail, so the competence has to be visible in what you do rather than in how you describe yourself.
The second is accountability they can actually see. Put your name behind the decisions, stay present through the consequences and own the recovery, whether that means joining the difficult client call, fronting the post incident review or staying with the problem until it is properly fixed rather than merely quiet for a while. Competence without that accountability can easily read as arrogance, and sympathy without competence offers comfort with nothing concrete behind it; it is when the two arrive together that they start to look like something worth trusting.
4. What they need to see next: truth over comfort
The next thing that earns trust is refusing to manage the message. Tell them what you actually see rather than what would be easiest for them to hear in the moment, and accept that sometimes that will be good news while at other times it will be that something is broken, has to change or has to be shut down entirely. Consistency matters far more than any single piece of news, because a leader who has been failed before has usually learned not to believe good outcomes and is listening instead for whether you flinch, soften things or disappear when the answer becomes uncomfortable.
The real test of this usually arrives early, in the form of the first serious incident on your watch, and in a damaged environment it will almost certainly arrive during your first few months. How you handle it matters far more than the fact that it happened. Tell the business before they hear it from a client, own it visibly rather than routing it through a vendor or a team lead, and show them that the recovery was faster and better informed than it would have been a year earlier. Then close the loop with a blameless post incident review that looks for causes in the system rather than for someone to blame, and make sure the corrective actions it produces are actually completed rather than filed. Repeated failure tends to persist because the same lessons are identified again and again without anything changing, and a business that watches you finish the follow up work starts to believe that this time the pattern might break.
5. Small wins, made visible
Most organizations will give a new leader some kind of window at this stage, often in the form of a change freeze, even where people privately doubt that you are the right person for the job. It helps to be precise about what that freeze covers: it should pause discretionary releases and new features, not the remediation work that recovery depends on, and in a badly damaged environment some regulatory, customer and operational changes cannot wait at all. Whatever window you get is a gift rather than a rest, because wasting it confirms every doubt people already had about you, while using it well starts to earn you the next one.
Spend that time fixing the basics that make everything afterwards possible. Repair the non production environment so that it actually resembles production, add proper logging and observability so that you can see what is happening rather than guessing, and bring in enough testers to catch problems before they reach customers. Slowing down here does not contradict the point that recovery needs a high volume of change, because what you are slowing is the decision loop, so that you understand the system before acting on it, and what you are then increasing is the throughput of small, safe, observable changes. More change does not mean bigger changes, and in my experience a recovery built on many controlled successes tends to outperform one built on a few heroic bets.
The enabling work only restores confidence when the business can feel its effect. Consider an illustrative example, a composite rather than a specific case: a payments platform whose month end batch fails roughly one run in four, with each failure delaying customer payments and leaving the business head fielding complaints from their largest clients. Rather than launching a replatforming program, the team spends six weeks on a bounded intervention, building a non production environment that can replay month end volumes, adding monitoring that flags the batch falling behind while it is still recoverable, and fixing the two defects the replays expose. Over the following quarter the batch completes on time every month, the complaints stop, and the business head can tell clients plainly what changed and why. In engineering terms that is a modest win, but it is exactly the kind of evidence that makes the next, broader piece of work easier to agree.
Make that progress visible through a small set of measures the business can read for themselves, framed in their terms rather than yours: whether month end completed on time, how many clients complained, how many incidents reached customers. The engineering measures underneath those, which section 7 returns to, matter just as much, but a leader who has been failed before will trust a number they already care about far more than one you have introduced. From there, expand the scope of change as the evidence improves while keeping each release small, observable and recoverable, so that each result makes the case for the next piece of work rather than it having to be argued for from scratch.
6. Clear out what is slowing the team down
The business keeps getting surprised by technology failures for a reason, and much of that reason sits inside the technology organization itself. Broken environments tend to grow a layer of procedure in response to each failure, and over time those layers stop being controls and start being obstacles, so that people spend more of their week feeding the process than doing the work it was meant to safeguard. The distinction that matters is between redundant process and necessary control. Removing a step that exists only because of a failure three years ago is healthy, whereas bypassing a control that genuinely protects customers, satisfies a regulator or separates duties is not, and a useful test is that every control you keep should have a purpose someone can state in a sentence and a named owner who is accountable for it.
Pay particular attention to silos. It is common to find that development, testing, operations, architecture and the various vendor teams have retreated into their own corners, communicating through tickets and escalations rather than conversation, with nobody holding a complete picture of how a change travels from an idea to production. Silos like that are where problems hide, because each group can honestly say its part worked while the whole still fails. Break those boundaries down deliberately by putting the teams in the same room and on the same calls, and where vendors have contributed to the problem, address those relationships directly and visibly so that both the vendor and the business can see that what was previously tolerated no longer will be.
Watch the flow of information as closely as the flow of change. In a damaged environment, bad news often loses precision and urgency on its way upward, so that by the time an issue reaches you it no longer resembles the problem on the ground. That is rarely malicious and it is not confined to any one level of the organization, but the latency and distortion it creates are exactly what leaves the business exposed. Create direct channels to the people doing the work, and address any layer, process or forum that consistently distorts rather than clarifies.
The most reliable way to find out what is actually wrong is to get the people who genuinely do the work around a table and let them talk. Engineers, testers, operations staff and the people who deal with the vendors day to day usually know where the pain is and often already know how to fix it, and what they have lacked is permission and a forum rather than insight. Organizing your recovery entirely around the existing structures risks reproducing the blind spots that created the failures in the first place.
7. How trust returns, and what happens to the approvals
Asking for trust usually makes it harder to obtain. You cannot negotiate someone into trusting technology again, and you cannot put “restore stakeholder confidence” on a slide and declare it green three months later, because trust is the residue left behind by repeated evidence rather than the outcome of an agreement. Autonomy follows the same logic, in that technology earns it through predictable delivery rather than being entitled to it because an operating model says so, and it can lose it again just as easily.
None of this happens quickly. What changes first is not the process but the tension in the room, as the leader starts noticing that your changes succeed far more often than they fail, that the gaps between outages are growing and that the noise from clients is dropping away. Later, trust stops being a conversation and becomes data: the change failure rate falls, recovery gets faster, incidents become less frequent and less severe, emergency changes become rare and releases stop generating war rooms. The business notices something wonderfully boring, which is that technology is no longer the thing everyone is talking about.
It would be convenient if the approvals then simply disappeared, but that is only partly true. Some sign offs are defensive and will fade as confidence returns, while others exist for valid risk, business readiness or regulatory reasons and should stay. Some remain embedded in policy long after the fear behind them has gone, and those will not loosen on their own however good delivery becomes. In a regulated business the board and the regulator are watching too, and they will often want to keep controls that the business itself would happily drop.
So as delivery becomes predictable, make the transition explicit. Agree which classes of change can proceed under standing approval, typically small, reversible changes with a good track record, and which still need business sign off because they affect customers, pricing, business readiness or regulatory commitments. Agree as well what evidence, such as a sustained rise in the change failure rate or a serious incident, would justify restoring tighter oversight for a period. Written down, that agreement protects both sides, because the business keeps a real lever it can pull when it needs to, and technology earns its autonomy against agreed criteria rather than goodwill.
If you get this right, you are not just removing a source of stress from the business leader’s working life; you are giving them back something they can sell, so that they can walk into a room with a new client and speak about the technology behind the business with genuine confidence instead of hoping the subject does not come up. In many of these situations technology has been their biggest liability for years, and fixing it properly makes it possible for the two of you to end up on the same side rather than merely tolerating each other across a sign off form.
8. The principle
So do not make the sign offs the fight. Fix the technology, make good changes, tell the truth when things go wrong, stand beside the business when they do, agree openly which controls should remain, and keep doing all of it for longer than feels comfortable. One day you will notice that the defensive approvals have quietly fallen away, leaving only the ones that serve a real purpose, and nobody will have announced the change. Trust is not restored when people agree to trust you, it is restored when they discover that they no longer need to protect themselves from you.