In the movie Rashomon (1950), four characters tell their versions of a samurai’s murder: a bandit, the samurai's wife, a woodcutter, and the samurai himself. Each person tells a different story of what happened, influenced by their own interests and motivations. The bandit claims he killed the samurai in a duel, the wife says she killed her husband in a fit of passion, the woodcutter spins a tale of the bandit and wife conspiring together, and the samurai claims he took his own life out of shame.
The Rashomon example highlights the fact that retrospectives usually are a result of different perspectives and interpretations of events. Put into the context of a work environment, one person can feel a project was a resounding success, while another can think the complete opposite. The "truth" often lies somewhere in the middle. The purpose of a retro is not to determine who is "right", but to piece together a more complete and nuanced picture that takes into consideration everybody’s perspectives. The result is that teams can identify areas for improvement and make more informed decisions moving forward.
Personally, I’m a big believer in the power of retros. My background is in technology. I've been passionate about technology and product development from a young age, studied computer science and spent many years focused on product planning and prototyping - not the Figma or Sketch prototyping we know today, but rapidly building working code to get products in front of customers for feedback as quickly as possible.
Over the years, I progressed into product leadership roles at various companies - leading the product team at Et Hadaat (aka Time to Know), eventually serving as CEO and growing the business to a successful acquisition. After that, I decided to go back to my roots as an entrepreneur and product builder. As an entrepreneur, you have to build, test, learn, adapt, and repeat. For the last “adapt or repeat” part, you have to think critically if you have the right information to make the right decision. Over the years, I've discovered that conducting retros is a powerful way to strengthen collaboration, improve performance, and maximize growth.
Two Paths of a Retro
We can divide retros into two main paths:
1. Team-centric: These retros focus on improving our own performance, learning from each other, and more.
2. Product-centric: These retros involve analyzing why a particular feature is working or not, and determining the next steps in its evolution. The goal is to find success/failure events that we can learn from
Keep in mind that for any retro to be successful, it’s important to consider the following:
Culture: You want to reinforce values like transparency, openness, and a commitment to learning, encouraging a process of continuous improvement.
Knowledge Sharing: Retros should provide a comfortable forum for team members to share their thoughts and experiences. This is especially valuable in a startup environment where everyone is wearing multiple hats.
Giving Everyone a Voice: Everyone should have an opportunity to contribute and be heard. This is essential for building trust and alignment within the team.
Truth's Relativity
When conducting retros, it's important to consider the state of mind of the person you're talking to. Someone on your team may tell you what they think you want to hear, rather than what actually happened, so try and create a neutral environment where people feel that they can be honest.
Also, be aware of cognitive dissonance - the mental discomfort people feel when a contradictory belief or action doesn't align with their values. For example, if a team member believes they're a great communicator but their actions suggest otherwise, they may struggle to acknowledge this discrepancy. As a facilitator, it's important to create a safe, non-judgmental space where people feel that they can confront any inconsistencies that may come up.
Approaches to a great retro meeting
When it comes to conducting a retro, there are two main approaches you can take:
The Detective Option
This approach is favored by many entrepreneurs, because it focuses on gathering objective evidence. The key here is to be methodical and use evidence-based research techniques to inform decision-making. Collecting and organizing data is crucial to forming a comprehensive and accurate picture of the situation.
The Empathic Option
In contrast to the detective approach, an empathic retro is based on building trust and understanding through open dialogue. The goal is to create an environment where people feel safe to share their honest perspectives and experiences. It's important to note that empathy is not the same as sympathy. With empathy, you're not necessarily agreeing with or condoning the other person's actions. Rather, you're seeking to understand their point of view and the context behind their choices.
How to think about retro
One helpful framework here is the "Theory of Minds" - the ability to put yourself in another person's shoes and see the situation through their eyes. By doing this, you can often get to the root of an issue more quickly, because the person feels heard and understood.
Empathic retros can be particularly useful in conflict resolution. By approaching with genuine curiosity and care, you can disarm defensiveness and get to the heart of the matter together.
Then, there’s the research process. I like to break this part into three stages:
1. Diagnose: Understand what happened, without passing judgment. Focus on gathering facts and piecing together the sequence of events.
2. Discussion: Explore the underlying factors that contributed to the situation. This is where you can start to dig into motivations, challenges, and thought processes.
3. Next Steps: Identify alternative actions that could be taken to address the issue going forward. Encourage the team to brainstorm solutions and take ownership of the next steps.
Feedback vs. Retros
It's also important to distinguish a retro from regular feedback. Feedback is more immediate and focused on improving execution at the moment, whereas retros are a deeper dive aimed at driving long-term change and performance improvements. I often think of feedback as "knocking on the door," while a retro is more like "opening the door and exploring what's inside."
When providing feedback, I try to follow a few key rules:
Only give feedback to those who ask for it. Unsolicited feedback can often feel like criticism and put people on the defensive.
Always frame feedback as an opportunity to help the person improve and succeed. The intent should be constructive, not punitive.
Be specific. Focus on behaviors that can be changed. Vague or general feedback isn’t actionable.
Empower the receiver of your feedback to come up with ideas for improvement. This helps promote a greater sense of ownership.
Summarize your main points and reiterate the fact that the goal is only to benefit the person receiving the feedback.
Retros at Jux
So how do we put these principles into practice at Jux? One way is through our open Slack channel where we all feel comfortable communicating "topics for the next retro". This makes it clear to everyone what will be brought up in the next retro.
We're also committed to making retros and feedback core parts of our culture. By creating an environment of openness, empathy, and continuous learning, we try to strengthen collaboration between our product and development teams, and ultimately deliver the best possible experience.
One of the key ways we're facilitating this is through the product itself. Jux is designed to give designers more direct ownership over their ideas and designs. We enable them to make changes and see the results in real-time, in the production environment, without the typical bottlenecks and back-and-forth with development. At the same time, Jux provides developers with clean, structured code that feels native and familiar, making it easy for them to integrate and build upon. By bridging this gap between design and development, we believe we can create a more intuitive, collaborative workflow that benefits everyone.
