Once you become an engineering executive, an invisible timer starts ticking in the background.
Tick tick tick. At some point that timer will go off,
at which point someone will rush up to you demanding an engineering strategy.
It won’t be clear what they mean, but they will want it, really, really badly.
If we just had an engineering strategy, their eyes will implore you, things would be okay.
For a long time, those imploring eyes haunted me, because I simply didn’t know what to give them:
what is an engineering strategy?

From Magnitudes of exploration,
which described Stripe’s aspirational approach to balancing between technical standardization and exploration,
to Staff Engineer’s Writing engineering strategy
(which I rewrote four times from scratch), I kept iterating on my definition.

Operating in the executive role, I’ve finally been able to solidify my point of view on
what engineering strategy should accomplish, and how an engineering executive
can guide that strategy’s creation.
Starting where I was a few years ago–not quite knowing what engineering strategy was–we’ll
work through:

• An example engineering strategy
• Richard Rumelt’s definition of strategy: diagnosis, guiding policies, and coherent actions
• How and when to write your engineering strategy
• Dealing with undocumented strategies in other functions
• Structuring your guiding policies around your: resource allocation, fundamental rules, and how decision are made
• Maintaining the right altitude in your strategy by ensuring guiding principles are: applicable, enforced, and create leverage
• The most common kinds of coherent actions in engineering strategies
• Whether strategy should be executive-lead

While the engineering organization may contain many strategies, there is only one overarching engineering strategy.
This document–often an implicit document that no one’s ever quite written down–is your constitutional document for
running engineering, and writing it is one of the most valuable things you’ll do as an engineering executive.

This is an unedited chapter from O’Reilly’s The Engineering Executive’s Primer.

Example strategy

I’m starting with an example strategy to demonstrate the concepts we’ll work through in this piece.
If you’d prefer to end with this example, you’re encouraged to skip this section and return after reading the rest.

The major factors we want our strategy to address are
(e.g. our diagnosis of our circumstances):

• We support three business lines (consumer, business to business, and new experiments).
  80% of revenue comes from consumer, 20% from b2b, and new experiments is pre-revenue.
  We expect the majority of revenue growth this year to occur in b2b, there will be sub 15% revenue growth in consumer,
  and believe there is a small but real chance of outsized returns from new experiments in the next 3-5 years
• We are an engineering organization of 400 (300 engineers, 40 managers, and 10 technical program managers).
  We project remaining cash-flow neutral to the extent we maintain our current size
• The #1 concern in our most recent developer productivity survey
  is test flakiness. Further, our test stability dashboards show stability has decreased ~40% YoY,
  causing one in three builds to fail incorrectly
• Since growing to 400 engineers, we’re seeing a significant spike in culture survey that folks don’t
  have the necessary information to do their work. As we followed up, we heard that people are particularly
  feeling unaware of releases and decisions being made on other teams

Our guiding policies to solve for those constraints are:

• Maintain 4:1 product engineer to infrastructure engineer ratio.
  This has been our ratio for the past several years, and it’s worked fairly well,
  so we intend to maintain it.

  For our next strategy refresh, we intend to also explicitly break out security and data engineering ratios,
  with the hope of becoming more deliberate in our staffing efforts there

• Target 45% product engineering resourcing towards b2b, 35% towards consumers, and 10% towards new bets.
  The remaining 10% will be focused on a 12 month investment into developer productivity.
  Relative to last year, we’re shifting about 20% more capacity towards b2b, as we see significant revenue growth
  happening there, and haven’t seen growth rebound in consumer.
  We want to maintain an ongoing investment towards new bets, but nothing has shown enough traction yet to
  warrant spinning out into its own business line. This shift will result in some team movement.

  The 10% investment towards developer productivity won’t impact team structure, instead each team will
  have some portion of its time prioritized towards developer productivity work (described in more detail in the “actions” section)

• Stay cash-flow neutral. We will avoid any actions that make us cash-flow negative.
  Particularly we will avoid hiring that grows our current headcount.
  In cases where staying cash-flow neutral is in conflict with using vendors for commodity solutions,
  have a discussion including the head of engineering

