Want to learn more about us?
Visit the Tible Group page
2026-02-05
Merijn Boom
In many organisations, frustration around IT is almost perfectly balanced. IT teams experience users as impatient, unclear and constantly changing direction. Business teams experience IT as slow, rigid and hiding behind procedures. Both perspectives make sense. And that is exactly why the tension persists.
What is often labelled as a communication problem is, in reality, a structural flaw in how organisations design collaboration, expectations and responsibility around IT.
In almost every organisation where IT is business-critical, the same pattern appears. A user says something is 'not finished'. IT responds that it was delivered exactly according to specification.
Technically, IT is right. Operationally, the user is right as well.
The conflict is not about effort or quality, but about different definitions of success that are never made explicit. IT defines success in terms of delivery, stability and agreements. The business defines success through flow: can people continue their work today without friction?
As long as those definitions remain implicit, discussions drift from problem-solving to position-defending. Escalation becomes the default, because people optimise for different outcomes.
To manage this tension, organisations rely on structure: contracts, SLAs, governance and escalation paths. These mechanisms are not wrong; they are often necessary. The problem is what they replace.
Instead of asking what a user needs right now, the conversation shifts to what was formally agreed. Judgment gives way to compliance. Problem-solving turns into obligation management.
It is common to see users encounter real, productivity-impacting issues while IT responds based on contractual commitments. From an agreement perspective, that is defensible. From an operational perspective, it is disconnected from reality.
Over time, IT is experienced less as a problem solver and more as the executor of agreements. Not because people do not care, but because the system rewards adherence to contracts more than responsiveness to impact.
The most harmful friction rarely appears in dashboards. Small irritations are solved locally, worked around or accepted. A system freezes briefly. An application slows down. A workaround exists, so the issue stops being reported.
The spinning beach ball on a laptop is a familiar example. The first time it appears, IT is contacted. The advice is simple: close applications, restart, move on. It works. The second time, the user repeats the fix. By the third time, the issue is no longer reported.
Eventually, it happens several times a day. Productivity drops, frustration grows, but nothing is logged. From IT’s perspective, the problem does not exist. From the user’s perspective, the system slowly becomes unreliable.
This is how dissatisfaction becomes structural: because it remains invisible.
It is tempting to blame communication skills or technical understanding. That explanation is comfortable but largely incorrect.
The real issue is missing shared context. Users rarely see architectural dependencies, risks or the cumulative impact of small changes. IT teams filter relentlessly due to volume. Neither side has the full picture, yet both act as if their perspective is complete.
This is not unwillingness. It is structural blindness.
Many organisations believe they collaborate well. Tasks are divided, tickets processed and meetings held. That is working together.
Thinking together is different.
Thinking together means creating shared understanding before commitments are made: aligning on what 'done' means, what can wait, what hurts now and what failure would look like in practice. Expectations are explicit before solutions are designed, promised or escalated.
Where this happens, things still go wrong. Systems fail. Projects surprise. The difference is not the absence of problems, but the predictability of how they are handled. Impact is discussed before responsibility is assigned. Adjustments are made together instead of defensively escalated.
The difference is not in the contract. It is in the conversations that happened before anyone committed to it.
As long as IT and business operate with different, unspoken definitions of success, frustration is not a failure of collaboration. It is the logical outcome of the system as designed.
Most IT problems do not begin with technology. They begin when assumptions remain implicit while decisions are still made.
True collaboration does not start with better tools, clearer SLAs or tighter processes. It starts with thinking together: creating shared understanding before building, promising or escalating.
That is not a soft skill. It is a structural requirement.
Visit the Tible Group page
Contact us for a free consultation.