Rollout and adoption of engineering strategy

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

key message: you can drive engineering strategy at your company, whether you’re an executive or an engineer

Communication: how do you document and make the strategy approachable Rationale to executive team … Slide decks, etc

Two primary ways:

From below: how you can rollout strategy without being the CTO engaging With above: how you can rollout if the CTO’s bought in Top-down This strategy is a modified version of the one describes in Writing an engineering strategy. At it’s core, the thing to recognize is: it’s easy to get CTO buy-in if you write the strategy that the CTO wants.

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.