• Use our standard technology stack and process (or escalate to tech spec review).
  We use our standard technology stack and processes (documented on our wiki) for all projects.
  Any projects that wants to introduce a new technology or deviate from our standard processes should
  be reviewed through our tech spec review process.
  This allows us to ensure we maximize the impact of our developer productivity investments,
  our security investments, facilitate easy cross-team transfers, and critically eases maintaining our compliance controls.

  I appreciate that this can feel draconian. This policy’s aim is to ensure we’re placing deliberate innovation bets,
  and completing our inflight bets before making new ones. The aim is not to avoid all new bets, and we encourage
  surfacing new ideas to tech spec review process for consideration

• If it’s unclear and seems risky, or there’s significant disagreement, quickly escalate technical issues to tech spec review, and other issues up the management chain.
  If there’s no written decision, the decision is risky or a trap-door decision, and it’s unclear who the owner is,
  then you should escalate! Technical decisions should escalate to tech spec review,
  and other decisions should escalate up the management chain.

  Escalations are often viewed as “negative” or “hostile”, but I want to really push back on that framing.
  Escalations are a natural part of working together, and allow us to quickly make decisions with the necessary context
  to make effective decisions.
  Escalations are only slow if we (in tech spec review, or in the management team) are slow, and we should fix that
  by addressing latency rather than assuming process is inherently slow!

• All technical changes announced in #tech-updates, all releases shared in #shipped.
  In an attempt to reduce surprises from technical decisions not being communicated widely,
  as well as cross-product impacting changes being shipped without visibility to other impacted teams,
  we are requiring both changes be communicated within #tech-updates and #shipped channels respectively.

  It’s possible we’ll need a heavier solution, but we want to start with something simple

While many of these guiding policies are continued from last year,
several of them do require specific one-time actions to implement:

• Org updates to shift product engineering from consumer to b2b.
  We’re shifting about 10% of product engineering capacity towards b2b engineering,
  in support of b2b’s accelerating revenue growth. This will result in several teams moving
  across organizations. There will be a small number of individuals moving as well, and generally
  we’re facilitating mobility towards b2b.

  See details in B2B Priorities update

• Test Stability working group moving forward.
  As documented in the recent Test Stability update, we’ll be devoting 10% of product engineering time this year
  towards improving test stability.
  We will also be devoting a significant amount of infrastructure engineering time there as well,
  with test stability being their third stability (behind security and overall site stability).

  Read the latest Test Stability update for more details

• Tech spec review: now also doing light-weight async reviews.
  We’re asking tech spec review to take on a larger role in reviewing technical decisions,
  but at the same time we want to acknowledge the feedback that it’s taking 1-2 weeks for
  tech spec review to provide actionable feedback on many questions coming their way.
  We’re now asking that all requests to TSR start in chat, at which point TSR will handle them
  immediately async if feasible, and only ask more complex topics to come to a weekly review session.

  We also intend to expand staffing on TSR in the next four weeks, update coming on that shortly

If you have questions on the engineering strategy, we’ll be discussing it at our next engineering Q&A on Wednesday,
and you’re also welcome to ask in #eng-ask-anything at anytime!

That ends the example engineering strategy, and now we’ll move on to breaking down the various components.

Defining strategy

Richard Rumelt’s Good Strategy, Bad Strategy
is the most approachable book on strategy that I’ve read, and I’ve learned a great deal from it.
Most importantly, it provides a concise, useful definition of what strategy is.
A strategy is composed of three parts:

1. Diagnosis: a theory describing the nature of the challenge.
   This is trying to identify the root cause(s) at play,
   for example, “high work-in-progress is preventing us from finishing any tasks, so we are increasingly behind each sprint” might be a good diagnosis
2. Guiding policies: the approaches you’ll apply to grapple with the challenge.
   Guiding policies are typically going to be implicit or explicit tradeoffs.
   For example, a guiding policy might be “only hire for most urgent team, do not spread hires across all teams.”
   If a guiding policy doesn’t imply a tradeoff, you should be suspicious of it
   (e.g. “working harder to get it done” isn’t really a guiding policy)
