In every role I’ve taken, I’ve instigated Leadership post-mortems. Here’s what they are, why/how you should do them as a leader and some quick tips.
What is a Leadership post-mortem?
Similar to a technical Post Mortem, A Leadership post-mortem is a form of structured reflection & open review for cases where a leadership decision has ultimately caused an issue for the team / a team member etc, e.g. dismissals, probation fails, layoffs, poor tactical choices etc. As with a system post-mortem, these are presented to the team in the immediate aftermath, with an open forum for questions.
An example of how it might run…
This type of post-mortem follows the exact same pattern as a technical post-mortem, with 5 steps as below. Let’s imagine the dismissal of a team member on the grounds of performance:
- What happened?
- Person X had been underperforming for 3 months
- Support was provided, and they were on a formal improvement plan
- Ultimately, they were dismissed due to underperformance. They were aware this was the result if specific requirements weren’t met.
- What was the impact?
- This was an upsetting experience for person X
- This has hit morale in the team, due to relationships with person X
- Our overall team output will be down for a period, putting more pressure on the team
- Why did it happen? (5 why’s)
- Interviewing did an insufficient job to test a particular skillset, leading to a mismatch between individual and role
- The mismatch was also not adequately recognised during probation
- Despite efforts and support to improve their performance, they could not meet the required level. This was putting pressure on the rest of the team.
…
- What did we learn for next time?
- Our interviewing and probation process needs to improve to avoid this in future
- What are the specific actions?
- Complete overhaul of technical portion of interview
- Rethink of the probation process
Why should you do them?
I know the feeling… after a difficult decision the last thing you want to do is face a public hearing. But the team need to see that you recognise the gravity of these decisions and that you are taking responsibility.
As with any post-mortem, that means demonstrating that you recognise the broad impact, that you are taking responsibility for your part, that you have learned for next time and are taking meaningful actions to avoid repeats. Using post-mortems as a format reinforces a mutual sense of accountability with tech teams, you practice what you preach and lead by example.
The format comes with a beneficial set of principles, namely that this should be blameless and open to input. It’s easy for developers to forget that managers are just humans making decisions and mistakes are made.
Some other more personal benefits to this:
Sense of safety: After a dismissal, it’s easy for people to think “Am I Ok? or am I next?”. This gives an opportunity to make the whole process transparent, that this person knew well in advance with plenty of opportunity to change.
Vulnerability and trust: This level of transparency and openness to feedback puts you in a vulnerable position. This helps to build an immense amount of trust in you as a leader.
Cultural alignment: This is an opportunity to lay out the approach taken with performance management in real terms and discuss it. This can help identify areas where individuals disagree with the company’s culture, to either work on alignment or ultimately agree it’s a poor fit for them.
Some quick tips when running one
- Respect the individual’s privacy
It’s important to respect the individual(s) involved, and not overshare the circumstances. Remember this is a mismatch between the individual and role, not a critique of their abilities. I focus on outlining the process followed, rather than the specific issues highlighted. It’s ok to say that you can’t share certain details to respect the individual’s privacy.
2) Avoid defensiveness
This can be hard and emotionally charged for team members, particularly those with strong relationships. When someone questions decisions, avoid getting defensive or personal. Invest time in talking things through with individuals independently if they have strong feelings about the circumstances.
3) Be sincere and fair
People are human bullshit detectors, and developers are sceptical by nature. They will almost certainly stay in contact with the affected individual(s) and hear both sides. Be honest, be vulnerable and admit mistakes / recognise failures / acknowledge learnings. There’s also no need to chastise yourself, this isn’t a public hanging.
4) Use this to motivate good behaviours in yourself / your managers
For me, knowing that any low performance process will eventually be scrutinised end-to-end by the team proved to be a strong motivation to follow a rigorous and fair process. Did I do everything I could to support the individual? Were they explicitly aware of the concerns throughout? Did I raise awareness as early as possible?