I didn’t start out as an automation architect. I started as a Marine – building and maintaining communication systems that had to work under pressure. In that world, downtime wasn’t just inconvenient; it could be mission-critical. That experience shaped how I think about networking to this day – precision, discipline, and designing for reliability above all else.

When I left the military, I carried that same mindset into the private sector – first with Verizon Wireless, where I helped support infrastructure for millions of subscribers, and later at Asurion, running large enterprise networks. But over the years, the work began to change. Networks were expanding, technologies were multiplying, and the manual way of doing things just couldn’t keep up.

I started learning Python not because I wanted to “get into automation,” but because I needed a way to survive the workload. My first script took what used to be a two- or three-week manual update and got it done in a few days. That single win lit a spark. I wasn’t just fixing problems anymore, I was starting to design solutions.

That’s when the shift began: from operating networks to orchestrating them.

In our conversation on Packet Pushers Total Network Operations, host Scott Robohn called this my “architect’s moment” – the point where you stop firefighting and start designing frameworks.

At Asurion, I led a small team of automation engineers. We were building great Python tools that saved hours of work, but each new script came with a new set of dependencies and maintenance overhead. The more we automated, the harder it became to scale.

We weren’t just solving problems, we were creating new ones in a different form.

I began to realize that automation isn’t just about doing things faster, it’s about doing them better, together. We needed structure. We needed governance. We needed a way to connect tools and processes so the work we built could live beyond a single engineer or use case.

That’s when we started exploring platforms that could help us move from individual scripts to orchestrated workflows. We looked at everything – Ansible, Terraform, even homegrown options – but most still required heavy coding and didn’t scale easily across systems.

Through a partner introduction, I came across Itential, and it immediately clicked. It wasn’t just another automation tool, it was a framework that let us take what we’d already built and expand it safely.

By combining our existing Python automations with Itential’s orchestration layer, we could connect APIs, manage data, and create reusable workflows. Suddenly, we weren’t just writing automation, we were designing a system that anyone on the team could use and build on.

That’s what orchestration really means – it’s the architecture behind automation. It’s how you turn clever scripts into systems the whole organization can trust.

As Scott said on the podcast:

That’s the architect’s journey. When you stop writing fixes and start designing frameworks.

He was right. And once we hit that point, the real transformation started.

Every engineer has that one project they dread. For me, it was PCI compliance. Endless spreadsheets, manual data pulls, and late nights correlating logs. It was the kind of work that drained morale faster than it delivered insight – the perfect candidate for automation.

So we built a process that could automatically pull audit data from multiple systems – firewalls, DNS, authentication, and user identity – and assemble a full compliance picture in seconds.

What used to take 45 minutes per IP now took six seconds.

That project became a turning point. Not only did it save time, it changed how our team felt about automation. We weren’t just saving hours, we were freeing engineers from the kind of work that made them want to leave the field.

As I said in the conversation, the ROI wasn’t just technical – it was human. Automation gave people room to think, learn, and grow again.

Ethan Banks summed it up perfectly:

Every business has a backlog of work that never gets done. Automation gives you the time to finally get to it.

Exactly. The real payoff of automation isn’t speed, it’s progress.

A big part of maturing as an architect is learning when not to automate. Early on, I chased every new tool from Ansible, to Terraform, even full-blown orchestration platforms I wasn’t ready for. Each misstep taught me something valuable about alignment, readiness, and scope.

The truth is, no single tool can solve every problem. The key is understanding what you’re trying to achieve – not just technically, but operationally. Automation is only as valuable as the process it represents.

That’s why I focus on designing systems that can evolve – systems that are modular, governed, and documented so they outlive the individual who built them.

And as I’ve moved into my role at Itential, that mindset hasn’t changed. My goal now is to help other engineers and organizations make that same leap – from automation as a set of scripts to automation as a structured, orchestrated framework that drives business outcomes.

Today, AI has become part of my workflow. I use it to learn faster, validate code ideas, and find new approaches to big data analysis. But AI doesn’t replace engineering discipline – it amplifies it. Without structure, it just accelerates chaos.

That’s why orchestration still matters. It provides the framework that lets automation – and AI – run safely and consistently across teams.

And through it all, I keep one lesson front and center: failure is the best teacher. Every broken script, every misfire, every wrong assumption has been worth it. Those failures shaped how I build, how I lead, and how I think about automation at scale.

As Scott said in the podcast’s closing moments:

The feedback loop from failure is much more effective than feedback from success.

Couldn’t agree more. Success tells you it worked. Failure tells you why.