Mean Time To Reorg; Writing as Resilience

I'm not sure any re-org I've been subjected to has led to anything useful but wasted time, confusion and the de-prioritisation of work already done which leads to more wasted time. One aspect of the wasted time comes from the need to explain or maybe even justify the work done by the team having active documentation on the team’s tenants, work and roadmap is one way that helps. Logan's recent blog titled Mean Time To Reorg; Writing as Resilience provides some good examples of this in action.

As a tech lead of a project, these reorgs led to frequent changes in management reporting lines. The twice-annual reporting line change drew my time away from the team and project, and was spent on understanding the positions and intent of the new management structure, and briefing them on the work we did and why it was valuable. [...] Folks new to the project who only did surface level due diligence would misunderstand the details rather than fail to grok them in the first place. When a new hire joins the company there’s an expectation of some number of months before they develop expertise in all of the in-house systems. When there’s a reorg there’s an expectation that the new manager of an area is effective overnight.

I learned that in order to preserve my time for the team and project I needed to improve the speed at which new people (particularly management) onboarded [...] I did this through writing and documentation. We had in-depth docs for users of our product. [...] Over time I learned that essentially writing context and documentation about the roadmap greatly benefited the onboarding of new managers, engineers in the area, and curious customers.