3. Coherent actions: a set of specific actions directed by guiding policy to address challenge.
   This is the most important part, and I think the most exciting part,
   because it clarifies that a strategy is only meaningful if it leads to aligned action

The first time I read this definition was eye-opening, because it solved two problems I’ve been thinking about for a long time.
First, how come when there is a written strategy, it’s almost always irrelevent to the situation at hand?
Second, how come so many people talk about needing strategy, but there’s almost never anything written down?

The reason most written strategies don’t apply is because they’re actually visions of how things could ideally work,
rather than accurate descriptions of how things work today.
This means they don’t help you plot a course through
today’s challenges to the desired state.

The reason they often aren’t written down, is that strategy is no more, or less, than how the organization tackles its problems,
which executives often don’t think is valuable to write down.
That’s not to say that these undocumented strategies are consistently good strategies, they often aren’t,
but if you’ve ever been upset that your company doesn’t have an engineering strategy, then I assure you that you do!
Your engineering strategy is how you approach your current challenges.

Writing process

In Staff Engineer, I argued that writing an engineering strategies is like being a historian:
look at how things are already working, write them down, and share what you’ve written:

To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy. To write an engineering vision, write five engineering strategies, and forecast their implications two years into the future. That’s your engineering vision.

This remains, in my opinion, the most effective way to write useful engineering strategies as a Staff-plus engineer.
That’s because enforcing strategy is the biggest challenge for Staff-plus engineers driving strategy work, and this approach collects
well-documented precedents to build consensus around. That consensus is the basis for enforcing the strategy going forward.

As an engineering executive, you don’t need to rely on consensus to drive enforcement, which means you can
take a much more direct path to writing your strategy document.
Rather than enforcement, your biggest risks are writing a weak diagnosis or ineffective guiding policies.
Managing those risks leads to a different process.

The process I recommend for executives is:

1. Commit to writing this yourself! Delegation is an extremely valuable executive skill, but the engineering strategy
   will significantly shape how the engineering organization functions.
   As the company’s engineering executive, you have the unique perspective to write this strategy, which no one else will have.

   If you recently joined and are worried that you don’t know enough yet to write this yourself,
   rest assured that writing the strategy is one of the best learning opportunities you’ll get,
   and there are a number of safeguards in the process to catch mistakes

2. Identify full set of stakeholders you want to align the strategy with.
   While you’ll certainly want to build buy-in with the full engineering team,
   the stakeholders list here should be edited down a bit.
   It should likely include the executive team, the senior-most Staff-plus engineers, the senior-most engineering managers,
   and potentially a few additional business and product leaders

3. From within that full set of stakeholders, identify three to five to provide early, rapid feedback.
   This is your strategy working group.
   You’ll share your roughest drafts with them, and their input will deeply shape the document.

   I recommend several Staff-plus engineers, a few of your direct reports, and your product counterpart.
   At earlier stage companies, this may well include the CEO, but remember that you’re here to do
   something the CEO isn’t able to do (whether it’s due to time or capability constraints), so I’d generally
   steer away from including the CEO in this smaller working group

4. Write your diagnosis section.
   Start with the current roadmap, competitive pressures, and financial plan.
   If you have cultural survey or developer productivity survey data,
   incorporate those results in.
   Pull in all the problems you’ve learned in your 1:1s and team meetings.
   Remember to trust your judgment: you’re leading the engineering function for a reason.

   However, don’t trust your judgment too much. Once you’ve drafted the diagnosis, workshop it with the individuals
   in your strategy working group. I’d generally recommend doing it 1:1 with each member, as it’s easier to get
   direct feedback in a smaller group.
   Meet with one group member, listen to their feedback, then incorporate that feedback before reviewing it with the next member.
   Once you’ve incorporated all that feedback, share a final draft with the working group before moving forward

5. Write your guiding policies.
   This starts with the same process as writing your diagnosis, but it ends with an extra step.

   After incorporating working group feedback, I highly encourage you to also get private feedback from two to three external
   engineering executives. It’s only other engineering executives who will fully understand your incentives and challenges,
   which makes their feedback uniquely valuable. That doesn’t mean they’re necessarily right, they will be overreliant on
   pattern matching since they are missing most of your company’s context

