How to Make the Most of a Project Post-Mortem

These Chicago Tech Companies Use Empathy and Action Points to Make Retrospectives More Productive
Written by Erik Fassnacht
April 7, 2021Updated: May 11, 2021

A productive post-mortem can’t change the past, but it can almost always alter the future.

According to Harvard Business School’s Francesca Gino and three colleagues, taking time to reflect on work improves job performance in the long run. Gino and her research team conducted three experiments that focused on the dual process theory of thought, which posits that humans learn in two different ways: faster-paced learning by doing and slower-paced learning by thinking and reflection. 

In all three experiments, those who were instructed to reflect and document what they learned significantly improved their job performance over those who continued working without reflection. In the third experiment, individuals who shared their reflections with others — and explained their notes in person — improved their job performances even more.

In the modern business world, a reflective post-mortem can redirect team performance toward far more fruitful projects in the future. While some organizations have resisted the post-mortem for a variety of reasons, it is imperative to assess the effectiveness of a completed endeavor, study what went right or wrong on both a macro and micro level, and adjust accordingly. What’s more, listening to the suggestions of everyone involved — a key factor in the scrum model — can lead to unique and effective solutions that resonate far into the future. 

We sat down with three Chicago tech companies to discuss how they make the most of a project post-mortem. We learned that unhampered honesty, clear communication, empathetic reinforcement and positive terminology can change both the tone and the content of a post-mortem, creating far better results than ever before.

 

Matt Pyra
Lead Software Engineer

Matt Pyra is a lead software engineer at Beyond Finance, a platform for customized financial products. He learned that the resistance many workers have toward post-mortems centers around preconceived notions about tone, negativity and a lack of impact. To turn this resistance around, Pyra focused on post-mortems that were positive, empathetic and packed with clear action items to utilize in the next project. 

 

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?

Of all the ritual meetings in software development, none is more gruesome than the post-mortem. It’s right there in the name. To encounter one of these meetings is, all too often, to dissect that which just went wrong — to peer into the grim reflection of failure itself! But, for all the dread this meeting can dredge up, it is an invaluable tool for improving team performance. 

In terms of format, a productive post-mortem follows the structure of a regular sprint retrospective, with the difference being the topic of discussion. Rather than focusing on the previous sprint, the focus is the previous project. Leveraging a familiar format helps to alleviate some of the stress that can be associated with a post-mortem.

 

BEYOND FINANCE'S TIPS FOR A PRODUCTIVE POST-MORTEM

  • Avoid the Term “Post-Mortem”: The phrase reinforces the negative and puts team members in a defensive posture. Try a more constructive term like “retrospective.”
  • Meet Regularly Beforehand: Most sizable projects have multiple phases. More frequent retrospection will improve team performance.
  • Facilitate Communication: Your team has its own identity and preferred style of communication. Learn the style of your team and embrace it.
  • Produce Meaningful Action Items: Teams enjoy self-regulation, and the “action item” has become the currency of legislation. Favor producing fewer, more impactful action items.
  • Encourage Empathy Toward the Failures: Utilizing empathy generously is a great strategy for any relationship. Remind team members that the purpose of this meeting is improvement, not blame.

 

Whats one of the most valuable revelations or lessons that has come from a project post-mortem, and how has that helped your team grow? 

A previous post-mortem improved our clarity on roles and expectations. On a recent project, there were assumptions made about who would provide requirements and coordinate cross-team collaboration. That assumption led to failures in these regards. Requirements were missing, and teams were unaware of their responsibilities. Now, those responsibilities are stated more clearly and checks are in place to ensure smoother roll out.

 

Whats one thing youve done to improve your post-mortems over time? What were the results?

The best improvement to our post-mortems is checking in more regularly. Having a post-mortem only at the end of a project means it is clearly too late to course-correct. Instead of meeting just at the end, we now meet at regular intervals. We keep track of issues as they arise and address them before the next meeting.

 

Jerome Karaganis
Engineering Manager

At Pareto Intelligence, a healthcare solutions company, engineering manager Jerome Karaganis knows that asking the right questions and staying away from self-implication or blame can get employees talking and sharing during a post-mortem meeting. The result: more impactful suggestions and changes that can be used in important projects going forward.

 

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 see retrospectives as a great way to improve the development process. My first tip is that post-mortems are old school. Why wait until the end of a project to find out that your team has been doing something wrong for a long time? The whole idea of Agile development is to foster continuous improvement, and retrospectives are a key part of that process.

Over the years, I’ve heard from team and project managers who have either been hesitant to add retrospectives or have given them up. Some give them up because they think they take too much valuable time. Believe me, I understand the crunch to get things done. However, if you’re not talking with your team about how time gets wasted every sprint — and more importantly, how to fix those problems — I guarantee you can find more than half an hour of productive time that can be reclaimed.

 

Whats one of the most valuable revelations or lessons that has come from a project post-mortem, and how has that helped your team grow? 

Asking “What went wrong?” may return nothing but the sound of crickets. On the other hand, directly asking each team member, “What went well for you this sprint?” is more likely to get an answer. Even better, asking leading questions like, “Oleks, I know that Ming helped you last week, can you elaborate on how that went?” is almost guaranteed to get a solid response. Encourage the team to cheerlead each other and to recognize both individual contributions and group collaborations — this is the start of building a team that likes to work together.

