3 Reasons That Blameless Retrospectives Build Trust

Lylan Masterman
Lylan Masterman
Published in
6 min readSep 12, 2016

An Operator-turned-Investor’s Perspective on Highly Functional Startups

Source: https://www.flickr.com/photos/59632563@N04/6239670686 under Creative Commons 2.0

My background

From early 2004 through late 2008, I developed a lot of best practices through professional training as well as trial and error while my colleagues and I collectively scaled Atlas, a division of aQuantive. As part of this education, Atlas brought in thought leaders of Agile, including some of the people who created the agile manifesto, to our office to train us.

Our training & experimentation with Agile occurred before Eric Ries wrote The Lean Startup; he was doing his own trial & error’ing at imvu during those years. It was before Marty Cagan’s Silicon Valley Product Group became a household name among Product Managers. Clearly, a lot less documentation on best practices existed when Atlas started adopting Agile in 2004. But even back then, we had tremendously valuable resources; many of Agile’s seminal books, consultants, and trainers had an influence on Atlas:

  • Martin Fowler trained us on-site at Atlas, each small team at a time, on Refactoring.
  • Mike Cohn trained on us on-site on Planning Poker.
  • Many of us became Certified ScrumMasters directly by Ken Schwaber’s trainings in Seattle.
  • James Shore trained us team by team on best practices on Quality Assurance and optimizing our unit tests. Atlas had eliminated the role of QA (with a few exceptions) and so we relied heavily on pair programming, test-driven development, unit tests, well-written user stories, a rigorous definition of binary-done/done-done, and a high level of conscientiousness by all team members as well as a focus on customer success.
  • Ron Jeffries, the godfather of Extreme Programming, spent a full week with each of our teams at Atlas, one team per week. Then he came back 6 months later and performed another round trip of our teams to give us each feedback on where we had improved and where we were still stuck in our old comfortable ways.

I spent a lot of time iterating and improving our agile processes along with development leads Nathan McCoy, Richard Arneson and Parker Whittle. Thanks guys for your willingness to experiment together. And to the team members who shared with openness and transparency their feelings about our experiments and who contributed their own ideas: thank you for helping us learn collectively!

In all due transparency, I didn’t at the time appreciate the value of this education. I was young and I thought I knew it all through my prior grooming at Microsoft. It was only years later that I truly appreciated the priceless training that we received. We learned collectively how to do Good Agile whereas so many companies struggle with Bad Agile.

The end result: we had incredibly low employee turnover even though other companies in Seattle were hiring very aggressively and tried to recruit our talent. Amazon, Microsoft, Getty, and startups like Zillow, Redfin, and Tableau were all vying to recruit Seattle’s most talented people. The Atlas engineering teams stayed in tact. Many people remained at Atlas knowing that they could earn a higher salary elsewhere. We had a winning culture built on mutual trust and a joy of working together. It culminated with a $6 billion acquisition.

Now that I’m a VC

Not every portfolio company wants an investor to meddle into their day-to-day, so sharing best practices on this platform is a safe place. And there is a larger audience than just the White Star portfolio who might benefit from these best practices. With my operating background as a former software engineer, head of product, head of engineering, and the priceless training I had at Atlas, I appreciate that I have tips to share that might be helpful to entrepreneurs, CTOs, VPs of Engineering, and Product leads at startups.

From time to time, I will share my perspective on best practices that startups can consider adopting. This is my first post in this series of “An Operator-turned-Investor’s Perspective on Highly Functional Startups”

Back to the Topic of this Article

While listening recently to Episode #40 of the Reboot Podcast “Beyond Blame with Dave Zwieback and Jerry Colonna”, I was reminded about one of the most impactful practices that we adopted at Atlas thanks to the training of Ron Jeffries: the practice of blameless retrospectives. The podcast compelled me to write this article and spread the knowledge.

If you’re new to blameless retrospectives, the basics and how-to’s for are covered in many articles, including Etsy’s Code as Craft and Etsy’s forums, Dave’s book and Rally / CA Technologies.

One of the aspects that I most appreciate about blameless retrospectives is that they foster trust. I value trust so much that I discussed the trust equation in this podcast where John Livesay interviewed me (kudos to The Trusted Advisor for equipping me with the vocabulary and framework to discuss trust.)

Blameless retrospectives, when done well, help increase trust in three key ways in an organization.

1. Reliability: You do what you say you’re going to do

  • When a leader says that blameless retrospectives will occur after every iteration/sprint and the retrospectives indeed do occur, the lead demonstrates that their commitments get completed. As a result, the lead is demonstrating a pattern of reliability. PS: the shorter the sprint, the shorter the retrospective (who wants a long drawn out retrospective?)
  • Write down the results where everyone can see them. Agree collectively on areas that can be improved. Work on making those improvements: walk the talk → this builds reliability.
  • It is a leader’s role to explain how a blameless retrospective works; there are some intricacies. It is the whole team’s responsibility to foster a blameless environment. It can take time to build the trust required for such an open candid environment, but over time if the culture of the meeting reliably remains blameless, trust gets built among all of the participants of the retrospective.

2. Intimacy: Generating safety and a “je ne sais quoi” feeling when others put trust in you

  • When the team embraces a blameless culture, a pattern tends to emerge: people increasingly share their true beliefs and they equally appreciate candour from others in the team. A cycle of safety is created, where people understand that all comments, even differing opinions, are meant for the growth and success of the team. This circle of safety creates intimacy.
  • As team members build a precedent of knowing that the blameless culture will not be violated or undermined, they feel safer with each other to be transparent.
  • When someone does assess blame, gently and kindly address it without blaming that person. This again helps foster safety for all parties involved, including the realization that slip-ups will be accepted rather than punished.

3. Managing self-interest: focus on company success and team success over individuals

  • A key focus of blameless retrospectives is to improve the team/company. While companies have many best practices that are focused on the success & improvement of individuals (1x1’s, code reviews, promotions, 360 reviews, etc), it is also valuable to have specific time allocated to the improvement of the collective group.
  • When someone says “my bad” for a mistake they committed, this is still assigning blame. Even if you assign blame to yourself, you are not fostering a blameless environment. Keep the focus on the team.
  • When people are more focused on the team than themselves, you will often see that people are listening to learn rather than listening to reply. When people are not overly anxious to speak, it helps show that their priorities are focused on the collective instead of having their thoughts heard.

Bringing this back to Venture Capital & Entrepreneurs

When I evaluate startups, one of the many characteristics that I look for is management teams that trust each other and trust their subordinates. And I look for leaders who have a history of fostering trust. Trust matters. Consider blameless retrospectives as a tool in your tool chest when you want to build trust in your teams.

My Ask

While I take an engineering angle in this article, I encourage all teams across an organization to embrace blameless retrospectives as an approach to fostering an environment of trust: sales teams, marketing teams, customer success teams, cross-functional senior management teams, etc. The benefits of trust are priceless.

______________________________________

Lylan Masterman is a Kauffman Fellow and a Venture Capital Investor at White Star Capital, an early-stage Venture Capital fund backing exceptional entrepreneurs with global ambitions. www.whitestarvc.com

--

--

Lylan Masterman
Lylan Masterman

Venture Partner at White Star Capital. Canadian-born New Yorker. Kauffman Fellow. CompSci Geek. The y in my name is pronounced as a hard i. www.lylan.com