In Will Laron’s book “Crafting Engineering Strategy” he covers different types of policies. As a quick reference, I’ve put them below:
Strategic policies: Define why the organization makes certain choices by aligning engineering behavior with business strategy.
Structural policies: Define who owns decisions and work by shaping teams, roles, and responsibilities.
Normative policies: Define how we are expected to behave by setting shared norms, standards, and expectations.
Procedural policies: Define how work gets done by specifying repeatable processes and workflows.
Why policies?
Policies help support the following organisational problems:
- How do we organize to build anything effectively?
- What constraints guide technical and organizational decisions?
- What must remain true regardless of which product bets we make?
- How do we scale execution without breaking ourselves?
How policies fit in strategy documents
A clean mental model for thinking about how policies fit into strategy documents
- Policies constrain
- Bets explore
- Plans execute
- Reviews learn
A simple rule to use for policies is policies govern how we place bets
When not to use policy language
Do not use policy language when:
- you are stating a hypothesis
- you are committing to a delivery outcome
- you are exploring unknowns
- you expect to change direction based on learning
That’s where experiment charters, investment memos, discovery docs, product strategy are better constructs.
Policy Writing: Do’s and Don’ts
DOs — What good policies do
- State what must remain true
- Policies define constraints, not intentions.
- Example: “All production systems must have a clearly accountable owner.”
- Be durable over time
- Policies should survive people, tool, and org changes.
- Avoid time-bound or phase-specific language unless intentional.
- Be implementation-agnostic
- Say what must be true, not how to make it true.
- Leave tools, processes, and steps to operations or handbooks.
- Constrain decisions, not behavior minutiae
- Policies remove ambiguity at decision time. j
- They clarify what is allowed, required, or disallowed.
- Encode tradeoffs intentionally
- Strong policies choose what you will not optimize for.
- This prevents constant renegotiation.
- Be explicit about authority when needed
- Decision rights and approvals belong in policy when they matter.
DON’Ts — Common policy smells
- Don’t put activities in policies
- Activities change; policies should not.
- Example to avoid: “Run a weekly SEO review.”
- Don’t include deadlines or milestones
- Dates belong in plans, roadmaps, or OKRs.
- Policies should still make sense after the date passes.
- Don’t encode personal judgment or motivation
- Avoid feelings, confidence thresholds, or goodwill.
- Policies should be objective and enforceable.
- Don’t solve today’s problem too narrowly
- Policies should address classes of problems, not one-off events.
- Don’t make policies aspirational
- “We strive to…” is not enforceable.
- Policies should describe what actually must happen.
- Don’t overload a single policy
- If a policy serves multiple distinct purposes, split it.
- Long chains of “and then” are a smell.
Quick policy checklist
- Will this still make sense in two years?
- Does it constrain decisions?
- Can teams comply in multiple ways?
- Does it avoid execution detail?
- Is it enforceable?