6. Now share the combined diagnosis and guiding policies with the full set of stakeholders.
   I recommend sharing the full document with the group, then spending time with those who have the most feedback.
   You often won’t get much feedback at this stage, which is fine, you are now moving into socializing the plan
   rather than simply crafting it.

   Be aware that once you share the document with the full set of stakeholders, it will almost inevitably leak
   out to the wider company. Companies are design to spread context, not to conceal it, and you just can’t
   fight that tendency. Instead, make sure to edit out anything too sensitive to share widely,
   particularly changes that directly impact individuals or teams

7. Write the coherent actions.
   The actions are usually less complex and less controversial than the guiding policies themselves,
   although not always.
   Iterate on the draft actions with the working group.
   If the actions are controversial, you may want to review it with some members of the extended stakeholder group,
   but often that’s not necessary

8. You’re almost ready to share the strategy with the full organization, but there’s one step left.
   Partner with your working group to identify the individuals in the wider team who are most likely to be
   upset or to strongly disagree with the strategy. Then go spend time 1:1 with those people.

   Your goal is to make sure they feel heard, and that you understand their feedback.
   If the feedback is helpful, then incorporate it into the strategy, but be careful not to compromise
   the strategy to make it more popular

9. Share the written strategy with the engineering organization, schedule a meeting to share the
   strategy and the rationale behind it (as well as take questions),
   and establish a timeline for taking feedback.

   Try to keep this timeline short, roughly a week or so.
   An extended feedback timeline generates more feedback but rarely better feedback,
   and prevents you from taking advantage of the strategy

10. Finally, finalize the strategy, send out an announcement, and commit to reviewing the strategy’s impact in two months.
    Your engineering strategy is complete (for now, you’ll of course be updating it on at least an annual cadence)

Although there are a number of steps here, they can be done very quickly,
and it’s much faster than the Staff-plus engineer’s documentation-driven approach.
Not only is it relatively quick, this is one task that I’d recommend engineering executives
start on sooner than later.

When to write the strategy

You can work your entire career without seeing a documented engineering strategy.
When I worked at Uber, there were many rules scattered across the organization, but there was never a documented, overarching engineering strategy.
Stripe, similarly, had no unified engineering strategy,
although there were numerous technical jurisdictions, such as detailed requirements for external APIs.

Shortly after joining Calm, I opened a document, titled it “Engineering Strategy”, and then stared into the blank abyss until putting it away for a year.
A year later, I came back and documented three core, guiding principles:
choose boring technology,
resolve conflict with curiosity,
and prefer vendors for commoditized functionality.
These few, simple statements greatly eased decision making, allowing us to focus more time on improving our product and business.
(If I could go back in time, I would move “resolve conflict with curiosity” into our values rather than including it in our strategy, but it’s what I wrote at the time.)

In all three cases, the organizations would have benefitted from writing a technology strategy sooner.
The three questions to ask yourself before getting started are:

1. Are you either confident in your diagnosis or do you trust the wider engineering organization to inform your diagnosis?
   If you’re not confident in your diagnosis, and you’re still not sure whose judgment to trust,
   then it’s too early to move forward with writing a strategy
2. Are you willing and able to enforce the strategy?
   If you think that engineers will successfully escalate past your strategy to the CEO,
   or that you’ll be unwilling to enforce the strategy it teams ignore it,
   then it’s too early to work on strategy
3. Are you confident the strategy will create leverage?
   Strategies require an entire organization to change their beahvior, which is quite expensive,
   and will quickly wear down their trust in you. If you don’t have at least a year’s worth of conviction that it’ll work,
   then it’s not worth solidifying

If your answers to those three questions is fairly positive, then I’d push to document the strategy now rather than next month.
While it’s reasonable to be wary of rolling out strategy too early, every bad strategy rollout I’ve seen has been rooted in the
executive’s inability to listen to clear feedback. Waiting wouldn’t have improved their strategy anyway.

Dealing with missing company strategies

