Is Your Studio A Mountaineering Disaster?

My climbing partner JP faces Looking Glass, ~500 feet of dimpled granite. 

For all of those that don't know, I'm an avid rock climber and mountaineer. I've spent weeks at a time all over the east coast placing pro in offwidth cracks, rappelling down granite faces, and clipping the occasional bolt. I've also climbed Pico de Orizaba and La Malinche and several smaller summits.

My main climbing partner is JP, an enterprise software architect, a cock-sure, experienced Java developer with dozens of projects under his belt. I, on the other hand, am a slightly more cautious gameplay and animations engineer more recently out of college. So, as you can imagine, we chat about building software as we prepare our rack for the morning climbing and plot to take over the world (something he has already started, having recently launched his own startup) while passing camp hooch around the fire.

Over the past year and a half, I have worked on two amazing, triple-A first person shooters. I've had the pleasure of experiencing very different organizations with vastly diverse cultures. I've witnessed the grizzled, experienced veterans and the slightly newer, shinier, not-yet-proven team. Additionally, I finished a degree in computer science and, in doing so, led a team of nine software engineers for a year in the development of a video game engine for Creo Ludus Entertainment. 

While hammering on some of Unreal's innards the other day, I had an epiphany about how I view projects. Now, I'll give fill disclosure, I'm a very, very process-oriented individual that has informally studied countless different sources. One of my good buddies is a SixSigma green belt and huge proponent of Lean; so, my view comes from an amalgam of these influences. 

So, what is "the view"? Well, it's that a project is like an expedition.

The basic results of an expedition are pretty apparent:

I think you can see the point. Mountaineering is a risky venture, one that can't be taken lightly.

To have a successful expedition, you need:

Respect

When individuals on the team don't respect one another, teamwork and discipline break down. The instant that respect is lost, mistakes are made that will forever haunt your expedition.

JP and I were looking at the tall, long, run out expanses of Stone Mountain, a frightening slab of granite in North Carolina. Between pieces of protection, there are easily 20+ feet of run out. That means the potential for 40+ foot falls.

He looks at me with a smile on his face. "I think we should change the teams up." Up until that point, I had been climbing with JP. The two stronger, less experienced climbers had been together, with JP and me making slightly faster time due to our good dynamics, ease of communication, and familiarity.

I trust his leadership and respect him, so we have a quick discussion about it and do exactly that. I'm put as the second of one of the stronger climbers, even though I have more lead climbing experience. JP's plan makes sense to me. It's simple: I have rescue skills and the stronger climber doesn't. In a pinch, if she were to be knocked unconscious after a hard fall or hurt, I could rig something to perform an emergency rescue, she couldn't. It makes sense. It's a risk, one that I'm willing to take, but it makes sense. 

Communication

