Explaining Network Engineering to Non-Technical People: How to Make Them Actually Understand (Without Their Eyes Glazing Over)
The Moment You Realize Technical Accuracy Doesn't Matter
It's a budget meeting, and you're presenting your request for a network infrastructure refresh.
You've prepared a detailed technical justification. The current equipment is end-of-life, the routing architecture doesn't scale, and you need modern capabilities for SD-WAN integration.
You're two minutes into explaining the technical details when you see it: the CFO's eyes have glazed over. The COO is checking their phone. Your own boss is giving you a "wrap it up" look.
You lost them.
Not because you're wrong and not because the need isn't real but because you're speaking a language they don't understand and answering questions they're not asking.
Here's what I'm learning as a manager:
Your technical expertise matters less than your ability to translate that expertise into language that stakeholders understand. You can be the best network engineer in the building, but if you can't explain why your work matters in terms that executives care about, you won't get the resources you need.
Let me share what's working (and what's failing) when trying to explain network engineering to non-technical people.
Why This Is So Hard (And Why It Matters)
The Problem We Face
As network engineers, we think in:
Protocols and architectures
Technical specifications and capabilities
How things work under the hood
Edge cases and failure scenarios
Non-technical people think in:
Business outcomes and revenue impact
Cost and ROI
Risk to operations
Competitive advantage
The gap is huge. And most of us were never trained to bridge it.
Why It Matters More Now
Seven months into management, I've realized:
Budget requests live or die on how well you explain them
Incident communication to executives affects how they view IT's competence
Project approval depends on translating technical benefits into business value
Your career progression depends on leadership understanding your impact
The hard truth:
Being technically brilliant but unable to communicate means you'll be passed over for resources, promotions, and opportunities. The person who can explain things clearly will advance faster than the person who's technically superior but can't articulate value.
The Mistakes We Make
What I was doing wrong:
Mistake 1: Assuming they want technical details
They don't. They want to understand impact, not implementation.
Mistake 2: Using jargon because it's faster
"We need to implement VXLAN with EVPN for our data center fabric" is meaningless to non-technical people. Faster for you, useless for them.
Mistake 3: Getting defensive when they don't understand
"This is basic networking stuff," or "I explained this already," makes them feel stupid, and you look condescending.
Mistake 4: Dumbing it down so much it's patronizing
There's a difference between simplifying and treating people like children.
Mistake 5: Leading with how instead of why
They don't care HOW your network works. They care WHY it matters to the business.
Communicating effectively with leadership connects to Managing Up as a Technical Manager - your ability to translate technical needs into business language determines what resources you get.
The Framework That Actually Works
Here's the structure I'm using now when explaining network engineering to non-technical audiences:
Step 1: Start with the Business Problem, Not the Technical Solution
Don't start here:
"We need to upgrade our routing protocol from OSPF to BGP."
Start here:
"Our current network architecture is creating a business problem: when we open new retail locations, it takes 6-8 weeks to get them fully connected and operational. This is delaying revenue from new stores."
Then:
"The technical reason is our current routing approach requires manual configuration at every location. We need to modernize our network architecture so new locations can be connected in days instead of weeks."
Why this works:
You've established a business problem they understand (slow store openings = delayed revenue) before introducing technical concepts.
Step 2: Translate Technical Concepts into Familiar Analogies
The challenge:
Network engineering is abstract. Packets, protocols, and routing - these aren't tangible things most people interact with.
The solution:
Use analogies from things they already understand.
Examples that work:
Explaining Network Redundancy:
❌ "We need redundant links with HSRP for gateway failover."
✅ "Think of it like having two engines on an airplane. If one fails, the other keeps you flying. Right now, our network has one engine - if it fails, everything stops."
Explaining Bandwidth:
❌ "We need to upgrade from 100 Mbps to 1 Gbps circuits."
✅ "Imagine our network connection is like a highway. Right now we have a two-lane road, and during business hours we have traffic jams. We need to expand to an eight-lane highway so traffic flows smoothly even during peak times."
Explaining Network Segmentation:
❌ "We need to implement VLANs and firewall policies for microsegmentation."
✅ "Right now, our network is like a building with no internal walls - if someone gets in, they can access everything. We need to add walls and locked doors so even if someone breaks in, they can only access one room, not the whole building."
Explaining SD-WAN:
❌ "We're replacing MPLS with SD-WAN using multiple transport options and intelligent path selection."
✅ "Right now, we pay for a dedicated private highway between our locations - expensive but reliable. New technology lets us use the regular internet, with smart routing that ensures our business traffic gets priority, like a dedicated lane on a regular highway. Same reliability, half the cost."
The key:
Find analogies that match their world - business operations, transportation, buildings, and security concepts they already understand.
Step 3: Lead with Impact, Then Explain Why
Structure:
What's the business impact?
Why is this happening technically? (brief)
What's the solution and its business benefit?
Example - Explaining a Network Outage:
❌ Technical-first approach:
"We had a spanning tree topology change that caused a broadcast storm, which saturated our uplinks and triggered interface error-disable."
Their reaction: "I have no idea what you just said."
✅ Impact-first approach:
"We had a network outage that took down our e-commerce site for 45 minutes, which likely cost us approximately $50K in lost revenue based on our average hourly sales.
Here's what happened in simple terms: our network has built-in protections to prevent loops, much like roads have one-way signs to prevent traffic from circling endlessly. A device was misconfigured and created a loop anyway, overwhelming the network with traffic until our automatic protections shut things down to prevent damage.
We've fixed the immediate issue and are implementing additional safeguards to prevent this type of misconfiguration in the future."
Why this works:
Starts with the business impact they understand ($50K lost revenue)
Explains technical cause in relatable terms (one-way streets)
Describes what you're doing without unnecessary detail
Focuses on prevention, not just fix
Step 4: Quantify Everything You Can
Non-technical people trust numbers more than technical claims.
Examples:
❌ Vague: "Our network is slow and needs an upgrade."
✅ Quantified: "Our network bandwidth utilization averages 85% during business hours. Industry best practice says performance degrades above 70%. We're seeing 3-4 complaints daily about slow application performance. Upgrading will cost $50K but eliminates an estimated 20 hours per week of productivity loss across 200 employees."
❌ Vague: "We need better network monitoring."
✅ Quantified: "Last quarter, we had 3 outages that we didn't detect until users called the help desk - average 30 minutes before we even knew there was a problem. Better monitoring would alert us immediately, reducing our mean time to detection from 30 minutes to under 2 minutes. That's 28 minutes of revenue-impacting downtime we could eliminate per incident."
❌ Vague: "This project will take a while."
✅ Quantified: "This project will require 120 hours of engineering time over 6 weeks. We'll complete it in phases to minimize risk - pilot at one location (week 1-2), validate results (week 3), then roll out to the remaining 24 locations (weeks 4-6)."
What to quantify:
Cost (upfront and ongoing)
Time (how long things take, how long outages last)
People impact (users affected, productivity hours lost)
Revenue impact (sales lost during outages, efficiency gains)
Risk (probability and cost of failures)
Step 5: Use the "So What?" Test
After every technical statement, ask yourself, "So what?"
Example:
"We need to upgrade our firewall firmware."
So what?
"The current firmware has security vulnerabilities."
So what?
"Those vulnerabilities could allow attackers to breach our network."
So what?
"A breach could expose customer data, resulting in regulatory fines, legal liability, and reputation damage."
The final statement is what you lead with:
"We need to upgrade our firewall firmware to address security vulnerabilities that, if exploited, could result in customer data breaches with regulatory and legal consequences."
Another example:
"We should implement network automation."
So what?
"It reduces manual configuration work."
So what?
"Engineers spend less time on repetitive tasks."
So what?
"They have more time for strategic projects and new business initiatives."
The final statement:
"Network automation will free up approximately 15 hours per week of engineering time currently spent on manual configuration, allowing us to take on strategic projects that we're currently deferring due to lack of capacity."
Keep asking "so what?" until you get to business impact.
Building business cases with quantified impact is something I explored in Your First IT Budget - every significant request needs this translation from technical need to business value.
Common Scenarios and How to Handle Them
Let me get specific about situations you'll face:
Scenario 1: Explaining Why You Need Budget for "Something That's Working Fine"
The situation:
You need to replace aging network equipment. To non-technical people, "it's still working" means "we don't need to replace it."
❌ What doesn't work:
"This equipment is end-of-life and end-of-support."
They hear: "IT wants to spend money on something that works because they like new toys."
✅ What works:
"This equipment is 8 years old and the manufacturer stopped supporting it last year. Here's what that means for the business:
If it fails, we can't get replacement parts. Recovery time goes from 4 hours to potentially days or weeks while we source used equipment or do emergency replacements.
We can't get security patches. We're running known vulnerabilities that could be exploited.
It doesn't support the capabilities we need for [specific business initiative].
The cost of proactive replacement is $75K. The cost of an unplanned failure - between emergency replacement costs, extended downtime, and potential security breach - could easily exceed $500K.
We're not replacing it because it's old. We're replacing it before it becomes a business-critical failure."
Why this works:
Explains what "end-of-life" means in business terms
Quantifies the risk of NOT replacing
Frames it as risk mitigation, not technology refresh
Scenario 2: Explaining a Network Outage to Executives
The situation:
Major outage. Leadership wants to know what happened. They don't care about BGP or spanning tree - they care about why customers were impacted and how you prevent it from happening again.
❌ What doesn't work:
"We experienced a routing loop due to a misconfigured redistribution policy between OSPF and BGP that caused suboptimal path selection and blackholing of traffic."
✅ What works:
"We had a network outage from 2:15 PM to 3:45 PM that impacted our customer-facing website and internal applications.
Business Impact:
Estimated $80K in lost e-commerce revenue
450 customer support calls
Delayed order processing is creating a backlog we're working through
What Happened: A configuration change designed to improve performance had an unintended side effect, creating a loop in how network traffic was routed. Think of it like a traffic circle with incorrect signage - cars kept circling instead of exiting.
Immediate Fix: We rolled back the configuration change within 30 minutes of identifying the issue. Full-service restoration took an additional hour.
Prevention:
Implementing automated testing for configuration changes (catches these issues before they reach production)
Requiring changes to be piloted in a non-production environment first
Adding monitoring to detect this type of issue within 2 minutes instead of 30 minutes
Timeline for Prevention Measures: Automated testing: 2 weeks with enhanced monitoring: Completed already. Pilot environment requirement: Policy updated, in effect immediately."
Why this works:
Leads with business impact (they care about this most)
Explains the technical issue in a simple analogy
Shows you identified and fixed it
Demonstrates concrete prevention steps
Provides a timeline for improvements
Scenario 3: Justifying Ongoing Network Maintenance Work
The situation:
Leadership sees engineering time spent on "maintenance" as unproductive. They want you focused on "strategic projects."
❌ What doesn't work:
"We need to patch systems, update configurations, and perform routine maintenance."
✅ What works:
"Network maintenance is like car maintenance - you can skip it for a while, but eventually it catches up with you, usually at the worst possible time.
Here's what our routine maintenance prevents:
Security patches (8 hours/month):
Address vulnerabilities before they're exploited
Last quarter, a vulnerability we patched early was exploited at 3 competitors, resulting in breaches and regulatory fines
Configuration updates (6 hours/month):
Keep systems aligned with current security standards
Prevent configuration drift that causes unexpected failures
Performance monitoring and optimization (10 hours/month):
Identify issues before they impact users
Prevent 3-4 potential outages per quarter based on trends we catch early
Total: 24 hours/month of maintenance prevents an estimated 50+ hours/month of emergency firefighting and reactive work.
If we defer maintenance to focus only on new projects, we end up with more frequent outages that interrupt those same projects plus damage business operations.
The question isn't whether we do maintenance - it's whether we do it proactively on our schedule or reactively during outages on the business's schedule."
Why this works:
Uses a familiar analogy (car maintenance)
Quantifies what maintenance prevents
Shows how deferring maintenance costs more time, not less
Reframes it as risk management, not just "keeping busy."
The importance of proactive maintenance relates to Technical Debt: What Engineers Wish Managers Understood - deferred maintenance becomes technical debt that eventually comes due with interest.
Scenario 4: Explaining Why "Just Use the Internet" Isn't Good Enough
The situation:
Leadership sees you paying for dedicated circuits or MPLS and thinks, "Why don't we just use regular internet like we do at home?"
❌ What doesn't work:
"MPLS provides guaranteed QoS and SLA-backed performance that commodity internet can't match."
✅ What works:
"Your home internet works fine for Netflix and email because it doesn't matter if there's a brief delay or if a video buffers for a second.
Our business applications - especially our point-of-sale systems processing credit card transactions - can't tolerate those delays. A 2-second delay in transaction processing means a frustrated customer at checkout. Multiply that across 50 stores during peak hours, and we're losing sales.
Regular internet is 'best effort' - like regular mail. It gets there eventually, but no guarantees on when.
Business-grade circuits are like a courier service - guaranteed delivery time, with financial penalties to the provider if they don't meet the guarantee.
The cost difference: Regular internet might save us $40K/year. But even a 1% decrease in transaction completion rate due to connectivity issues costs us approximately $200K/year in lost revenue.
We're not paying extra for performance - we're paying to guarantee consistent customer experience and revenue."
Why this works:
Acknowledges their reasonable question
Explains the difference in business terms (courier vs. mail)
Quantifies the false economy of the "cheaper" option
Frames it as customer experience and revenue protection
Scenario 5: Getting Approval for Network Redesign vs. "Band-Aid Fixes"
The situation:
You want to do a proper network redesign. Leadership wants you to just "add capacity" or "patch the problem."
❌ What doesn't work:
"The architectural approach is fundamentally flawed and needs to be redesigned from the ground up."
✅ What works:
"I'll use a building analogy. Our current network is like a house that was built for a family of 3, and we're now a family of 10.
We could keep adding rooms and extensions - that's what we've been doing. Each addition works initially, but:
The foundation wasn't designed for this weight
Electrical and plumbing are overloaded
Heating and cooling can't keep up
Each addition is more expensive and less effective than the last
At some point, it's actually cheaper and more effective to build a properly-sized house from the start.
Here's our reality:
Band-aid approach:
Cost over 3 years: $150K in incremental fixes
Performance: Declining as we add more patches
Failure risk: Increasing because patches create complexity
Scalability: Hits limits in approximately 18 months
Redesign approach:
Cost: $200K upfront
Performance: 10x improvement
Failure risk: Significantly reduced with modern architecture
Scalability: Supports growth for 5+ years
The $50K difference buys us:
Better performance
Lower ongoing costs
Reduced outage risk
Runway for business growth
We can keep patching, but the patches are becoming more expensive and less effective. At some point, we'll be forced to redesign anyway - during a crisis instead of on our terms."
Why this works:
Relatable analogy (house additions)
Shows you considered the band-aid approach (not just pushing for redesign)
Quantifies both options
Demonstrates long-term thinking
Acknowledges their concern about cost while making the business case
Adapting Your Communication to Different Audiences
Not all non-technical people are the same. You need to adjust your approach:
CFO / Finance Team
What they care about:
ROI and payback period
Operating expense vs. capital expense
Budget impact and cash flow
Risk to financial performance
How to frame network projects:
"This $100K network upgrade reduces ongoing circuit costs by $30K annually - 3.3 year payback. It also reduces downtime risk, which averaged $50K per incident last year."
Language they understand:
Total cost of ownership
Payback period
Operating expense reduction
Risk mitigation
Budget vs. actual
CEO / Executive Team
What they care about:
Strategic objectives and competitive advantage
Revenue impact
Customer experience
Business risk
Reputation
How to frame network projects:
"This network modernization enables the store expansion strategy by reducing new location connectivity time from 6 weeks to 3 days. It also improves point-of-sale reliability, directly impacting customer experience and revenue."
Language they understand:
Enables business strategy
Customer impact
Revenue growth
Competitive positioning
Risk to operations
Operations / Department Heads
What they care about:
Day-to-day operational impact
Employee productivity
Customer service capability
Reliability and uptime
How to frame network projects:
"This network upgrade eliminates the application slowness your team experiences during peak hours, improving order processing time by an estimated 15-20%. It also reduces the 'network is slow' help desk tickets that consume your team's time."
Language they understand:
Productivity improvements
Reduction in complaints
Operational efficiency
User experience
Board of Directors
What they care about:
Strategic alignment
Major risks
Significant investments
Competitive position
Regulatory compliance
How to frame network projects:
"Our network infrastructure strategy aligns with the company's digital transformation initiative while addressing cybersecurity risks that could result in regulatory action. The proposed investment positions us to support projected growth while maintaining the security and reliability our customers expect."
Language they understand:
Strategic alignment
Risk management
Long-term positioning
Regulatory compliance
Competitive advantage
What NOT to Do (Common Mistakes)
Mistake 1: Using Acronyms Without Explanation
❌ Bad:
"We need to implement QoS on our WAN links using DSCP markings and configure our edge routers with CBWFQ and LLQ for voice traffic prioritization."
Even this is too much:
"We need to implement Quality of Service (QoS)..."
If you use the acronym, they'll stop listening.
✅ Better:
"We need to implement traffic prioritization so that voice calls and critical business applications get network priority over less important traffic like software updates or file backups. This ensures call quality remains high even when the network is busy."
Mistake 2: Over-Explaining
The trap:
You understand the topic deeply, so you explain all the nuance and edge cases.
The reality:
They need 20% of what you know. More detail creates confusion, not clarity.
❌ Too much detail:
"We need to replace our access switches. The current models are Catalyst 2960-X with limited stacking bandwidth and no support for MACsec encryption. The replacement Catalyst 9300 series offers higher stacking throughput, support for 802.1AE MACsec, upgraded to a modular architecture with field-replaceable components, and includes DNA licensing for enhanced security analytics and automated troubleshooting capabilities..."
✅ Right level:
"We need to replace our access switches. The current models are 8 years old and can't support the security features we need for compliance. New switches will provide required security capabilities and are more reliable with lower failure rates."
Mistake 3: Being Condescending
The trap:
You're frustrated they don't understand networking, so your tone becomes patronizing.
❌ Condescending:
"It's really quite simple. I'm surprised you don't understand this."
"This is basic networking. Everyone knows that..."
"Let me explain this in terms you can understand..."
✅ Respectful:
"Let me explain this differently. [Analogy or simplified explanation]"
"This is a complex topic. The key thing to understand is..."
"Here's a way to think about it: [example]"
Mistake 4: Blaming Them for Not Understanding
❌ Defensive:
"I explained this in the last meeting."
"This is why we need technical people making technical decisions."
"You just need to trust me on this."
✅ Owning the communication:
"I may not have explained this clearly. Let me try a different approach."
"I realize this is technical. Here's what it means in practical terms."
"Let me walk through the business impact of this decision."
The reality:
If they don't understand, that's a failure of your communication, not their intelligence.
Mistake 5: Getting Technical When Challenged
The trap:
Someone questions your recommendation. You respond with more technical detail to "prove" you're right.
❌ Doubling down on technical:
Them: "Why can't we just use cheaper equipment?"
You: "Because the cheaper equipment doesn't support BGP multihoming with conditional advertisement and has lower MTBF ratings with insufficient buffer depth for our traffic patterns."
✅ Addressing their actual concern:
Them: "Why can't we just use cheaper equipment?"
You: "Good question. The cheaper equipment would save us $15K upfront but creates two problems: it doesn't have the reliability we need (higher failure rate means more downtime), and it can't support the redundancy features that prevent outages. The total cost of ownership including downtime risk actually makes it more expensive over time."
Address their underlying concern (cost), not their technical understanding.
Practical Tips for Specific Situations
Writing Email Updates About Network Issues
Structure:
Subject line: Impact-focused, not technical
❌ "Spanning tree topology change event."
✅ "Network connectivity restored - 45 minute outage resolved"
First paragraph: Impact and current status
What was affected
How long
Current state (resolved/ongoing)
Second paragraph: Cause in simple terms
Brief, non-technical explanation
One analogy if helpful
Third paragraph: What you're doing
Immediate fix (if applicable)
Prevention measures
Timeline
Close: Contact info for questions
Example:
Subject: E-commerce site connectivity restored - 45-minute outage resolved
Our e-commerce website experienced a network outage from 2:15 PM to 3:00 PM today, preventing customers from placing orders. Service is fully restored.
The outage was caused by a configuration error that created a traffic loop in our network - similar to a traffic circle with incorrect signage, causing cars to circle endlessly rather than exit properly.
We've corrected the configuration and implemented additional monitoring to detect this type of issue within 2 minutes in the future (vs. 30 minutes today). We're also adding automated testing to catch configuration errors before they affect production.
Please let me know if you have questions.
Presenting Technical Projects in Budget Meetings
Slide 1: The Problem (Business Impact)
What's not working
Impact on business operations
Cost of continuing the current state
Slide 2: The Solution (High Level)
What you're proposing (simple terms)
How it solves the problem
Why this approach
Slide 3: The Numbers
Cost breakdown
Timeline
ROI or risk mitigation value
Slide 4: The Risk
What happens if we don't do this
What happens if we defer
Slide 5: The Ask
Specific budget request
Decision needed
Next steps
Keep it to 5 slides. If you need backup details, put them in an appendix that they can review if interested.
Handling "Why Is This Taking So Long?" Questions
❌ Defensive technical explanation:
"Network migrations are complex. We have to consider BGP route propagation, maintain routing adjacencies, coordinate with multiple vendors, and ensure no disruption to production traffic flows."
✅ Business-context explanation:
"We're connecting 25 locations with zero downtime allowed for customer-facing systems. Think of it like replacing all the roads in a city while keeping traffic flowing - it requires careful planning and coordination. We're doing it site by site to minimize risk. If we rushed it and caused an outage, the business impact would be significant."
Then provide a timeline:
"Current progress: 8 of 25 sites complete. Remaining 17 sites will be completed over the next 6 weeks at a rate of 2-3 per week."
What I'm Still Learning
Seven months into management, here's what I'm still figuring out:
How much simplification is too much?
Sometimes I simplify so much that I lose important nuance. Finding the right balance is hard.
When to push back on oversimplification from others?
Sometimes, non-technical people oversimplify to the point of being wrong. When do I correct vs. let it go?
How to handle "just make it work" responses?
When I explain constraints and get back "I don't care about the technical details, just make it work," - how do I respond?
Building credibility with audiences who don't trust IT?
In organizations where IT has historically over-promised and under-delivered, how do I rebuild trust through communication?
The Bottom Line: Your Career Depends on This Skill
Here's what I'm learning about technical communication:
Your technical expertise gets you in the door. Your communication skills determine how far you go.
Non-technical people aren't stupid. They're experts in their domains. Your job is to translate your expertise into terms they understand.
Business impact matters more than technical elegance. Lead with why it matters, not how it works.
Analogies are your friend. Find relatable comparisons from their world.
Quantify everything possible. Numbers are a universal language.
Simplify without being condescending. Respect their intelligence while explaining clearly.
If they don't understand, that's on you. Communication is your responsibility, not theirs.
Practice makes better. You'll get better at this with every budget meeting, outage explanation, and project presentation.
The skill compounds. Better communication leads to more approved budgets, which leads to better infrastructure, which leads to fewer outages, which leads to more credibility, which leads to more approved budgets.
It's not optional. If you want to advance in your career, you must master this skill.
The Framework I Use
Before any technical communication to a non-technical audience:
What's the business impact? (Lead with this)
What do they actually need to know? (Not everything you know)
What's the analogy? (Find a relatable comparison)
What are the numbers? (Quantify impact, cost, timeline)
What's the ask? (Decision, approval, budget, support)
During the communication:
Lead with impact
Explain in simple terms
Use one good analogy
Provide specific numbers
State the ask clearly
Stop talking
After:
Did they understand? (Check for comprehension)
Did I get what I needed? (Approval, support, budget)
What could I have explained better? (Learn for next time)
Continuing the Conversation
Related Topics:
Managing Up as a Technical Manager - Communicating effectively with leadership
Your First IT Budget - Building business cases for technical spending
When Your Team Is Right and Leadership Is Wrong - Translating between technical and business perspectives
Communication in Practice:
Managing Your Team Through a Major Outage - Incident communication to stakeholders
Both Sides of the Desk: Asking for a Raise - Making your case in business terms
Should You Move to the Cloud? - Explaining complex decisions to leadership
📧 Want to improve your technical communication skills? Subscribe to my monthly newsletter for practical perspectives on technical leadership, communicating with non-technical stakeholders, and advancing your career through better communication. First Tuesday of every month. Sign up here
How do you explain network engineering to non-technical people? What analogies work for you? What's been your biggest communication failure (and what did you learn)? Share your experiences in the comments or connect with me on LinkedIn - we're all learning this together.