How to team: lessons in mountaineering and software engineering
I’m a mountaineer and software QA engineer, and would consider myself ‘intermediate’ as a technical practitioner in both disciplines. I started climbing and joined my first tech team 7 years ago, at 27. Never having ever worn a backpack with a hip belt nor written a single line of HTML, I embarked on two journeys that had enough in common that I excelled more in both together than if I had tried each thing on their own. Many lessons from mountaineering applied to technology, and vice versa. The following are comparisons between stages of a successful mountain climb and a software release cycle.
Planning: Trip planning & Sprint planning
Execution: The Climb & The Sprint
You did it!: The Summit & The Commit
Descent: Rappelling & Regression
Expecting the unexpected
Lessons learned: Debrief & Retrospective
Do it again, better
As they say, “off you go!”
Planning: Trip planning & Sprint planning
For a successful climb, planning is paramount. At a high level you want to know:
- Team size
- Team skill set
- Terrain
- Conditions
- Weather
- Gear needed
- Route beta
Team size and skill set is often based around terrain, conditions, and gear. The team should have the skills required to complete the climb and be able to pick out and use the right tools for the job.
In tech, we have similar things to consider when planning:
- Team size
- Team skill set
- The software
- Software dependencies
- Management’s feelings about the project (e.g. support or skepticism)
- Libraries and technology needed
- Discussions about upcoming challenges
As a newer engineer, one of the most useful points is learning from more experienced technologists. This is the mountaineering equivalent to discussing ‘route beta’ with someone who has climbed what you plan to climb. Participating in informational interviews (a.k.a get coffee) and domain-specific meetups can be a useful strategy to find out how others respond to challenges, employ methods and strategies. It’s not at all cheating to get route beta from other climbers, as well as other technologists.
Hearing about other people’s experiences make your challenges easier to plan, and seem much more possible to take on.
Execution: The Climb & The Sprint
Both a climb and a sprint have time constraints. In climbing, you have a mountain to climb. In a software sprint, you deliver software to customers. The climbing concerns of days, daylight, stamina, and technical skill are akin to the concerns of having 10 workdays, stamina, and technical skill of your software team.
Teams in both areas identify members who either a) have or b) have been allotted the time to develop their skills to perform necessary tasks. Ideally , you’ve anticipated rough spots up front. Be them a 5.8 trad route 16 miles into your trip or a gnarly refactor you found out needs to happen half-way into the sprint.
Here are four key activities for both climbs and software sprints:
- Know where you are
Route-finding is a serious mountaineering challenge. This, arguably, can be the most difficult and overlooked skill in the sport. I’ve learned to know where I am at all times. Every junction, look at the map. Ask the questions:
- What cardinal direction am I headed?
- Distance to the next junction
- With the terrain, and my team’s projected stamina, how long will it take to get there?
- What landmarks are coming up?
In the sprint, tracking progress is important to help you understand whether or not you will meet self/company-imposed deadlines.
- Am I making technical choices that will make future choices easier?
- How long do I expect to work on this task?
- With the technology we’re working with, and my teammate’s current speed and endurance, how long will upcoming tasks take?
- What do I expect to see when I finish the task (e.g. a working prototype, passing tests)?
2. “Do the best you can, where you are, with what you have”
This is a saying in my mountaineering club, when it comes to wilderness first aid. First aid is not unlike fixing issues as they come up in a sprint. An unexpected issue arises, and things are taking longer than you might think. There’s a whole section on ‘Expect the unexpected’ below, that expands on this point. But I say this here because: your team is your team. You’re on the trip together. Make the best of it, work with the utmost integrity, and don’t kill yourself, or each other, in the process.
3. Anticipate where you fit in to upcoming challenges, but adapt as necessary
On a team, each person has their own strengths. Many of our skills overlap, but in any given moment, you might want to plan who is going to lead, and who will assist.
Sometimes, the leader or the assistant will be busy, or unavailable, when the anticipated challenge you planned comes up. That’s when it’s time for you to step in, exercise your own skills, and trust you’re ready.
Most recently, on Mt. Washington in Oregon, I was neither a designated leader or assistant, but welcomed as a skilled team member. We were on the descent where the folks ahead of me were setting up the final rappel to the summit block. The wind ripped through the saddle. My teammates before me tried throwing the rope three times, each time it caught on the ragged, unforgiving red and rough volcanic rock below. When I reached them, and even though I wasn’t ‘supposed’ to manage this, I knew how to check the anchors, re-set the carabiners, coil the rope in saddle bags, and rappel down, feeding the rope through my harness so the wind wouldn’t be a factor. So I did it. With the checking and rechecking of my work with my teammates, for safety. It wasn’t against the rules to get the job done. And while the team could have descended without me, I made it faster, and more pleasant.
In a similar vein, I recently helped with a project to ship a microservice to a customer who downloads our software, but we haven’t made that microservice available to all customers who download our software. Working with senior engineers, myself an associate, it turned out I was the first to have virtual machines ready to work on this proof-of-concept. While I wasn’t the leader, or the assistant, but a member of the team, I helped create, and prove out, the deliverable worked. In the end, I wrote out the documentation and helped lead QA and customer-facing teams to understand how the system worked so they could interface with the customer. While neither the tasks nor roles were initially assigned to me, and the job could have been done without me, I made it go faster, and …yes, more pleasant.
- Communicate
On the mountain, you need to communicate your flight plan. This is the plan between climbers for what they’ll say to each other at each pitch. Talking through the route and its dangers. Speaking up if you have a blister or are hungry.
In software, discussing your current progress, even if you think what you’re saying is redundant or a given, is invaluable to your team, and management. It also gives you practice at communicating your choices, and gives others the opportunity to provide feedback at each step.
You did it!: The Summit & The Commit
These moments are what you’ve been working so hard for. You did it. You did it!
You climbed a mountain!
You merged your code into the engineering team’s common repository (e.g. master, develop)!
You can take a breath, enjoy your hard work, and feel on top of the world. You earned it. Have a snack! Go to the bathroom! Peeing on a mountain or attaching my name to a commit gives me the same satisfaction. As long as the glaciers don’t melt or the software doesn’t get thrown out, your signature, biological or virtual, is forever!
Descent: Rappelling & Regression
They say climbers are the only sportspeople that celebrate their success when they’re only half-way done. I’d argue tech people are pretty similar in that regard. You’re still on a mountain and your code hasn’t yet shipped to customers.
It’s going down.
Rappelling
BARK is an acronym for Belt, Anchor, Rappel device, Knot. Use BARK to check critical pieces of equipment for failure points when you’re ready to rappel. By ‘ready’ I mean, you’re doing it, you do not live on the mountain. If the belt of your climbing harness is not buckled, it will fall off under load. If your anchor is not secured, it will buckle under load. If your rappel device does not have the rope going through it, you won’t be anchored to the rope. The knot at the end of the rope will prevent you from rappelling off the end of that rope.
ANY TIME YOU MAKE A CHANGE TO YOUR EQUIPMENT, YOU HAVE TO DO THE CHECK AGAIN.
If someone distracts you while you’re doing your safety check? Do it again. Did you go to the bathroom on your way up, taking your harness off? Check your belt. Do you trust the person who set up the anchor, but are they hungry and aloof? The checklist is a fail-safe against the absolute worst-case scenario, even if you and your team are seasoned climbers.
Critical Product Scenario
The Critical Product Scenarios are important to test when you change anything about your product. The CPS represents the touch points in the steps a user takes to accomplish something with your software. Let’s say the user wants to buy something.
ASAP is an acronym for Authenticate, Select, Add-to-cart, Purchase. Hey, that’s clever! Did I make that up? Anyway, with every release of your software, you need to regression test, or check your critical product scenarios for potential breakage. If the user can’t log in, they can’t save their cart. If they can’t click a link to the product, they can’t see it. If they can’t add it to their cart, they can’t buy it. If they can’t pay you, you don’t get paid.
ANY TIME YOU MAKE SIGNIFICANT CHANGES TO YOUR SOFTWARE, YOU HAVE TO CHECK CRITICAL PRODUCT SCENARIOS.
The reason I use all-caps is because it takes time, but you just can’t mess them up.
Sorry-not-sorry if this task takes longer than your team wants, your managers, your product owners. Your users need you to make sure these user flows work every time. If they don’t work, actual people doing actual work with your software are screwed.
Expecting the unexpected
The difference between people I want to climb and develop with, and the people that I don’t, is their approach to the unexpected.
It’s very easy to be irritated or angry or afraid or fail to be in control when things feel out of control. I get it! I can be that way too.
Being on the mountain, when something unexpected happens, you have to “do the best you can, with what you have, where you are.” I said it before, and it bears repeating. You need to ensure your own safety, the safety of your team, first. In software, you try your best to understand the consequences of the code you’re writing, but sometimes it interacts with services, libraries, users in ways you didn’t expect. You have to take care of your software, your users, and the emotional safety of your team members when your plans are interrupted.
If you’re approaching something you don’t understand, go back or take it slow if you have the luxury of time. You can always return to basecamp, or stop your work progress, do more research and try it again.
As a responsible team member, please consider the following when things get tough:
- If someone makes a mistake, help them
- If someone doesn’t know what to do next, help them
- If someone doesn’t understand core principles you thought they did, help them
- You are going to need help some day
- Everyone does
- If you need help, you have to ask for it
Lessons learned: Debrief & Retrospective
‘To learn’ is to know something now you didn’t know before. Or to do something that didn’t work, and understand why, and do something different next time.
Both after climbs and software sprints, the team does a debrief a.k.a retrospective in order to learn how to improve.
What went well?
- Comradery
- Good attitude
- Seamless transitions
What went wrong beyond our control, and how did we respond?
The weather turned at 10,000 feet, seeing a lenticular cloud growing with the wind turning up. We turned back, even though we all traveled 10 hours to get here. Proud of us for making the right decision.
The frontend refactor broke the styling of another part of the application. The logic was so convoluted we couldn’t justify the time it would take to make the styling consistent and functional across the system. We had to stop. It was a hard decision, but we had to move on. We documented the issue for a future team to manage a frontend overhaul.
What did we learn?
The approach wiped us out more than we thought it would, so it took 10 hours instead of 7.
By trying to move quickly, we made technical decisions we had to back out of because we could not make them work in time.
How can we do better?
We will train more in advance and bring much more food.
To avoid making faulty technical decisions, we’ll justify doing more technical dives, so we know what we’re getting ourselves into before we jump in.
Do it again, better.
You’re going to climb more mountains. You’re going to release more software. You’re going to be a better climber, you’re going to be a better engineer. If you keep doing it, with people who can teach you and who you can teach, and be open to learning, you’ll get better. And while I believe everything I wrote, understand I will always be challenged, sometimes we come up short. But we’re learning. That’s how succeeding in mountaineering and tech works.
Thanks for reading! Remember, leave no trace out there! Pick up your garbage, and please delete old unused branches. :D
