From Engineer to Architect - It’s much more than pretty diagrams.

I used to think my career was a straight climb up a technical ladder.

When I first started this Substack, I leaned heavily into my technical roots. The name itself—Beyond the Terminal—was a bit of a nod to network automation. I wanted to talk about moving away from the CLI, embracing Ansible, and dragging our infrastructure into the modern age.

But then, life happened.

I found myself without a job. I went through the ups and downs of a pretty turbulent year, and in the moments between self-doubt and interviews, I realised that the underlying passion that brought this project to life wasn’t actually about the tech.

It’s about people. Specifically, how we connect, and perhaps how often we fail to.

This goes back a lot further than this blog.

When I first landed in Australia, I was fresh out of university and, frankly, I thought I knew it all. I was grinding away at my CCNA and figured I’d just walk straight into a network engineer role.

Apply for a few jobs, show off the degree, and get the offer. Easy, right?

I quickly realised it’s not that simple.

Turns out, the industry here values more than just what’s printed on your resume. They value relationships. And back then? I didn’t know a single soul in the Australian IT industry.

I eventually landed a role, but it wasn’t through a cold application. It was through a connection of a relative. I still had to walk into that room and prove my worth, but that referral was the foot in the door I couldn’t find on my own. It was my first real lesson that technical skill is only half of it.

But there was a catch. It wasn’t a networking role, and little did I know I was beginning my journey as a generalist.

The best step backwards

Six months later, I was back on the hunt. This time, I was in a new city with no family, no friends, and no “connections” to tap on the shoulder.

I desperately tried to get back into network engineering. Instead, I found myself in IT support. On the helpdesk and on the phones.

It felt like a massive step backwards. I had a networking degree and experience with a massive telco back in the UK, yet here I was resetting passwords and answering basic tickets.

It was the best thing that could‘ve happened to me.

Whilst I was in the trenches of support and field engineering, something shifted. I met people, I made friends (some of them were even clients), and I actually helped clients solve problems that felt world-ending to them, even if it was just a simple DNS issue.

I was opened up to a world where being “technically good” was only half the battle. Leaders way above my pay grade took the time to talk to me—and more importantly, to listen and mentor me.

It wasn’t because I could recite BGP attributes (still can’t), it was because I was able to connect with them as a person around the office.

From Engineer to Architect

In my next role, I saw it even more clearly: the vendors, the partners, the entire business, it’s all built on relationships. It was during this time that I started to understand what an Architect actually is.

When you’re an engineer, your world is “How.”

How do I configure this VLAN?

How do I automate this deployment?

How do I fix this broken BGP peering?

You’re the hero in the trenches, making sure the packets keep flowing.

But an Architect? An Architect lives in the “Why.”

They aren’t just the person with the most certifications or the one who knows the commands inside out. In fact, I reckon a lot of Architects would need to reference documentation to deploy the things they design. Because that’s not what they need to think about.

An architect is a translator.

Their job is to sit between the technical capability and the business goals. They can listen to a CEO talk about “operational efficiency” or “acquisitions” and translate that into a resilient, scalable, and cost-effective system design.

And you can’t do that with technical skill alone. You do it with:

• Empathy: Understanding that the “Slow Wi-Fi” isn’t just a ticket on the board. It’s a frustrated operations assistant who can’t process orders and is worried they can’t meet their KPIs.

• Influence: Persuading a CFO to spend $30k on a redundant core switch, not because “it’s best practice,” but because it protects the company’s operations.

• Curiosity: Asking the right questions to find the human problem before you ever reach for a technical solution.

That’s why the mission of this Substack has evolved. I want to help you develop the people skills that take you from an engineer to an architect. Technical depth is vital, don’t get me wrong —but empathy and connection are the secret ingredients that build a career “off the tools” whilst staying firmly in the tech world.

We spend so much time mastering the technology, but we often forget to analyse the environment the technology lives in.

I’m here to advocate for the power of looking beyond the hardware and focusing on people. Whether you want to remain an individual contributor or step into leadership, understanding the human side of the business is no longer “optional.”

Let’s be honest: the “How” is increasingly being handled by the machines. We have self-healing networks, intent-based networking, and AI that can spit out a Python script in seconds. If your value is tied purely to your ability to configure a box, you’re racing against an algorithm you can’t beat.

But an algorithm can’t build trust. It can’t read the energy of a frustrated operations team and design a solution that actually makes their lives easier. The next generation of engineers won’t be defined by how well they remember commands, but by how well they navigate the room.