When Following the Process Means Missing the Goal: Why Engineering Leaders Need Context Over Checklists
TL;DR: In 4 minutes, you'll learn how to stop treating company processes as the goal and start giving your team the context they need to deliver business value when plans inevitably fall apart.
The Problem with Process-First Leadership
Reed Hastings, Netflix's co-founder, built one of the most successful tech companies by doing something counterintuitive: removing controls and leading with context instead of process. His philosophy was simple. If you give employees context about goals and constraints, they make better decisions than if you force them through rigid procedures.
Most engineering and systems leaders do the opposite.
They build teams around procedures. Documentation requirements. Approval chains. Sign-off processes. These become "the rules of working with my team." And when things go sideways (which they always do), those same leaders try to force the anomaly back into the existing process.
I learned this the hard way during a game launch that nearly failed because we followed the rules.
When the Checklist Became More Important Than the Contract
We were launching games into a new market. Contractual deadline. Non-negotiable. But our company's standard testing, release, and compliance processes would make us miss it by weeks.
One individual contributor kept pushing back. "We can't skip the documentation steps. It's against policy."
Instead of arguing, I went to the senior manager above them. Not to complain. To understand. "Help me understand what you need to make this work. Here is the goal and why it matters."
Here is what I discovered: Most of the documentation existed because something happened once, years ago. We were terrified of repeating that mistake. But we had already fixed the root cause when it first happened. The checklist remained even though the problem was gone.
We condensed three approval meetings into one email thread. We kept the security review (legal boundary) but eliminated the redundant sign-offs (process theater). We launched on time.
And I learned that leadership is not about following processes—it is about making judgment calls that serve the business goal.
Why First-Level Managers Default to Procedure
According to research on leadership judgment, most managers treat processes as decision-making shortcuts. They follow the rules because following rules feels like competence. The problem is that heuristics-based judgment only works when conditions match expectations.
When conditions change, the checklist fails.
Here is what happens:
Managers assume the process protects them. If they follow every step and still miss the deadline, they can say "we did everything right." Leadership does not reward effort. Leadership rewards outcomes.
Teams escalate decisions they should make themselves. Without context, they default to asking permission for things that do not need approval. This creates bottlenecks. (I wrote about this in managing former peers, where I avoided making calls because I thought collaboration meant consensus.)
Anomalies get forced into existing procedures. A client needs something urgent. A system fails in an unexpected way. A market shifts. The team tries to fit the square peg into the round hole because "that is how we handle these situations."
This is learned helplessness. And it is costing your team velocity, innovation, and the ability to respond when the world does not cooperate.
The Bridge Between Rules and Sound Judgment
Context over process.
That is the bridge.
When your team understands the goal, the business value that needs to be delivered, and the actual constraints, they can make smart decisions without waiting for permission.
When they do not understand context, they treat the checklist as the goal. They miss deadlines because they assumed completing steps was more important than delivering value.
What Leadership Scaffolding Actually Means
Noel Tichy and Warren Bennis argue that judgment is the single most important leadership skill. But judgment does not mean "make it up as you go." It means understanding the scaffolding, the non-negotiables that actually matter.
Here is the scaffolding:
Legal and ethical boundaries. We could not skip the security review. That was a legal requirement. No amount of deadline pressure changes that.
Company policies that exist for real reasons. Not "we have always done it this way" but actual risk mitigation or strategic alignment.
Your own values and principles. The lines you will not cross, even under pressure.
Clarity on the goal and the business value. What success actually looks like, not just what tasks need completing.
Information about the environment and constraints. What your team is working within, what has changed, what matters now.
Everything else is judgment. Not a playbook. Not step-by-step instructions.
We could not skip the security review. But we could condense the approval process. The goal (protect the company from risk) stayed the same. The business value (launch on time, meet the contract) was protected. We removed the process that did not serve either.
What Most Engineering Managers Do Instead (And Why It Backfires)
Research on participative leadership and decision-making shows that managers struggle with knowing when to involve teams and when to make calls themselves. Most default to one of two extremes:
They escalate everything to leadership. Waiting for permission. Covering themselves by getting sign-off. This slows delivery and signals to your team that you do not trust your own judgment.
They muscle through with the existing process. Working harder instead of working differently. Accepting that they will miss the deadline because "we followed the rules."
Neither approach delivers the outcome leadership actually needs.
The Question That Changes How You Lead
When you face your version of this (launch deadline, urgent client need, system failure), do not ask "what is the process?"
Ask: "What is the goal, and what do I actually need to deliver it?"
Then give your team the same clarity. Not just steps to follow, but the context that lets them make smart calls when the steps do not fit.
This connects directly to what I wrote about in communication and building influence across your organization. You cannot build that influence if you are stuck waiting for permission or hiding behind procedures.
How to Lead with Context Starting Monday
Stop looking for the next checkbox to check.
Instead, answer these three questions before you pull out the process manual:
- What is the goal? Not the task list. The actual business value that needs delivering.
- What do I actually need to deliver it? Which parts of the process serve the goal, and which parts are theater?
- What context does my team need to make smart calls themselves? Legal boundaries, company policies, strategic goals, current constraints.
Then communicate that context. Not once. Repeatedly. In different ways. (I call this "7 times, 7 ways" because people need multiple exposures before information sticks.)
Your team will deliver faster. They will make better decisions. And when the unexpected happens (and it will), they will not freeze waiting for you to tell them which checkbox to check next.
They will build the bridge between following the rules and delivering the outcome leadership actually rewards.
What process are you following right now that no longer serves the actual business goal?
You're great at the work. Let's build the bridge.
Ready to lead with context instead of checklists? Let's talk about how to give your team the clarity they need to make decisions without waiting for permission every time something does not go according to plan.
Comments
Post a Comment