How Network Engineers Can Build a Product Mindset for Automation

If you’ve been in networking for a while, chances are you’ve seen automation efforts come and go. We’ve all written scripts to save time, automated the things we hated doing manually, and maybe even built a few workflows to make life easier. But here’s the thing: automating existing tasks isn’t enough.

In the latest episode of Total Network Operations (TNOps), I had the chance to sit down with Scott Robohn and Ethan Banks to talk about adopting a product mindset: why network teams need to shift from just automating tasks to delivering network automation as scalable products. We unpacked the difference between automation and orchestration, why error handling is the most overlooked part of automation, and how network engineers can evolve their skill set in an API-first world.

Here’s why you should listen — and why this conversation might change the way you think about network automation.

For years, the approach to automation has been: “What’s the most repetitive, manual thing I do? Let me write a script for that.” And that’s fine as a starting point. But when you think about it, if all you’re doing is saving time while continuing to do things the same way, how much value are you creating?

Implementing a network change might only be 10-20% of what needs to happen to fulfill a service end-to-end. Until you can actually deliver services faster — from request to fulfilment — you’re optimizing inside your own silo, but you’re not going beyond that.

And if every engineer writes their own scripts, and those scripts live on personal laptops, what have we really accomplished?

If you can fully automate every step of a process and coordinate it as a service, aka orchestration, that’s when automation is really transforming how the network supports the business overall.

Automation is about efficiency. Orchestration is about scale. The real shift happens when you stop automating tasks for yourself and start building services that anyone can use, consistently, at scale. That’s what we mean when we talk about a product mindset for networking.

One of the most important topics we covered was how automation and orchestration are fundamentally different. 

Automation is about handling specific tasks — like configuring core routing or setting up SD-WAN. Building anything that handles multiple tasks gets complicated, so often, network engineers write a few scripts and then still hand-execute them in sequence to perform a service.

Automation is great for quick wins, but it only takes you so far.

Orchestration is where things start working together. It ensures that tasks happen in the right order, with validation, with error handling, and as part of a structured process.

Ethan summed it up perfectly on the podcast: “Orchestration is where you stitch together automation in a way that’s consumable as a service. It’s about making sure the network actually does what the business needs.”

So, if you’re automating tasks, great. But if you’re not thinking about orchestration, you’re still operating in a silo.

One of the biggest takeaways from our conversation was this: stop thinking of automation as a tool. Start thinking of it as a product.

If you’re a network engineer, your job isn’t just to build VLANs, configure routers, or troubleshoot BGP. Your job is to deliver network services that are reliable, repeatable, and consumable.

The real “a-ha” moment for me, and for most network engineers, was realizing that 95% of what you do for a network change process is the same. If you’re doing router upgrades, you have to modify one or two variables, but the overall workflow is the same. That realization is when I saw the opportunity to treat automation like a standardized product, instead of a collection of scripts.

This is a huge mindset shift. Instead of automating VLAN provisioning manually every time someone requests one, why not build a self-service portal where anyone can request and deploy VLANs on demand? That’s what I mean by treating automation as a product.

Networking doesn’t exist in a vacuum. Yet, for years, network teams have worked separately from cloud, compute, and storage teams. That has to change.

Developers are accustomed to spinning up infrastructure instantly in AWS, but when they shift to on-prem environments, they hit a wall — suddenly, they have to submit a ticket and wait two weeks for the network team to provision something. This disconnect isn’t sustainable.

If we can’t provide network services on-demand, then the business is just going to move everything to the cloud. Expectations have changed. The business needs things faster than ever — if we can’t deliver, they’ll go around us, and that only opens up more problems.

This means networking has to evolve. Here’s how Scott put it on the podcast: “Being a next-gen network engineer isn’t just about subnets and spanning tree anymore. That’s table stakes. Now, you need to understand automation, orchestration, APIs, Git, and pipelines to stay relevant.”

Removing bottlenecks with cross-domain orchestration is critical. Networking needs to be part of the broader IT automation strategy—not a separate entity that teams work around.

If you’re going to orchestrate network changes and deliver them for people to self-serve, you obviously need to ensure error handling, validation, etc. are taken care of. You can’t risk turning out self-serve automations that will break the network.

The thing is, error handling is one of the most overlooked parts of automation. It’s something we all ignore because, honestly, it’s not the fun part of automation.

Ethan put it bluntly in the podcast: “When I write a script, my first instinct is just to get it running. Do I go back and add error handling? No. I tend to not do that.”

This is normal. Too normal. I have to call this out as one of the biggest gaps in network automation today. The excuse I hear is, ‘I don’t have time to add error handling.’ But imagine how much faster you can diagnose failures when automation runs dozens of tests in seconds instead of an engineer manually running show commands for an hour.

If you want automation you can trust, it has to include proper validation, rollback processes, and failure detection. Otherwise, you’re just replacing manual work with automated chaos.

This conversation with Scott and Ethan was one of the most insightful discussions I’ve had on network automation. We covered:

• Why automation alone isn’t enough — and why orchestration is the missing piece.
• How to treat automation like a product and deliver true network services.
• The importance of cross-domain orchestration and integrating with IT workflows.
• The #1 mistake engineers make in automation (and how to fix it).

Orchestration is the key to delivering real, on-demand services and embracing the product mindset that I truly believe is the future of networking.

It’s about making the shift from isolated scripts to true, scalable products that anyone in the business can consume.

If you’re an engineer looking to scale automation — or a leader trying to operationalize automation across your org — listen to the episode here.