Engineering strategies are rarely documented, and unfortunately this is part of a larger problem:
surprisingly few companies document any of their strategies.
This is a problem, because it’s remarkably difficult to write an effective diagnosis
without understanding the company’s other strategies that should inform engineering’s strategy.

The good news is that these strategies do exist, even if they aren’t written down or are visions pretending to be strategies.
The bad news is that this means you’ll have to do some work of your own to make sure you understand these other strategies
before you start writing engineering’s.

The overachieving executive’s default approach here is trying to train
the company on writing good strategies, and then run a company-wide strategy documentation process.
That might work, but going that route will slow down writing a useful engineering strategy by months, quarters or years.
You can probably move faster by modeling a good strategy within engineering than
trying to directly change the overall approach to strategy;
if the executive team was aligned on doing strategy this way, it would already be done.

Instead, I recommend focusing on the handful of non-engineering strategies that are most relevant to engineering,
and privately documenting their strategies yourself.
The business and product strategies are usually the most important starting places, but that will vary by the particulars of your business.
For each strategy you need to document, spend time with the responsible executive understanding their perspective until
you can write a short draft of their strategy. Once you have the draft, test it with that executive to make sure
it’s generally accurate, then keep it as a private draft to inform your understanding.
It may be tempting to share this written draft more widely, but instead of unlocking progress on the engineering strategy,
you’ll instead find yourself in conflict with the responsible executive for undermining them.

Some of the questions that I’ve found valuable to explore in these draft strategies are:

• What are cash-flow targets?
• What is the investment thesis across functions (e.g. sales and marketing, research and development, general and administrative)?
• What is the intended role of mergers and acquisitions?
• What is the business unit structure?
  How do the business units support one-another?
  How are costs expensed across business units?
• Who are your products’ users, what do they need, and how are you prioritizing across those users?
• How will other functions evaluate success over the next year?
• What are your current distribution mechanisms, and how are you trying to change them?
• What are the most important competitive threats?
• What about the current strategy is not working?

Drafting these missing strategy documents is always tricky, and your goal is to pull together a reasonable
sketch, not to write something perfect.
If you get stuck, spend another cycle validating your diagnosis, and then move forward
to guiding policies. If you’ve missed something important, writing the policies will often
reveal the gap for you.

Structuring your guiding policies

With your diagnosis in hand, the next step is determining guiding policies.
There are many, many ways to articulate your guiding policies, but I would
recommend starting by answering three key questions,
which I believe get at the heart of effective engineering strategy:

1. What is the organization’s resource allocation against its priorities?
   (And why these ones?)

   Competition can be healthy, but competing internally on budget and headcount tends to reward
   empire building rather than effectiveness. It also means you’ll often underinvest
   in critical priorities like compliance or security. Avoid this sort of internal competition by
   ensuring your engineering strategy clearly articulates resourcing and priorities.

   As an engineering executive, it’s particularly important to think about the priorities that no one else
   is asking for (especially security, reliability, compliance, and developer productivity), and ensure your investment thesis
   addresses those.

   Just as important is connecting the resource allocation back to your diagnosis.
   This grounds your allocation in the specific constraints you’re solving for, and makes
   it clear what problems any counter-proposal must address.

   Example:
   We aim to maintain a ratio of 4 product engineers for every 1 platform engineer (security, reliability, infrastructure, developer productivity, etc).
   In addition to that standard ratio, this year
   we are running two major projects outside of that ratio, prioritizing a total of 10 engineers on security
   (all production access requires MFA and is connected to an uneditable audit-trail), and
   developer productivity (progressive migration of all JavaScript codebases to TypeScript)

2. What are the fundamental rules that all teams must abide by?
   (And why do they matter?)

   Many of the most impactful guiding policies are predicated on broad, consistent adoption.
   For example, requiring all backend projects to be implemented in Golang would greatly narrow
   your security, compliance, and tooling needs. Similarly, requiring all new projects to use a
   specific database would narrow those needs.

   These sorts of rules must be specified at the engineering organizational level because that’s
   the only place where you can make the appropriate, organization-level tradeoffs.

   Folks are much more open to following rules if you explain why the rules are valuable,
   so I strongly recommend explicitly explaining why each rule is important.
   Things that are obvious to you may not be obvious to others.

   Example:
   All development must use our standard development stack (
   background services use Golang, frontend services use TypeScript, storage is in
   a service-isolated instance of Aurora PostgreSQL) and
   development lifecycle (standard code review, linting, and deployment processes documented in Development Lifecycle wiki).
   Exceptions to these rules must be approved by both Tech Spec Review and CTO

