Skip to content

Prime Philosophy

The PRIME Philosophy

Why Philosophy Matters Before Process

Most automation vendors sell you a methodology—a process to follow. "Here are the steps. Trust us."

We start differently: with principles.

Before we write a single line of code, before we design a workflow, we agree on what matters. These principles shape every decision, every line of documentation, every conversation with your team.

If you understand our philosophy, you'll understand why the PRIME Framework works the way it does.

Five Core Principles

Our philosophy rests on five interconnected principles that appear throughout all we deliver:

  1. Transparency — No black boxes, full understanding
  2. Measurability — Data-driven decisions, proven ROI
  3. Ownership — Your team owns the automation
  4. Safety — Production-grade reliability, not shortcuts
  5. Empowerment — Understanding, not dependency

The Five Core Principles

1. Transparency Over Obscurity

The Principle: Every line of code, every decision, every workflow must be explainable to your team.

Why It Matters:

Most automation vendors optimise for vendor lock-in. Obscure code keeps you dependent. Complex architectures require their consultants. Proprietary frameworks mean you can't modify anything without calling them back.

We optimise for operational independence.

In Practice:

  • Line-by-line documentation — Every script includes inline comments explaining why decisions were made, not just what the code does
  • Human-readable logs — When automation runs, logs explain what's happening in plain English
  • Runbooks and walkthroughs — Step-by-step guides so your team can understand, modify, and extend the code
  • No proprietary frameworks — We use standard Python libraries (Netmiko, Nornir, PyATS) that your team can learn and use independently

The Test:

If we disappeared tomorrow, could your team maintain and modify the automation? If the answer is "no," we've failed.

2. Measurability Over Assumptions

The Principle: Every automation decision must be backed by data, and every outcome must be measurable.

Why It Matters:

Most automation projects start with assumptions:

  • "This task feels painful, let's automate it"
  • "The team thinks this will save time"
  • "We assume this is high-impact"

Assumptions lead to wasted effort. You automate the wrong things. You can't prove ROI. Leadership questions the investment.

In Practice:

  • Time-motion studies — We measure actual time spent on tasks before automating
  • ROI calculations — Every automation opportunity gets a payback period estimate
  • Success metrics defined upfront — Before implementation, we agree on what "success" looks like (time saved, errors eliminated, tickets reduced)
  • Post-implementation tracking — We measure actual results and compare to projections

The Test:

Can you walk into an executive meeting and prove the automation delivered value? If the answer is "no," we've failed.

3. Ownership Over Dependency

The Principle: Your team owns the automation. We're here to build capability, not create dependency.

Why It Matters:

Vendor lock-in is profitable for consultants. Build mysterious code, make yourself indispensable, charge £1,500/day every time something needs changing.

We believe the opposite: the best consulting engagement is one where you don't need us anymore.

In Practice:

  • Knowledge transfer from day one — Your engineers shadow development, ask questions, and learn as we build
  • Training embedded in delivery — We don't just hand over code; we ensure your team understands it
  • Documentation for independence — Every deliverable includes runbooks so your team can modify, troubleshoot, and extend
  • Open-source tools only — No proprietary platforms. Everything we build uses tools your team can learn and continue using

The Test:

Six months after we leave, can your team modify the automation without calling us? If the answer is "no," we've failed.

4. Safety Over Speed

The Principle: Automation that breaks production is worse than no automation at all.

Why It Matters:

Network automation touches critical infrastructure. One bad script can take down your entire network.

Most vendors optimise for speed to delivery. "Ship code fast, iterate later."

We optimise for production safety. Speed matters, but not at the expense of reliability.

In Practice:

  • Pre-flight validation — Scripts check requirements before making changes (device reachability, config backups, version compatibility)
  • Dry-run modes — Test runs show what would happen without actually making changes
  • Rollback mechanisms — Every change includes a rollback plan (config backups, previous state snapshots)
  • Post-change validation — Scripts verify that changes worked as intended (using PyATS, show commands, reachability checks)
  • Graduated rollout — Test in lab → pilot on non-critical devices → phased production rollout

The Test:

If the automation fails, can your team recover quickly without an outage? If the answer is "no," we've failed.

5. Empowerment Over "Magic Buttons"

