When Being Busy Feels Like Progress
Here’s an uncomfortable truth: it’s incredibly easy to fail with the wrong goals. Worse, sometimes you think you’re succeeding — the sprint board is full, PRs are merging, dashboards are green — but you’re not actually adding any value. You’ve been busy, not effective.
I’ve watched a lot of teams over the years, and one pattern stands out. Ask an engineer on a high-performing team why they’re working on something, and they answer instantly and clearly. Ask the same on a struggling team, and you get the what (“I’m building this service”) or the how (“I’m migrating it to Kubernetes”) — but not the why it matters to the business. That missing why is almost always the difference.
The good news is that this should be simple. Every piece of work should be crystal clear about what it’s for. And there’s a great mechanism that forces exactly that clarity: OKRs.
What Is an OKR, Really?
OKR stands for Objectives and Key Results, and it’s simpler than the corporate slide decks make it look. At its core it answers three questions in order:
WHY I’m doing that → WHAT tells me I’m getting there → HOW I’ll actually do it.
- Objective — the goal that inspires and sets direction. Where do I need to go?
- Key Results — the measurable steps that tell you whether you’re making progress. How do I know I’m getting there?
- Initiatives — the concrete tasks and projects you execute. What will I do to get there?
OKR framework: Objectives are goals that inspire and set direction, Key Results measure progress toward an objective, and Initiatives are the tasks required to drive progress
The framework was created by Andy Grove at Intel and later brought to Google by John Doerr, where it became famous. Today most serious companies use OKRs — or at least the basics: define a goal, then plan the work backward from it. Used well, OKRs bridge the gap between high-level company strategy and your daily tasks.
Why You Must Start with the WHY
Starting with the why isn’t a motivational cliché — it’s where the real value comes from. The why is what generates the need. It’s the end goal, and the end goal is never the technology. It’s the business value your leadership expected when they hired you.
If this idea resonates, read Simon Sinek’s Start With Why — it’s genuinely excellent, and it reshapes how you think about your work. Sinek’s core model is the Golden Circle: three concentric rings — Why at the center, How around it, and What on the outside. Most people and teams communicate from the outside in: they lead with what they do (“I run the Kubernetes platform”), sometimes how they do it, and rarely touch why. The people and organizations that inspire and endure do the opposite — they start from the Why, the purpose, and let it drive the How and the What. Notice how neatly that maps onto OKRs: the Objective is your Why, the Key Results and Initiatives are the How and the What that flow from it. Get the Why right and the rest lines up.
This matters especially for senior, staff, and principal engineers. Your job is not only “keeping the house running.” That’s table stakes. The expectation is that your work generates value. And yes — this absolutely applies to operations work too. Improving automation, building a new self-service tool, reducing risk: those are legitimate goals when tied to an outcome. Without that thread, you can pour months into a dozen worthy-looking tasks that, added together, still don’t move anything that matters.
There are two ways to show up at work. You can be reactive — waiting for tickets and orders. Or you can be proactive and propositional: someone who brings solutions, suggestions, and constructive ideas to the table. A propositional leader proposes initiatives that measurably improve a process, and builds a culture around outcomes rather than activity. That’s the posture OKRs reward.
Does the Goal Create the Work, or Does the Work Create the Goal?
This is the trap I see most often. Engineers fall in love with a technology or a pet project, ship it, and then invent a goal to justify it. That’s backward.
You should work backward from the goal. Start from the objective, define what would genuinely be valuable, and only then decide what to build. It takes some humility, because working backward sometimes reveals that the thing you’ve been treating as your personal project at the company is irrelevant to the business — and may never scale beyond your own laptop. Better to learn that from the OKR than from a reorg.
And from an SRE perspective, this is gold. Key Results are, essentially, SLOs and other measurable indicators. “Reduce checkout p99 latency from 800ms to 300ms,” “cut toil hours per on-call rotation by 40%,” “bring the service to 99.9% availability and stay within error budget” — those are Key Results a business leader can understand and an engineer can instrument. OKRs give your reliability work a scoreboard that ties directly to outcomes, so automation, monitoring, and release engineering stop being “engineering hobbies” and become visible business wins.
A Concrete Example
Theory is easy to nod at, so here’s what this looks like in practice. Say the Objective is Improve Customer Satisfaction — a pure business why, no technology in sight. From there you define the Key Results that prove you’re getting there: increase the satisfaction score to 90%, achieve 99.9% application uptime, and reduce MTTR (mean time to repair). Only then do you decide on Initiatives — the actual engineering work: implement functional tests, improve the deployment strategy, migrate the database to a managed service. And each initiative breaks down into concrete tasks (adopt IaC, switch to a safer deploy tool, and so on). Notice how every task at the far right can be traced all the way back to a customer outcome on the left.
OKR example tree with four columns — Objective, Key Results, Initiatives, Sub-Initiatives. The objective “Improve Customer Satisfaction” branches into key results (satisfaction score 90%, 99.9% uptime, reduce MTTR by 30%), which branch into initiatives (functional tests, improve deployment strategy, migrate database to a managed service), and the deployment initiative breaks down into sub-initiatives like create/use IaC and use CodeDeploy
Your Next Steps
Don’t just nod along — go do this:
- Find the OKRs of your company and your team. If you can’t name them, that’s your first finding.
- List all your current activities. Everything you’re actually spending time on.
- Check alignment. Is each activity tied to an Objective and its Key Results? Kill or reshape the ones that aren’t.
- Position yourself as a strategic leader in meetings — always speak with a business lens, not just a technical one.
And here’s a challenge worth taking on 🚀:
- Define one initiative straight from the KRs. Have at least two strategic conversations with someone on the business side. Uncover the real pains of the personas involved. Plan the initiative, present it, get the buy-in — and then execute.
That single exercise will teach you more about impact than a quarter of heads-down coding.
The Takeaway
It’s easy to be busy and still add nothing. OKRs are the antidote: they force you to say the why out loud, measure whether you’re actually getting there, and only then decide how. Treat Key Results like SLOs, work backward from the goal, and your engineering — reliability work included — becomes something leadership can see and value.
Stop asking only “what should I build?” Start asking “what are we actually trying to achieve, and how will we know we got there?”
Want to go deeper on turning reliability work into measurable business outcomes? That’s exactly what the trainings at mugnos-it.com are built for.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
