I spent most of my twenties trying to eliminate uncertainty from my life. Does that make it ironic that I am now promoting systems thinking in network automation?
At first, network engineering was perfect for smothering myself in certainty. Protocols are deterministic. Standards are concrete. BGP does what BGP does, every time, according to rules that don’t change based on someone’s mood or the phase of the moon. The appeal was obvious: a world where things actually made sense.
Then I tried to automate networks at scale and ran face-first into the messiest, most unpredictable element of any system: people.
This week, Harvard Business Review published an article that articulates something I’ve been circling around for years: Why You Need Systems Thinking Now. Written by Tima Bansal and Julian Birkinshaw, it argues that the dominant approaches to innovation (breakthrough thinking and design thinking) are fundamentally broken. They solve problems by ignoring complexity, and in doing so, they create new problems we never anticipated.
Reading it felt like someone had finally put words to what I’ve been experiencing in the network automation space.
The Gordian Knot Problem
The article uses Alexander the Great’s solution to the Gordian knot as a metaphor for breakthrough thinking: when faced with complexity, just slice through it. Move fast and break things. This works great when the problem is bounded, like getting a rocket into space, but fails catastrophically when you’re dealing with complex adaptive systems.
Like, say, an organization trying to adopt network automation.
The technical problems in network automation are solvable. We have the tools. We have the platforms. We can observe state, generate configurations, push them to devices, validate state, and roll back failures. The technology works.
But most network automation initiatives still fail. Not because the technology is inadequate, but because we keep trying to slice through the Gordian knot instead of understanding it.
Recognizing the System
For the past few years, I’ve been diving deep into complexity theory. The work coming out of the Santa Fe Institute on things such as emergence, complex adaptive systems, and feedback loops has fundamentally changed how I think about networks and the organizations that run them.
Here’s what I’ve learned: nothing is isolated. Every action creates ripples. When you automate a network task, you’re not just replacing a CLI command with an API call. You’re changing power dynamics, threatening identities, disrupting workflows, and challenging decades of accumulated knowledge and practice.
This is why systems thinking matters. It’s not about finding the perfect solution. It’s about understanding the flows, the relationships, the feedback loops. It’s about recognizing that when you change one part of the system, you affect the whole.
The HBR article puts it perfectly: Systems thinkers “start by zooming out to understand the system that the innovation will be part of before they zoom in to solve the problem.”
I wish I’d understood that twenty years ago.
NetDevOps and the Sociotechnical Reality
When I started working on defining NetDevOps, I thought I was solving a technical problem. How do we bring DevOps practices to network operations? What tools do we need? What processes should we implement?
What I discovered was that network automation is fundamentally a sociotechnical challenge. The barriers aren’t technical. They’re human. We’re asking network engineers to fundamentally reimagine their role, their identity, their value. We’re asking organizations to restructure around flows instead of silos. We’re threatening the expertise that people have spent careers building.
And we wonder why there’s resistance.
The breakthrough thinking approach would be to just push through. Deploy the automation platform, train the team, mandate the change. Move fast and break things.
But what you break are people. And organizations. And trust.
Design thinking would focus narrowly on the user experience. Make the tools easier to use. Improve the interface. Reduce friction for the network engineer.
But that ignores everyone else in the system: The security team, the application developers, the managers who need to redefine success metrics, the executives who need to justify the investment.
Systems thinking recognizes that this is a wicked problem. There’s no single solution. You need to engage multiple stakeholders who experience the dysfunction differently. You need to iterate on the problem definition itself. You need to focus on changing flows and relationships, not just implementing tools.
Most importantly, you need to be comfortable with uncertainty.
Learning to Love the Mess
This is where I’ve had to grow the most.
The younger version of me wanted concrete answers. Tell me the protocol, I’ll implement it. Give me the standard, I’ll follow it. Show me the right way, I’ll do it.
But systems thinking doesn’t work like that. The HBR article describes it as “nudging your way forward” through an “ecology of actions.” You run experiments. You expose interdependencies. You learn what you couldn’t have known before you tried.
This requires being okay with not knowing. With trying things that might not work. With defining success as “we learned something valuable” rather than “we deployed the thing.”
For someone who chose network engineering specifically because it was rules-based and logical, this was uncomfortable as hell.
But here’s what I’ve discovered: The uncertainty isn’t a bug, it’s a feature. Complex adaptive systems are inherently unpredictable. You can’t model them perfectly. You can only engage with them, learn from them, influence them.
The article warns against the traditional systems thinking approach of trying to “identify and model all the flows, interactions, and feedback loops.” That’s futile in a fast-changing world. Instead, you need “a general understanding of critical patterns” and then you collaborate with actors in the ecosystem to test simple ideas.
This is exactly what we’ve been learning in network automation. You can’t perfectly plan the transformation. You need to start somewhere, learn from what happens, adjust, and move forward.
Slow is smooth. Smooth is fast.
Four Principles for Network Automation
The HBR article offers four principles for systems thinking that map beautifully to network automation challenges:
1. Define your desired future state. Not “we need network automation” but “we need to be an organization that can safely deploy network changes at the speed of business.” Your North Star determines what you optimize for.
2. Frame and reframe the problem iteratively. Maybe the problem isn’t “our network engineers don’t know Python.” Maybe it’s “our change approval process creates a two-week bottleneck” or “our monitoring gives us alerts but not insights.”
3. Focus on flows and relationships, not products. Network automation isn’t (just) about buying a platform. It’s about information flow between teams, trust relationships between systems, feedback loops between deployment and validation.
4. Nudge your way forward. Start with automating documentation. Or backup collection. Or configuration validation. Small experiments that reveal the system’s dynamics and build momentum.
The breakthrough thinkers want to deploy everything at once. The design thinkers want to perfect the tool first. The systems thinkers start small, learn continuously, and evolve the approach based on what emerges.
Why This Matters Now
The article argues that breakthrough and design thinking “may create as many problems as they solve” when dealing with complex, interconnected challenges. I think they’re right. And I think we’re seeing this play out in network automation.
We’ve spent years trying to breakthrough-think our way to network automation. Deploy the platform. Mandate the change. Move fast.
Result: High failure rates, burned-out engineers, and skepticism about automation itself.
We’ve tried design-thinking our way there. Focus on user experience. Make the tools easier. Reduce cognitive load.
Result: Tools that work great in demos but don’t account for brownfield networks, organizational dynamics, security requirements, or integration complexity.
What we need is systems thinking. Recognize that network automation touches everything; culture, processes, skills, tools, metrics, incentives, power structures. You can’t slice through that complexity. You have to work with it.
This means being comfortable with uncertainty. With iteration. With experiments that expose system dynamics rather than immediately solving problems.
It means growing up a little bit.
Join the Conversation (Or the Transformation)
This is exactly the kind of conversation we’re having at the Network Automation Forum. We’re not pushing a specific tool or methodology. We’re bringing together practitioners who are wrestling with the messy reality of transforming network operations in complex organizational systems.
If you’re trying to figure out how to navigate the sociotechnical challenges of network automation, and if you’re tired of approaches that ignore half the problem, come join us. The NAF community is where people who understand that the technical part is actually the easy part gather to figure out the rest. We also talk about a lot of technology, of course. =)
And if you’re ready to move from conversation to action? That’s why I built Khadga Consulting. I work with organizations navigating exactly these challenges; understanding the system, reframing the problem, focusing on flows and relationships, nudging forward. I bring that deep network expertise and those hard-won lessons about the human side of technical transformation. Reach out for a free consultation if you want to talk about what systems thinking looks like in your organization.
Because the rest is where the real work happens. And it’s messy. And uncertain. And exactly what we need to embrace.
Read the full HBR article here. Then come tell us what you think.
My take? The network automation revolution won’t come from breakthrough thinking or design thinking alone. It’ll come from people willing to think in systems, embrace uncertainty, and nudge their way forward together.
Join the conversation: NAF Slack community
Ready for change: khadgaconsulting.com
