Nearly every service provider I’ve worked with runs some version of the same organizational pattern. You’ll probably recognize it.
An Architecture team designs. New products, new services, new topologies, new approaches. They hand that design to an Engineering team, who translates concept into reality: mapping it onto actual hardware and software, writing the configurations and procedures that will run in production. Engineering hands that to Operations, usually structured as a NOC hierarchy. Tier 1 opens tickets. Tier 2 handles the routine cleanup. Tier 3 is the final escalation point for customers and the group that actually implements the configs and procedures Engineering built.
Your company may draw the lines differently. Maybe Engineering implements its own changes. Maybe Architecture and Engineering are the same group. The specific org chart isn’t the point. What matters is the communication pattern it describes: whoever designs the service hands it off before they have to run it, and whoever runs it inherited a design they had no hand in. Ownership stops at the handoff. So does insight.
It doesn’t have to be this way. The methodologies we commonly call DevOps can be successfully applied to digital infrastructure similarly to pure software practices. Service providers and data center operators can restructure around flow instead of function, and in doing so change what the business is capable of delivering. Here’s the reasoning, the evidence, and some advice:
Conway’s Law Is Not a Metaphor
In 1968, Melvin Conway published a paper. His claim: any organization that designs a system will produce a design that copies its own communication structure. Fred Brooks named it Conway’s Law in The Mythical Man-Month. Decades later, a Harvard Business School study tested it directly, comparing open-source and commercial codebases, and found that loosely coupled organizations reliably build more modular products, tracking the coupling of the teams that built them.
This is not a management platitude. It’s closer to physics. The assembly line above doesn’t just slow down delivery, it gets built into the network itself. The handoff between Architecture and Engineering becomes an interface in your systems, one where intent gets lost in translation. The handoff between Engineering and Operations becomes another, one where the people closest to customer impact have the least influence over what they are asked to run. You didn’t design a fragile network. Your org chart did.
Flip it around and you get the Inverse Conway Maneuver: design the team structure you want, and the system architecture tends to follow.
Four Team Types, Applied to Infrastructure
Team Topologies, by Matthew Skelton and Manuel Pais, gives a vocabulary for what a flow-oriented org actually looks like. Four team types, not a murder of functional silos:
Stream-aligned teams own a service end to end. Not “network engineering” as a function, but an IP transit service team, a colocation and interconnection team, a cloud on-ramp team. Each takes a customer request through to production and owns what happens after.
Platform teams build the internal tooling that lets stream-aligned teams move without waiting on someone else’s calendar. Automation and orchestration, observability and telemetry, DCIM and IPAM. They treat the stream-aligned teams as customers, and they win when those teams can self-serve.
Enabling teams show up temporarily to build a capability, then leave. An automation coaching team that gets a stream-aligned team fluent in infrastructure as code, then moves on to the next one, rather than becoming the team everyone waits on forever.
Complicated-subsystem teams hold the depth that would otherwise overwhelm everyone else. BGP and traffic engineering. DWDM and optical transport. DDoS mitigation and security engineering. Specialized, insulated from becoming a bottleneck, not generalized into everyone’s job.
This is where the flow metrics actually show up. DORA’s research tracks four of them: deployment frequency, lead time for changes, change failure rate, and time to restore service. Two measure speed, two measure stability, and elite performers do well on both at once. Team topology is the mechanism. It’s not a separate initiative from improving MTTR, it’s the reason MTTR moves at all.
This Isn’t Just Theoretical
Telenet, a Belgian telecom with around 3,300 employees, ran a version of exactly this transformation and published the results. They moved from a Spotify-style agile model that still left them with functional handoffs, to what they call “tribe archetypes”: customer-facing teams that own a mission end to end, platform tribes that serve those teams as internal products, and enterprise tribes that keep the whole thing aligned. Their billing tribe alone runs around 150 people across 15 teams, owning the billing systems and the billing experience together, not handed off between separate groups. Telenet’s CEO described the result as tribes that continuously sense and adjust their own boundaries as the business changes, instead of waiting for the next executive-mandated reorg.
That’s a telecom applying this to itself, not a software company’s language borrowed for a keynote.
The underlying idea is older than Team Topologies as a book. In a 2006 ACM Queue interview, Amazon’s Werner Vogels described giving developers full operational ownership of what they built. It became known across the industry as “you build it, you run it.” That’s the stream-aligned team’s whole thesis, in five words, from almost twenty years ago.
Where the Framework Runs Out
Here’s a challenge: Team Topologies was built for software organizations, and a meaningful share of your infrastructure isn’t software. Fiber splicing. Outside plant work. Racking equipment and running patch panels in a colo. None of that fits cleanly into “complicated subsystem” or any of the other three types, because the book assumes the work product is code.
Even Telenet’s own case study makes this distinction, without saying so directly. It covers ServCo, the services side of the business, after Telenet split its physical network assets into a separate NetCo entity. The framework got applied to software and service delivery. Nobody in the published case study claims it maps just as cleanly onto fiber in the ground, because it doesn’t.
I don’t think you avoid this. I think you name it and adapt deliberately. My working approach: treat physical fulfillment (smart hands, splicing, racking, cabling) as a platform-style capability that stream-aligned teams draw on through a standardized, ideally self-service request, rather than trying to force it into one of the four boxes as written. That’s not in the book. It’s the kind of adaptation that has to be made on purpose, with someone who understands both your operational model and the framework, not defaulted into by accident.
The M&A Question, Both Directions
There are two sides to this for anyone doing diligence on a service provider or data center deal.
The red flag: if the target company’s team topology looks nothing like yours, Conway’s Law says their system architecture probably doesn’t either. That’s not just a people-integration problem to solve after close. It’s a signal that the network, software, and operational systems you’re acquiring were shaped by an org chart you didn’t design, and that reshaping the systems will require reshaping the teams first.
The lever: the same logic runs in the other direction. If you know which architecture you want post-close, and you know team structure is upstream of architecture, you have a deliberate mechanism for getting there. Use the Inverse Conway Maneuver to restructure the integrated teams on purpose, and the systems that follow inherit the deployment frequency and change failure rate you designed for, not whatever the two legacy organizations happened to default to.
Either way, team topology deserves the same diligence attention as the cash flow and the cap table.
Where This Leaves You
The handoff chain described in the opening is the default at nearly every service provider I’ve worked with. And Conway’s Law explains exactly why it produces the fragile, slow-to-change networks that come with it.
The fix is not a reorg for its own sake. It’s picking a team topology on purpose, understanding what it will produce, and treating the physical-world exceptions as deliberate design decisions instead of accidents.
Your org chart is already shaping your network, whether anyone planned it that way or not. Khadga Consulting helps service providers and infrastructure operators make that a deliberate choice instead of an accident. Let’s talk.
