Digital transformation initiatives don’t fail because of bad technology choices. They fail because the business can’t coordinate the work. Digital transformation is inherently cross-functional. It impacts multiple organizations within the enterprise that think of themselves as vertical, siloed, or independent. When you set out to change how things work, to change what you’re doing or how you do it, you need coordination across different groups. But most organizations focus obsessively on the technology stack while completely ignoring the communication stack.
This results in communication debt accumulating faster than the transformation can progress. You end up in a death spiral where more time is spent on coordination than on actual work and there are still surprises in the form of breaking changes.
In this article, you’ll discover:
- Why it takes so long to do seemingly trivial things and what this reveals about communication debt in your organization
- The military exercise that proved decisively that decentralized decision-making beats command-and-control
- The simple formula that explains why your transformation is drowning in coordination overhead
- The three interaction modes that determine whether teams spend their time on value delivery or figuring out how to work together
- Why “working in public” internally is the key to scaling communication and how one company eliminated status meetings entirely
- The hub-and-spoke model that prevents signal degradation from executive vision to front-line execution
- How treating teams like APIs – with published interfaces, SLAs, and self-service documentation – can cut coordination time by 80%
What is communication debt?
If you’re familiar with technical debt, you’ll understand communication debt immediately. It’s when the efficiency of communication becomes so poor that more time is spent on communication than on actual work.
The math is simple but brutal. Communication pathways increase according to the formula n(n-1)/2, where n is the number of people involved. Add one more person to a five-person team and you don’t just add one more communication channel – you add five. With ten people, you have 45 potential communication pathways. With twenty people, that jumps to 190.
These pathways can be served efficiently or inefficiently. Here’s what communication debt looks like in practice:
Too many meetings. Everybody spends their entire day in meetings trying to figure out how to work together. Teams spend all their time in what should be temporary “collaboration mode” – a design flaw, not a feature.
Constant surprises. People get blindsided by changes, misalignments of purpose, misalignments of timing, misalignments of expectations. Something breaks as a result. Friction develops between teams.
Communication chaos. Unstructured, ungoverned communication paths everywhere. No defined roles for what goes in email versus Slack versus meetings. Haphazard communications across multiple channels make it impossible to track anything.
Everything is push-based. If you can’t find something out without talking to somebody, that’s a communication problem. When all information requires direct human interaction, you can’t scale.
Let me give you a concrete example. I recently worked with a client where it takes 13 days to provision a new development environment. Why? Because provisioning requires manual communication between four different organizations. On average, it takes 32 individual Jira tickets just to get one environment stood up.
It should take one ticket. One automated process. Complete in minutes, not days. That’s a measurable communication overhead.
Why Traditional Organizational Models Fail in Digital Transformation
Most organizations operate with a command-and-control structure that works reasonably well in stable environments. But digital transformation isn’t a stable environment. It’s dynamic and constantly evolving, requiring continuous learning and adaptation.
The Command-and-control problem
The Millennium Challenge 2002, a $250 million U.S. military war game, remains one of the most controversial exercises in military history.
The Blue Team (representing U.S. forces) used a highly centralized, high-tech approach dependent on complex digital command-and-control systems. The Red Team, led by retired Marine Lieutenant General Paul Van Riper, used a decentralized strategy with low-tech communications: motorcycle messengers, light signals, methods that completely bypassed the sophisticated electronic surveillance.
Within the first few days, Van Riper’s decentralized force sank 16 U.S. warships, including an aircraft carrier. The exercise was halted and “reset” because the decentralized approach won so decisively that the organizers couldn’t test the new technologies they’d spent millions to showcase. Van Riper was so disgusted by the subsequent rule changes and scripting that he quit halfway through, stating, “Nothing was learned.”
What should have been learned was this: decentralized decision-making beats command and control in dynamic environments.
The reason for this is signal degradation. It’s like playing telephone. Information degrades as it moves from the top of the organization to the people actually doing the work. You see this constantly. The organization’s strategic goal is “grow market penetration by 10%.” Great. But how does a quality tester’s daily work connect to that goal? For most people, it doesn’t. They can’t see the connection, so they can’t make informed decisions.
And command and control absolutely doesn’t work when you’re learning new things every day, which is exactly what happens in digital transformations.
The ad hocracy problem
On the flip side, you can’t just say, “Every team, go do your part of X and report back.” The signal-to-noise ratio becomes too high. Nobody knows what anyone else is doing. Efforts are duplicated. Critical dependencies get missed.
I’ve seen organizations swing between both extremes, sometimes simultaneously. One department operates under rigid command-and-control while another is in complete chaos. Neither works.
The cognitive load problem
There’s a deeper issue here that Matthew Skelton and Manuel Pais address brilliantly in their book “Team Topologies.” Teams have finite mental bandwidth. The more time and cognitive energy they spend figuring out how to work with other teams, the less they have available for actual value delivery.
Meeting culture is the most visible symptom of this problem. You’ve probably experienced it: large organizations where everybody spends their entire day in meetings and does their actual work around the edges – early mornings, late evenings, weekends. That’s not sustainable, and it’s certainly not scalable.
The API-driven enterprise model
The solution is to treat your organization the way you treat your software architecture. In software, we use APIs – Application Programming Interfaces – to define how different systems communicate with each other. Each system publishes its interface: here’s how you send me requests, here’s what format I need, here’s what you can expect back, here’s how long it will take.
The same concept applies to teams. Each team defines and publishes their “API” – their interface for how other teams work with them. This creates clear boundaries, reduces cognitive load, and makes communication scalable.
This isn’t only useful for digital transformation initiatives, but transformation is where the pain becomes acute enough that you can’t ignore it anymore. When you’re trying to coordinate significant changes across multiple organizations, you need a communication architecture that actually works.
The four key components of a communication architecture
1. The governance layer: RACI and making work visible
Start with a well-defined RACI (Responsible, Accountable, Consulted, Informed) matrix. There are variations – some organizations use DACI or RASCI – but the concept is the same: clearly define who does what.
Don’t just create a spreadsheet that lives on a shared drive somewhere. Codify it into your workflow. Automate it into your processes. When it’s time for a decision to be made, the right person should be automatically notified. The process should enforce the governance without requiring meetings.
This connects directly to making all work visible. Pick one system – Jira, Asana, whatever – and make that the single source of truth. All work gets tracked there with no exceptions. No shadow systems. No work happening outside this visibility.
For example, people who are accountable for approvals get automatically assigned to a ticket when it’s ready to move from “work completed” to “done and accepted.” Only they can move it forward. No meetings are required. No emails asking for approval. The system enforces the governance.
2. The hub-and-spoke model: cross-functional liaisons
Digital transformation requires a coordinating layer that connects all the different functions involved. Each function needs a single person who represents that function at what I’ll call the digital transformation project board. Not a governing board – that implies too much hierarchy – but a group of peers, probably at the director level. Not senior VPs; that’s too high. You need people close enough to the work to understand the details but senior enough to make decisions for their organizations.
One of my clients calls these people “technology business partners.” They are Sr Directors and VPs that have day jobs in the technology organization and this label captures the role: they’re connectors, translators, the spokes in a hub-and-spoke model.
This group reports to whoever is in charge of the overall transformation – typically a senior executive, SVP, or CXO who is singularly accountable for delivery. That person sets the north star: the vision, the narrative, the timeline, the high-level roadmap, the expected outcomes, what the business looks like when the transformation is complete.
The cross-functional liaisons work with that executive to create the detailed plan. But, and this is crucial, they don’t sit in a room and define all the work for their teams without input from those teams. Instead, they’re translators. They take the mission of the initiative and work with their teams to figure out what work needs to happen.
This is decentralized decision-making in action. If you’re planning a migration from an outdated technology stack to a modern one, the best person to define what that work looks like is probably the lead engineer of the team that’s going to do it. Not a director in a conference room guessing at the complexity.
3. Team APIs: published interfaces for each team
Now we get to the core concept. Each team defines and publishes their API – their interface for how other teams work with them. This has three components:
Inbound Interface
How do you request work from this team? Is it through Jira? A specific form? Make it explicit. And make it equally explicit what doesn’t work: not through DMs on Slack, not through emails to individual team members.
If you’ve decided to make all work visible in Jira, then requests go through Jira. Period. This isn’t about being rigid for the sake of it, it’s about ensuring there’s a record, so that everyone who needs to know can see it, and so that work doesn’t get lost in someone’s inbox.
Service Level Agreements
People should know what to expect. How long before the team will acknowledge a request? How long before they’ll prioritize it? How long before they’ll commit to completing it?
If it takes your team three days to look at incoming requests, advertise that. If it’s one hour, advertise that. The specific timeline doesn’t matter as much as setting clear expectations. Uncertainty creates anxiety and generates unnecessary follow-up communications.
Self-Service Knowledge Base
This is critical for scaling. Every team should maintain a knowledge base organized for self-service. For example, the identity management team should have a self-service article on resetting passwords. If someone has to open a ticket every time they forget their password, we have a problem.
The same principle applies to everything a team does repeatedly. Document it. Make it searchable. Make it accessible. Reduce the communication overhead.
4. Interaction modes
“Team Topologies” defines three interaction modes between teams, and these are worth adopting explicitly:
Collaboration Mode
This is intense, high-cost, high-bandwidth interaction between teams. It should only be temporary. You use collaboration mode when designing the plan for your digital transformation. You use it when solving a novel problem that requires multiple perspectives. But once the problem is solved, once the approach is defined, you move out of collaboration mode.
If teams are in collaboration mode all the time, you didn’t do the planning properly.
There’s one exception and that’s production outages. These require temporary, intense collaboration. One of our clients handles it like this: when there’s an outage, they create a Jira ticket and an online meeting, and they link the meeting to the ticket. Everyone who needs to be involved – someone from the application team, someone from infrastructure, someone from networking, someone from security – joins the meeting. They work their respective issues and call out updates so everyone can hear.
This is cross-functional collaboration at its most intense. Recently, they had an outage where a new firewall rule unintentionally blocked traffic between the application and its backend. Without the security people in that meeting, they never would have identified the problem. But this is temporary, crisis-mode collaboration. It’s not how you operate day-to-day.
X-as-a-Service Mode
This is the goal for most team interactions. One team provides a service that another team consumes with minimal interaction. Self-service. No friction. No waiting. No manual steps.
Resetting passwords should be X-as-a-Service. Provisioning a development environment should be X-as-a-Service – push a button, get an environment. Low cost, highly efficient.
Remember that client where it takes 13 days and 32 Jira tickets to provision an environment? That’s the opposite of X-as-a-Service. That’s communication debt compounding daily.
Facilitating Mode
This is an advisory role. For example, I have a client with an enterprise architecture team where each architect is responsible for one or more technology areas. They provide architectural guidance to software development teams. “Here’s the pattern you should use for this integration.” They don’t do the work, they facilitate the implementation.
Project managers in large organizations often play this facilitating role, helping teams navigate obstacles, coordinating without commanding.
Building a documentation culture to go from push to pull
The most fundamental shift you need to make is moving from push-based to pull-based communication.
In most organizations today, information is pushed. If you want to know something, you have to ask someone. You send an email, you schedule a meeting, you send a Slack message. Every piece of information requires direct human interaction. This doesn’t scale.
In a pull-based model, information is proactively documented and made accessible. When you want to know something, you go look it up. You pull the information to yourself.
I have a client that uses Miro boards as an ongoing dialogue about implementations. Nobody has to write status emails, nobody has to send reports, nobody has to have meetings to explain what’s happening. Everyone involved can go to the Miro board whenever they want to know the current state. They pull the information themselves. Miro isn’t the important part here, the mechanism and exclusive use of a single tool is what makes this work.
How to build this culture
Start with making all work visible. Create a culture where documenting status, progress, and issues publicly in your work tracking system is expected. Information should be in comments. Status updates should be on tickets.
Enable asynchronous collaboration through your work tracking tool and collaboration tools. When someone uses Miro to work through a design problem, that Miro board should be linked to the relevant Jira ticket. Anyone who needs to see it can easily get to it. It’s all in one place.
Get people used to what LinkedIn calls “working in public” – though I mean that in an internal sense. Make your roadmaps visible. Make your Confluence pages accessible to everyone. You might limit who can update things, but everybody should be able to see what’s going on.
If people can’t see what’s happening, they’ll resort to the old patterns: sending emails, calling meetings, gossiping. Gossip is the worst form of communication debt because it spreads misinformation while consuming enormous amounts of time.
The push communications that remain
You can’t eliminate push communication entirely. Some will always remain. People want status updates. Executives need summaries. The question isn’t whether to have push communication but what the right channel is for it.
Maybe it’s a team Slack channel. Maybe it’s a weekly email. Maybe it’s dashboards with key metrics that people can subscribe to. Define the channel, and use only that channel for that type of communication.
The goal is to minimize push communication and make pull communication the default.
Designated channels for different communication types
This might sound bureaucratic, but it’s not. It’s about reducing cognitive load. When every type of communication has a designated channel, people don’t have to think about where to communicate. They don’t waste time searching across multiple systems for information.
Here are some examples:
If you need information about a ticket you’re working on, don’t DM someone on Slack. Tag them in the Jira ticket. They get notified and they can respond in the ticket comments. The information is there for everyone to see. This is a governed interaction.
Collaborations for in-progress work happen through the work tracking system and only through the work tracking system.
Status updates to all interested parties go through one designated channel and only that channel.
Urgent requests for assistance? What’s the right channel for your organization? Is it an @all in a Slack channel? Is it creating a high-priority “do right now” Jira ticket? Define it. Make it consistent.
This isn’t about control. It’s about creating predictability that reduces the mental overhead of working together.
The four communication layers in practice
When you put this all together, you get four distinct communication layers:
The Vision Layer
Executives do regular town halls, reiterating the vision. In change management we have a rule – the 7×7 rule – that messages must be repeated seven times in seven different ways before they take hold. This isn’t about talking down to people. It’s about overcoming the natural resistance and distraction that happens in any organization. Repetition creates clarity.
The Translation Layer
This is where your cross-functional liaisons operate. Managers, product managers, capability leads. They take the vision and translate it into their teams’ context. What does this mean for us? What do we need to do? What’s our part in this?
The Execution Layer
This is the pull-based culture using work tracking tools. Designated channels for different types of communication. Asynchronous collaboration. Teams doing the actual work with minimal coordination overhead.
The Demonstration Layer
Digital transformations don’t happen all at once. You don’t just replace the mainframe with the cloud in one go. They happen in small iterations, in pieces. Progress needs to be visibly demonstrated at regular intervals.
I don’t mean reporting up to executives, I mean showing everybody involved – across all the teams – that progress is being made. People need to see visible results, tangible changes. It gives them confidence and it provides a forum for feedback so you can adjust course if needed. Demos are part of the communication architecture.
From digital transformation to operating model
The API-driven enterprise model is the most effective way to set up a communication architecture for a digital transformation initiative. But I’ve also found that organizations that implement this model for transformation often realize it’s actually a better way to run the entire organization.
When communication scales properly, when the architecture is intentional rather than ad hoc, teams spend their time on value delivery instead of coordination overhead. The architecture becomes self-sustaining and the system maintains itself.
You still need governance. You still need leadership setting the vision. But the day-to-day coordination happens through well-defined interfaces rather than through constant meetings and status updates.
That’s the goal. That’s what makes digital transformation sustainable rather than just another exhausting initiative that burns people out and delivers minimal results.
Moving forward
If you’re in the middle of a digital transformation that feels like it’s drowning in coordination overhead, the problem probably isn’t your technology choices. It’s your communication architecture – or the lack of one.
At Ten Mile Square, our technology assessment process helps CEOs identify these kinds of operational bottlenecks. We look at the technology, yes, but we also look at the organizational patterns that are preventing you from executing effectively. Our 5-step assessment involves discovery, problem definition, gap analysis, key findings and recommendations, and comprehensive reporting.
We don’t just identify problems. We provide detailed action plans that address both the technical gaps and the organizational constraints that are limiting your ability to scale.
If your digital transformation is spending more time in meetings than making progress, let’s talk about what’s actually broken and how to fix it.