Another thing learned is that retrospectives should never be about blaming. They are not an opportunity for outsiders to talk to the team. Retrospectives are a chance for the team to talk to itself and improve organically. Creating an environment where people feel safe to admit their own mistakes and work together to find solutions is the primary goal. As a leader, one of the best ways to show the team what retrospectives are all about is to model the desired behavior: Admit your own mistakes, detail how you plan to improve and then follow through.

 

Retrospectives are a chance for the team to talk to itself and improve organically.

 

Whats one thing youve done to improve your post-mortems over time? What were the results?

Some resist retrospectives because they believe it leads to complaining or venting without any real change. While it’s easy for a retrospective to become an extended chat session, even then, it’s not a waste of time. People like being heard and knowing that someone is paying attention, but the best way to pay attention is to guide the team to come up with actionable solutions to the issues that arise. One of the best outcomes of a good retrospective is finding items that can be turned into Jira tickets and tracked, so that the next retrospective can naturally begin with a discussion of progress on those items.

When I first started running post-mortems and retrospectives, I was apprehensive because I didn’t know how the team would take it. I realized, though, that at a bare minimum, they are a chance to tell my team how much I appreciated all the hard work they put in. Who wouldn’t want to sit through that? And finally, a post-mortem is the idea of reviewing a project with the hope of learning from the past. Retrospectives are the exact same thing — just more frequent — and this advice applies equally to both.

 

Alan Spadoni
Vice President of Engineering

Alan Spadoni is vice president of engineering at Buildout, a platform for commercial real estate. He believes that the key to a quality post-mortem is not only a consistent format to keep everyone on track, but also making sure post-mortems are conducted after all projects, including the most successful ones. With an ongoing attitude that even the best products and features can be updated and improved, the post-mortem becomes more positive and productive than before.

 

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?

Each development team hosts retrospective meetings each month to discuss internal team process and sprint-level issues. We also host larger, cross-team retros on project milestones. We use a specific format for consistency to ensure we stay on track. Furthermore, each meeting’s notes are written down and shared with the department in confluence. 

 

Whats one of the most valuable revelations or lessons that has come from a project post-mortem, and how has that helped your team grow? 

In September 2020, when going through the retro on a project to build a Google and Outlook contact sync that resulted in some customer attrition from our CRM product, we noticed that a number of steps in the project went “just OK,” which compiled into a bad user experience. This was a key revelation in both the root cause of our issues, and as a reminder that “just OK” isn’t what we should strive for.

 

We consistently schedule retros now, even after an extremely successful project milestone.

 

Whats one thing you’ve done to improve your post-mortems over time? What were the results?

The biggest improvements to our process have been threefold. First, we consistently schedule retros now, even after an extremely successful project milestone. Constant iteration and improvement are necessary. Cargo culting also applies to process — you can’t copy something you’ve done at another company and never change it, nor is any process ever truly perfect. Secondly, on the team level, we host a 5-minute mid-week check-in to identify and address any blockers that haven’t been identified in daily scrum due to the inherent myopia of daily meetings. Finally we call these meetings “retrospectives” instead of “post-mortems.” It sounds silly, but the attitude shift toward positive, constructive feedback with the name change was noticeable. The only remaining “post-mortems” we create are for service outages.

 

Jobs from companies in this blog35 open jobs
All Jobs
Data + Analytics
Design + UX
Dev + Engineer
HR + Recruiting
Marketing
Operations
Product
Sales
Developer
new
Beyond Finance
Remote
Operations
new
Beyond Finance
Chicago
Sales
new
Buildout, Inc.
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Developer
new
Pareto Intelligence
Chicago
Developer
new
Pareto Intelligence
Chicago
Operations
new
Beyond Finance
Chicago
Marketing
new
Beyond Finance
Chicago
Marketing
new
Beyond Finance
Chicago
Developer
new
Beyond Finance
Remote
Operations
new
Pareto Intelligence
Chicago
Design + UX
new
Beyond Finance
Chicago
Developer
new
Beyond Finance
Remote
Developer
new
Pareto Intelligence
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Developer
new
Beyond Finance
Remote
Data + Analytics
new
Beyond Finance
Chicago
Operations
new
Beyond Finance
Chicago
Product
new
Beyond Finance
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Operations
new
Pareto Intelligence
Chicago
Sales
new
Buildout, Inc.
Chicago
Operations
new
Buildout, Inc.
Chicago
Developer
new
Pareto Intelligence
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Developer
new
Buildout, Inc.
Chicago
Data + Analytics
new
Buildout, Inc.
Chicago
HR + Recruiting
new
Pareto Intelligence
Chicago
Developer
new
Beyond Finance
Chicago
Data + Analytics
new
Pareto Intelligence
Chicago
Product
new
Buildout, Inc.
Chicago
Product
new
Beyond Finance
Chicago
Operations
new
Buildout, Inc.
Chicago

Chicago startup guides

LOCAL GUIDE
Best Companies to Work for in Chicago
LOCAL GUIDE
Coolest Offices in Chicago Tech
LOCAL GUIDE
Best Perks at Chicago Tech Companies
LOCAL GUIDE
Women in Chicago Tech