This is a work-in-progress draft!

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.

Notes

*These are directly copied from https://lethain.com/eng-strategies/ :

The process I recommend for executives is:

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

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

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

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

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

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

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

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

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

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)