You know this meeting. Business walks in with a date that was promised to a client last week. IT walks in with a list of reasons why that date is fiction. Forty-five minutes later everyone leaves frustrated, nobody changed their mind, and the only thing that got created was one more Slack thread full of passive-aggressive “just to clarify” messages.
Sounds familiar?
Here is what bothers me the most: in almost every organization I work with, both sides are competent, committed and genuinely want the company to win. And still, cooperation feels like hell. It is not a talent problem. It is a communication and leadership problem. And it costs a lot: McKinsey’s Developer Velocity research showed that companies in the top quartile (where business and technology actually work as one system) grew revenue four to five times faster than those in the bottom quartile.
So let’s name the 5 things that turn the business-IT relationship into a battlefield, and what you, as a tech leader, can do about each of them.
#1 Business Orders Solutions, IT Takes Orders
“We need a dashboard.” “We need an integration with X.” “Just add a button.” When business comes with a ready-made solution instead of a problem, IT becomes a feature factory. Engineers build exactly what was asked, and three months later it turns out that nobody uses it, because it never solved the real issue.
PMI’s Pulse of the Profession found that inaccurate requirements management is the primary cause of failure in 47% of unsuccessful projects. And when poor communication was named as a primary cause of failure, 75% of organizations said it hit requirements harder than any other area.
What to do: stop accepting solutions, start asking for problems. “What is going to be different for the client when this is done? How will we know it worked?” Marty Cagan describes this beautifully as the difference between feature teams and empowered product teams: teams that get problems to solve, not lists of features to build.
#2 Two Languages, Zero Translators
Business speaks revenue, clients, deadlines, market windows. IT speaks architecture, dependencies, risk, scalability. Both are right. Neither is understood. And when people do not understand each other, they start to assume, and assumptions are the fastest way to build a communication debt that the whole organization pays with interest.
From the Process Communication Model perspective, it is often also a clash of personality Bases. Many IT teams are full of Thinkers who need facts, data and logic before they commit. Many sales and business leaders have a strong Promoter energy: fast, action-oriented, “let’s just do it and fix it on the way”. Put them in one room without awareness, and each one sees the other as the problem.
What to do: become the translator. Before any important discussion, translate your technical argument into the business consequence (“if we skip this, onboarding new clients will take 3 weeks instead of 3 days”). And ask business to translate their request into the outcome they need.
#3 The Invisible Work Nobody Paid For
“Why is it taking so long? It’s just one field.” Every tech leader has heard it. What business does not see is the technical debt underneath that one field. In McKinsey’s survey of CIOs, 10 to 20% of the technology budget meant for new products gets diverted to resolving tech debt issues. That is real money and real time, invisible on the roadmap, so it looks like IT is just slow.
What to do: make the invisible visible. Show the tech debt in business language (time, cost, risk to clients), and agree on a fixed share of capacity for it. If you do not talk about it, you are the one who will be blamed for it.
#4 The Blame Game (a.k.a. the Drama Triangle)
“IT is always late.” “Business always changes its mind.” Once these sentences become the default, you are deep in the Drama Triangle: someone plays the Persecutor, someone the Victim, and somebody (usually a project manager) desperately tries to Rescue everyone. Lots of energy, zero value created.
This is not only psychology. DORA research shows that a high-trust, generative culture (where failure leads to inquiry, not to looking for the guilty one) predicts both software delivery and organizational performance. Blame literally slows you down.
What to do: when something goes wrong, replace “who did it?” with “what in our process allowed this to happen?”. And watch your own reactions. If your Base is Persister or Thinker, distress can make you judgmental, and your team will copy exactly that.
#5 No Contract, Only Expectations
Business expects IT to “just deliver”. IT expects business to “finally decide what they want”. Nobody said it out loud, so nobody agreed to it. This is the root of most of the frustration I see: expectations that were never turned into a contract.
A good contract (in Transactional Analysis terms) has three levels: administrative (who, when, where), professional (what exactly, how we measure it) and psychological (what we are really afraid of, what we need from each other). Most business-IT agreements cover only the first one, if at all.
What to do: at the start of every important initiative, have a contracting conversation with your business partners. Agree on:
- the problem we are solving and how we will know it is solved,
- who decides about scope changes (and how fast),
- how and how often we talk about risks and delays,
- what “done” really means for both sides.
And then re-contract every time something changes. Because in tech, it always does.
Where Does It Start?
With you. Not because it is fair, but because you are the one reading this. The business side will not wake up one day speaking your language. Somebody has to build the bridge first, and leaders with high Communication Intelligence (CQ) do exactly that. I wrote more about the skills behind it in Building a Product-Centered Organization.
If you want to see these patterns from the inside, read The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. It is a novel, and there is a big chance you will recognize your own steering meetings on the very first pages.
So here is my question for you: which of these 5 is costing your team the most right now, and what is one conversation you could have this week to start changing it?
PS. If you want a practical blueprint for building those bridges (with the CQ Leadership Method, contracting templates and PCM tools), grab “From Code to People”. And if you prefer this kind of content weekly, straight to your inbox, join the Leman Leadership Pulse!
