The IT Department Exists Because Someone Has to Translate. Soon Nobody Will.
For ten years I have tried to build genuinely cross-competent teams. It was never willingness that stopped it. It was the arithmetic.
Count for yourself. A team that can deliver the whole way without asking anyone: developers, test, design. Someone who knows the regulation. Someone who knows the customer. Someone who knows the business and the money. Someone who knows the process for real, not as a description. Data. Security.
You land at around twenty-five people. And twenty-five people is not a team — it is a department with a daily stand-up.
The best attempt I have been part of was in 2019 and took less than two days. Everyone in a room, one rule — every product needs a team with all the competences required to succeed — and no manager deciding who went where. They optimized for the products rather than for themselves, and every team left knowing why it existed.
And we went in properly. The business’s own translators — the people who knew both the process and what it meant for a system — ended up inside the development teams. Not as requesters. As members.
That was as far as it was possible to go in 2019, and it was a real improvement. But notice what we actually moved in. We moved in the translator, not the competence. The lawyer stayed where she was. So did the economist. So did the person who really owned the process. What fitted was somebody who could speak for them — and a representative of a judgement is not the same thing as the judgement.
The rest stayed outside. Not out of unwillingness. There was no room.
A first step, then. And a good one — the best available in 2019.
The second step has not been possible until now.
Let me be exact about what merges
The claim is that the business and development become the same team. Not that IT disappears.
Those are two different things that usually sit in the same department and are rarely separated in the conversation. One is development: turning an intention into something that works. The other is core IT — network, identity, platform, operations, integration, data at scale, the workplace, the thing everyone else stands on.
It is the development half that merges with the business. Core IT merges with nobody. It becomes something else, and I will come back to what.
It didn’t work, for three reasons
It was too expensive. Twenty-five people in a team can be defended once, for the most important product. Not across twenty teams. The economics object long before the ambition does, and then what always happens happens: one genuinely cross-competent team, and nineteen sharing the rest through queues.
It was person-dependent. The broad coverage nearly always rested on a couple of people who happened to know more than their own area. That works — until one of them changes job or takes three weeks off, and it turns out the team was cross-competent on paper and through a human being in practice.
And the quiet reason: the model assumed a kind of person. For seven people to cover everything, each has to be roughly this tall — properly good at their own thing and continuously picking up the next one. Some want that and thrive on it. Many do not, and they are right not to. They are good at what they are good at, and they are under no obligation to become broader because an organizational model requires it. A model that only works with superhumans is not a model. It is a wish list with an org chart around it.
Which is why adding people doesn’t help
A team should be small enough that everyone in it can hold the whole of what they are responsible for in their head. Team Topologies gives the constraint its best name — cognitive load — and it is a better measure than headcount, because it measures the thing that actually binds.
A team of five carrying four unrelated domains is heavier than a team of nine carrying one coherent capability. Counting people tells you almost nothing. Counting how many separate things they have to understand tells you most of it.
I have watched an organization “fix” an overloaded team by adding two people, which made the load worse — more coordination, more context to keep in sync, the same domains still sitting there. And watched another fix it by moving one domain out, with no change in headcount, after which the team was visibly faster within a month.
So the three reasons are really one: every additional competence in the team cost a whole human being, and a human being takes up room in the budget, in the room, and in everyone’s head.
What was missing was not the hands. It was the judgement.
This is the part I am most sure of, because it can be tried tomorrow.
Find the person the team keeps waiting on — the one whose assessment is needed before anything can be called finished. Move them inside the team. Then let them decide without checking, which is the half that gets skipped and the half that matters.
It will cost somebody a person they consider too valuable to tie down. The objection is genuine and usually wrong. The specialist spread across six teams is not being leveraged — they are being queued. The leverage everyone believes they are getting is mostly other people waiting politely.
And when the competence genuinely cannot be embedded — there are three of them and eleven teams need them — the honest answer is not a better queue. It is to look at what they are actually being asked for, and how much of it could be settled once, written down, and stop being a question.
Hold on to that sentence. It is the whole bridge to what is happening now.
That is why the translation layer existed
Ask why the boundary between IT and “the business” exists and you get answers about governance, standards and security. All three are real. None of them explains why the boundary appeared. They grew up around it.
The boundary exists because turning an intention into a working system required an unusual competence. Unusual competences get gathered into a function, given a queue and managed as a supply. The requirements document, the intake process, the prioritization forum, the delivery contract — and the phrase the business, used by people who work for the same company — all descend from a single premise: that someone has to translate.
That premise is the thing that is going.
AI removes part of it. Not all of it.
Be precise about what actually lightens, because this is where the argument otherwise turns optimistic.
What lightens is the breadth each person has to carry alone. Part of the technical load can be carried by something else, and that frees up not hours so much as room. Three things follow, and all three are what sank the earlier attempts:
The economics. The coverage that required twenty-five people fits in nine. A team that size can exist in twenty places, not only in the most important one.
The person-dependency shrinks. Some of what sat in one head is now written down and runnable. That is not the same as it disappearing, but the difference between “we ask Maja” and “it is in the rule Maja wrote” is the whole difference between a team that works and a team that works when she is there.
The demand for superhumans falls. You no longer have to be broad to belong. You have to be genuinely good at your own thing, and able to work in a team where the rest is in the room — as a person or as something else.
What does not lighten: the judgement, the ownership, the accountability for the outcome, and the will to learn. An agent does not make anyone a lawyer. It makes it possible for the lawyer to sit in the team without the team bursting at the seams.
What we built in 2019 was a well-chosen representative per area. The second step is that the representative can be exchanged for the person.
And that is the difference from every earlier attempt. This is not a better idea than the one I had ten years ago. It is the same idea in a reality where it holds, for the first time, both economically and structurally — not only on a whiteboard in a room where everyone agreed.
Cross-functional on the inside is not cross-functional from the outside
Many teams called cross-functional are cross-functional inwards. They have developers, test and design — and still need five other teams to get anything into the world.
The test from outside is harder, and it is the only one anybody else notices: can the person who needs something get it from the team, without knowing how the team is composed?
Be careful with the answer. The lowest form of interface is a person you have to know — and from the inside it feels like the highest, because for anyone who knows her the answer arrives immediately. A team can look self-sufficient right up until that person is on holiday.
The teams I see passing the test today nearly always work on purely digital products — and they pass it despite lacking several of the competences. That is worth pausing on.
They pass because the whole chain sits inside their boundary: no warehouse, no service desk that has to do its part, no physical delivery, no other department between the decision and the user. Nothing stops them. That is not the same as having everything they need to decide well.
It is the difference between self-sufficient and equipped. A team can go from idea to production in a week and still make a decision about personal data that nobody in the room can assess, or set a price whose consequence nobody sees until the quarter closes. The outside test measures whether anyone is blocked. It does not measure whether anyone could have objected.
So the evidence is weaker than it looks, in both directions. That cross-competence works where it is easiest to achieve does not say it works in a bank with two hundred years of process, or in a company whose product goes out on a lorry. And the teams passing the test today partly do so by having fewer things to take into account, rather than by having covered them.
This is where the change bites. For those already passing the test it does not solve delivery — that was solved. It makes room for the lawyer, the economist and the person who knows the process, which is the half that was missing. For everyone else it is the other way round: the obstacles are real and some of them no agent removes — a boundary against something physical, a regulator, a negotiated agreement. But at least those can be seen and discussed. The shortage of room in people’s heads never could be. It only showed up as everything taking longer than anyone could explain.
A team that passes both halves stops being a development team. The word names the competence that has just stopped being the scarce one.
And core IT?
This is the part that usually falls away when somebody says IT and the business should merge, and it deserves saying plainly: core IT does not dissolve into the business. It becomes a platform.
Network, identity, operations, integration, data at scale, the thing everything else rests on — and the capabilities where being wrong is expensive. That remains specialist work for a long time yet, and it becomes more important rather than less, for a simple reason: when more people build more, what is needed is better coordination, not more control.
But the relationship changes shape. Close collaboration is expensive and should be temporary. Consuming something as a service is cheap and should be the default the moment the thing is stable enough to have an interface. In friction terms: collaboration is a handover you have chosen to keep, a service is a handover you have removed.
That gives core IT a different measure of success. Not how much the function delivers, but how much others can do without asking it. A platform is measured by what becomes possible without its involvement. A queue is measured by throughput, which is why a queue never becomes a platform merely by getting faster.
And expect the building to spread. More people will create more software in more corners than any plan assumes. Some of it will be very good. Some of it will be a spreadsheet’s worth of business logic living on somebody’s laptop, which is not new — it is just faster now. The question is not whether to allow it, but which guardrails and interfaces make it safe enough to be a good thing. Those take longer to establish than the tools take to arrive. That gap is the whole planning problem, and it is core IT’s job.
The friction does not disappear. It changes form.
Removing technical friction does not remove the complexity. It relocates it — into ownership, into interfaces, into information, into decisions.
Take three things AI would plausibly accelerate where you work. For each, ask who owns the outcome. Not who runs the process — who is answerable for whether the result was any good.
Where that returns a name, acceleration is straightforwardly a good idea. Where it returns a committee, the situation is more interesting than it looks. A committee is an owner, simply a slower one, where the accountability has been shared out until it is nobody’s in particular. That can be entirely correct. What it cannot do is answer at the speed the acceleration demands. Make the work ten times faster and a monthly forum becomes the whole system’s clock.
The same thing from the other direction: an agent that reaches a question nobody has settled stops and asks. A person guesses and carries on, and the cost surfaces six months later.
Execution can be delegated. Ownership cannot.
And this is where digital transformation takes its next step
The phrase has been carried for fifteen years, mostly by programmes. Start date, end date, steering group, completion report.
Run that way, a transformation treats the organization as a machine to be rebuilt and handed back — and it manufactures friction while it runs: its own boundaries, its own steering group, its own reporting line and a handover at the end. Meanwhile the thing it was meant to change carries on being what it always was, something living that never finishes. And the friction returns the moment attention moves elsewhere.
What is happening now is not a programme. It is that the basic unit changes shape — and when the basic unit changes shape, the structure becomes a different one rather than a faster version of the old.
The unit becomes the capability, not the system and not the function. It is the only boundary that is coherent by construction: the things inside belong together, so understanding one helps with the next.
The business sits inside the team, not on the other side of a document.
Core IT becomes a platform, measured by what others manage without it.
And the pace is set by what has been settled. Not by how many developers you have, but by how much the organization has actually decided and written down, so that work can proceed from it.
That opens things that were not possible before. A team that goes from idea to something working within the same week, without asking anyone. A smaller organization that can carry a capability that used to require a department. An org chart that stops being the tool you redraw when something needs to change, because the change happens inside the teams rather than between them.
Which is why I think this is the first real step. Not because the technology is impressive — it is, but it has been before. Because it is the first time in ten years that something has made the structure we have been describing all along actually possible to staff.
With one objection to the word worth keeping: this never finishes. It resembles tending something living more than transforming something. Programmes end. This does not — and that is exactly why it is worth starting with the structure rather than with the tools.
How far away is it?
Closer than it sounds, and further than the technology suggests.
The technical part is essentially here. The large middle — the ordinary building that consumes most of the development capacity — is already moving to the people who know why the thing is needed. Complex systems, integration, data at scale and everything where being wrong is expensive remain specialist work for a long time yet.
What sets the pace is not the models. It is how much the organization has already settled and written down, and whether ownership returns a name when something goes wrong. Two weeks on that question is cheaper than the pilot, and considerably cheaper than the eighteen-month conversation about who owns the data that otherwise follows.
So: a couple of years for those who have done the groundwork. Considerably longer for those planning to buy their way past it.
How many are ready?
Fewer than think they are, and it is not primarily a technical question.
The hard part is not learning the tools. It is what happens to an organization when it no longer needs as many people and functions to translate between business and technology.
A manager whose mandate rested on owning that translation will need to build something else. Specialists who sat centrally and answered team after team come closer to the work instead.
So the question for a technology leader is not how to adopt AI. It is which of the two parts you lead. One merges with the business and stops being a development function of its own. The other becomes core IT: a platform that makes it possible for others to build and change without asking every time.
Both are needed, and they are two different jobs. Few organizations have started talking about them as two.
And that is why I do not think this is fundamentally an AI question. AI changes what is possible. The rest is about how we organize ourselves when an old constraint disappears: where the line around a team goes, which competence has to be inside it, who gets to decide, and what should be shared.
Those are the same questions I was trying to understand when I wrote Organizational Flow. Back then I saw AI as something that would amplify the shift.
Now I am starting to wonder whether it is bigger than that.
Perhaps AI is what makes an organizational model we have talked about for years practically possible for the first time: small teams that can genuinely carry the whole capability, not only the development part of it.
So the interesting question is not how much faster we can build. It is what we do with the organization when we no longer have to build it around the translation.