When You Can’t Script Every Move, You Need a Compass

In the last four weeks, we’ve built the ITSM foundation:

  • We defended why ITSM still matters in a tech-first world
  • Explored the Service Value System as a value-alignment engine
  • Debunked governance myths and reframed them as enablers
  • And just last week, we mapped the Service Value Chain, your go-to framework for turning intent into outcomes without the handoffs turning into chaos.

But even with that structure in place, there’s one unavoidable truth:

You can’t create a playbook for every situation.

Sometimes you need to make a call right now, with half the information and zero precedent.

This week is about those moments.

We’re diving into ITIL’s Guiding Principles, the low-key MVPs of ITSM 4. These aren’t rules. They’re the decision filters that help teams:

  • Stay aligned without micromanagement
  • Move fast without creating chaos
  • Deliver consistent value, even in ambiguity

Whether you’re a developer, project manager, service desk lead, or exec. If you’ve ever stared at a decision and thought, “What now?”, this week’s post is for you.

Why Teams Struggle with Decision-Making

Walk into any standup, sprint review, or incident bridge, and you’ll start to see it:

  • Teams aren’t struggling because they lack tools, frameworks, or talent.
  • They’re struggling because they’re stuck in decision limbo.

Lack of Alignment = Delays, Debates, and Shadow Processes

One of the most common symptoms I see? Endless back-and-forth over who gets to decide what.

Product says yes. Ops says no. Security says, “We weren’t consulted.” Support is already getting tickets.

Because no one agreed on priorities, value, or ownership, and now every task feels like a negotiation. That leads to:

  • Teams/Slack threads that look like group therapy
  • Escalation emails written with passive-aggressive poetry
  • Teams quietly bypassing governance just to get something out the door

When alignment dies, velocity goes with it… and shadow processes take over.

Too Many Frameworks, Too Little Clarity

DevOps. SAFe. Agile. ITIL. SRE. Internal playbooks. External tools.

Each team is operating within its own framework… and that’s part of the problem.

  • One team prioritizes “customer value”
  • Another anchors everything to “risk reduction”
  • A third thinks “delivery velocity” is the only metric that matters

Everyone’s playing a different game, but they’re all on the same field. And no one’s agreed on the rules.

The result? Paralysis. Friction. Conflicting metrics. Death by alignment meetings.

Fear of Getting It Wrong → Escalation or Stagnation

Here’s the dirty little secret most teams won’t say out loud: They could make the decision… but no one wants to be wrong.

  • “Let’s run it by legal.”
  • “Let’s wait until the product owner’s back.”
  • “Let’s put it on the parking lot for the next steering committee.”

Suddenly, everything is a “leadership call.” Not because it has to be, but because no one feels safe making the wrong one.

Fear-based cultures don’t ask for clarity. They ask for cover.

Frontline Teams Aren’t Empowered to Move

Even in “Agile” orgs, we see it all the time:

  • Devs aren’t sure if they can deploy
  • Service desk teams don’t feel authorized to suggest fixes
  • QA hesitates to stop a release even when something feels off
  • A junior PM wants to streamline a process but doesn’t know if they’re “allowed”

The intent to empower is there… However, without consistent decision-making filters, autonomy becomes just another buzzword.

The Bottom Line

Decision friction isn’t just a leadership issue. It’s an operational tax, paid in time, but also in trust and missed opportunities.

When teams don’t share a common way to evaluate decisions, every new initiative becomes a potential source of contention.

That’s why Guiding Principles matter. They provide everyone, from developers to directors, with the same mental checklist for making confident, aligned decisions.

And when that happens? Team drama drops, delivery sharpens, and meetings get a lot shorter.

What Are the ITIL Guiding Principles?

The ITIL Guiding Principles are seven core ideas that help teams make decisions, not by following a strict rulebook, but by applying practical, value-driven thinking in real-world situations.

These principles aren’t prescriptive. They’re not steps, phases, or frameworks.

Think of them as decision filters. A simple, shared lenses that teams can use to evaluate trade-offs, stay aligned, and move faster with confidence.

Here’s a quick look at all seven:

1. Focus on Value

Always ask: Who is this for? and How does this help them?

Everything we do should deliver meaningful results, not just activity.

2. Start Where You Are

Don’t reinvent the wheel. Assess what’s already working and build from there.

3. Progress Iteratively with Feedback

Break big efforts into smaller steps. Learn as you go. Adjust based on what you discover.

4. Collaborate and Promote Visibility

Work together early and often. Keep stakeholders informed and avoid surprises.

5. Think and Work Holistically

Every change has ripple effects. See the bigger picture, systems, teams, and outcomes before acting.

6. Keep It Simple and Practical

If it doesn’t add value, strip it away. Complexity is the enemy of momentum.

7. Optimize and Automate

Improve what works, then automate it to scale. Don’t automate broken processes… fix first.

These principles are powerful because they scale. From the frontlines to the C-suite, across Agile, DevOps, ITSM, and beyond, they provide a consistent foundation for making informed, contextual decisions without micromanagement.

