Your IT Shop Isn't Failing to Deliver. It's Failing to Partner.
Enterprise IT spends more every year and satisfaction with that spending keeps falling. That gap is not a delivery problem. Ticket volume is fine. Uptime is fine. The systems mostly work. What is broken is the relationship between IT and the business it exists to serve, and no amount of additional spend fixes a relationship problem. Until IT leaders name that plainly, they will keep funding the wrong repair.
The Posture Behind the Spending
Walk into most large IT organizations and you will find a quiet but consistent posture. IT believes it understands the problem better than the business does, because IT understands the systems. That belief is not usually stated out loud. It shows up in smaller ways: the requirements document handed back with corrections before a real conversation happens, the solution presented as already decided, the tone that treats a business stakeholder’s question as a gap in their technical literacy rather than a legitimate input.
Call it what it is. IT elitism. It is the assumption that technical fluency confers authority over the business problem itself, when in practice the two are not the same thing. A business owner who cannot explain a data model can still understand their customer, their market, and their operating constraints better than anyone in IT ever will. When IT treats its own expertise as a trump card instead of one input among several, it stops being a partner and becomes something closer to a vendor that happens to sit inside the building. Vendors get managed. Partners get trusted. Those are different relationships, and the business can tell which one it is in even when nobody says so directly.
This posture is rarely malicious. It usually comes from people who worked hard to earn technical credibility and reasonably expect that credibility to count for something. The problem is where they let it count. Credibility in the how does not transfer automatically into credibility in the what, and a shop that has not made that distinction will keep dictating solutions to people who stop bothering to explain the problem, because they have learned that explaining it does not change the outcome.
Where It Shows Up
Partnership failure does not stay abstract. It hardens into structure, and the structure is what everyone actually experiences day to day.
The first symptom is silos, and there are two kinds worth separating. Business-side silos are the familiar version: marketing does not talk to operations, finance does not talk to sales, and IT ends up building for whichever department shouted loudest that quarter. But the more damaging version sits inside IT itself. Infrastructure does not talk to application development. Security reviews arrive after architecture is locked. Data engineering builds a pipeline that the analytics team did not know was coming. A business stakeholder trying to get one coherent answer from IT often has to broker peace between IT’s own factions before their actual request even gets addressed. That is not a business problem IT is failing to solve. That is IT failing to solve itself, and the business absorbs the cost of that failure as delay and confusion.
The second symptom is overhead without flexibility. Central IT functions get built to standardize and control, and standardization is a legitimate goal. The trouble is when the control apparatus grows heavier than the value it protects. Every new request routes through the same review board regardless of size or risk. Every exception requires the same paperwork as every major initiative. The organization ends up with a security review process, a governance process, and a data process, each independently reasonable, that together make a two-week business need take three months. The business does not experience this as prudence. It experiences it as an organization that has optimized for protecting itself rather than for serving the people paying for it.
Both symptoms trace back to the same root. An organization that trusted its business partners would not need this much internal control, because control is what you build when you assume the people asking for things cannot be trusted to ask for the right things. Silos and overhead are not separate problems from the partnership failure. They are what the partnership failure looks like once it calcifies into an org chart.
The Capability That’s Missing
Fixing this is not a restructuring exercise, though restructuring often gets tried first because it is easier to execute than a change in posture. The actual fix is a shift in how IT leaders think about ambiguous problems, and the clearest name for that shift is effectual thinking.
Most IT operations are built for causal thinking. You start with a defined goal, work backward to the steps required to reach it, and execute the plan efficiently. Causal thinking is excellent when the goal is clear and stable, which is why it works so well for infrastructure builds, system migrations, and anything with a fixed spec. It fails the moment the business shows up with a problem it cannot fully define yet, because causal thinking has no good move for that situation except to force the business into stating a goal before it actually knows one.
Effectual thinking starts from a different place. Instead of beginning with a fixed goal and working backward, you begin with what you actually have, your capabilities, your relationships, your available resources, and you work forward with the people who own the problem to discover what is achievable. It treats ambiguity as the normal starting condition rather than a failure of the business to do its homework before showing up. It is inherently collaborative, because you cannot work forward from shared resources and relationships without the people who hold the other half of them.
This is why effectual thinking is the direct answer to the posture problem, not a separate initiative layered on top of it. IT elitism survives in a causal shop because causal execution does not require partnership. You can execute a fixed spec in isolation and hand back a finished result. Effectual thinking cannot be done in isolation. It requires sitting with the business before the answer exists and building it together, which makes the posture of assumed superiority structurally impossible to sustain. You cannot dictate a solution you have not yet worked out with the person who owns the problem.
Practically, this looks like showing up to ambiguous requests without a pre-built answer. It looks like asking what resources and relationships are already available before proposing a project. It looks like treating the first conversation with a business stakeholder as genuine discovery rather than a formality before requirements get written down. None of this requires new headcount or a reorg. It requires IT leaders to stop treating technical expertise as the whole conversation and start treating it as one contribution to a conversation that the business has equal standing in.
The spending will not go down by doing this, and it should not be the goal. The goal is that the business starts experiencing IT as a partner it chose to work with rather than a function it has to manage. That shift shows up first in trust, then in speed, and eventually in the budget conversations getting easier because nobody is fighting over whether the spend was worth it. The organizations that get this right did not do it by finding a better process. They did it by finding a different posture, and then building the capability to hold it under pressure.