I think that some of the approaches that I have used to get better at mountain climbing can be applied to software engineering with a similar effect.

Discuss every day work

My climbing partner and I have a practice at the end of each climbing day: we talk about the day. This started as a way to spend our post-climb waking hours productively by persisting the experiences in our memory. We often have multiple hours of hiking, traveling, and/or resting before sleep. We start by verbally describing as many details as possible, riffing off of each other as we go, sometimes asking probing questions. We talk about the turns on the hike in, as many nuances of the climb that we can remember, how we were feeling during parts of the climb (nervous, tired, engrossed, etc), what we liked, what worked well, what was hard (we’ve both described how following -- not leading -- can seem much more challenging and scary), what mistakes we made, what workarounds we employed, what risks we took, what we’d do differently if we repeated the day, what could have been worse, etc. If it happened today, it could happen tomorrow.

Over time, I have come to realize that these conversations do much more than simply help us memorialize our joyous adventure and pick up a few climbing tips. Having these conversations teaches us about each other’s challenges, mindset, stressors, fears, skills and limits. These conversations allow us to practice storytelling, describing and providing context. We practice listening, acknowledging and eliciting deeper information from each other. We demonstrate our ability to understand, support, reciprocate, sympathize and empathize. Having these conversations enhances our psychological safety and builds trust. We’re more comfortable and effective at discussing goals, fears, mistakes, and risks. We’re more ready to handle future challenges together. Because we discuss our days, I think that we’re a better team.

Software teams do not have the luxury to spend an hour or more at the end of each day to discuss each person’s day in detail. However, software teams do make time to review recent work throughout the day and in meetings like daily standups, sprint retrospectives, monthly business reviews and other ceremonies. 

These work review ceremonies are all opportunities for software teams to

• Understand who can contribute in which ways
• Share difficulties, surprises, fears
• Learn how success occurs despite difficulties and surprises
• Practice communication and coordination
  

All of these activities are investments towards a higher performing team that is more equipped to handle both planned and unexpected work.

Learn from incidents

I have only been involved in a few memorable incidents in my 4 years of climbing. After these incidents, we talked about what happened, what could have been worse, how to mitigate risks in the future, etc -- pretty similar to what many software teams will do after an incident. However, while direct experiences with injury are memorable and instructive, I’d rather not wait for personal climbing accidents to learn -- the stakes are too high, and at least in my case, the frequency is very low. 

The climbing community has some very helpful accident resources:

• Since 1948, the American Alpine Club has put out an annual publication called Accidents in North American Climbing which “documents the year’s most significant and teachable climbing accidents. Each incident is analyzed to show what went wrong, in order to help climbers avoid similar problems in the future.” The compilation contains written descriptions and analyses of accidents from a variety of people, situations, locations, and styles of climbing.
• Ashley Shaupe created The Sharp End podcast in 2015 to “minimize future outdoor accidents by way of storytelling, [... ] shift our way of thinking about accidents and intentionally create a culture that allows people to share their stories, judgment, shame, and guilt-free.” By way of conversation with people involved in accidents, the podcast serves a personal story which often comes with more emotion and messy details which make them more memorable to me than the analyses from the Accidents book.
  

Both are deep wells of insights for climbers to learn from others. I learn about risk management techniques like tying stopper knots when rappelling and avoiding the High Sierras when there are clouds overhead. However, I also learn about how climbers plan, communicate with their team, and generally succeed at many of their steps along the way. Both Accidents and The Sharp End have accelerated improvements in my overall climbing performance, not solely my “climbing incident management” performance.

What the software industry can learn from the climbing community

In the software industry, we’ve already been gaining perspective from incidents for years. And, year after year, we keep getting better and better. 

Imagine a team standup or sprint retrospective which talks about fears, workarounds, and mistakes. Imagine that software incidents were shared through stories with emotions, and shared publicly. Imagine the insights we’d gain and how that might make us better at our craft.

Here are a few more ideas to continue upleveling the software industry, based on my experiences learning how to climb mountains:

• Discuss every day work to learn tips/tricks and gel as a team. Getting better at every day work makes you more prepared for future incidents. Getting better at every day communication makes you a better communicator during incidents and after incidents.
• Foster community, psychological safety and trust in teams and across teams/organizations/companies. In climbing, accidents are shared publicly for the broadest possible education.
• Incidents shared more broadly (and even publicly) provide more people the opportunity to learn. So, share your incident with other teams in your company, and with other companies!
• Interviewing incident responders and stakeholders allows them to share their personal experiences and tell their story. Represent these stories in group review meetings, writeups, or recorded productions.
• Shift from boring analyses to engaging incident stories, with multiple personal perspectives, context building nuance, challenges, and emotion, to make them easier to remember.
• Publish collections of incident stories. A consolidated publication maximizes reach by nearly eliminating the discovery step for readers -- they only need to learn about the collection, not separately about each individual story. These could be really helpful to a new colleague who is onboarding or the majority of colleagues who won’t have enough time in their day to follow along every incident as it unfolds.
  

In the climbing community, these approaches have saved countless lives through broad and effective education, and accelerated my own climbing progress. If applied in the software industry, imagine the insights we’d gain, how that might make us better at our craft, and how we might just be able to climb any mountain, together.