Operations for strategy

This is a work-in-progress draft!

Even the very best policies fail if they aren’t adopted by the teams they’re intended to serve. In my experience, it’s common for a thoughtful strategy to be ruined by a terrible rollout strategy. Can we persistently change our company’s behaviors with a one-time announcement? No, probably not.

The good news is that effectively operating a policy doesn’t have to be magic. There are common patterns that take time and attention, but I’ve seen them work consistently, and they’ll work for you as well.

This chapter will dig into those mechanisms, with particular focus on:

• …
• …
• …

Let’s drill into the details.

What are operations?

Include 2-3 stories of driving strategy with very different emphasis on how it worked. This might be Calm strategy vs Uber services strategy. Point is emphasizing how different operational mechanisms might be.

How to add operations

TODO: write

Operational mechanisms

TODO: Gotta rework, but I think start by listing the three categories, then give list of examples in each category with context/explanation?

• “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.

TODO: write

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

Technical, training, role modeling, and process solutions Meetings — described in strategy testing Charts — a number that moves with policy adoption Nudges Role modeling Training — people can’t adopt things they don’t know about, but generally visibility more than courses.. courses work for a few but not all, this relates back to informational herd immunity in is strategy useful?

• mechanical/technical vs process vs cultural enforcement
• model document share vs drop-down
• single-threaded communication forum, e.g. email thread or chat channel
• recurring meetings
• escalation forums
• durable educational resources

Navigators Architecture committees

Less effective methods

In addition to the operational methods discussed above, there are a number of additional mechanisms that are frequently used, but which I have found generally ineffective.

1. Top-down pronouncements: Sometimes a policy will be operationalized by simply declaring it must be followed.
   It’ common to see a leader declare that a policy is now in effect, assuming that the announcement is a useful way to operate the new policy.

   For example, some “return to office” policies dictate that the team must work from their office, but driving a real change requires informing individuals who aren’t attending

2. Education-as-announcements rollouts: The default way that policies are rolled out is through one-time “education,”, often as an all-company announcement for existing employees, followed by updating training for onboarding new-hires. Education sounds great, because it’s easy to believe that these two trainings will change organizational behavior, but that rarely works.

   Changing behavior requires ongoing reminders, visible role models, inspection to understand why some teams are not adopting the behavior, and so on. Education is a good component of operationalizing a policy, but it’s just a small part, and cannot stand on its own.

3. Mandatory recurring trainings: These are a staple of compliance driven policies, generally because of laws which require providing a certain number of hours of relevant training each year.

   There’s are two deep challenges with mandatory trainings. First, because they are required, people tend to make little effort to make the content good. Second, many folks don’t pay attention because they expect the content to be low quality. It’s not uncommon to hear people say that they’ve never heard of a policy that they’ve performed annual training on for multiple years.

   It’s possible to overcome these barriers, but in a situation where you’re accountable for changing outcomes, as opposed to shifting legal obligations away from the company, these tend to work poorly.

4. Change the culture. How?!

5. ?

If you’re using one of these approaches, the takeaway isn’t that isn’t necessarily a bad choice. Instead, you should just make sure you can explain why you’re using it, and then you need to also make sure you believe that explanation. If you don’t, look for a mechanism from the earlier

What if you’re not an executive?

TODO

To do that:

Align up frequently, and take time to debug their feedback Be trustworthily curious: folks know you’ll listen hard to understand their point Be pragmatic rather than dogmatic Have a track record of Doing The Work to build buy-in Frame it as a low-risk experiment, “We’ll try for 3 months then reevaluate” Let CTO decide how to break ties If you’re reading this and your biggest thought is, “My CTO will never let me do this”, then 7 out of 10 times, I promise you that either you’re not writing the strategy that the CTO wants. The other 3 out of 10 times, there’s some internal conflict that the CTO just isn’t willing or able to resolve, which is a bit trickier, but you can approach via the next strategy.

Bottom-up The approach to bottoms-up rollout is described in Write five, then synthesize:

Write 5 design docs Synthesize those design docs into a “narrow strategy” Do the above five times, until you have 5 “narrow strategies” Synthesize those five into a “broad strategy” You just wrote a really good engineering strategy This approach definitely takes a long time, but I’ve seen it work a number of times. Even if your current strategy has some gaps in it, birthing it into an explicit strategy document will always make it much easier to address those gaps.

How to pick appropriate methods

• centralize enforcement rather than spread it widely
• set a cap for centralized cost or it’s going to fail
• educate, discipline or exempt the outliers rather than making operation worse for everyone

Beware cargo-culting

The longer that I am in the industry, but more I am surprised by how few strategists seem to care if their approach actually works. Instead, they seem focused on doing something that might work, offloading accountability to either the organization or some team, and then moving off to the next problem.

Perhaps this is driven by an unfortunate reality that leaders are often evaluated by how they appear, rather than by what they accomplish. Whether or not that’s the underlying reason for why it happens, it does make it surprisingly difficult to know which patterns to borrow from strategy rollouts and implementations.

The best advice, unfortunately, is to remain skeptically optimistic. Collect ideas widely, but force the ideas to prove their merit.

Summary

Now that you’ve finished this chapter, you’re significantly more qualified to write a complete, useful strategy than I was a decade into my career. Often skipped, the operations behind your strategy are at least as essential as any other step, and any strategy without them will fade quietly into your organization’s history.

In addition to being able to rollout a strategy of your own, this chapter also provides a useful rescue toolkit you can use to put an existing, floundering strategy back on track. If you don’t see an opportunity to write new strategy within your organization, then there’s still probably room to flex your operational skill.