In the past five years, rock climbing has ridden high atop the wave of newly expanding fitness activities, and distinguished itself as a hip way to stay in shape. Climbing has lured people of all backgrounds and professions, and created communities of enthusiasts who are eager to break the monotony of the traditional gym. Routes up the climbing wall have a wide range of difficulty grades, and require a type of physical problem solving that is absent from weight training. In fact, even climbing terminology reveals that problem solving is a core part of the culture. Paths up a wall are often referred to as "problems", different types of hand and foot holds have specific, technical names, and the Glossary of Climbing terms Wikipedia page has hundreds of terms that I've never even heard of. It is no surprise to me that so many technically-minded people have adopted climbing as a hobby.
I think climbing has more to offer than helping you get ripped. Since I began climbing in college, I've learned a lot about problem solving from observing other climbers, thinking critically about my own technique, and receiving great advice. Moreover, many of these lessons have reverberated with elements of our engineering culture at Flatiron. In this post, I'll lay out a few observations from climbing that have made me a better engineer, and detail how Flatiron has built processes and adopted values similar to those of rock climbing.
Strive to preview the route
Some of the best climbers spend several minutes before each section of a climb looking ahead at how they might overcome the next set of problems. They estimate how much effort the section will require, create a plan for navigating the holds, determine what gear will be required, and importantly look for the next place to rest and reassess.
When I started climbing - much like when I started working as an engineer - I had a thoroughly naive planning process. I would walk up to a problem, throw myself onto the holds and head right up until I found myself stuck and confused. By watching other climbers, I have developed an appreciation for planning and estimation. Investing more time up-front towards thinking about the nuances of a problem can reveal new ways of solving it that may be drastically simpler and reduce technical debt in the long run.
At Flatiron, "design documents" are one way that we structure planning and estimation without sacrificing velocity. Engineers may write a design document for anything from a small feature to a large system, with the goals of planning out a solution, communicating with other teams, and soliciting 30% feedback. Writing design documents, even for seemingly trivial features, has forced me to think through my plans more rigorously. Sometimes, a design document leads me to change my approach to a problem altogether.
Be self-critical
In climbing, as in life, the difficulty of a problem can be mitigated by implementing a more effective technique. I have often spent twenty minutes failing to get more than half way up a route only to watch another climber casually climb the whole thing forward and backwards by making a slight alteration to my approach. Strength is certainly a factor in some cases, but more often, the other climber has a better sense of technique - shifting her weight gradually and using holds in non-intuitive ways.
Watching the elegant technique that other climbers employ to solve certain problems has inspired me to be self-critical of my methodology. Over time, being self-critical has helped me develop the intuition to recognize when I powered through a move to compensate for sloppy technique, and how I could have solved a problem differently.
Being vocally self-critical is actually one of our core values at Flatiron. This value can manifest during a monthly retro, an incident post-mortem, or even on a casual whiteboard design session. I am always impressed by how my colleagues are able to avoid getting attached to their ideas and ask "what are the drawbacks of this design?" The culture of vocal self-criticism has helped us re-visit stale processes and designs when we otherwise may have accepted the status-quo.
Design human-proof protocols
Climbing can be a dangerous activity. There is an undeniable risk in being held 50 feet above the ground by harness and rope, secured by nothing but your trusty college buddy. This risk multiplies when you leave the gym and head outdoors, where you must set up anchors and tie knots on your own, rely on your teammates, and navigate uncertain holds.
In order to mitigate this risk, the climbing community has developed a variety of safety protocols with the goal of human-proofing the activity as much as possible. Critical climbing gear like carabiners almost always have a safety, such as a foolproof locking mechanism. Load bearing anchors are often set up with 2x or 3x redundancy. Most importantly, even the simplest activities that require communication have a defined checklist or set of commands. For example, the belay protocol defines precisely how to communicate as one teammate secures the other while ascending a wall.
Rock climbing is undoubtedly safer because of protocols that avoid human mistakes. Learning about climbing protocols has helped me realize the value of automation and checklists for engineering operations. One protocol that has helped me avoid countless mistakes is Flatiron's culture of creating on-call and deployment playbooks. Our playbooks have been a safety net for me during my first months in the on-call rotation; they have helped us on-board team members quickly and expand our bus-factor; and they have served as documentation for various systems and their dependencies. A culture of playbooking aggressively has helped us work towards our goal of being able to easily train our own replacements and strengthen our resilience as a team.
Climbing has helped me learn a great deal by overlaying physical and technical problem solving. I'm grateful to the many mentors I've had at the climbing gym, and also to the great mentors at Flatiron!
