Project post-mortems often serve as opportunities for growth and understanding on engineering teams, forcing participants to reflect on what went well and what could have been done better.
Each team has its own take on project post-mortems. But regardless of the approach taken, the goal is largely the same: listen to each other’s perspectives, aggregate feedback and derive actionable insights.
For Michael Olshansky, senior engineer at text-messaging software provider Zipwhip, a successful post-mortem doesn’t always involve reaching a unanimous decision. In fact, disagreement is fine, as long as everyone knows how to move forward in the right direction, he said.
Built In Seattle caught up with Olshanksy to learn how his team tackles project post-mortems.
What does a typical post-mortem look like for your team, and how do you structure those meetings to ensure you’re making the most of that time?
I look at a project post-mortem like a greatly enhanced version of a sprint retrospective. While engineers and a manager are always present, it’s sometimes prudent to include product owners, project managers, DevOps and platform engineers, managers, engineers and even directors. We ask that everyone comes prepared with a list of items that they think went well and could have been done better, with no subject area off-limits. We then go around the room and give everyone a chance to say what they think, aggregate the feedback and distill it into action items that are then used as process improvements on subsequent projects.
The goal is always the same: to be constructive and reflective, understand each other’s perspectives and learn what we can do better — individually, as a team and as an organization.
What’s one of the most valuable revelations or lessons that has come from a project post-mortem, and how has that helped your team grow?
Regardless of whether this is a new team or a well-established one that has done project post-mortems many times, the common themes are always communication, decision-making and process improvements. One valuable lesson we learned is the importance of getting off on the right foot. If requirements are ambiguous, it can result in analysis paralysis, which can be a drag on a team’s velocity and a net negative for their confidence. The solution is to call a meeting immediately, including the stakeholders needed to resolve the ambiguity, as well as a stakeholder who will act as the tie-breaker if a decision can’t be made by the group. This leads to another revelation — sometimes we simply need to disagree and move forward for the good of the project.
The goal is always the same: to be constructive and reflective, understand each other’s perspectives and learn what we can do better.”
What’s one thing you’ve done to improve your post-mortems over time?
It’s important to identify trends. Before starting a project post-mortem, it can be helpful to look back at ones from previous projects. Are we repeating past mistakes? Are people complaining about the same sort of issues? Addressing them by creating action items or process improvements can be a big plus, allowing the team to self-identify and self-correct rather than fall back into old patterns.
.png)
