I heard it again last week. Same sentence I have heard a hundred times before.
“Business wants this.” “IT does not understand the customer.”
Something snapped. Not because the sentence was new. Because it wasn’t.
We have repeated this split at every conference, in every retro, in every postmortem, for years. We renamed it, softened it, wrapped it in better slides. And somehow, nothing changed.
This article is about why that split is false, what it actually costs, and what to build instead.
Two Camps That Never Existed
“Business” and “IT” sound like two departments with two agendas. In practice, they are two labels for the same group of people trying to ship the same product.
The moment we draw that line, we stop asking “what does the user need” and start asking “whose fault is this.”
That is the real damage. Not the language itself, but what the language trains us to do.
The split does not describe reality. It creates a worse one.
Where the Line Actually Went
The line made sense once. IT was a support function. Business decided, IT executed.
That world is mostly gone.
Forward deployed engineers sit with customers. Full-stack builders own features end to end, from database to conversion metric. AI compresses the distance between an idea and a shipped feature to hours, not sprints.
The border between “deciding” and “building” has been dissolving for years. We just kept drawing it anyway, because the org chart was slower to catch up than the work itself.
What the Split Actually Costs
This is not a semantic complaint. The cost is operational.
- Decisions slow down, because nobody owns the outcome, only their piece of the process.
- Postmortems turn into negotiations about blame instead of root cause.
- Products get worse, because the person closest to the code has no stake in whether the feature works, and the person closest to the customer has no stake in whether it ships well.
Responsibility that is split in two is responsibility that belongs to no one.
The Line Is a Responsibility Dodge
There is a second reason we keep the split alive, and it is less flattering than tradition.
The line is convenient.
“Business asked for it, so we built it.” “It did not make sense, but that is not on us.”
That sentence lets everyone off the hook at the same time. The person who requested the feature is protected because “engineering approved it.” The person who built it is protected because “I was just executing.” Nobody decided. Nobody owns it. The feature ships anyway, and it quietly fails anyway.
A border between roles is often just a border between who gets blamed.
This is where it gets uncomfortable for leaders specifically. We do not hire unqualified people. We pay engineers a lot of money precisely because we expect judgment, not just execution. If we trust someone enough to write the code that runs the business, we should trust them enough to say “this request does not make sense” and be heard.
Stripping engineers of that voice does not protect the business. It removes one of the few checks that could have caught the mistake early.
Autonomy is not a perk. It is what you are paying for.
Outcome, Not Origin
Here is the reframe I keep coming back to: stop asking where someone sits. Start asking what they are accountable for.
It does not matter if someone sits in product, sales, analytics or development. What matters is whether they feel ownership of the problem, the user, and the result.
We are not building “business.” We are not building “IT.” We are building products.
That sentence sounds almost too simple to write down. It is also almost never true in practice, which is exactly the problem.
What This Looks Like Operationally
Removing the split is not a poster on the wall. It shows up in three concrete places.
- Shared metrics. If engineering and product track different numbers, they will optimize for different outcomes. One outcome metric, owned jointly, forces alignment before conflict starts.
- Language in the room. Ban “business wants” and “IT says” from meetings. Force people to name the actual decision-maker and the actual constraint instead of hiding behind a department.
- Rotated exposure. Engineers who never talk to customers optimize for elegance. People who never touch delivery constraints optimize for wishful roadmaps. Cross the wires deliberately.
None of this requires a reorg. It requires a leader willing to keep saying it until it sticks.
Closing Thought
- The business/IT split was a description of an old org chart, not a law of nature.
- It survives because it is comfortable, not because it is useful.
- Replace department as the unit of responsibility with outcome as the unit of responsibility.
- Say it once and nothing changes. Say it for a year, and the culture starts to shift.
Outcomes and delivery counts.