It started like any other Friday. However, at midday, in what was supposed to be an innocuous group sync about a current priority, one person silenced the group with the declaration: “I feel really surprised by this update. Actually, I feel upset, excluded, and disappointed.”
The meeting ended awkwardly and without resolution. Soon after, everyone was sending direct messages to each other trying to process what happened. The day didn’t recover; it finished with an already scheduled retrospective where people were full of thoughts and questions but nothing was shared aloud. Two people left for the weekend questioning whether they were at the right company, and everyone spent time and energy thinking and worrying. For our startup, this was a fundamental system failure. In the same way that a severe service outage, database failure, or code defect can grind a team to a halt, the impact of what transpired was massive, and we needed to find a fix. Unlike a problem with a database, there wasn’t a magic patch or update to solve the issue. In this talk, we’ll share how we planned and executed recovery work. We needed to apply systems thinking to people problems and navigate discussions that helped us each feel heard and understood. Our aim is to inspire you to consider a systems approach when something with your team goes wrong, and we’ll provide a template for what we think worked well.