3. How are decisions made within engineering?
   (And why do we work this way?)

   Even the most comprehensive strategy will omit many important details,
   but it should explain how those decisions are generally made.
   This is a nuanced navigation of positive and negative freedoms
   between teams and others impacted by their decisions.

   You want teams to know what they can decide themselves, what they should optimize for
   when making those decisions, and how to move forward with decisions that they can’t make independently.
   You also want individuals to know why you work this way: there are many implicit tradeoffs in each way of
   working, and these tradeoffs are often invisible to folks who are frustrated with a current process.

   Example:
   Technical decisions that deviate from the standard development stack or standard development lifecycle should
   be approved by Tech Spec Review and CTO.
   Changes to those two standards should similarly be approved by Tech Spec Review and CTO.
   Changes to organizational structure, hiring prioritization, and general people process should be approved by CTO.
   All other decisions should be made by the teams and leaders closest to the decision.
   If anyone believes we are making a meaningfully suboptimal decision, please escalate that decision
   using our Escalation Process

If you answer those three questions clearly, you will have an uncommonly valuable engineering strategy.
At least as importantly, the strategy will be explicit about how it ties into the surrounding company strategies,
and the degree of freedom it cedes to the teams and leadership within engineering.

Conversely, if your diagnosis doesn’t support answering these questions, then I’d push you
to think more deeply about your diagnosis. It’s likely accurate, but missing
an altitude that an executive is uniquely suited to bring.

Maintaining your guiding policies’ altitude

It can be difficult to write guiding policies without unnecessarily constraining
the teams within your organization. You can argue that each team’s roadmap
and technology choices fall within the scope of engineering strategy.
I recommend using engineering strategy sparsely, while ensuring you take advantage of
its unique advantages.

To ensure your strategy is operating at the right altitude,
ask if each of your guiding policies is applicable, enforced, and creates leverage:

• Applicable: it can be used to navigate complex, real scenarios, particularly when making tradeoffs.

  Much as applicability is essential for useful values, it applies to guiding policies as well.
  Guiding policies should be living, useful tools.
  If you can’t apply them, then scrap it!

  Example: we generally prioritize stability of the existing product over new product work.
  If stability work takes less than a week, teams should self-approve the work.
  If it takes longer, they should review sequencing one step up their management chain.

  Example: we prefer SaaS vendors over building our own commodity solutions, but
  we only consider SaaS vendors with current SOC2 Type 2 compliance.
  Build versus buy decisions should be reviewed by Tech Spec Review.
  Exceptions to our SOC2 Type 2 policy should be approved by CTO (but won’t be granted).

• Enforced: teams will be held accountable for following the guiding policy.

  Guiding policies will only actually guide an organization if they’re enforced.
  Every experienced engineer has their own stories of working somewhere with a standardized technology stack,
  hiring a new engineer that doesn’t want to use it, and the ensuing conflict.
  A policy is only effective to the extent that you are willing to enforce the policy,
  even if the person violating is your friend, or previously worked at a cool company.

  It’s hard to talk about universal examples.
  Instead, this is more of a cultural question for you to ask yourself:
  are you willing to enforce this policy? If not, look for something else that you’re willing to enforce.
  Often the gap between unenforcable and enforcable can be bridged by a simple nuance
  (e.g. “unless approved by CTO”).

