This article on Guiding Policy is the second in a multipart series, "What’s Your Strategy?" - A Guide to Developing an Engineering Strategy. In case you missed it, Part 1 is about building a Diagnosis.
From Diagnosis to Direction
You’ve completed your diagnosis—digging into your engineering organization to uncover bottlenecks, risks, and opportunities. The urge to act is strong: assign tasks, launch projects, and start fixing things. But hold on. Jumping in without a plan is like throwing darts blindfolded—you might hit something, but it’s unlikely to be the bullseye.
Enter the guiding policy: the critical link between diagnosis and execution. It’s not a checklist or a slogan, but a set of principles that steer your team toward solutions without micromanaging their every step. Done right, it transforms your insights into a focused, practical approach tailored to the complexities of software engineering.
Richard Rumelt, in *Good Strategy/Bad Strategy*, defines it succinctly: a guiding policy is “an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.” It’s your stance on *how* to tackle the challenges ahead.
To illustrate, let’s consider a hypothetical engineering department. This team excels at shipping features fast, but unreliable systems and legacy code are slowing them down. We’ll use this example to explore how to craft guiding policies that address these issues effectively.
The Crux: Finding the Heart of the Challenge
The design phase isn’t about slapping policies on the most obvious problems. It’s about digging deeper to uncover how your challenges connect and pinpointing the core issue—the “crux.” In The Crux*, Rumelt describes this as the toughest, most pivotal part of your problem set, one that’s both critical and feasible to address. Finding it takes domain expertise and strategic thinking.
As Rumelt puts it: “You don’t ‘pick’ a strategy; you create it. Then you do your very best to choose among the alternatives you have created.” This means analyzing your challenges, brainstorming responses, and grounding them in reality—your resources, culture, and tools.
Take our hypothetical engineering department. Their diagnosis reveals:
Frequent outages stem from unmonitored legacy systems.
Technical debt in our core app slows feature development.
AI-generated code harms readability and optimization.
These could be treated as isolated issues, but a closer look reveals a shared root:
“Our systems are harder to maintain, slower to improve, and more prone to failure because we’re not intentionally managing their evolution.”
This crux, the lack of deliberate control over system growth, ties the problems together. Focusing here ensures our policy targets the cause, not just the symptoms.
Now you need options to tackle the crux. Brainstorm different approaches:
Could you overhaul legacy systems entirely? Too expensive, perhaps.
Could you isolate them and prioritize new development? More doable.
Consider your constraints—budget, team skills, tooling—and weigh each option for feasibility and impact. A policy to rewrite everything might sound bold, but if funding’s tight, it’s a fantasy. Choose an approach that’s ambitious yet achievable, setting the stage for a guiding policy that holds up in practice.
Crafting the Guiding Policy
With the crux in focus and alternatives at hand, it’s time to craft your guiding policy. Will Larson identifies four main policy types typically found in engineering strategies:
Approvals: Define processes for recurring decisions, like mandating architecture reviews for major changes.
Allocations: Assign resources to priorities, such as reserving time for system upkeep, reflecting your beliefs about productivity.
Direction: Offer explicit instructions for clear, consistent decisions—like standardizing a deployment process.
Guidance: Provide recommendations for nuanced choices, allowing flexibility in execution.
Most strategies mix these to balance clarity and adaptability. For our hypothetical engineering department, a high-level direction might be:
To stay competitive, we’ll maintain high development velocity while ensuring systems remain reliable and adaptable. Our approach prioritizes resilience, controlled technical evolution, and scaling velocity without letting short-term wins create long-term friction.
This sets the tone, but teams need more to act. Supporting policies can flesh it out:
Direction: “Set domain boundaries around legacy systems with a defined contract to limit their impact and guide their evolution.”
Guidance: “Follow the scout rule—leave code better than you found it, ensuring the domain is clear before adding features.”
Approvals: “Every code review must align with our Definition of Done, including debt and health checks. Exceptions must be approved by the Engineering Manager”
Allocations: “Launch a Reliability Working Group to track code health and technical debt, with each team contributing a Senior Engineer.”
These policies work together—direction controls legacy sprawl, guidance fosters incremental improvement, approvals enforce standards, and allocations provide resources. They’re high-level, leaving details to supporting documents like the Definition of Done, but clear enough to guide decisions. The mix depends on your context—just ensure they’re cohesive and avoid contradictions.
Guidelines for a Good Guiding Policy
A strong guiding policy isn’t a shot in the dark. It follows principles that make it effective and enforceable. Rumelt emphasizes focus and power—leveraging your unique strengths, not copying others. Here’s what to aim for:
Coherent & Focused: Target the crux to align teams, avoiding conflicting priorities in architecture or operations.
Feasible & Actionable: Root it in real limits—technology, budget, people—and clarify what to prioritize or sacrifice.
Adaptable, Yet Resolute: Allow tactical flexibility while anchoring to core ideas, steering clear of rigid rules or short-term fixes.
Leverages Engineering Strengths: Tap your team’s skills, tools, and context—don’t chase someone else’s playbook.
Creates Cascading Alignment: Enable engineers at all levels to make policy-aligned decisions without constant oversight.
Explicit About Trade-Offs: State what matters most—speed, reliability, cost. For example, choosing reliability might mean slower releases for better testing.
Turning Insight into Action
By pinpointing the crux, crafting a clear guiding policy, and ensuring it’s practical and cohesive, you transform your diagnosis into a strategy that works. It’s about giving your team direction to navigate challenges confidently. In our upcoming article, we’ll focus on Coherent Actions, and how these can make our policies actionable. See you!
*With special thanks to Paco Mendes for introducing me to the book!