If your leadership team has lost confidence in IT, the problem probably did not start with one failed project or one bad decision. Trust tends to erode through repeated interactions until department heads and senior leaders stop expecting IT to help them move the business forward.

The clearest sign may not be complaints about IT at all. It may be that people have stopped involving IT until after a decision has already been made.

I stepped into an environment where that had already happened. Departments had established their own vendor relationships, created their own service accounts, and built separate technology stacks because centralized IT was no longer giving them a reliable path forward.

The technical team was not the underlying problem. The breakdown was in IT leadership, and over time that leadership failure had changed how the rest of the organization interacted with the entire IT department.

If your organization is in that position, replacing a few systems or hiring another technician will not rebuild the relationship by itself. You first have to understand why people stopped trusting IT, then give them a reason to bring IT back into the conversation.

Watch What Happens to the Requests

One of the easiest places to see a trust problem developing is in how IT handles requests from the rest of the organization. A department leader brings something forward and repeatedly hears no, a request sits without a clear answer, or somebody is told to manage a technology issue themselves even though they reasonably expected IT to own it.

Eventually, people adjust their behavior because the business need still exists even when IT says no or fails to respond. The department finds another way to solve the problem, whether that means calling a vendor, buying an application, creating an account, or finding someone internally who becomes the unofficial technology owner.

After enough of those interactions, the relationship changes. Departments stop bringing IT a problem they want help solving and start bringing IT a decision that has already been made.

The conversation becomes, “We bought this, and now we need you to make it work.”

That puts IT in a completely different position. Money may already be committed, a contract may already be signed, data may already be moving through the system, and another application may now need to be integrated into an environment IT had no opportunity to evaluate beforehand.

When IT is involved earlier, leadership has more options. IT may be able to identify a platform the organization already owns, expand an existing capability, eliminate an unnecessary purchase, or determine that the new system is the right choice and retire 2 overlapping tools instead of adding a third.

That is the difference between IT participating in a business decision and being brought in afterward to clean it up.

When Trust Drifts, Ownership Follows

Once departments stop expecting IT to help them, technology ownership begins moving away from the IT function. That was one of the conditions I inherited, with departments managing their own vendor relationships and technology stacks outside centralized governance or visibility.

The consequence is not limited to technology. When nobody has a complete view of the applications, licenses, contracts, renewals, vendors, and business owners across the organization, leadership has a harder time understanding what the technology portfolio actually costs and whether the organization is getting value from it.

Outside research shows how significant that visibility problem can become. Zylo’s 2026 SaaS Management Index analyzed more than 40 million SaaS licenses and $75 billion in SaaS and cloud spend under management, and reported that 36% of SaaS licenses were unused on average.

Zylo also reported that business units controlled 81% of SaaS spending in its dataset while IT directly managed 15%. The point is not that those percentages will match your organization, but that technology purchasing has moved well beyond the traditional IT budget in many businesses, while centralized visibility has not always moved with it.

Productiv reported a related problem in 2025. Across an average SaaS portfolio of roughly 342 applications in its data, 40% were either unused or overlapped with functionality available elsewhere.

The governance problem extends beyond cost. In a 2025 Cloud Security Alliance survey of 420 IT and security professionals, 55% reported employees adopting SaaS without security involvement, while 57% reported fragmented SaaS administration.

Those numbers are industry benchmarks, not assumptions about what is happening inside your business. What they show is that decentralized technology ownership can create real financial and governance consequences when nobody is accountable for seeing the environment as a whole.

You may have 2 departments paying for tools that solve the same problem. You may have unused licenses renewing quietly, vendor contracts approaching expiration without review, or applications processing company information that were never evaluated through a security or governance process.

What started as a trust problem can eventually become a cost, risk, and accountability problem.

Before You Take Ownership Back, Find Out Why You Lost It

If your organization has reached that point, the first move should not be an announcement that every technology vendor and application now belongs to IT. Taking control without understanding why departments went around IT risks recreating the same behavior that damaged the relationship in the first place.

The rebuild starts with a conversation.

Senior leadership and department heads need an opportunity to explain where the relationship stopped working. That means asking what they have not been getting from IT, where IT has made their work harder, what they have stopped bringing to IT, and what they need from the relationship going forward.

Those questions can be uncomfortable, especially when the answers point back toward IT itself. Requests may have gone unanswered, approvals may have taken too long, security requirements may have been implemented poorly, or IT may have repeatedly rejected requests without helping the department find another path.

The important part is not defending every previous decision. If leadership is trying to rebuild the relationship, the IT leader needs to understand what the organization actually experienced and which parts of that experience need to change.

The conversation should also move beyond what is wrong today and toward what each department is trying to accomplish. Ask what is changing over the next 6 or 12 months, what objectives they are working toward, and where technology is helping or getting in the way.

That changes the role of IT from reacting to technology requests to understanding the business problem before deciding what technology belongs in the answer.

Rebuild Accountability Around the Technology Stack

Listening does not mean IT gives up ownership. It gives the organization enough context to rebuild that ownership in a way that supports the business instead of simply centralizing control.

Someone needs to be accountable for understanding the technology stack as a whole. That includes the applications in use, the vendors involved, what those relationships cost, when contracts renew, what information each system handles, who owns the business process, and how each technology decision affects the rest of the environment.

