Learning from the Past to Power up the Future
Startup teams looking to learn solely “from the data” may not realize that they can end up getting really good at learning from the quality of outcomes for which data is more easily available rather than the quality of their decisions, on which data is really hard to get. The quality of a decision cannot be judged by the quality of the outcome. For most of us, this aphorism from the field of Decision Analysis takes a while to digest and internalize as we are strongly conditioned to conflate decisions and outcomes.
Successfully avoiding decision-outcome conflation requires slowing down and asking some fundamental questions, which is all the more difficult for startups as they operate under intense timescales and require many sacrifices from team members to make progress. Now throw new team members into a context where the older members don’t have time to slow down and provide orientation, and there are a lot more missed opportunities for learning.
Teams that don’t slow down to retrospect on the quality of their decisions tend to experience burnout, hurt feelings, and disconnection from the purpose of the startup. Given how strapped a startup tends to be in its initial years, even one disgruntled member on a team can significantly affect what the team is able to achieve as a collective. In such contexts, regularly calling a timeout after a major sprint to conduct a retrospective can provide a much-needed opportunity to focus more on the quality of our decisions instead of the quality of our outcomes, learn as a community and build bottom-up strategy.
As a participant in and a facilitator of retrospectives, I have been amazed by the value that this humble process delivers. Every time I’ve been with a team on a retrospective inquiry, we have come away recharged with a deep feeling of bonding and ownership of the team’s challenges. We have developed a bottom-up strategy as a direct response to our challenges and created projects that would have been impossible to intuit top-down. At an organizational level, I have found that teams that retrospect together stick together. Instead of turning their stress upon each other, their performance goes to new heights and the team becomes formidable in its ability to learn from and empathize with each other. Retrospectives allow small teams to punch above their weight class by aligning mutual understanding and collective energy.
So, what’s the difference between a retrospective and a post-mortem?
It is not exactly clear how the morbid “post-mortem” entered official management parlance. There isn’t a community of practice around how to do post-mortems wisely and it has largely been a placeholder that operates as a checkbox for leaders to say they did one. Without any clear principles driving it, post-mortems can often turn into a blame game that can permanently damage teamwork.
Retrospectives, on the other hand, come from the pioneering work captured in Norm Kerth’s classic, “Project Retrospectives,” and stem from decades of hard work by the Appreciative Inquiry community (the other AI!) The term “retrospective” helps us avoid the heaviness of a post-mortem because nobody died. We are in the land of the living and want to continuously learn. We do not need to leave dead bodies in our wake to accomplish a learning culture. A retrospective is a highly disciplined and stylized process that uses very specific steps to allow for the discovery of insights in a safe space. In fact, when done right, the process establishes safety as a foundation for the learning conversation.
To understand this process, I will share from a recently-conducted retrospective from one of Ulu’s portfolio companies and draw out lessons along the way. But first, here is a summary card for the busy reader.
Lesson 1: Recognize the need to slow down and do a retrospective.
Ping, an Ulu portfolio company, is driving breakthrough innovation in legal time-keeping. This industry is overdue for innovation, and Ping’s team has been hard at work delivering software that creates an amazing user experience with artificial intelligence for lawyers to do away with antiquated timekeeping. Ping’s team had been running hard and fast for several months. Their Head of Product Janesh Gupta and Head of Engineering Matt Bordas felt it would be good to pause and reflect. Their team had also grown from five founders to more than double. It was important to ensure that everyone had a shared understanding of the challenges in front of the team, and to mine the past to build a better future. They reached out and asked if I could facilitate a retrospective for them, which brings us to the next lesson.
Lesson 2: Get someone from outside your immediate team to facilitate.
This is an extremely important aspect of a retrospective. The facilitator holds space for safety and dialog. If any interaction descends into blame, it is the facilitator’s job to restore safety in the space so dialog can resume. Imagine the difficulty of restoring safety when the facilitator was a participant in the team and is now being blamed. I have been in that spot once. I recognized defense mechanisms and resentments kicking in, and there was no one else there to keep the space safe for dialog. Thankfully, I had enough awareness to say, “I am recognizing the need to enter this dialog as a participant, so I need someone else to come in as a facilitator to keep the space safe for dialog.” A colleague who wasn’t involved in the contentious topic jumped in and saved the day. Chastened by experience, I would now recommend that teams use an outside facilitator whenever possible, especially if there has been any conflict among team members.
Retrospectives are not a series of mechanical steps. Great dialog doesn’t just happen. The facilitator brings a strong intention of well-being and growth for the team and is listening very deeply. In fact, the facilitator’s listening shapes the space for dialog. Any team thinking about a retrospective should ensure that the facilitator is someone who can truly listen neutrally and has enough standing to hold all participants accountable for safety in the space.
Gupta notes, ‘Having a technically-oriented investor lead our retrospective, selfishly, is exactly what a seed-stage company should be doing. This is truly a value-added investor move. Personally, I was able to join the retrospective as a participant in my day-to-day role while Somik led and (most importantly) taught us how to facilitate a retrospective as we aim to scale this company.’
If your team is large or cross-functional enough, you may have members who can step in as a neutral facilitator. At Ping, COO Kourosh Zamanizadeh shadowed me so he can do this for the team the next time. This would work well as he has enough distance from the engineering work for him to facilitate a retrospective without becoming a participant in the conversation.
Lesson 3: Start with safety
The most important part of a retrospective is the opening where ground rules are set. It is here that a space of safety needs to be created in order for the rest of the conversation to be successful. Norm Kerth offers us the “Prime Directive,” which says the following:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
— Norm Kerth, Project Retrospectives: A Handbook for Team Review
In Ping’s retrospective, I wrote it word by word on a sticky flipchart in bold letters and put it in the space so everyone could read it. Then, I proceeded to read it out loud, and even repeated some parts so it would sink in.
Reflecting on how the emphasis on safety in the space fit with Ping’s culture, Zamanizadeh noted, “At Ping, we’ve never believed in the need for brutal honesty, just honesty. This allows for the most candid conversations while still maintaining the highest standard for mutual respect.”
Lesson 4: Bring time into the room
Time is an important character in a team’s story, one that is rarely acknowledged or recognized. Post-mortems tend to focus on failures, while the gems hidden in the team’s successes are often lost. When we are able to show the arc of our work over time, it allows for greater appreciation of the distance we have covered and develop a more wholesome view that includes both successes and failures. According to Suhui Chen, Head of Product at SmartOrg, “People tend to focus too much on issues that came up during their project. And yes, we all want to improve and resolve issues. Taking the time to recognize and celebrate achievement is just as important and it boosts motivation and makes people more resilient to challenges.”
After the welcome, Retrospectives usually begin with the construction of a timeline that shows how work progressed over time. There are many ways to do this, and I like organizing timelines around calendar months. Ping’s team had started a bite-sized iteration retrospective practice every week at a certain point in their development trajectory. This simple practice involved drawing two columns, “What worked well,” and “What needs improvement.” For our major team retrospective, the team created stickies from each entry in the iteration retrospectives and put them up on the wall under the month in which it happened, while also adding any other events that they felt merited discussion. For the months prior to the start of the iteration retrospective practice, the team relied on calendar, email, and memory to fill up the wall with the major events in their development journey.
Lesson 5: Vote Holistically
It is all too common to see life in binaries — success and failure. A retrospective offers us a deeper dive through four juicy questions:
- What did we do well, that if we don’t record, we might forget?
- What should we do differently next time?
- What did we learn?
- What still puzzles us?
The first question focuses us on mining things that we want to continue doing and allows us to recognize, celebrate and enshrine successful practices in the team’s work. The second question explicitly avoids asking, “What did we screw up?” Instead, we are asking an appreciative question driven by the prime directive around what we would do differently next time so that we don’t get into the space of feeling like we are under a personal attack.
The third question “What did we learn?” is about recognizing new capabilities that have developed in the team. By making this visible, we are giving members of the company outside this team the opportunity to understand and incorporate these new capabilities in the company’s strategic decision-making in other areas.
The fourth and last question is a delightful one. “What still puzzles us?” allows us to be honest about what we don’t know so we can hold space for true inquiry. Some things initially seem like they fit in the bucket of “what we need to do differently next time,” but upon deeper reflection, are puzzlers. This nuance allows us to nominate the biggest puzzlers as learning projects to be worked.
Examining the timeline from the lens of these four questions allows people to view the same event from multiple perspectives. It also demonstrates that the same event can have different interpretations. Once the timeline was complete, I asked all team members to walk up to review each post-it and vote for the ones that mattered to them for our retrospective dialog using a distinct color, one for each of the four questions.
This process helps in the emergence of a holistic vote, not necessarily from one individual but from the collective wisdom of the team. Sometimes, one person may hold multiple perspectives and vote differently on the same item. For instance, there may be a “what worked well” vote along with a “what did we learn” vote going together, or a “what worked well” and “what still puzzles us” for something that has seen incremental progress.
Lesson 6: Dialog, not Debate
Once the voting concludes, we have a pretty clear picture of the items that have the most juice in the community. The team can also guide the facilitator as to post-its that look different but are surfacing the same issue.
The facilitator can then open up the floor on each of the topics and serve as a note taker, listening for insights and assigning the insights to the corresponding question bucket where they fit best. Holding space for dialog is different from debating. People take turns to talk and do not talk over each other. Most importantly, they listen deeply to each other, receiving what is offered before making their own offering. With the awesome team at Ping, this was a breeze. They have a beautiful culture where the team holds a deep respect for each other. When there are contentious issues, and a free-for-all is possible, a facilitator can keep a bag of tricks, like a talking stick that participants must have in their hand before they speak. This introduces a healthy pause and encourages patience in the conversation.
Great dialog happens when people feel safe to be vulnerable. Gupta notes, “No matter who you are in the crowd (Manager, Founder, Engineer), don’t be afraid to set the tone and empower others through your own vulnerability. Being open about where you think your shortcomings and strengths are helps others and the retrospective achieve its goals.”
By the time we were done with our dialog, we all felt deeply energized and inspired. Four posters were filled up with insights.
Lesson 7: Deepen Relationships
A great benefit of a retrospective done right is deeper relationships between team members. Whenever thorny issues arise, they are an opening for a breakthrough. When one leader worked three nights in a row, it had an effect on the rest of the team. This showed up on a retrospective poster and was nominated for discussion. This leader heard from other members that they wanted to shape up so he’d never have to do that again. Can you imagine how supported he felt by hearing this from his team? Retrospectives are a great opportunity to make breakthroughs in empathy.
Lunch breaks are an opportunity to deepen relationships even further. In our scheduled four hours, we took a break for lunch over which senior members of the team paired up with new members with the charge of interviewing each other about their life and adventures. When we got back in plenary mode, each person shared something fascinating they learned and it heightened caring all around.
Reflecting on the overall process, Chen says, “No matter how big or small the retrospective is, the most important thing is to keep communication open. Taking the time to establish relatedness following check-in protocols and patterns from Primes helps us lay the foundation for open communication. This allows us to focus on thorny issues instead of pointing fingers. What happened is in the past, and we can only focus on what to do next.”
Bordas echoes this sentiment when he notes:
“We build software and we’re always improving it. It’s valuable to look at your team as something that should always be improving, along with your software. Retrospectives help you increment your team’s major version number.”
Zamanizadeh adds, “At a startup, you’re often only looking forward in preparation for the next challenge. It’s important to pause and also look backward because that is where many of the learnings are. A retrospective is designed to shed light on those learnings and that can be invaluable for a team.”
Is it time for your team to pause and learn from the past to fuel the future?
Further Reading
- Project Retrospectives: A Handbook for Team Reviews by Norm Kerth
- Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby
Diana Larsen, Goddess of Retrospectives, gave me the privilege of learning by observing a master, and Benny Sadeh was my co-conspirator in learning retrospectives. Thank you Joshua Kerievsky for creating that context and for including Retrospectives as an essential part of the Agile Software Development process. A big shoutout to my SmartOrg family that joined me in so many retrospectives and continue that practice for its tremendous value. Thank you to Suhui Chen at SmartOrg for permitting me to share our older retrospective posters. Thank you Janesh Gupta, Matt Bordas, Kourosh Zamanizadeh and the awesome team at Ping for inviting me to facilitate the retrospective and for supporting this article.
