When I was a senior network engineer running WAN projects at a fintech company, I burnt out. I was working three to four maintenance windows a week, I had little kids at home, and I was exhausted just keeping the lights on. Then they announced, "you need to learn network automation." My inner voice said, “When am I supposed to do that?

So I found more study time the only way I knew how. I studied every spare moment I had. Early mornings before the kids woke up, again from nine at night to one in the morning. I stopped working out. I slept less. I chugged copious amounts of caffeine. Everything in my life that wasn't work started to feel like it was in my way. Even family obligations started to feel like they were “in the way.” 

Eventually, my body sent the bill. The first migraine of my life turned into a month-long migraine that almost ended me. Brain scans. Medication. And a lesson I couldn't unlearn: I cannot push myself to the absolute limit without paying for it, in my mind and body.

Tim Bertino defined burnout on our Burnout and Rustout episode: burnout is exhaustion. Emotional, mental, and physical.

The grind is real

Network engineering is uniquely exhausting. In our Mental Health episode, I described my production experience: "it's a tough gig. It never ends. There's always the next thing to learn. It was automation, it was cloud. You turn around and you might be outdated."

During that conversation I compared my networking career to my sister-in-law’s career as a pediatrician. She does continuing education every year; sits in a class for two hours, takes and passes an easy test. Not to minimize what she does, but network engineers are constantly learning new technology stacks on nights and weekends, taking time away from our families. Part of the problem is technology is always changing, and we have to grind on nights and weekends to try and keep up.

Tim Bertino echoed my sentiment: "I have that constant desire outside of work that tells me that most of my energy needs to be toward bettering myself in technology, or I'm going to fail and I'm going to lose everything. And I'm going to have failed my family at that point. And I know that's ridiculous, but I can't convince myself that that's ridiculous."

If you feel that too, you're not alone.

Why the network team gets crushed

Some of this is structural. As Anil Varanasi put it, "there's a massive shortage" of network engineers, and the inflow of talent just isn't there. Meanwhile, "the number of devices and applications on a network have grown dramatically," and where there used to be one IT person for every 75 to 100 people in a company, "today, the average is about 250."

We don’t have enough new talent coming in, there are more expectations added every year, and there is more traffic traversing our networks than ever before.

Tim Bertino named the reality of being the highway builder everybody needs: "when so many different people need so many different things... we have to have these constant chats; “Okay, what do you need? Why do you need it? I need X amount of time to build that because I've got 3 projects in front of you."

So what can we do?

Say no. I take full responsibility for my burnout. My manager told me to dedicate Tuesdays to learning automation. I mismanaged my time and filled Tuesdays with maintenance window prep work. Looking back, saying no to the work that was stepping on protected time would have gone a long way. My time was worth protecting, but I didn't say no to competing priorities. There will always be someone asking you for “one more thing.” Protect your time. Say no.

Align with the business. For years I felt separate from the business. I lived on network island and it felt like everyone blamed the network. We were always trying to prove problems weren't the network’s fault, and over time I got defensive about it. From my perspective it felt like “us” vs “them.” But some of “them” were the leaders of our business. The same business that paid my salary, matched my 401k, and provided affordable healthcare. Eyvonne Sharp has said this for years: the best thing you can do if you're in a network engineering role is learn the business, join those calls, and find out what's important to leadership. When I finally leaned in, saw there was a bigger picture, remembered this is a company running a business, running applications customers have to reach so we can generate revenue, and saw my part in that ecosystem, it took some of the “us vs them” wind out of my sails. “They” weren’t coming after me. They were working on keeping our customers happy, and network outages made our customers unhappy.
Once I aligned with the business, I felt like I could contribute to meaningful strategy discussions and be part of the solution.

Embrace change. This one is hard. Nobody likes change. I experienced a lot of change, I didn't like it, I cried, nobody cared. I got laid off, panicked, learned a bunch of new stuff, and now I'm in a better place. Jeff Clark said it well: "part of being a network engineer, part of being in IT... is embracing the change. Network engineers, we figure stuff out. We don't know things, we figure things out." Change is a constant and fighting it is self-inflicted exhaustion. Accept that tech is always shifting beneath our feet, and go with the flow.

Skills are transferrable. If burnout hits and you feel trapped, there is usually a way out. As Tim Bertino pointed out, network engineers become "a very versatile person as far as skill sets" because you get pulled into everything; the business, the applications, virtualization. That versatility means "if you want to pivot to something else... it's easier for you to." Roddie Hasan felt his own role start wearing thin with the silly customer requests, and his answer was a pivot: "you know what, maybe I need to get back into consulting." And sometimes, as Jeff Clark tells newer engineers, "sometimes you gotta move out" before you burn out. Changing jobs and trying new roles is often a better strategy than white knuckling an unbearable situation.

The Silver Lining

Is network engineering a dying field that may grind you into dust? No. On a Networking Field Day podcast, Tom Hollingsworth made the case that it isn't: "there are still COBOL programmers and mainframe engineers out there, and they're going to be there forever." His guest Remington Loose framed it this way: “not dying, just shrinking.” There's always going to be a network.” Ned Bellavance drove home why you've got a leg up: programming is hard, but it's not that hard. What's really hard is the years you've put into network fundamentals, "and that's something that's irreplaceable."

If you feel overwhelmed and exhausted, take a deep breath and get some perspective. The hard part is already behind you, in the fundamentals you learned. What's left is finding a way to learn the latest and greatest technologies on a sustainable schedule, not by torching your nights and weekends forever, and driving the burn out bus. The nights-and-weekends grind wasn't sustainable for me, and I don't think it is for anyone. It comes down to figuring out the when.

One thing that worked for others was talking to their boss, saying they wanted to learn a new technology stack that would help the business, and ask to carve out a few dedicated hours during the work week to skill up. In that scenario everyone wins, and you don’t destroy your health in the process.

Having realistic expectations about what you can do in a set amount of time, and enforcing healthy boundaries around those expectations is something I wish I learned earlier in my career.

Find Joy

When I was burning out, I didn't tell anyone. I white-knuckled it alone, at one in the morning, convinced that suffering in silence was just the job. I didn’t know I was slipping into burnout. It’s sneaky; insidious. One day it just feels like you are working harder than usual, then you look up and realize something is off. Something has been off. You don’t feel like yourself, and the feedback coming in is people have noticed. “What’s up with Andy?” 

What pulled me out of this spiral wasn’t a book or a therapy session. It was people. In 2020, at the bottom of all of this, AJ Murray asked me to help start a podcast. I said yes. The nights we recorded became the highlight of otherwise dreary, stressed-out months. Virtual strangers became friends. My darkest year got a little brighter because I stopped grinding in isolation and started showing up with people who understood me.

Community is real, and it is all over our field if you look for it. Jason Gintert spent years building one, a network of in-person user groups for engineers across the country. He wrote a piece called "Putting the Human Back in Network Engineering," about how a screen-only, never-in-the-room isolation can negatively impact us. His pitch is simple: "We want to see everyone come together."

We are better together than apart. I learned that at my bottom, and I’m extremely fortunate fate brought the AONE crew into my life when it did. You don't have to carry the weight of your career alone. 

Find your people. 

As I write this, I’m coming out of my second career burnout and both were caused by unrealistic expectations, and not enforcing healthy boundaries. I think I can do the work of 10 people and I believe I can do it alone. That’s a delusion, and that’s on me. It is my hope that by sharing my mistakes with you, as well as the lessons learned over the years at AONE, you might avoid the common career pitfalls and choose a better path.

See you next week,

/Andy