That does not mean IT should own every business process. Finance should still determine what it needs from a financial system, marketing should still own the outcome it needs from a marketing platform, and operations should still define the workflow it is trying to support.

IT should own the technology governance around those requirements. Leadership should be able to ask what the organization owns, why it owns it, what it costs, what risk it introduces, and whether it still supports the business, and somebody should be accountable for providing that answer.

That is not about building an IT empire. It is about restoring visibility and accountability around something the organization is already paying for and depending on every day.

Stop Waiting for the Business to Come to IT

Once the immediate trust issues are understood, IT also has to change how it interacts with the rest of the organization. Waiting for tickets, project requests, or vendor problems keeps IT in a reactive position, which is exactly where the relationship started breaking down.

A practical place to start is a scheduled conversation with department leaders. Depending on the organization, that might be monthly, quarterly, or aligned to the department’s planning cycle, but the purpose should not be to read through ticket counts or deliver an IT status report.

The conversation should be about what the department is doing next. Are they changing a process, hiring people, evaluating a vendor, opening a location, replacing a system, preparing for a contract renewal, or dealing with something that is making their work harder?

That gives IT a chance to contribute while there are still choices available.

The same shift needs to happen with senior leadership. In the engagement I am drawing from, I eventually stopped bringing completed IT decisions to the leadership team and started bringing infrastructure lifecycle issues, security concerns, AI adoption questions, and vendor renewals into the conversation before the decisions had been made.

Leadership had the context to participate, and IT had the opportunity to understand the business impact before deciding what the technical response should be. Over time, departments that had previously viewed IT as a function that complicated their work began engaging with it differently.

That change is important because trust is not really restored when somebody says they trust IT again. It is restored when their behavior changes and they start bringing IT into decisions earlier.

Rebuild the Relationship One Project at a Time

There was no single meeting or project that changed the organization I worked in. It took roughly 6 to 8 months before I started seeing a noticeable cultural shift, and that timeframe reflects that specific environment rather than a universal rule for how long rebuilding trust takes.

What changed was the accumulation of consistent interactions. Requests had owners, projects moved forward, IT followed through, and departments began seeing that bringing IT into the conversation did not automatically mean more friction or another reason something could not be done.

One example involved a fragmented digital presence that individual departments had built and managed over time. The obvious technical response would have been to point at the governance problems and simply take control, but those departments had legitimate reasons for the communication channels they had created.

The conversation was reframed around the organizational outcome first, including how people using those channels experienced the organization and what departments needed to preserve during any transition. That allowed ownership to come back under organizational control through a phased process shaped with the department leaders rather than imposed on them.

Another project involved emergency notification capabilities across multiple locations. The technology itself could not be designed correctly without first understanding communication protocols, escalation paths, and the operating requirements of the departments that would depend on it.

Both were technology projects, but the technology was only part of what mattered. The way the work was handled showed departments that IT could understand the business requirement, involve the right people, and still provide governance and technical leadership.

That is how trust starts coming back, one project and one interaction at a time.

You Will Know Trust Is Returning When IT Gets Invited Back In

Leadership does not need to formally announce that the relationship with IT has been repaired. You can see it in what starts happening around the organization.

A department considering a new platform brings IT into the conversation before selecting it, which gives the organization an opportunity to evaluate what it already owns, understand the new requirement, and make the decision with the full technology environment in view. A vendor renewal comes up and IT is involved early enough to help leadership decide whether to renew, renegotiate, consolidate, or replace it.

The same thing happens at the executive level. A strategic decision has technology implications, and somebody asks for IT’s perspective before the decision is complete instead of forwarding the contract afterward and asking IT to make it work.

That is the outcome leadership should be looking for.

The engagement I have described eventually reached that point. It moved from an environment where executive leadership had lost confidence in IT to one where technology decisions were being discussed with leadership before they were made, and IT had become part of the organization’s broader strategic decision-making.

Getting there required accountability, difficult conversations, proactive involvement, and consistent follow-through. It also required the IT function to recognize that technical authority alone was not enough to rebuild a relationship the organization had already learned to work around.

If your leadership team wants IT back in the room when business decisions are being made, start by looking at why people stopped inviting it in. Then rebuild the relationship through the way IT listens, owns its responsibilities, follows through, and contributes to the next decision.

Trust is earned through that work every day, and so is respect.

Sources

1. Zylo. “2026 SaaS Management Index.” January 29, 2026.
   Used for: analysis of 40M+ SaaS licenses and $75B+ in spend, 81% of SaaS spend controlled by business units versus 15% directly managed by IT, and an average of 36% of SaaS licenses unused. (Zylo)
   https://zylo.com/news/2026-saas-management-index

2. Productiv. “Why Duplicative SaaS Apps Are Dominating Your Tech Stack.” March 10, 2025.
   Used for: average SaaS portfolio of roughly 342 applications, with 40% unused or overlapping in functionality. (Productiv)
   https://productiv.com/blog/duplicative-saas-apps/

3. Cloud Security Alliance. “State of SaaS Security Report 2025.” April 21, 2025.
   Used for: survey of 420 IT and security professionals, including 55% reporting SaaS adoption without security involvement and 57% reporting fragmented SaaS administration. (Cloud Security Alliance)
   https://cloudsecurityalliance.org/artifacts/state-of-saas-security-report-2025