I keep getting called in after the technology already arrived.
The automation platform is installed. The AIOps dashboard is live. The intent-based networking tool has a license and a champion and a signed contract. Procurement worked. The rollout didn’t. And when I start asking questions, the answers are often the same: leadership bought a solution to a problem they hadn’t actually diagnosed. The real problem isn’t the tool. It’s the culture.
For enterprise IT shops, that’s an expensive lesson. For service providers and data center operators, it’s a nightmare. Your customers are buying uptime, throughput, and reliability; and when your operations culture can’t support the automation systems that guarantee those things, the failure goes straight to revenue and customer retention. There’s no back-office cushion. The degradation is visible, measurable, and yours.
That’s the context. Not “culture matters too.” Culture is the variable that determines whether your automation (including AI) investments return anything at all.
The Science of Culture
In 1988, sociologist Ron Westrum developed a typology of organizational cultures that has held up remarkably well across complex, high-stakes technical domains. He identified three types. Pathological organizations are power-oriented: information gets hoarded, failures lead to scapegoating, new ideas get crushed by whoever finds them threatening. Bureaucratic organizations are rule-oriented: information moves through formal channels, failures get siloed, novelty is tolerated when it follows procedure and ignored when it doesn’t. Generative organizations are performance-oriented: information flows to whoever needs it, failures drive inquiry rather than blame, and the mission is clear enough that people can make judgment calls without waiting for permission.
Most network operations teams, if they’re being honest, are bureaucratic. A meaningful number are pathological. Very few are generative.
The question isn’t which label fits your org chart. It’s what actually happens when something breaks at 2am, when an engineer wants to try something new, when an automation script causes an unplanned outage. Does information flow to the people who need it? Does the team learn, or does it blame?
The DORA research program has been tracking the relationship between culture and operational performance across technical organizations for years, and the findings are not ambiguous. The 2021 Accelerate State of DevOps Report found that elite performers who meet their reliability targets are 2.9 times more likely to have a generative culture than their low-performing counterparts. For an SP or DC operator, that number isn’t abstract. Reliability is your product. The 2.9x gap in performance culture is a gap in your ability to deliver what you’re selling.
The 2023 DORA Report extended that finding: generative cultures correlate with 30% higher organizational performance overall. Culture isn’t “soft.” It’s a performance variable. The research is consistent across years and across organizations. A pathological or bureaucratic ops culture structurally limits what your automation stack can return.
Resistance Is Personal
There’s a dimension to this that the Westrum typology describes but doesn’t fully explain, and it operates at the individual level before it ever shows up at the organizational one.
Network engineers, especially experienced ones, build their professional identity around what they know how to do. I’ve written about this before, including in Identity Crisis: Navigating the Resistance to Network Automation. The person who spent fifteen years mastering a vendor’s CLI isn’t being irrational when they resist automation that replaces that mastery. They’re defending something real. The resistance isn’t about the tool. It’s about who they are.
I’ve watched this play out in a specific, recurring pattern that shows up across operator environments. An engineer builds something (sometimes a custom tool, sometimes a workflow wrapped around a commercial platform, sometimes just deep expertise in a legacy system) and becomes its sole custodian. The team grows around it. The capability gets outgrown. When the conversation turns to replacing or evolving it, the engineer who owns it fights back. Sometimes openly, sometimes by running out the clock on evaluations, sometimes by making the replacement seem harder than it is.
The fight is never really about the tool. The tool is the identity. And no amount of change management process dissolves that if the culture doesn’t offer a credible alternative identity to move into.
In a generative culture, that engineer becomes the architect of what replaces their tool. The organization honors and leverages their expertise in the transition. In a bureaucratic or pathological one, they either win the fight and keep the organization stuck, or they lose it and leave, taking the knowledge with them. Neither outcome is good.
Culture Eats Culture For Breakfast
I spent several years at Time Warner Telecom in the early 2000s, and I had a hand in building what was, for its time, a highly automated network. The team was small. The culture was generative. We built operational capabilities that most carriers twice our size couldn’t match.
Level 3 acquired Time Warner Telecom in 2014. CenturyLink acquired Level 3 in 2017 and eventually rebranded to Lumen. What happened to that automated network? Level 3 tried to replicate it across their broader infrastructure. They couldn’t. The technology wasn’t the hard part. The culture was. Today, that network still runs as a distinct entity within Lumen (preferred where it’s available) because the larger organization never built the cultural capability to absorb it.
That isn’t a technology failure. It’s a culture failure that has persisted for over a decade and that still shapes how a major carrier operates today.
Think about that from an investment perspective. Multiple rounds of M&A activity, billions of dollars in transaction value, and the acquirer couldn’t integrate the most operationally advanced part of what they bought because they couldn’t close a culture gap. The capability is right there. Stranded.
This is not a unique story. I’ve watched versions of it play out at multiple operators. The larger, more traditional culture reliably suppresses the more advanced one. The smaller, more capable team either gets assimilated into the old way of doing things, quietly shuts down their better tools, or runs in isolation indefinitely. The automation gap that acquisition was supposed to close doesn’t close. It just gets more expensive.
A Timebomb
There’s a dimension to this that’s accelerating, and most executive teams are not fully reckoning with it.
The engineers who carry the institutional knowledge of how SP and DC networks actually work are starting to retire. I’m watching it happen among people who were my mentors and my peers. The retirement announcements show up on LinkedIn with real regularity now. These are engineers who know why the network is configured the way it is. Which undocumented workarounds are holding the whole thing together. Why you never touch that one parameter. What happened the last time someone did.
When they leave, whether to a beach, a vineyard, or just another job, that knowledge goes with them. That is unless it’s been codified, automated, and made institutional rather than personal. In a generative culture, knowledge flows and gets documented because that’s what the culture rewards. In a bureaucratic or pathological one, it stays locked in people’s heads because that’s how those people remain valuable. Then they retire. And then it’s gone.
Hyperscalers are making this harder. They’ve been pulling from the same talent pool that SPs depend on: engineers who understand both legacy network infrastructure and modern automation tooling. That cohort is small and getting smaller. Losing them isn’t just a headcount problem. It’s a continuity problem. The question of whether your organization can function after key people leave is, at its core, a culture question.
Culture is Discipline
A generative SP/DC operations culture isn’t soft or loose. It’s high-discipline. That discipline is simply applied to outcomes and information flow rather than hierarchy and protocol.
In practice, incidents generate learning rather than blame. Post-mortems are blameless not because nothing went wrong, but because blame doesn’t produce improvement and everyone knows it. The engineer who surfaces a problem early gets recognized. The one who hides it until it becomes a crisis does not. Teams share failure information across the organization rather than burying it in tickets or letting each team quietly handle its own incidents.
Knowledge doesn’t live exclusively in people’s heads. Runbooks exist and get maintained. More than one person documents and understands the automation. The engineer who built the tool is expected to make themselves unnecessary rather than irreplaceable. That’s a cultural value, and it has to be modeled from the top down. If leadership tolerates the hero who nobody else can replace, the culture sends a clear message: hoarding knowledge is a career strategy.
New approaches get tried in controlled ways. Canary deployments, rollback procedures, staged automation aren’t borrowed DevOps concepts (well, maybe they are, but also); they’re how you build a team willing to experiment on live infrastructure without gambling the network on each attempt. When failure is survivable and instructive, teams stop avoiding risk and start managing it. That’s how automation actually gets adopted rather than installed.
The metrics shift too. Traditional NetOps tends to measure activity: changes deployed, tickets closed, configurations pushed. These tell you how busy the team is. They say almost nothing about whether your customers’ experience is improving. Generative teams track outcomes. In practice, that means two numbers: MTTR: how fast you restore service when something breaks. And change failure rate: what percentage of your changes cause incidents.
The ROI of Culture
If you’re evaluating an automation program for an SP or DC operator, you need to build in a culture variable or your projections are fiction.
Vendor ROI projections for network automation consistently lead with OPEX reduction and faster time-to-provision. What they almost never model is adoption rate or the cost of a failed rollout due to cultural resistance. That cost isn’t just the wasted tool budget. It’s the deferred competitive advantage while the market moves and you don’t. It’s the operational risk that accumulates when engineers route around systems they don’t trust or understand.
For acquirers specifically: if the cultural assessment of an acquisition target’s ops team isn’t part of your diligence process, you’re underwriting a liability you can’t see. The question of whether the acquirer can absorb and scale the target’s automation capabilities is a culture question before it’s a technology question. The answer determines a meaningful portion of the deal’s actual value.
The operators who close the automation gap in the next few years aren’t necessarily the best-funded or the most aggressive in vendor procurement. They’re the ones who built organizations capable of actually using what they buy.
Money Can’t Buy You…
The technology isn’t the hard part. Everyone knows this somewhere, but few treat it that way.
The hard part is building an environment where information flows, where failure leads to learning rather than blame, where knowledge becomes institutional rather than personal, where the engineers who’ve been carrying the network in their heads feel safe handing it off to systems and to colleagues. That work is slow, it’s uncomfortable, and it doesn’t come with a vendor demo or a deployment timeline.
It also doesn’t have a substitute. You can defer it, but the cost of deferring it compounds. The culture gap between where you are and where your automation stack needs you to be is the gap between the ROI you projected and the ROI you’ll actually see.
Some operators I know are doing this work. Most aren’t.
Ready to move from diagnosis to action? Khadga Consulting helps service providers and infrastructure operators close the operational intelligence gap: technology, culture, and all the uncomfortable parts in between. Let’s talk.
