Writing a re-org post-mortem
In 2016, our company began a big shift in how we worked with our technical stacks. It didn’t end work out in the end, but it took a long time (2023) for that to be truly realised. In 2023, when the project was shut down, a colleague and I were given the task of documenting what went wrong, and what went right. This documentation was effectively a post-mortem on steroids - 10 team retros, 60 participants with many individual interviews after. The write up is about 1/3rd the length of the first Harry Potter book. Since the report was written, about 180 of the product & tech organisation have read it, and we’ve given multiple presentations on top. Others have listened to it in podcast form, thanks to Notebook LLM. This document is probably the most consistently mentioned historical artifact our tech organisation refers to.
The objectives
To figure out who we needed to talk to, we needed some clear objectives. Objectives that would help us understand why we needed to talk to people. Once you know why you are analyzing something, figuring out who you should talk is a bit easier to think about.
Our objectives were straightforward: objectively document why this attempt failed, to use these learnings for the future. There was considerable frustration within tech, so an additional objective was to give people a chance to air these frustrations.
The process
There were some teams that were clear we should talk to: those who worked on the central stack, and stakeholder teams that worked directly with the central stack team. We realised half-way through that it would be beneficial to talk to management, too - to understand both the concept, and how different problems were managed.
That left us with two types of retros: team retros, and individual interviews.
For both the retros and interviews, we’d take both written notes, and an audio transcription. For retros, we also had postit notes from those who took part - grouped into categories we had defined beforehand.
As the whole centralizing had caused considerable frustration, we felt it was important to avoid directly attributing any quotes to specific people, where possible. When we did directly attribute people, we gave them both the quote and the context beforehand - so they could either approve or reject the quote.
The goal was not to blame to specific people - it was to understand what happened. Much like blameless post-mortem culture, this report could be thought of as blameless analysis. However, it’s good to note - there were problems to blame, and we didn’t hold back on that. But in blameless post-mortems, you blame processes and not people.
We were sure to highlight as many problems with the process of centralizing as we could. At the same time, we also made sure to highlight any successes. For any future learning, focusing on both things that went particularly well and particularly badly is highlight valuable. Things that went badly can be avoided, or done differently. But you also want to repeat the things that were done well.
Once we ran all the sessions with teams and individuals, we then turned the notes from each session into a summary for that specific individual or team. Other than me and the other author of the report, nobody else would see the transcribed notes we had taken. Very intentionally, we avoided leaking any direct quotes.
The summaries were provided in the report, but were also used to provide executive summaries, do’s and don’t, and specific topic-basic summaries.
The report is pretty huge - so we intentionally make it possible for people to read a specific section without needing to read the whole document. Google Docs’ sections and headlines makes it easy for people to dive to a specific team, for example. We assumed that most team members would be interested in reading the executive summary + their own team’s summary.
What about bias?
Both myself and my co-author were involved in some way. Myself as a user of the platform, and the co-author as someone who was on that team. We naturally had opinions, and biases. But the objective was not “write up what Noah and Hilde think about CNP”, it was “document what went right and wrong with CNP”. We took part in two of the sessions as participants, where we voiced our opinions, but in every other session and the write up, we tried to reflect the opinions of the org. It can be pretty challenging to avoid that, on a topic you’re passionate about. However, if we were afraid of bias, we’d discuss with each other to make sure we’re grounded.
In the document, and in presentations, we made sure to explicitly mention bias. The document is mostly free of our personal bias, but in presentations, we would often include things that we felt didn’t fit in the report, but was important for others to hear. For example, our personal recommendations, or tough-but-fair feedback that management needed to hear.
Then what?
We feared when writing that nobody would read it. Or that management would ignore it. Instead, the opposite is true. Several people have read it multiple times - including management. Both me, my co-author, and others in management frequently mention or send it to others, and we know they read it.
A core aspect of why so many people have read it is that for several years, this was a heated topic within teams. People had strong opinions and frustrations, possibly for the majority of the time they were in the company. The report is a healing factor: showing the company not only cares about doing things differently in future, but also giving a voice to employees.
I’m personally pretty happy with the outcome. It took a lot of time and energy, and so much rewriting to get each phrase just right. But I’m proud that the company both gave us the time and resources to write the report, and that the company has received it well.