Operations for strategy

This is a work-in-progress draft!

Explain the general role of operations for writing strategy.

This is an exploratory, draft chapter for a book on engineering strategy that I’m brainstorming in #eng-strategy-book. As such, some of the links go to other draft chapters, both published drafts and very early, unpublished drafts.

Escalate to the CTO

See how Calm’s engineering strategy relied on CTO escalations for any new technology:

• Some felt it was “less fun”, but ultimately it got a lot more fun and we did right by our users
• We argued a lot less about tech investments
• Consolidated tooling on TypeScript monolith
• Spent out innovation chips on product enhancement
• A couple engineers left the company because they couldn’t agree to follow this policy

Notes

resources: the new oreilly book is pretty good on some of the architecture review pieces, maybe worth a mention here

• “Default escalation mechanism” – a sufficiently clear default escalation mechanism solves all operations issues

The final component of strategy is coherent actions to implement your guiding policies. If you follow my recommended approach to structuring your guiding policies, then you’ll find three major categories of actions:

Enforcements: how will engineering’s rules be maintained? Even the most thoughtful policies won’t create leverage if they aren’t followed. Enforcement actions explain the process used to maintain policies, as well as a clear, ongoing process for evaluating exceptions. Although the formality here may feel awkward, it’s much easier to be explicit.

Example: Tech Spec Review will meet weekly and review requested exceptions to our standard development stack.

Escalations: how should folks constructively argue that a guiding policy doesn’t work or doesn’t apply to their case? Ideally, there are just a few (or even just one) escalation processes shared across all guiding policies. Many people view “escalations” in a very negative light, but I’d push you to rethink that perspective. Whether you acknowledge them or not, escalations are going to happen implicitly, so it’s better to acknowledge and structure that process.

Example: if you believe our guiding policy is meaningfully wrong, escalate up the technical or managerial reporting chain.

Transitions: how do we transition between the current state and the new state? This is particularly relevant to changes in resource allocation, which might involve people or teams changing their focus. In its simplest form, this might be a few people shifting focus for a quarter, for a larger shift it might be an engineering reorganization

In cases where your guiding policies requires a transition from one technical approach to another, e.g. changing your primary data storage technology, then the action is conducting a migration.

Example: we are winding down our proposed migration to services, and instead recommitting to our monolithic service. Team structure won’t be impacted, but priorities will be. First, individual teams will stop work on service migration. Second, our developer productivity team will prioritize test and build stability as their top priority.

These actions are a bit unusual, because engineering-scope guiding policies should persist for many months or even years. Long-lasting guiding policies require fewer one-off actions, and more enduring actions to maintain the policies over time. It’s natural, and even desirable, to feel a bit anxious that your engineering strategy’s actions aren’t action-y enough. As long as they clearly connect back to your diagnosis, then you’re in good shape.