Engineering strategy every org should write. | Irrational Exuberance
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?