In the next section, we’ll break down how to use them in real scenarios — from product planning to release management to daily team prioritization.

Using Guiding Principles as Decision Filters

In tech, you won’t always get perfect information. You won’t always have a runbook. And some days, you’ll feel like you’re picking between five bad options and one expensive one.

That’s where the Guiding Principles earn their keep.

They’re not rules. They’re not sacred texts. They’re tools, designed to help you cut through the noise and make decisions with context, confidence, and clarity.

1. Prioritizing Backlog Work

Your board is full. Everyone wants everything yesterday. Sound familiar?

🧭 Use:

  • Focus on Value: What actually matters to the business or customer?
  • Progress Iteratively with Feedback: Can we break this into smaller, testable chunks?

Pro tip: If the item’s been sitting untouched for three sprints… it’s either not valuable or too big to bite.

2. Making Architecture or Tooling Tradeoffs

Buy vs. build. Simplicity vs. flexibility. Cloud-native vs. what already runs.

🧭 Use:

  • Start Where You Are: What do we already have that works?
  • Think and Work Holistically: What else does this decision impact — teams, processes, support, budgets?
  • Optimize and Automate: Can we streamline or scale this later?

I’ve seen teams re-platform for “future state” without checking if anyone could support the present one. Don’t do that.

3. Deciding When to Automate vs. Optimize

Automation is seductive. So is premature optimization. But if you automate a broken process, you just get faster bad results.

🧭 Use:

  • Optimize and Automate: Always improve first, automate second.
  • Keep It Simple and Practical: If a shell script does the job… do we really need a Kubernetes operator?

Ask yourself: is the complexity justified, or just cool?

4. Running Cross-Functional Planning Meetings

You’ve got product, dev, QA, infra, and support all at one table. Chaos potential: high.

🧭 Use:

  • Collaborate and Promote Visibility: Everyone brings context — use it.
  • Think and Work Holistically: What’s going to ripple out? Who’s on the receiving end of this change?

Great planning isn’t about everyone agreeing. It’s about everyone being heard and aligned.

5. Responding to Incidents

Something broke. Tensions are high. Decisions need to be made now.

🧭 Use:

  • Start Where You Are: What do we know right now?
  • Keep It Simple and Practical: Don’t overcomplicate your response.
  • Progress Iteratively with Feedback: Restore service fast, then improve in layers.

If your incident call includes a 10-slide deck, you’re doing postmortem work during the incident. Stop that.

A Few Everyday Scenarios

🛠️ “Should we add this new feature?” → Focus on Value, Start Where You Are, Progress Iteratively

🛎️ “Support wants a new escalation path.” → Collaborate and Promote Visibility, Keep It Simple

🧪 “We’re thinking about rewriting the platform in Rust.” → Focus on Value, Think Holistically, Optimize and Automate (then… breathe)

Bottom Line from the Field

I’ve worked in enough orgs to know: when teams don’t share a decision filter, every meeting becomes a debate. And eventually? A stall.

The Guiding Principles give you a way to keep moving, not recklessly, but intentionally. They create alignment without a thousand-page policy binder.

Use them often enough, and you won’t need to look them up. They become instinct, just like good engineering should.

Practical Takeaways

✅ Use principles as part of every decision, not just retros. Bring them into planning, incidents, design sessions… anywhere a decision is made.

✅ Start small by applying one principle at a time. Don’t try to “use all seven” every time. Start with what fits. One well-applied principle beats a checklist that no one follows.

✅ Build the language into your culture. Ask questions like, “Are we focusing on value?” or “Can we simplify this?” It reinforces shared thinking without formal training sessions.

✅ Let principles guide, not gate. This isn’t red tape. It’s your team’s decision-making north star. Use it to move faster with fewer regrets.

Actionable Questions

  • When was the last time our team made a decision that felt aligned, fast, and confident? What helped?
  • Are there patterns where we over-engineer or over-escalate? Which principle might help?
  • Which of the seven principles resonates most with how we want to work?
  • Do new hires or cross-functional teams understand how we evaluate decisions, or are they guessing?

When decision-making becomes intentional and repeatable, velocity isn’t just faster, it’s smarter.

Coming Up Next: Rethinking the Modern Service Desk

Next week, we’re heading back to the front lines and taking a hard look at how the service desk is evolving from ticket triage to a strategic experience hub.

We’ll break down:

  • Why experience matters more than resolution time
  • How self-service, automation, and knowledge-centered support are changing the game
  • And why the best service desks don’t just fix things… they fuel loyalty

If your help desk still feels like a necessary evil, next week’s issue might just change your mind.

Final Thought

In the fast-moving chaos of modern IT, decisions are constant, and the margin for error is tight.

You won’t always have time for a meeting. You won’t always have perfect data. But you can always have a compass.

The ITIL Guiding Principles aren’t there to slow you down; they’re there to help you cut through noise, avoid overthinking, and make smarter, more aligned choices that stick.

Because when your whole team makes decisions from the same foundation, you don’t just move faster… you move together.

And let’s be honest: that’s where the real wins live.