The Principle: Automation should empower your team with understanding, not create "magic buttons" nobody comprehends.

Why It Matters:

It's tempting to build fully automated, one-click solutions: "Just press this button and everything happens."

The problem: when it breaks, nobody knows why.

We build automation that your team understands and controls.

In Practice:

  • Verbose outputs — Automation explains what it's doing as it runs
  • Approval gates — For high-risk changes, scripts pause for human confirmation before proceeding
  • Evidence collection — Automation generates reports showing before/after states, validation results, and audit trails
  • Teachable moments — Every automation includes documentation explaining the underlying network concepts (not just the code)

The Test:

Can a junior engineer explain what the automation does and why? If the answer is "no," we've failed.

How Philosophy Drives the Framework

The PRIME Framework is our philosophy in action:

Framework Stage Philosophy in Practice
Pinpoint Measurability — Data-driven ROI analysis, not gut-feel prioritisation
Re-Engineer Safety — Fix workflows before automating; design rollback from the start
Implement Transparency — Line-by-line documentation, human-readable logs
Measure Measurability — Track actual results vs. projections, prove ROI
Empower Ownership & Empowerment — Knowledge transfer, training, team capability-building

The Philosophy in Real-World Scenarios

Scenario 1: The "Black Box" Script

Vendor A: Delivers a 400-line Python script with no comments. It works. When you ask how to modify it, they say "That'll be £3,000 for a change order."

PRIME Philosophy: Every script includes inline documentation. Your network engineer can read it, understand it, and modify it independently.

Result: You own the automation. No dependency.

Scenario 2: The Unproven ROI

Vendor A: "We automated VLAN provisioning. It's faster now."
Your CFO: "How much time did we save? What's the payback period?"
Vendor A: "Um… we don't track that."

PRIME Philosophy: Before automation, we measure time spent. After automation, we measure time saved. You get a report: "280 hours saved annually, £16,800 ROI, 3-month payback."

Result: Leadership sees value. Funding continues.

Scenario 3: The Production Outage

Vendor A: "Our automation will deploy configurations to 200 switches overnight."
You: "What if something goes wrong?"
Vendor A: "It won't. Trust us."
[Next day: 50 switches unreachable because the script didn't validate connectivity first.]

PRIME Philosophy: Pre-flight validation checks reachability, takes config backups, validates compatibility. Dry-run mode tests on 5 devices first. Rollback scripts are ready before production deployment.

Result: Safe, phased rollout. No outages.

Who This Philosophy Serves

Do I Need Python Knowledge?

Short answer: Not necessarily.

The PRIME Philosophy and Framework work for organisations at different technical maturity levels:

If your team doesn't know Python:

  • ✅ You still benefit from all five PRIME stages
  • ✅ Philosophy principles (transparency, measurability, ownership, safety, empowerment) apply regardless of technical skill
  • ✅ Ownership means operational ownership—you own the outcomes and can use the automation effectively
  • ✅ Empowerment focuses on understanding what the automation does (not necessarily writing new code)
  • ✅ We deliver comprehensive documentation so your team can operate the automation confidently

If your team knows Python:

  • ✅ Full framework value—you gain code-level ownership
  • ✅ Empowerment includes training to modify and extend automation independently
  • ✅ Higher long-term ROI as your team builds new automations without external help
  • ✅ Faster ramp-up during knowledge transfer

The Philosophy doesn't require Python expertise—it requires a commitment to transparent processes, measurable outcomes, and continuous improvement.

See Services: Engagement Tracks for tailored approaches based on your team's skill level.

Why We're Transparent About This

Most consultants hide their philosophy. They sell process, not principles.

We're transparent because you deserve to know how we think.

If you don't align with these principles—if you want fast code over safe code, if you prefer vendor dependency over team ownership—then we're not the right fit.

But if you believe automation should be transparent, measurable, owned by your team, safe, and empowering—then the PRIME Framework will make sense immediately.

The Bottom Line

Our philosophy:

Automation should be transparent (no black boxes), measurable (prove ROI), owned by your team (no lock-in), safe (production-grade), and empowering (your team understands it).

If we violate these principles, we've failed—even if the code works.

That's the PRIME Philosophy.