I have spent my career standing between IT and the business. Not as a neutral observer, as an active translator, trying to ensure that what IT builds is what the business actually needs, and that what the business asks for is actually buildable.
What I have observed is that the communication failures between these two groups are not the result of incompetence or bad faith on either side. They are the result of two groups that have genuinely different languages, different priorities, and different definitions of success, and that rarely have structures in place that acknowledge these differences and compensate for them.
Different languages
IT teams think in systems, data structures, integrations, and technical constraints. When they describe a problem, they describe it in terms of its technical components. When they propose a solution, they propose it in terms of its technical architecture. This is not jargon for its own sake, it is the language that allows precise communication within the technical domain.
Business teams think in outcomes, processes, timelines, and operational impact. When they describe a problem, they describe it in terms of what is going wrong in their day-to-day work. When they propose a solution, they describe it in terms of what they want to be able to do. This is also not imprecision, it is the language that reflects what actually matters to the business.
When these two groups try to communicate directly, the conversation often goes wrong in one of two ways. Either the business team does not understand what IT is proposing and accepts it without understanding the implications. Or IT tries to implement what the business asked for literally, without understanding the underlying need, and produces something that meets the specification but misses the point.
"The business said 'faster.' IT built 'automated.' They delivered different things."
Different definitions of done
For an IT team, a project is done when the system works. Tests pass. Data migrates. The go-live happens. This is a meaningful definition of done, and achieving it represents genuine work and genuine achievement.
For the business, a project is done when operations have improved. The system is a means to that end. A system that works technically but has not changed how the business operates, because adoption is low, or because the processes around it were not redesigned, or because the configuration does not match the actual workflow, is not done. It is a project that has produced output without impact.
This difference in what "done" means creates significant friction. IT celebrates go-lives that the business experiences as failures. Business complains that IT "delivered" something that does not work. Both descriptions are accurate from their respective perspectives, which is precisely why the conversation is so difficult.
Different incentives
IT teams are typically measured on technical delivery: on time, on budget, to specification. Business teams are measured on operational outcomes: revenue, efficiency, quality, speed. These metrics do not automatically align, and an IT team that is hitting its delivery targets can be doing so in ways that undermine the business outcomes the project was supposed to deliver.
The most common example is scope management. An IT team under pressure to deliver on time and on budget will, rationally, manage scope tightly. Anything that was not in the original specification will be deferred. But the things that get deferred are often the things that matter most to the business, the edge cases, the specific workflows, the integrations that were considered secondary but turn out to be essential.
Why requirements processes often fail to bridge the gap
The conventional answer to the communication problem between IT and business is a requirements process: a structured method for documenting what the business needs so that IT can build it. In theory, this should work. In practice, it often does not, for several reasons.
Requirements documents are written in language that has to serve two masters: precise enough for IT to build from, clear enough for business stakeholders to validate. This usually means they satisfy neither group fully. IT finds them ambiguous in the technical detail. Business finds them difficult to validate because they describe the system rather than the process.
Requirements are also static documents in a dynamic situation. By the time a requirements document has been written, reviewed, approved, and implemented, the business context that generated the requirements has often evolved. The requirements are correct for the problem as it existed six months ago.
What actually bridges the gap
The most effective bridge I have found between IT and business is a person, not a document or a process, who genuinely understands both sides and can translate in real time.
This person does not need to be a technical expert. They need to understand enough about technology to know what is and is not feasible, and enough about the business to know what actually matters. They need to be able to sit in a meeting with an IT architect and understand the implications of a technical decision for the business process. And they need to be able to sit with a business team and translate their operational needs into something IT can work with.
In my experience, this is one of the rarest and most valuable capabilities in any organisation. It is also one of the most consistently underinvested. Organisations spend significant resources on technical expertise and on business expertise, and very little on the capability to translate between them.
The result is predictable: technology projects that produce technically correct solutions to the wrong problem, or correct solutions implemented in ways that the business cannot use. Both outcomes are avoidable with the right translation capability in place.
Practical steps for your organisation
If you recognise this pattern in your organisation, here are the practical steps I would suggest.
First, identify who currently plays the translation role, formally or informally. Almost every organisation has someone who sits in the middle, a product owner, a business analyst, a technically capable operations manager. Make this role explicit and invest in it.
Second, change how requirements are documented. Instead of system specifications, document the business process as it should work: who does what, in what sequence, with what information, and what happens when something goes wrong. Then build the system to support that process, rather than building the system and asking the business to adapt to it.
Third, include business representatives in technical reviews and technical representatives in business process discussions. Not as token participants, but as genuine contributors whose perspective is needed to make good decisions.
If any of this resonates with a challenge you are facing, I would be happy to have a direct conversation. No commitment, no agenda.