They Don’t Want Control, They Want Change That Actually Works: A Guide for CIOs Rebuilding Trust After Technology Failure

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.

1. The symptom

When you walk into a technology area that has suffered through repeated instability, failed projects, failed products and a long run of operational incidents, you will almost always encounter the same behavior from the business, which is that they want to sign everything off. Every release, every change and every meaningful decision has to cross someone’s desk before it is allowed to happen, and that someone is usually a senior leader who has far better things to do with their time.

On the surface this looks like control for its own sake, or perhaps just bureaucracy that has been allowed to calcify, and it is tempting to read it as a business that has decided technology cannot be trusted with its own decisions and has responded by trying to make all of them itself. That reading is understandable, but in a technology environment with a long history of failure it is often wrong, and acting on it will usually make things worse.

2. Where it comes from

The people asking to sign everything off are usually not difficult people at all. They are people who have been hurt, repeatedly and over a long period, by the very thing you are now asking them to trust again, and their behavior makes a great deal more sense once you sit with what that experience has actually been like for them.

Think about what it feels like to run a business through years of unreliable technology. It is not a single bad incident that you recover from and move past, but rather a long pattern of being stung again and again, often without warning and frequently without any clear explanation of what went wrong or why. Managing that experience is closer to managing a swarm of hornets than managing a project plan, and you cannot reasonably expect someone in that position to respond with calm, measured rationality, or to articulate precisely what is wrong and what would fix it, because nobody thinks clearly while they are being stung.

It is also worth remembering who actually absorbs the damage when something breaks. The business leader is usually the one standing in front of clients when things go wrong, 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 go out and win new business, which means selling the company honestly and with confidence, and every failure makes that conversation harder because it is very difficult to sell confidence in something you privately do not trust. In a very real sense, technology instability makes them look bad in rooms you will never sit in, and they carry that with them long after the incident report has been closed.

Wanting to approve everything is simply what that experience looks like from the outside. It is armor rather than policy, and it grew there for a reason.

3. The real ask

Underneath all of the sign off requests sits a much simpler truth, which is that they do not actually want to approve every change at all. What they want is for things to work, and the approvals are just the only lever they have found that gives them any sense of protection.

They do not have a problem with change either, even though it can look that way from where you are standing. They have a problem with bad change, with the kind of change that has hurt them before and that they have every reason to expect will hurt them again. They do not want to run technology, and they never did. They want technology to get out of the way so that they can get on with running the business, which is the job they were actually hired to do.

That distinction is the whole article, so it is worth sitting with it before reading any further. Every governance argument, every negotiation over approval thresholds and every attempt to win back autonomy by talking someone out of their sign off habit misses this completely, because you are not dealing with a control problem at all. You are dealing with a trust problem that happens to be wearing control’s clothes.

4. The recovery paradox

Here is the paradox that makes this genuinely hard rather than merely annoying. The organizations most frightened of technology change are very often the ones that need the most of it, because recovering from a badly broken environment normally requires a great deal of change, and you cannot stabilize something by freezing it exactly as it is when the thing you would be freezing in place is the very thing that broke in the first place.

The systems, the architecture, the processes, the controls, the skills and the ways of working may all need to change substantially, and so you find yourself stuck with an uncomfortable reality. The business wants less change because change is what has hurt them, while you need considerably more change than usual in order to fix the thing that is hurting them, and both of those positions are entirely reasonable from where each side is standing.

You cannot practically allow a senior business leader to personally approve every individual technology change, and you should not try to make that work, because it will not scale and it will exhaust everyone involved. At the same time, you cannot simply dismiss what is driving the request, because both of those responses fail in exactly the same way. They treat the sign off habit as the problem to be solved, when it is really just the symptom pointing at the real one.

5. What they need to see first: competence and shared exposure

Before anything else, take the person aside directly and acknowledge what they have lived through, not as a management technique but because it is true, and because being heard is usually the first thing that has been missing from their experience of technology leadership.

Then show them two things at once, because either one on its own will not be enough to shift anything.

The first is competence. They need to see that you know what you are doing, that the people you are bringing in know what they are doing, that you are willing to make hard calls including decommissioning things and taking real risks, and that you understand things will sometimes go wrong regardless of how carefully you plan. Confidence without a track record is just noise to someone who has heard confident promises before and watched every one of them fail, so the competence has to be visible in what you do rather than in how you describe yourself.

The second is shared exposure. Tell them plainly that you are putting your own name behind these changes, that if something goes wrong it will hurt you just as much as it hurts them, and that you are not walking away until the problem is properly fixed rather than merely quiet for a while. Competence on its own can easily read as arrogance, and a leader who is only sympathetic, with nothing concrete to back it up, offers comfort without any real substance behind it. It is only when competence and shared risk arrive together that they start to look like something worth trusting.

6. 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 genuinely broken, has to change, or has to be shut down entirely.

Consistency matters far more here than any single piece of news, whether good or bad. A leader who has been failed before is not primarily listening for good outcomes, because they have learned not to believe those. They are listening for whether you flinch, whether you soften things, and whether you disappear when the answer becomes uncomfortable. Someone who tells the truth reliably, including the parts that cost them something to say, gradually becomes someone whose word can be relied upon, and that is worth more than any individual reassurance you could ever offer.

7. Small wins first

Before attempting anything large, use whatever window you are given deliberately. A change freeze is common at this stage of a recovery, and most organizations will grant you one, even where people privately doubt that you are the right person for the job. Most organizations will give a new leader some kind of grace period, although it can be shorter than you would like, and in a badly damaged environment a full freeze may not be possible at all because regulatory, customer or operational changes simply cannot wait.

