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:
- How do we review, merge, deploy, and release code?
- What are our approved technologies for new projects?
- When and how do we deprecate user-facing functionality?
- When and how do we deprecate internal tools?
- How do we document our software and process?
- Because this is a surprisingly controversial topic, explicitly which tools do we and don’t we use for documentation?
- How do we evaluate, select and adopt new technologies?
- How do we migrate away from our existing technologies?
- How do we respond to incidents?
- How do we identify and prioritize incident remediations?
- How do folks switch teams?
- How do you staff work on “unowned” areas and tools?
- How do folks move from individual contributor track to management track? How do they move back?
- How do you think about evaluating internal versus external candidates for scarce roles?
- 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.