Both Sides of the Desk: Burnout (The Engineer's Perspective)

Introducing: Both Sides of the Desk

Welcome to a new blog series where I explore the same topics from two different perspectives: the network engineer and the network manager. Having recently transitioned from one to the other, I remember what it felt like on the engineer side, and I'm experiencing the manager perspective in real-time.

This series isn't about picking sides or assigning blame. It's about understanding how the same situations look and feel from different vantage points, and hopefully creating some empathy and insight that helps both engineers and managers work better together.

We're starting with one of the most pervasive issues in IT: burnout.

The Engineer's Perspective: When the Passion Becomes Exhaustion

I spent 20 years as a network engineer before becoming a manager. I loved the work - the problem-solving, the learning, the satisfaction of designing elegant solutions. But somewhere along the way, that passion started feeling like a burden.

The excitement of learning new technologies became anxiety about falling behind. The drive to advance my career became a treadmill I couldn't get off. The pride in being the technical expert became pressure to have all the answers.

This is burnout, and it's an epidemic in network engineering. Let's talk about what it actually looks like from the engineer's side of the desk.

The Next-Level Trap: Never Good Enough

The Pattern: You're a network engineer with a CCNA. You study nights and weekends for CCNP. You pass it, feel accomplished for about a week, then immediately start thinking: "Now I need to get my CCIE," or "I should learn AWS," or "Everyone's talking about automation, I'm behind."

What It Feels Like: There's no finish line. Every achievement immediately becomes the baseline for the next goal. You're constantly chasing the next level, the next certification, the next skill that will finally make you "good enough."

The Exhaustion: You've been studying for certifications for years. You've sacrificed weekends, evenings, and family time. You've passed multiple exams, learned new technologies, and expanded your capabilities. But instead of feeling accomplished, you feel further behind than when you started.

The Industry Amplification: Every vendor release brings new features to learn. Every conference reveals technologies you don't know. Every LinkedIn post from peers highlights their latest certification or project. The message is constant: if you're not learning something new right now, you're falling behind.

The Reality Check: This treadmill is designed to be endless. Vendors want you to always pursue the next certification. Employers benefit from your constant skill development. The industry thrives on creating new technologies faster than anyone can fully master the old ones.

But here's what nobody tells you: you can't learn everything, and trying to will destroy you.

I explored the certification landscape and what actually matters in my network engineering certification guide, but even more important is knowing when to step off the hamster wheel.

Certification Burnout: The Credential Treadmill

The Promise: Get this certification and you'll advance your career. More certifications equal better opportunities, a higher salary, and job security.

The Reality: You've spent thousands of dollars and hundreds of hours earning certifications. You passed the exams, updated your resume, and... not much changed. You're doing the same job, facing the same challenges, with a few more letters after your name.

What Drives This:

  • Fear of Being Left Behind: Everyone else seems to be collecting certifications

  • Job Market Pressure: Postings require certifications you don't have

  • Employer Expectations: Your company wants you to get certified, but won't give you time to study

  • Industry Messaging: Constant barrage of "upskill or become obsolete"

The Breaking Point: You're studying for your third recertification of the year while simultaneously trying to learn the new SD-WAN platform your company just bought, and somewhere in there, you're supposed to actually do your job. Something has to break, and usually it's you.

The Uncomfortable Truth: Certifications have value, but they're not the answer to every career challenge. Sometimes the real problem is:

  • You're in the wrong role

  • Your organization doesn't value technical expertise

  • You need experience, not another exam

  • The job market in your area doesn't reward certifications

  • You're chasing credentials instead of capabilities

Work Overload: The "Always On" Trap

The Typical Week: Monday through Friday, you're handling tickets, working on projects, attending meetings, and putting out fires. Weekends, you're doing maintenance windows because "that's when we can take systems down." Evenings, you're responding to emergencies because you're the one who knows the systems.

The Unspoken Expectations:

  • Networks run 24/7, so you should be available 24/7

  • "Passion for technology" means working outside normal hours without complaint

  • Being "dedicated" means always saying yes to additional projects

  • If something breaks after hours, you're expected to respond immediately

The Gradual Escalation: It starts reasonably, occasionally after-hours work, and rarely weekend maintenance. But slowly, the exceptions become the norm. "Just this once" becomes "just this week" becomes "this is just how it is."

What It Feels Like: You're constantly on edge, waiting for the next emergency. Your phone becomes a source of anxiety. Vacation time doesn't feel like vacation because you're monitoring email and checking systems. You haven't had an uninterrupted evening with family in months.

The Breaking Point: You realize you haven't truly disconnected from work in years. The thought of more years of this feels suffocating. You fantasize about jobs where work ends when you leave the office, even though you once loved the challenge of networking.

Why It's Hard to Address:

  • Saying no feels like letting your team down

  • Someone has to handle the work, and you don't want to burden colleagues

  • You worry that boundaries will harm your career advancement

  • The culture normalizes overwork and celebrates those who "go above and beyond"

The challenge of protecting yourself from overwork while supporting your team is something I'm grappling with now from the management side, which I discuss in leading remote network engineering teams.

Organizational Chaos: No Clear IT Vision

The Symptom: You're implementing technologies with no clear strategy. Projects start with enthusiasm but die halfway through. Priorities change weekly. Leadership can't articulate why you're doing what you're doing beyond "we need to modernize."

What It Looks Like:

  • Project Whiplash: Start SD-WAN evaluation, switch to cloud migration, drop both for security audit

  • Technology FOMO: Implement every trending technology without understanding business value

  • Reactive Everything: No proactive planning, just constant emergency responses

  • Budget Uncertainty: Can't plan projects because funding appears and disappears unpredictably

The Engineer's Experience: You're trying to build expertise in technologies that might be abandoned next quarter. You can't complete projects because priorities keep shifting. You're asked to solve business problems but given no context about business strategy.

The Exhaustion: Every project feels like pushing a boulder uphill, not knowing if someone will redirect you before you reach the top. The work feels meaningless because there's no clear connection to business outcomes. You're building skills in technologies your organization might not even use long-term.

Why This Causes Burnout: Humans need purpose and progress. When your work feels arbitrary, changeable, and disconnected from meaningful outcomes, it's psychologically draining. You can handle hard work if it matters. Pointless work is soul-crushing.

The Impossible Position: You're expected to be strategic about technology while leadership provides no strategic direction. You're supposed to anticipate business needs while business requirements remain unclear. You're blamed when initiatives fail, even though you were following directives that made no sense.

Creating a business context for technical work is something I explored in making the business case for network modernization - but that only works when business leadership has a clear vision.

The Leadership Carousel: Constant Change at the Top

The Pattern: New IT Director arrives with big plans and new priorities. You realign your work, learn their preferences, and adjust to their management style. Eighteen months later, they're gone. The next director arrives with different big plans and different priorities. Repeat indefinitely.

The Impact:

  • Strategic Whiplash: Every new leader brings a new direction, abandoning previous initiatives

  • Relationship Exhaustion: Building trust and communication with each new manager takes energy

  • Project Graveyard: Your best work gets scrapped because the new leader has different preferences

  • Career Uncertainty: Unclear who will advocate for your advancement or understand your contributions

What It Feels Like: You're constantly starting over. Every time you build momentum, new leadership resets everything. The projects you poured energy into become irrelevant. Your expertise becomes less valuable because new leaders favor different technologies or approaches.

The Career Impact:

  • Advancement depends on leaders who don't stick around long enough to promote you

  • Performance reviews from managers who don't understand your work

  • Skills development in technologies that new leadership might not value

  • Difficulty building long-term professional relationships

The Cynicism That Develops: After the third or fourth leadership change, you stop investing emotionally in initiatives. You do the minimum because you know the priorities will change anyway. You become cynical about organizational goals because nothing seems to stick.

Why This Is Particularly Draining: Engineers often thrive on building things that last. We take pride in an infrastructure that runs reliably for years. Constant leadership turnover creates an environment where nothing you build - technically or professionally - has permanence. That's fundamentally at odds with engineering psychology.

The Technical Gap: When Managers Don't Get It

The Scenario: You're explaining why a network upgrade will take three months. Your manager, who hasn't touched a router in a decade, doesn't understand why you can't "just push a configuration update" and be done in a week.

Common Disconnects:

Complexity Underestimation:

  • Manager thinks: "It's just changing a few settings."

  • Reality: Configuration changes across 200+ devices, testing, rollback planning, documentation, and coordination with multiple teams

Risk Blindness:

  • Manager thinks: "We'll just do it during business hours, no big deal."

  • Reality: One mistake takes down 50 store locations and costs hundreds of thousands in lost revenue

Resource Misunderstanding:

  • Manager thinks: "You're a senior engineer, you should be able to handle multiple major projects."

  • Reality: You're context-switching between six different priorities while handling day-to-day operations

The Communication Breakdown: You try to explain technical constraints. Your manager hears excuses. You provide realistic timelines. Your manager thinks you're being lazy or inefficient. You highlight risks. Your manager sees unnecessary caution.

What This Feels Like: Your technical expertise is dismissed. Your professional judgment is questioned. Your attempts to prevent problems are seen as resistance to change. You're constantly justifying decisions to someone who doesn't have the technical foundation to understand the justification.

The Professional Damage:

  • Your recommendations get overridden by people with less technical knowledge

  • You implement solutions you know won't work, but can't convince leadership otherwise

  • When things inevitably go wrong, you're blamed for not speaking up more forcefully

  • Your credibility erodes because you're implementing bad decisions at management's direction

The Deeper Problem: This isn't just frustrating - it's existentially exhausting. You became a network engineer because you valued technical excellence and logical problem-solving. When your work environment doesn't value those things, you're fighting against the core reasons you chose this career.

Now that I'm on the management side, I'm acutely aware of this gap, which is why I wrote about the technical manager's dilemma - managers need to maintain enough technical knowledge to make informed decisions.

The Compounding Effect: When Everything Hits at Once

Here's what makes burnout so insidious in network engineering: these factors don't exist in isolation. They compound each other.

The Perfect Storm:

  • You're overworked with unrealistic deadlines (work overload)

  • Studying for certifications to advance your career (credential treadmill)

  • Projects keep getting reorganized with each leadership change (organizational chaos)

  • Your manager doesn't understand why you can't go faster (technical gap)

  • No clear strategy about where IT is heading (lack of vision)

  • All while trying to get to the "next level" in your career (advancement pressure)

The Downward Spiral: When you're burned out, everything becomes harder:

  • You make technical mistakes you wouldn't normally make

  • You're irritable with colleagues and management

  • You struggle to learn new technologies

  • Your job performance suffers, increasing anxiety about career progression

  • The certification studies that used to be interesting feel like torture

  • You stop caring about work that used to matter to you

The Warning Signs:

  • Sunday evening dread about the week ahead

  • Checking work email obsessively even on vacation

  • Physical symptoms: trouble sleeping, headaches, fatigue

  • Cynicism about projects and initiatives

  • Detachment from work that used to engage you

  • Fantasizing about leaving IT entirely

What Engineers Can Actually Control

Here's the hard truth: you can't fix organizational chaos, force your manager to understand networking, or stop leadership from changing. But you can control some things.

Setting Boundaries:

  • Define and protect your off-hours time

  • Learn to say "no" to additional commitments

  • Take a vacation and actually disconnect

  • Communicate capacity constraints clearly

Reframing Career Development:

  • Chase capabilities, not just credentials

  • Learn because it's interesting, not just for advancement

  • Accept that you can't learn everything

  • Define what "success" means for you personally

Managing Expectations:

  • Provide realistic timelines, not aspirational ones

  • Document technical decisions and recommendations

  • Communicate risks clearly, then accept management's decisions

  • Focus on doing your job well, not saving the organization

Finding Meaning:

  • Connect your work to outcomes that matter to you

  • Build relationships with colleagues who understand

  • Develop expertise in areas you find genuinely interesting

  • Remember why you chose this career initially

Knowing When to Leave: Sometimes the organization is broken beyond what you can tolerate. Sometimes your manager is fundamentally misaligned with how you work. Sometimes the career path you thought you wanted isn't actually right for you.

Recognizing when to leave isn't failure - it's self-awareness.

The Manager Perspective Preview

This blog covered burnout from the engineer's perspective - what it feels like on the receiving end of these organizational dynamics and pressures.

The next post in this series will examine burnout from the manager's side: What do managers see that engineers don't? Why do they make decisions that seem to ignore engineer burnout? What pressures are they under that create these situations?

Understanding both perspectives doesn't excuse poor management or organizational dysfunction. But it might help engineers and managers find ways to work together more effectively, or at least understand why the gap exists.

Conclusion: Burnout Is Real and It's Not Your Fault

If you're experiencing burnout as a network engineer, you're not alone, and you're not weak. The structure of IT work - constant change, always-on expectations, endless learning requirements, organizational chaos - is designed in ways that create burnout.

Here's what I want you to know:

You can't learn every technology. The treadmill is endless by design. Choose what matters to you and let the rest go.

Your worth isn't measured by certifications. Three letters after your name don't define your capability or your value as an engineer.

Working constantly doesn't make you dedicated. It makes you burn out. Boundaries aren't selfishness; they're survival.

Organizational chaos isn't your responsibility to fix. You can influence your immediate environment, but you can't solve systemic problems above your level.

Sometimes the problem isn't you. Sometimes the organization is broken, the manager is incompetent, or the situation is untenable. Recognizing that and making changes is a strength, not a failure.

You get one career, but you get one life. If your career is consuming your life in ways that make you miserable, something needs to change - whether that's boundaries, a new role, a new company, or a new career entirely.

I spent 20 years on the engineering side, experiencing many of these pressures. Now, three months into management, I'm seeing the other side. The next post will share that perspective, but for now, this one is for the engineers:

Your burnout is real. Your frustrations are valid. And you deserve better than what many IT organizations provide.

The first step toward addressing burnout is recognizing it, naming it, and understanding that it's not a personal failure. It's a systemic problem that requires both individual boundaries and organizational change.

Take care of yourself. Your network will survive if you set boundaries. Your career will progress even if you don't get every certification. And your value as an engineer isn't diminished by acknowledging that you're human with limits.

Continue the Conversation

Both Sides of the Desk Series:

  • Burnout (The Engineer's Perspective) - You are here

  • Burnout (The Manager's Perspective) - Coming soon

Related Posts

📧 Want more honest conversations about network engineering careers and management? Subscribe to my monthly newsletter (next issue: November 4th) for practical insights, real experiences, and perspectives from both sides of the desk. Sign up below!

Next
Next

What I Look for When Hiring Network Engineers: Beyond the Resume