Whatever window you do get is a gift rather than a rest, and if you waste it you will confirm every doubt they already had about you, while if you use it well you will start to earn 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, bring in enough testers to catch problems before they reach customers, and slow down enough to see the system clearly rather than reacting to whatever happens to be loudest on any given day.

It is worth being clear that slowing down here does not contradict the earlier point that recovery needs a high volume of change. What you are slowing is the decision loop, so that you understand the system before you act on it, and what you are then increasing is the throughput of small, safe, observable changes. More change does not mean bigger changes, and a recovery built on many controlled successes will outperform one built on a few heroic bets every time.

Before acting on any of it, listen. Talk to the people actually doing the work about what they have been wrestling with, rather than assuming you already know the answer from a document or a briefing, because the people closest to the problem usually understand it far better than anyone has given them credit for. Where vendors have contributed to the problem, those relationships need to be addressed directly and visibly, so that both the vendor and the business can see that whatever was previously tolerated will not be tolerated going forward.

Once the fundamentals are in place, move in progressive steps, with each one carrying slightly more risk than the last. The point of each step is not caution for its own sake but rather making sure that every step produces a visible result, so that the case for the next, slightly larger step builds itself instead of needing to be argued for every single time. Make that progress visible to the business as you go rather than asking them to take your word for it, because trust recovers far faster when it does not have to depend on your reassurance.

8. Clear out what is slowing the team down

While you are fixing the basics, look hard at the processes and structures that have accumulated around the technology organization, because a great deal of what you find will be slowing people down without protecting anyone. Broken environments tend to grow layers 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 actually doing the work it was meant to safeguard. Every step that does not clearly reduce risk or improve quality is a candidate for removal, and removing it is usually one of the fastest ways to give a tired team some of its energy back.

Pay particular attention to how many silos exist in the area you are repairing. It is common to find that development, testing, operations, architecture and the various vendor teams have all retreated into their own corners, communicating through tickets and escalations rather than conversation, and that nobody has a complete picture of how a change actually travels from an idea to production. Silos like that are not just inefficient, they are where problems hide, because each group can honestly say that its part worked while the whole still fails. Break those boundaries down deliberately, put the teams in the same room and on the same calls, and insist that they speak to each other directly rather than through intermediaries.

Be equally willing to look at the management layers between you and the people doing the work. Some of those layers will be adding real value, but in a damaged environment a surprising number exist mainly to filter, soften and reframe bad news on its way upward, and by the time an issue reaches you it has often been translated into something that no longer resembles the problem on the ground. That is not usually malicious, but it is misdirection all the same, and it will cost you weeks of chasing the wrong things if you let it continue. Where a layer is obscuring rather than clarifying, remove it or route around it.

The most reliable way to find out what is actually wrong is to get the people who genuinely do the work together around a table and let them talk. Engineers, testers, operations staff and the people who deal with the vendor day to day usually know exactly where the pain is and often already know how to fix it, and what they have lacked is permission and a forum, not insight. Do not feel obliged to work through the structures that already exist, because those structures may well be part of the reason things are broken, and reorganising your recovery around them will only reproduce the same blind spots that created the failures in the first place.

9. What happens next, and how slowly

Before describing what recovery looks like, it is worth being honest about one awkward property of trust, which is that asking for it 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. Your changes work, your forecasts turn out to be accurate, you tell people about problems before they discover them for themselves, and you keep your promises, and eventually the controls that were built around distrust begin to look unnecessary even to the people who demanded them. The same logic applies to autonomy, which technology is not entitled to simply because an operating model says that technology owns technology, but which it earns through predictable delivery and can lose again just as easily.

This is what those progressive steps start to produce, and it does not happen quickly, so it is important not to expect it to.

Do not expect the leader to suddenly announce that they no longer need to sign things off. That instinct is how they have been managing pain for a long time, and letting go of it is not a decision they make once but rather something that erodes gradually as the evidence accumulates around them.

What changes first is not their process but the tension in the room. They start noticing that the people you have brought in are competent, that the changes you make succeed far more often than they fail, that the gaps between outages are growing longer and that the noise from clients is starting to drop away. The habit of signing everything off is usually the last thing to loosen rather than the first, and it loosens on its own once the evidence has done its work.

At some point along the way, trust stops being a conversation and becomes data. The change failure rate falls, recovery gets faster, incidents become both less frequent and less severe, and releases stop generating war rooms. Emergency changes become rare, the blast radius of anything that does go wrong shrinks, and production settles into longer and longer stretches of being uneventful. The business notices something wonderfully boring, which is that technology is no longer the thing everyone is talking about, and that quiet is the clearest signal that the trust is coming back.

Remember what all of this actually means for them personally. If you get it right, you are not just removing a source of stress from their working life, you are giving them back something they can sell. They can walk into a room with a new client and speak about the technology behind the business honestly and 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 if you fix it properly it becomes possible for the two of you to end up genuinely on the same side, rather than merely tolerating each other across a sign off form.

10. The principle

In an organization that has learned through repeated failure not to trust technology, resistance to change and excessive sign off are not the real problem. They are symptoms of lost trust, and the cure is not less change but sustained, successful change combined with visible shared accountability, delivered patiently enough that the evidence has time to speak for itself.

The goal is never to convince them to stop signing things off, and it is not worth making that the fight. Fix the technology, make good changes, tell the truth when things go wrong, put your own reputation beside theirs and then keep doing all of it for longer than feels comfortable. One day you will notice that the sign off requests have quietly disappeared, and nobody will have announced the change, because trust simply made them unnecessary. 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.