Parallels between mountain climbing and software projects

Delivering software projects and climbing mountains have a lot in common.

The similarity between the two struck me while I navigated a complex project with some peers in 2022. This article shares some of my experiences of success and failure and explores the importance of people in both endeavours. I will also share some of the concepts used in climbing that may be helpful when delivering complex software; after all, when you are rock climbing a mountain in the “traditional style” with ropes and hand-placed protection, the stakes are your life, so it's generally approached with more care than a software project.

I’d welcome discussion, feedback and other perspectives!

I have also pulled out several takeaway points if you just want to skim-read.

Planning

At some point, you or your friend see a mountain or lump of rock and think, wouldn't it be amazing to climb that?

To give the project analogy, you or one of your colleagues sees an opportunity to build or significantly modify some software and associated business process and think, wouldn't it be amazing if we built that? However, of all the projects to deliver or mountains to climb, only some of them will be attempted.

When choosing a climb, you need to be grounded in the reality of your ability. You may choose to push your ability and climb something harder or longer than you have ever climbed before, but given the high stakes, it’s essential to be realistic. I usually climb as a group of 2-4 people, and it’s crucial everyone agrees on the climb. One of the first places a project can go wrong is when one person makes a judgement call about what other people can do without a robust discussion with them.

Takeaway:

You shouldn’t take your friends rock climbing up the side of a mountain without having a discussion, asking if it’s feasible and sensible for them or not. So don’t start a project without having a similar conversation with the engineers who will work on it.

Predictably

In many ways, climbing a mountain is easier than delivering a project because, more often than not, someone has climbed it before and written down where the route goes and what to look out for. In software engineering, the help and direction are usually a little more abstract, e.g., StackOverflow.

That said, the bigger the climb or, the bigger the project, the less predictable it is. Length gives more opportunity for things to go wrong.

A number of years ago, me and a friend had set our sights on the north face of Lliwedd in Wales.

It was the first cliff in the world to have a guidebook written for it over 100 years ago, and it was where early pioneers of Mt. Everest trained in the early to mid-1900s. Our route required around 250m of climbing, our longest at the time, but was only graded as “severe”, which is not too tricky with modern climbing gear and easier than our limit at the time.

We thought it would be a 9-hour round trip (approaching, climbing and descending), but it took over 14 hours in the end. All said and done, it was a really successful day, but why was our predictability off by so much when we had used two different guidebooks and a map?! In short, a few things happened that we didn’t expect, but they added a lot of time as we discussed how to proceed.

To highlight the lesson, I need to compare this experience to a climb I did on Puig Campana in Spain more recently.

The climb was almost 50% longer and a grade harder. The climbing itself took just five hours vs the eight we spent in Wales on Lliwedd. Whilst luck played a part, a lot of the difference was down to team consistency. I climbed Puig Campana in Spain with the same partner I climbed on Lliwedd in Wales with, only by this point, we had travelled up kilometres of rock together in the time between. We knew each other’s ways of working, strengths and weaknesses really well and have a much greater level of trust. Trust is a hard-to-describe characteristic of teamwork and predictability, especially in an office environment. Still, when teams have both skill and real trust, there is little need to waste time “creating alignment” (i.e. having slow meetings) because the team is never not aligned. Importantly a long-standing team or partnership makes dozens of tiny micro adjustments and judgment calls when needed rather than going way off track and then needing a big meeting to create alignment again.

Takeaway:

Stuff goes wrong. The bigger the plan (project or climb), the more scope there is for unexpected things to happen. Trust and long-standing teamwork and partnerships can really improve predictability. If teams change often, predictability is almost impossible. In climbing, like project delivery, going too fast or too slow can be very dangerous. In climbing, you get stuck on a mountain when the sun sets, or you take risks with your life. In projects, you miss opportunities to launch at a good time, or you introduce tech debt. Therefore, predictability is important but not easily or quickly attainable.

Planning to Fail

