“You have to go slow to go fast." and Speed is safety”

Both of these phrases are oft-quoted in software. Each have individually been well-explained by better writers and engineers than me, but I think the combination can get confusing when we talk about innovation and building new software systems.

The best metaphor I have for this is downhill skiing (I did a lot of ski racing in high school).

Slow Preparation

Slow is important before a race. Do you have the right equipment? The mechanics feel intuitive to me now, but equipment is vital to speed in skiing. Collecting and maintaining the right gear is half the challenge in reducing friction:

Low friction is great when skiing because you will find it easier to turn and accelerate when you hit the slopes.

Part of the practice of ski racing is sharpening your edges regularly, by taking them into a shop once or twice a season (pros probably do this more often). Another key ritual is applying wax before a race (it wears off).

Speeding that preparation wouldn’t make sense. It takes the time it takes, and it’s critical to do that work.

To me, this is the same as planning in ambitious software projects. The agile manifesto never said “don’t plan at all”, but so many organizations and non-technical leaders seems to have interpreted it that way.

What outcomes are you looking to achieve? How will you know if you’ve hit them? What kind of thresholds should you establish for reconsidering the slope or equipment (this should be done up front! too often leaders assume they will “just know” when they need to make a change, but it’s very hard to recognize inflection points intuitively). This is one of the best ways you can use data; for decision-making and evaluation of the problem space. And it’s critical that you take your time to question the data from multiple perspectives.

So we go slow. We go slow, because we want to go fast.

Let Go and Go Fast

When you’re standing at the top of a mountain looking out over those skis though? That’s the time to let go of any hesitation. Because once you’re skiing or building, speed is safety.

Skis slide because the thin layer of snow underneath the ski melts from your kinetic energy (skiing) transforming into thermal energy (heat) via friction. That softens the snow and creates a fragile layer of water, which reduces friction much more than you want. This means you lose control over your skis and end up sliding very easily!

The faster you move, the less snow melts; and this reduces the risks of a wipeout.

There’s another aspect to control though, which is that fear of crashing will make you hesitate, and that hesitation counter-productively causes you to be rigid when you hit bumps. Hitting bumps at speed means you can catch some air and keep going. Sometimes that short flight makes you even faster and helps you win the race.

In a software startup, and probably any new endeavor, the same principles apply. The terrain is going to contain bumps and ice patches. Welcome them. Let them inform you about the landscape and lift you up.

And let’s talk about falling, because even the best do wipeout on occasion. I was legendary for my spills as a skier. Racers on other teams would come up to me at meets and be like “oh wow, you’re the one who lost her skis twice, had to hike back up, and crossed the finish line backwards laying down that one time!” (I guess it’s good to be famous for something?)

I never got hurt skiing though, because once I felt myself falling, I let it happen. The worst injuries happen when you see it coming and fight gravity. A little over a year ago, I fell down a staircase (okay, yeah, there’s a theme here and I am a bit clumsy). If I had rolled, I would have been fine - it wasn’t that far to fall. But instead I reached out to grab the railing, held on too tight, and ended up with a broken hand.

The software entrepreneurs I know and admire talk about this all the time. As long as you understand the risks, falls are just stories that can launch you into the next adventure.

It Requires a Team

And there’s one last critical piece of going fast that seems relevant. In high school, I was the only skier at my school who was held on the junior varsity team, instead of making varsity as an upper-class student. But every varsity race I was on the roster. When we ran time trials or side-by-side races, I was fast, I won almost every time.

I finally got frustrated and asked why they kept racing me if I wasn’t good enough for varsity. My coach told me my technique was terrible, but I was the only girl on the team who didn’t hold back. He said if I didn’t wipeout, I’d get the kind of times that could make the difference for the team.

Candidly, I skied for years and never looked up how scores were calculated until I started writing this post. After meets, the coach would get on the bus and announce the rankings. Apparently, this is how they do it: they total the scores of the top 4 finishers of teams that meet criteria. The bottom 5th and 6th scores aren’t considered (so if a couple of folks wipeout, the slow scores are disregarded).

Knowing that, I can see the strategy. He had said I might fall 4 out of 5 times, but that 5th time we’d win.

Here’s where a mistake occurred unfortunately. The more often I was raced varsity without the recognition, the more feedback I got on details of my technique, the more I lost confidence. By my senior year, we kept talking about my “bib-itis”; how I never fell in time trials during practice, but as soon as I had a racing bib on I started racking up those really impressive yard sales. It put me on edge. I had the twisties.

In retrospect, maybe nothing was wrong with my technique. Maybe I just had a different style. After all, when I was having fun, I got the kind of outcomes we wanted.

Anyway, what does that have to do with software startups? Everything. You don’t race or build software alone. Trusting teammates is critical. If I feel like I’m racing with and for my friends? Whew, watch me fly. If I feel like my style is bringing down the team? I freeze and fall. Startups are usually founded by old friends, close colleagues, or even family members for this reason. It’s something you have to be careful about - members of the team have to feel comfortable disagreeing and challenging each other, even when it’s difficult. But the camaraderie you bring is part of what makes that possible. (I’ve always struggled with understanding this - when friends or past colleagues try to recruit me, I worry it’s nepotism rather than recognition).

The downside with startups is that they can miss out on potential because they aren’t matching the problems to the people. It’s a lot of work to recruit well and build friendship and trust. Not everyone has a talent for those things. It’s kind of a secret ingredient. Someone on the team who listens attentively, appreciates others, and can match people to opportunities is a speed multiplier.

Which brings me to another relevant quote: “To go fast, go alone. To go far, go with a team.” Software startups need to do both, continually balancing each type of motion.