(And It’s Costing You More Than You Think)
Most network engineers pride themselves on solving problems.
That’s the job, right?
Something breaks, something doesn’t scale, something behaves unexpectedly, and we jump in to fix it.
But what if the real issue isn’t how you’re solving the problem?
What if it’s that you’re solving the wrong problem entirely?
The Trap Most Engineers Fall Into
In a recent conversation with @radiaperlman, the inventor of Spanning Tree Protocol, she said something that stuck with me:
“You should know what problem you’re solving before you try to solve it.”
Sounds obvious.
It’s not.
Because most of us were trained to do the opposite.
We learned networking by memorizing:
- protocols
- commands
- configurations
- “best practices”
We weren’t taught to step back and ask:
What problem was this technology designed to solve? Is that even the problem I have?
So we default to what we know.
We reach for familiar tools.
And we optimize solutions to the wrong problems.
Why Modern Networking Feels So Confusing
There’s a reason networking sometimes feels messy, inconsistent, or overly complex.
According to Radia:
“Nobody would have designed what we have today.”
That’s not criticism, it’s reality.
Modern networking wasn’t built from a clean, logical blueprint. It evolved through:
- constraints
- business decisions
- standards battles
- and yes, egos
Protocols weren’t always chosen because they were the best solution.
They were often the ones that:
- shipped first
- were easiest to deploy
- or simply “won” at the right time
Which means:
The systems we operate today are full of historical compromises.
And if you don’t understand the original problem, the solution won’t make sense.
A Perfect Example: Spanning Tree
Spanning Tree is taught as a foundational concept.
But it wasn’t designed as an elegant, long-term solution.
It was a workaround.
At the time:
- End systems assumed the entire network was one big Ethernet
- Changing that wasn’t an option
- Loops became a problem
So the question wasn’t:
“What’s the best way to design a network?”
It was:
“How do we make this work without breaking everything that already exists?”
That’s a very different problem.
And it led to a very different solution.
The Real Skill: Problem Framing
The biggest takeaway from this conversation wasn’t about protocols.
It was about thinking.
Great engineers don’t just solve problems faster.
They:
- define problems better
- question assumptions
- and understand context
Because if you misunderstand the problem:
- your solution can be technically correct
- and still completely wrong
Where This Shows Up Today
This isn’t just history.
It’s happening right now.
You see it in:
- overengineered automation
- unnecessary complexity in data center designs
- blind adoption of new technologies
- chasing tools instead of outcomes
We’re still optimizing the solution before validating the problem.
The Question You Should Be Asking
Before you touch a config, write code, or deploy anything, ask:
What problem am I solving? Is it the right one?
Because once you get that wrong, everything else is just efficient failure.
Final Thought
Most engineers pride themselves on solving problems.
But if you’re solving the wrong problem, you’re just getting better at being wrong.
Listen to the full conversation: https://www.buzzsprout.com/2127872/episodes/18844805
Watch the video episode: https://youtu.be/X9WNL9l0NA0
Links: https://linktr.ee/artofneteng
Discover more from The Art of Network Engineering
Subscribe to get the latest posts sent to your email.