Morocco is an amazing place to climb in Winter. It’s dry and warm enough to climb in shorts. The danger is, at night, it’s literally freezing, especially at altitude in the Jebel el Kest mountain range. Being most of the way up a mountain in just shorts when the sun sets, the world goes dark, and the temperature drops below zero will, of course, kill you if you don’t have warm clothes and a headtorch to help get you somewhere safe. However, the more you take with you on the climb, the slower you go and the more likely you are to need the emergency gear.

Part of the magic of traditional climbing for me comes from navigating this planning trade-off: Take everything we could possibly need to stay safe, and it will add 10KG+ to each person’s gear which will mean the team are likely to move slowly, eventually fail and need the emergency gear. Take only the essentials, and the team maximise the chance of success, but the cost of failure in the most extreme example could be fatal.

The analogy to project delivery relates to meetings, status reports, steering committees, change approval boards etc. If you add ten hours+ of admin needed each week in report writing, issue logs, risk registers, status meetings and steering comities, the project will take longer. I don’t just mean ten hours a week longer because, of course, these meetings generate vast amounts of work and follow-up actions themselves. That said, the meetings and artifacts are there to spot issues and reduce risk, so without them, the project could go badly wrong. Therefore, once again, it’s a planning trade-off.

Recently Mindera were working with one of our more prestigious clients on ways of working. They clearly felt like they were going too slow, but also felt like they needed all the process around every release and struggled to navigate this dichotomy. In Morocco, the balance we agreed was each person taking thermals, a head torch with spare batteries, and I carried a 600g emergency shelter for four people that would, in the event of a disaster, keep us alive (but only just) for a night. We didn’t need any of it.

Takeaway:

It’s important to understand the cost of failure.

Climbing easy routes close to civilisation (and hospitals or at least pubs!) means failure is not too troublesome, and therefore it’s safe to dive in with very light-touch planning. Expeditions to remote mountain locations require much more care and planning and enough safety equipment to keep you alive.

With project delivery, the key is to work out what is just enough process to avoid the worst-case scenarios, diving right in when it’s safe or low risk and doing enough planning where failure is expensive for the business. The concept of having “just enough process” is a helpful one.

Summit fever

Summit fever is a strange psychological phenomenon that applies to projects just as aptly as it’s etymological origin in mountain climbing. It describes a climber’s desire to get to the summit at any cost. It’s usually used to describe poor decision-making that happens when close to the summit. It’s all too common for dozens of climbers to die on peaks like Everest in a single year, not because of freak accidents but because they took unreasonably high risks because they thought they were “almost there”.

I can attest to the fact your decision-making changes the closer you get to the finish line in both projects and climbing. I’ve saw summit fever on a couple of big projects in the last few years; I will use an older example to avoid being too contentious. Back in 2019, when I joined a tech team, we were in the final stages of a nine-month-long project to upgrade the version of the off-the-shelf eCommerce software that was the website's core. The end result was a failed upgrade and over eleven hours of downtime, giving customers a poor experience and costing the business hundreds of thousands of pounds.

Whilst the deployment was always destined to fail, the downtime should have been just a few hours, but summit fever drove the whole company to keep going because they were so close. Ironically big, overly planned Waterfall projects are the most likely to suffer from summit fever in my experience, and all those carefully made milestone plans get adjusted when milestones are missed.

Takeaway:

Humans don’t like giving up when they are almost there.

This means risks we would have considered unacceptable earlier in a project (or climb) start to become okay the closer we are. This “summit fever” can lead to poor decision-making. Being mindful of it and calling it out is a simple way of trying to stay on top of it.

Conclusion – 4 key ways rock climbing can help understand & improve software delivery

• Treat a project or product iteration like a dangerous climb and get all the people taking part brought into the plan from the very start;
• A consistent team with a history of working together will make projects more predictable and more successful;
• Put in place just enough processes to ensure a good balance of speed and risk and so optimising for the best outcome;
• Be wary of summit fever and call it out when you see it happening.