Is engineering strategy useful?

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

Impact of Calm’s strategy:

We stopped arguing about technology investments We exited several engineers who didn’t want to follow our strategy Combined, this meant we could consolidate our tooling investments into our TypeScript monolith We started spending our innovation chips on product enhancements, culminating in ML-powered algorithm to determine best content for each user based on their behavior, UI to allow content team to self-service content management rather than require engineering support, and so on This was initially viewed, by some, as making it “less fun”, but ultimately meant we spent a lot more time having doing fun work that both stretched us as engineers and helped our users

These strategies are effective for a few reasons:

Many interesting properties only available through universal adoption (“we run our own hardware”) Concentrate tooling investment onto smaller space (“we run in a mono repo”) Reduce energy lost on conflict (“we are a product engineering company”) Control your innovation budget (all three) New hires, especially senior new hires, forced to engage explicitly with strategy rather than having option of ignoring it (all three) This is the power of making explicit, consistent tradeoffs across an entire organization.

Absence shows value as well In addition to arguing the value of strategy from these positive examples, it’s easy to find negative examples where a missing or inconsistent strategy caused a great deal of pain:

Digg’s 3+ year migration to V4, onto a 100% new codebase with a new database, new frontend, new backend, and new algorithms. Honest diagnosis about challenges, but highly impractical approachs Stripe’s introduction of Java had unclear evaluation criteria, took years to assess effective. Rooted in inaccurate diagnosis about problems at hand Uber’s invested heavily in competing routing technologies, causing significant friction. Rooted in simultaneous following conflicting approaches without aligning on approach I’m sure you can think of examples from your careers as well!