Engineering strategy every org should write.

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.

The question I want to briefly explore here is, “What strategies should most engineering organizations try to document?” I’ve taken a somewhat overly broad view of what you might consider an engineering strategy, including both technical and organizational aspects.

An unordered list of strategies I would recommend every engineering organization document as they grow are:

1. How do we review, merge, deploy, and release code?
2. What are our approved technologies for new projects?
3. When and how do we deprecate user-facing functionality?
4. When and how do we deprecate internal tools?
5. How do we document our software and process?
6. Because this is a surprisingly controversial topic, explicitly which tools do we and don’t we use for documentation?
7. How do we evaluate, select and adopt new technologies?
8. How do we migrate away from our existing technologies?
9. How do we respond to incidents?
10. How do we identify and prioritize incident remediations?
11. How do folks switch teams?
12. How do you staff work on “unowned” areas and tools?
13. How do folks move from individual contributor track to management track? How do they move back?
14. How do you think about evaluating internal versus external candidates for scarce roles?
15. How do you empower senior engineers to contribute to the engineering organization beyond day-to-day technical contributions?

For many of these, you could argue that they are more policy than strategy. That’s a reasonable argument, but for me the distinction is that you turn a policy into a strategy by explaining the rationale behind it: a policy is just an incomplete strategy.