You’ve probably seen “tenets” before.
They’re written on posters, buried in wikis, or flashed briefly at the start of some all-hands meeting. Most engineers glance at them once, think “corporate fluff,” and go back to their terminals.
I get it. A lot of so-called tenets are fluff.
But when they’re done and followed properly, tenets are one of the most powerful tools you can have as an engineer, for your day-to-day decisions, for your team’s culture, and for your career growth.
Used well, tenets are how you move from “I configure things” to “I define how we work around here.”
Let’s talk about what that looks like, especially in the context of modern network engineering and NetDevOps.
1. Tenets Are Decision Filters, Not Wall Art
Forget buzzwords for a minute.
A tenet is a short, opinionated principle that answers a simple question:
“When there are trade-offs and uncertainty, what do we bias toward?”
It’s not a vague value like “excellence” or “innovation.”
It’s closer to something like:
Security First – if a decision trades security for short-term convenience, we say no.
Simplicity Over Complexity – when in doubt, we choose the simpler design, even if the complex one looks “smarter.”
Notice what those statements do:
They disqualify certain options. If a proposed design clearly violates “Security First,” you don’t have to argue for three hours: you point at the tenet, and everyone knows it’s a non-starter.
They travel across contexts. The same tenet can guide a BGP policy discussion, a data model design, or a CI/CD pipeline.
Bad tenets are fuzzy and non-committal:
“We care about quality.”
“We like efficiency.”
These never change anything, because every option can claim to follow them.
Good tenets are sharp enough that you can imagine a real situation where they force you to say:
“I like option B, but given our tenet, we need to pick A.”
That’s the bar.
2. Why Tenets Are a Cheat Code for Career Growth
Let’s be blunt: a lot of engineers stagnate not because they lack technical skill, but because they struggle with ambiguity.
They can configure BGP or write Python, but when there are multiple viable designs, they freeze.
In a design review, they defend their choice with “I just think this is better” instead of a clear, principled argument.
In incidents, they get lost when priorities conflict: recover quickly vs. avoid risk vs. capture data.
Tenets give you a way out of that.
Imagine two engineers in a design meeting.
Engineer A says:
“I think we should use this multi-protocol design: OSPF for underlay, BGP for overlay, plus a custom controller. It’s flexible.”
Engineer B says:
“Given our tenet Simplicity Over Complexity, I’m leaning toward BGP-only with EVPN for the overlay. We get what we need with fewer moving parts, fewer failure modes, and a simpler operational model. The extra flexibility of the other option doesn’t justify the complexity tax.”
Even if both options are viable, who sounds more like the future staff or principal engineer?
The second one, because they:
Use a shared tenet, not personal preference.
Reason in terms of reliability, operations, and trade-offs.
Give the team a reusable pattern for similar decisions in the future.
Tenets become your language for leadership, even if your title doesn’t yet say “leader.”
3. The NetDevOps Manifest: Tenets for Modern Network Engineers
Let’s make this concrete with a set of tenets that work really well in network engineering and NetDevOps.
I call this set the NetDevOps Manifest. You don’t have to adopt all of them, but notice how each one shapes decisions.
3.1 Availability Is Not Negotiable
If a design or change materially harms availability, it’s wrong, no matter how elegant it looks on paper.
If introducing a new firewall cluster creates a single point of failure on a critical path, you either change the design or reject it.
If a migration plan requires taking the entire core down for “just 10 minutes,” you keep planning until that’s no longer true.
You’re allowed to negotiate features, timelines, and aesthetics.
You’re not allowed to negotiate uptime for key services.
3.2 Failures Are Inevitable – Recovery Must Be Boring
You don’t design a network hoping it won’t fail. You design it knowing it will.
Links will flap, optics will die, processes will crash, and humans will fat-finger commands.
The question is: do you rely on luck and heroics, or do you build in fast detection and predictable recovery?
This tenet biases you toward:
Fast reroute mechanisms (TI-LFA, FRR, PIC).
Clear failover sequencing.
Runbooks encoded into automation, not just stored in someone’s memory.
When you internalize this, you stop being impressed by “we saved the day at 3 a.m.” and start asking, “Why did it require saving in the first place?”
3.3 Routing Intent Must Be Explicit and Enforceable
If your routing behavior lives only in configs and tribal memory, you don’t really control it.
This tenet pushes you to:
Describe routing policies, topologies, and traffic goals as data in a source of truth.
Make them reviewable (“we want traffic from A to B to avoid C during business hours”).
Validate them continuously using telemetry and tools like BMP, flow logs, and path tracing.
No more “well, that’s just how it’s always been configured.” If it matters, it’s written down and enforced.
3.4 Measure Everything, Assume Nothing
Humans are great at stories and terrible at intuition under load.
You might feel like “convergence is fast enough” or “latency is fine,” until data proves otherwise.
This tenet means:
You measure convergence times after changes.
You measure packet loss and jitter between critical endpoints.
You measure how often incidents actually happen, how long they last, and what caused them.
Then you design and automate based on data, not vibes.
3.5 Simplicity Enables Reliability
Complexity isn’t evil on its own; it just charges interest.
Every extra protocol, layer of abstraction, or clever optimization:
Adds new failure modes.
Makes debugging harder.
Lengthens onboarding time for new engineers.
This tenet doesn’t ban sophistication; it says:
“If a simpler design meets the requirements with acceptable cost, choose it, even if the more complicated one looks cooler on your résumé.”
When in doubt, you remove knobs; you don’t add them.
3.6 Automation Is the Only Path to Scale
Manual work doesn’t scale, not in device count, not in complexity, not in reliability.
This tenet pushes you to:
Treat repetitive CLI work as a bug, not a job description.
Build pipelines with pre-checks, staged rollout, and rollback instead of ad-hoc scripts.
See automation as safety, not as a risky “extra layer.”
It also shapes career choices: you invest time in tools, data models, and platforms, not only in isolated scripts or commands.
4. How Tenets Change Real Decisions
Let’s walk through a few realistic situations where tenets make the difference.
Situation 1 – “Ship Now, Fix Later”
Product wants a new region turned up quickly to capture demand. The network change is large, touches multiple edge routers, and introduces a new peering policy.
The shortcut: push the change globally in one window, with minimal testing.
Tenets kick in:
Availability Is Not Negotiable – a global blast radius for a new, unproven policy is unacceptable.
Measure Everything, Assume Nothing – we need targeted tests, traffic simulations, and telemetry hooked up.
Decision:
Phase the rollout: enable the policy on one edge router in a less critical region first.
Monitor reachability, error rates, and path behavior.
Only expand when evidence says it’s safe.
Ship speed is preserved and risk is controlled. Tenets provided the backbone to say “we’ll deliver, but not recklessly.”
Situation 2 – “The Clever Franken-Design”
An enthusiastic engineer proposes using OSPF for underlay, BGP for overlays, and a custom controller to steer traffic based on fancy heuristics. On the whiteboard, it looks like a sci-fi network; very impressive.
Tenet time:
Simplicity Enables Reliability – can we meet requirements with fewer moving parts?
Automation Is the Only Path to Scale – can we realistically automate and test this multi-protocol beast?
You explore a BGP-only underlay + EVPN overlay design. It covers almost all requirements with less complexity and a clearer automation story.
Decision:
You choose the simpler BGP/EVPN architecture, document the trade-offs, and explicitly record in the design doc:
“We rejected the multi-protocol design because it violates our simplicity tenet and would be harder to automate reliably.”
Now your decision is defensible and consistent, not just “we felt like it.”
Situation 3 – “Let’s Just Fix It on the Device”
During an incident, someone suggests:
“Don’t touch the automation; I’ll just log into the router and add this static route. We’ll clean it up later.”
It’s tempting. It might even work. But your tenets say:
Routing Intent Must Be Explicit and Enforceable – if we bypass intent now, we’re creating hidden state.
Automation Is the Only Path to Scale – making exceptions by hand is exactly how scale and reliability collapse.
So you do something slightly harder but much safer:
You update the source of truth or the intent model.
You let the pipeline generate and push the change.
You then prioritize cleaning up the underlying design so you don’t have to rely on emergency statics next time.
Tenets forced you to resist the hack and protect the system long term.
5. Designing Your Own Tenets
You don’t have to use my NetDevOps Manifest word for word. In fact, you should adapt and extend it. Or make your own from scratch; whatever suits you best!
Here’s a simple way to draft tenets for yourself or your team.
Step 1 – Look at your scars
Think of:
The incidents that haunt you.
The projects that dragged on or failed.
The migrations that hurt more than they should have.
Ask: “What principle, if we had followed it, would have saved us?”
Maybe it’s:
“No change without automated rollback.”
“Never deploy a feature we can’t observe.”
Those are tenets.
Step 2 – Look at your proudest wins
Identify:
The designs you still feel good about years later.
The migrations that went suspiciously smoothly.
The moments when you made a hard call that turned out right.
Ask: “What principle was I unconsciously following?”
Perhaps you kept the design brutally simple, or insisted on having a lab that matched production. Name those instincts as tenets.
Step 3 – Distill into sharp sentences
Refine each into something:
Short enough to remember.
Strong enough to cause disagreement.
Clear enough to apply under pressure.
“We value quality” is not a tenet.
“Security beats convenience every time” is.
Step 4 – Publish and use them
Tenets are only useful if they’re used:
Put them in your design doc template: a section called “Tenets and Trade-offs.”
Reference them explicitly in reviews: “This approach violates Simplicity Enables Reliability; do we accept that debt and why?”
Bring them into incident postmortems: “Which tenet did we ignore? Do we need a new one?”
As you do this, tenets move from being slogans to being operating rules.
6. Tenets in Team Rituals: Reviews, On-Call, and Postmortems
Let’s see how tenets show up in the day-to-day.
Design Reviews
Instead of endless bikeshedding over personal preferences, you:
Anchor the discussion in tenets: “Given Availability Is Not Negotiable, I’m worried that this fails over too slowly.”
Capture explicit decisions: “We accept this complexity because it’s the only way to meet regulatory requirements, even though it pushes against our simplicity tenet.”
Over time, your design docs become a library of trade-off stories, each linked back to principles.
On-Call and Incident Response
When things break at 3 a.m., tenets become a triage compass:
“Protect availability first; we can refactor tomorrow.”
“Don’t bypass automation unless keeping the system alive absolutely requires it, and then document it fully.”
This keeps the team aligned even when adrenaline is high and details are fuzzy.
Postmortems
After an incident, you don’t just ask “what went wrong?” You also ask:
“Which tenet did we violate?”
“Do we need to refine an existing tenet or add a new one?”
For example:
If you repeatedly struggle because you can’t see what’s happening during changes, you might add:
“No change without observability: if we can’t see it, we don’t ship it.”
Now incidents actively evolve your tenets, and your tenets actively prevent future incidents.
7. The Meta-Tenet: Own Your Craft
Underneath all of this, there’s a bigger shift.
Most engineers spend their whole careers inside a system someone else defined:
Someone else chose the tools.
Someone else set the standards.
Someone else decided what “good” looks like.
When you start crafting, using, and refining tenets, you step across a line.
You’re not just keeping the network alive; you’re designing the way engineering is done in your sphere of influence.
That’s what senior leadership actually looks for:
People who can make hard decisions in ambiguous situations.
People who can encode good judgment into simple, shareable principles.
People who can explain why a design is the right one, not just how to configure it.
Tenets are one of the best tools you can use to move into that space.
Start small:
Pick two or three tenets from the NetDevOps Manifest that resonate with you—maybe Availability Is Not Negotiable, Simplicity Enables Reliability, and Automation Is the Only Path to Scale.
Add one personal tenet based on your own scars and wins.
Use them explicitly in your next design, change, or postmortem.
You’ll notice two things:
Your decisions become clearer and easier to defend.
People start to see you differently, not just as “the BGP person” or “the automation person,” but as someone who brings a coherent engineering philosophy to the table.
And that, more than any particular vendor cert or tool, is what will carry your career forward.
If you want to go deeper into these tenets and how they play out in real ISP, data center, and hyperscale environments, that’s exactly what I unpack in my long-form content and newsletter, The Routing Intent.
In the meantime, start writing your tenets.
Because if you don’t define how you work, someone else, or worse, pure randomness, will do it for you.
Leonardo Furtado