November 26, 2020.
Few companies understand their engineering strategy and vision. One consequence of this uncertainty is the industry belief that these documents are difficult to write. In some conversations it can feel like you’re talking about something mystical, but these are just mundane documents. The reality is that good engineering strategy is boring, and that it’s _easier_ to write an effective strategy than a bad one.
November 7, 2020.
Writing my recent article on Engineering strategy was one of the most challenging pieces of writing I’ve done in the past few years because I had far more ideas than I could fit into a coherent narrative. I extracted a number of those into semi-edited snippets filed under the strategy tag, and here is the last one in that vein.
November 7, 2020.
While sharing my advice for writing an engineering strategy, my second draft had an extended section of “rules for writing engineering strategies.” I think these were all _useful_, but it was a piece that suffered for too many ideas, and I ended up removing most of them.
November 7, 2020.
If by some act of perseverance and skill you write an engineering strategy that’s well-received by your organization, then you’re faced with the next challenge. How do you keep this living document alive past that initial burst of excitement?
November 7, 2020.
When you’re writing an engineering strategy, what you put in is important, but it’s almost as important to be deliberate about what you choose to leave out. The full list of things to exclude is uncountably vast, but there are a few worth emphasizing in particular.
November 7, 2020.
Before attempting to document what an engineering strategy ought to be, it’s useful to sharpen a related problem statement: why do engineering teams decide to write an engineering strategy?
November 5, 2020.
One of the projects from my time at Stripe that I’m proud of was writing our engineering strategy, which I later sanitized into a public version in Magnitudes of exploration. The strategy was an elegant document that carefully reconciled two worldviews that had initially appeared incompatible within the engineering organization. While it was both a conceptually pure and utterly pragmatic document, in the end, it wasn’t particularly useful. It reflected how we described making tradeoffs as opposed to how we genuinely made tradeoffs.