Lessons from a Network Engineering Journey

The year 2025 marks my 26th in data networking as a profession and over 30 years since I started experimenting with networks. As I find myself between engagements, I've had time to reflect on where I've been and the road ahead. This pause in the journey has given me a unique perspective as I haven't had this long of a break to actually reflect before.

Looking back at the path from teenage hacker to business owner and now to whatever is next, I find myself with few regrets but not none. My biggest regret? Not being more present and attentive to things I dismissed as unimportant that later proved essential. This retrospective is my attempt to illuminate a path for those who might be somewhere similar in their own journey.

The Evolution of a Network Engineer

My career has unfolded across five distinct phases, each offering its own lessons and growth opportunities.

Phase 1: Teenage Hacker

I started playing around with computers at a fairly young age but it was the mid-90s, in my teens, when I started using modems to connect to other computers. Between Bulletin Board Systems (BBS), university shell accounts via VMS or UNIX (borrowed, I never attended college) and finally getting a dial-up internet access account in 1995, I spent a lot of time connecting to other computers. Once connected, I would utilize tools like ZMODEM, telnet, gopher, FTP and others to fetch files, post files and connect to computers somewhere else. This is when I realized how cool networking was and that this is what I wanted to do for a job.

Phase 2: Helpdesk

In 1999, I started doing dial-up tech support at a regional ISP. It was simultaneously some of the hardest and some of the most important work I've ever done. Those long shifts talking customers through configuring their TCP/IP stack, modem driver installation and reassuring them those squealing, scratching sounds were supposed to happen taught me the most crucial aspect of working in technology: we're in the business of helping people.

I still remember the relief in a customer's voice when their connection finally worked after an hour of troubleshooting. That feeling and that moment of solving someone's problem remains at the heart of everything I do.

For those entering the field today, I strongly advise against skipping this phase. The temptation is strong to quickly evolve past the front lines or bypass them entirely because it can be a slog. That said, understanding users' frustrations, limitations and needs creates an empathy that will serve you throughout your entire career. If you're in this phase now, I know it seems hard but stick with it. Trust me, it'll be worth it.

Phase 3: Junior Engineer to VP of Engineering

As I progressed through junior network engineering roles and bounced between regional ISPs, I climbed the ladder to director and eventually VP positions. This was my technical prime as I lived and breathed network hardware, protocols and deployment methodologies.

I fondly recall the pride I felt learning new protocols (for real, read the RFCs), deploying the latest technologies and troubleshooting really hard problems. Each technical challenge conquered built confidence and expertise. But I was missing something important that I wouldn't put my finger on until later.

Phase 4: Solutions Architect

About a decade ago, I realized my greatest satisfaction came from the human side of the work. Straight up engineering roles were gratifying for a long time but I wanted to get out into the field and work with people. I also wanted to make more money 😄 So I made what many engineers consider a controversial move to the "dark side" of engineering. Technical sales and solutions architecture.

As the engineer in the room aligning products with customer expectations, I learned something invaluable. One had to listen to understand what customers actually wanted which wasn't necessarily what they were asking for. Many times, I found that what customers requested didn't actually align with solving their problems, or maybe they didn't completely understand all of the pros and cons. This role transformed my understanding of technology from "what it does" to "what business problem it solves."

Phase 5: Founder

In 2016, I cofounded a company called WAN Dynamics with one of my industry friends—ironically, my manager from that first dial-up job. Though initially fun and exciting, nothing in my career had prepared me for the grinding difficulty of entrepreneurship.

For two years, I made half my previous salary while working twice the hours. The persistence required to push through 2016-2018 before finally gaining traction was truly difficult. When we started, I handled so many things from sales to solutions architecture to implementation to support tickets. As we grew, delegating those responsibilities to our team allowed me to focus on strategic leadership which was a transition both necessary and challenging.

I learned a lot during this time. To anyone who thinks that when you have your own company, you are your own boss has it all wrong. Everyone else is your boss: your customers, your employees, your vendors. You spend every day fighting the next fire. I'm so glad I did it but man, it was hard.

Five Critical Lessons Learned

I've distilled my experience into five key insights. These lessons stand out as the most impactful takeaways from my journey.

Understanding Business Is More Important Than You Think

I spent the early years with my head down in the CLI thinking "I'm gonna focus on engineering, business stuff is boring and dumb." This was my greatest professional mistake.

The alignment of engineering objectives with business requirements is super important, regardless of your position. The most successful technologists I've known navigate both realms skillfully. My technical sales and founder phases both would have been way easier had I paid attention to sales & marketing funnels, business development and P&L statements earlier in my career. Don't ignore this stuff, pay attention and be aware of their importance.

Certifications Are Initially Crucial, Eventually Not So Much

The certification debate rages eternal in our industry. Yes, certs matter and especially early on. They open doors, provide structured learning and satisfy employer requirements.

That said, their importance diminishes as one's career advances. Understanding fundamental technologies and protocols matters so much more than mastering any vendor's particular implementation. I've seen engineers certified out the wazoo who couldn't troubleshoot their way out of a wet paper bag. On the other hand, I've worked with many certification free veterans (both expired or never bothered) who were absolute internet wizards.

I've had and lost many certs that served their purpose initially but lost their luster along the way. Right now, I have none. The key to certs is to learn the technology, not just how to pass a test. Be sure to understand as much of the stack as you can.

Your Human Network: The Most Important Network

The most powerful network you'll ever manage isn't connected with routers and switches: it's made of people. Help others without expectation of return. Call it karma, kismet, or good vibes, but these connections yield dividends beyond calculation.

I haven't submitted a formal job application since 1999. Nearly all of the business we landed at the company that I co-founded came through relationships built over decades. Some of my most valuable professional insights didn't come from training courses but from conversations with peers over coffee or troubleshooting sessions.

Success is not found in a vacuum. You need people in order to thrive.

Embrace Hard Work But Demand Balance

Engineers early in their career typically have more time than responsibilities. Use this period wisely: attend training, join local meetups like the USNUA, build home labs (which can be entirely virtual now), volunteer for late night maintenance and take on-call rotations.

However, and this is crucial, don't allow yourself to be taken advantage of. On-call responsibilities should rotate, knowledge should be shared, don't take on every maintenance alone and insist on taking your vacation time. Your brain needs regular disconnection from work to maintain peak performance and prevent burn out.

As you advance, gradually transition away from operational firefighting toward strategic work and mentoring junior team members. This progression should be intentional and expected. Also know, management isn't for everyone. Staying an individual contributor is OK if it suits you! Many employers will make sure to take care of you even if you don't take the management track.

"Rockstars" Are Toxic, Don't Be One

We've probably all encountered one. The technical genius who solves impossible problems but hoards knowledge, ridicules colleagues & customers and becomes a single point of failure. These "rockstars" ultimately harm organizations more than they help.

Their immediate technical contributions become overshadowed by a damaging effect on team morale, lack of information sharing and harm to system resilience. When they inevitably leave (often dramatically), they leave behind undocumented systems that others fear to touch.

If you've read "The Phoenix Project," you'll recognize this in the character Brent. Strive instead to be a teacher, a documenter and a multiplier of others' abilities.

Looking Forward

So what's next?

The technical skills, business understanding and, most importantly, the relationships I've cultivated will guide me to wherever I need to be. And perhaps that's the final lesson: trust the journey, even when you think you're off course or the destination is not yet visible.

I sincerely hope these reflections help someone else navigate their own path through this crazy ass field we call networking. The technology will evolve, but the principles of helping people, continuous learning and building meaningful connections will never change.

What has your experience been? I'd love to hear your stories and lessons.