Rock climbing has relatively standardized commands for running over routine elements (on belay, belays on, climbing, climb on, off rappel, off rope, off belay, on you, that's me, etc.). There's a common language spoken with understood words that are as simple as can be. Rope teams have their own sets of traditions and understandings that are expressed rapidly and uniquely.

No one is afraid to speak up. It's your life at risk, after all. If something wrong is happening, not voicing your opinion could lead to your death. I've been on an expedition where I didn't expressly say, "I think we should camp at 12,000 feet before moving to 14,000 feet" and, as a result, we didn't make it to the summit and one of my climbing partners got acute mountain sickness. I'll tell you that story (involving me helping my severely ill partner descend 3,000 feet down steep ice, getting off track, and nearly climbing out over the void) if you buy me a beer sometime.

Ownership

You are the team medic. That is your duty. You make my team no longer ill. You are god of "this man is too sick to climb." We respect you and follow your word.

You are the team's best climber. You have first dibs on summiting; but, you also are most responsible for the safety of the team (rescue attempts, etc.).

On the team, the strengths of each individual is known and respected. They own that domain. There is no question. On my Tennessee trip, JP was the most technically advanced climber, Matt was the strongest physically, Joanna was the second strongest, and I was the most first-aid knowledgeable and second most technical of the climbers.

JP picking out the tools he'll need to lead Looking Glass. There are a lot of options; but, having a firm grasp of his own ability and the purpose of each component, he can easily build a rack that will see him to the top. 

But, what happens when...

Okay, so, that's a summary of how the "personal relationships" are. It doesn't speak about how decisions are made, situations handled, etc. All it does is set a framework in place that allows problems to be solved, instead of remaining there. In climbing, there's a culture of "speak up." It's your life. Speak up!

This, coupled with respect for your climbing partners and your ownership/mutual understanding of abilities, acts as a catalyst for problem aversion. But, what happens when a problem occurs?

First, you have to identify the problem. I have two examples:

Communication breakdown 

JP and I were 250+ feet up on Looking Glass, climbing a traditional route that involved him placing gear as he ascended, building an anchor from bolts, and then belaying me up as I cleaned the pieces. Our rope was 60 meters in length (180 feet), and the climb was gently curving.

As I watch him, gusts begin to come in, hard and heavy. Quickly, my senses are overpowered as I pull myself into the thin layer of hardshell I brought, hood up to keep dust out of my eyes and the chilled bite of the wind at bay. I delicately put my face against the tight weave of my bluewater rope, feeling for the faintest hint of a pull. The tug comes and I let out more slack for JP as he leads.

Then, without warning, two hard pulls follow and I instinctively lock off. Either JP has just fallen a bit, or he's done something we hadn't discussed, but I rapidly figure out what he's doing. The wind was roaring at that point and my voice and his were easily drowned in the tumult. I take the device off the rope just as it's pulled quickly up, JP having secured himself to an anchor.

As it's my turn up, I progressively tug on the rope, a single, long pull, and any slack that remains is quickly taken in. 

It's an old trick, one I hadn't known at the time. But, JP tried it, knowing that I've always been a quick study. It worked out. I successfully made it to his belay position without incident, smiles on both of our faces. Disaster averted due to quick thinking on both of our parts.

I knew JP would never put me in danger and I understood the process of climbing a route well enough to evaluate how the rope was acting at any given moment and what that meant about my climbing partner. This understanding led to us successfully completing that pitch of the route.

Loss at 400 feet

Mistakes happen. What's important is understanding that any misdirection can be solved, as long as it's visible and acted upon immediately.

At 400 feet, JP had climbed off route and created his own hook up to another route. In doing so, we were now climbing side-by-side with our other rope team. There was a problem that was almost immediately apparent.

The leader of that rope team had managed to drop her belay device. Without one, she didn't have the proper training (which JP and I both did) to create an impromptu belay device (see: Munter hitch). JP and I quickly discussed what to do.

I put him on belay and fed out slack as he got as close as he could. JP and I had a second rope with us for doing a double-rope rappel (a way to make our descent faster) and he quickly untied it and prepared for a rapid rescue. He tied a knot into the rope for weight and tossed it over.

The leader of the other rope team caught it, JP tied a butterfly to it and clipped his backup belay device. Quickly, she pulled it over and, after a few minutes of clean up, we were all in the green again.

JP sending a rope over to transfer a belay device at ~400+ feet on Looking Glass

Okay, okay, I see... But, what about...

A few more analogous elements:

Me! Resting on Looking Glass after having followed JP up a crazy link up pitch that combined two different routes. While waiting for our other team to catch up, we chowed down on some homemade energy bars.

Hitting the glacier on Pico de Orizaba. Taken at 17,000 feet, just as my climbing partner got ACM.

In summary, a successful project might not be the death-inspiring act of mountaineering, but it can benefit from the several hundred years of evolution climbing has gone through. While process and management are well documented, instilling the same fear that crafted these practices as an 18,000 foot volcano in Mexico is rather difficult. That being said, fear isn't required to learn from them.

As developers, it is our responsibility to learn from as many sources as we can, be it a hospital's implementation of Lean or a climbing team's successful process for assaulting K2. Within all great endevours there are lessons to be learned.

Let's all make our next summit attempt a success. 

Me and JP on our successful summit attempt of La Malinche in Mexico.

About the author:

Andrew Grapsas is a software engineer in NYC. He interned at EALA on the current Medal of Honor and is now employed by THQ's Kaos Studios working on Homefront as a gameplay and animations programmer.

You can read his blog all about crafting stories and writing novels at www.aagrapsas.com. If you'd like to have him write more about process/development, e-mail him and let him know!

About the photographs:

If you'd like to see more, check out JP's flickr account at www.flickr.com/jplikesbikes! 

Edit: Fixed typos and added two more links (SixSigma and Lean).