• Create leverage: create compounding or multiplicative impact.

  Leverage is making the organizaton more efficient, either
  directly (e.g. using a data interface that abstracts data privacy issues from product engineers),
  or indirectly (e.g. creating a new machine learning powered content selection tool,
  which means folks don’t need to argue about what content is shown where).

  Many forms of leverage are accessible to the teams within engineering,
  and it’s often not necessary to directly address those opportunities in your engineering strategy.
  However, some approaches must be deployed at the engineering strategy layer to be impactful,
  particularly standardization strategies that require org-wide commitment
  (e.g. everyone uses TypeScript for frontend development).

  Engineering strategy also needs to solve for scenarios where no team is capable of prioritizing a given effort, despite
  the effort being very valuable, such as a compliance or privacy initiative that
  doesn’t fall cleanly into any given teams scope but is necessary for continued business operation.

  Example: Google historically constrained development to four languages: Python, C++, Go, and Java.
  They enforced this fairly rigoriously, and it created leverage in their development tooling.
  Each new project happening within that ecosystem increases a centralized tooling team’s impact on the company.

  A closely related example is Dan McKinley’s Choose Boring Technology,
  which advocates building leverage by constraining technology choice, which was heavily enforced
  during Kellan Elliott-McCrea’s era of Etsy engineering leadership.

  Example: Uber (in 2014) had an implicit technology strategy, related to its Let Builders Build value,
  of letting teams select their own tools. This aimed to create leverage by allowing teams to select the
  best tool for the job at hand, and was enforced through both engineering leadership’s absence of an enforced counter-policy,
  and permissive service tool which merrily ran any Docker container.

  This approach is implicitly grounded in the theory that teams’ individual gains would outweight the inability
  to operate a high-leverage developer productivity team.
  More importantly it highlights the value of explicit engineering strategy: otherwise you get implicit engineering strategy,
  which is often ineffective.

  While ineffective in this case, in a consulting company that built bespoke tools for other companies, it’s possible this
  guiding policy would be very effective.

If one of your guiding policies doesn’t meet these criteria, but is necessary to address your diagnosis, then I wouldn’t worry about it.
However, if you find that many of your guiding policies don’t meet these criteria, then it’s worth spending time
reflecting on what’s creating that gap until you’re confident that they do meet these criteria, or that these criteria don’t
apply to your diagnosis.

Coherent actions

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.

Shouldn’t strategy be bottoms-up?

Even with that efficiency argument in mind,
there’s a certain type of person who encounters a strategy and immediately argues that it’s disempowering.
The argument comes in a few different flavors:

• Strategies are top-down, removing autonomy from teams doing the work.
  We value autonomy, so teams should determine their own strategies
• Managers, including the engineering executive, shouldn’t set strategy,
  it should be owned by engineers rather than managers

I think these questions are a misunderstanding of how strategy works.
Strategy can only be employed top-down,
so it’s not a question of top-down versus bottoms-up.
Instead it’s a question of whether to have strategy at all.
Outside of small, slow-growing organizations that can use social pressure to enforce strategy,
only top-down leadership (or groups wielding that delegated authority) are capable
of enforcing a practice, which is necessary for an effective strategy.

When I hear questions like these, usually the concern is really about how strategy is being set
(e.g. did our migration to Go ignore certain perspectives?) or with a specific strategy (e.g. is our monorepo strategy not working?).
If you can find the root concern, there’s almost always something interesting to learn there!

If someone is genuinely opposed to a consistent organizational approach, then they’re opposed to most scalable forms of leverage.
Certainly you can successfully run a small company that way, but it’s an expensive way to operate anything larger,
and that’s a lesson for them to learn rather than your organization to suffer through.
(As always, some caveats exist. If your company only does prototypes that never go to production, or if you always contract out
to build for other companies, then you’d be able to offload most of the costs to them instead, but I’m skeptical if that’s
the right choice in most cases.)

Start simple

Strategy is a deep topic, and it’s easy to drown in that depth if you aren’t careful.
This is why so many executives never end up writing anything.
They start working through the diagnosis, guiding principles, actions, application, enforcement, and creating leverage,
and push it off until tomorrow. Then next week. Then indefinitely.

If you look at the full set of ideas and practices here, and think, “I’m not going to do that,”
then I think that’s fine. This doesn’t have to be a massive, one-time creation.
I firmly believe you can be a top ten percent engineering strategist by simply documenting your existing, implicit strategies.
Once you’ve documented them, discussions will happen more frequently, which will create a persistent pull towards improvement.
It’s better to go slowly than to avoid starting altogether.