What Ironman 70.3 Taught Me About Shipping Software Products

This year I finally realized a long time ambition of mine—to complete an Ironman 70.3 triathlon. I did this not once, but twice. I was challenged to do these races by one of our staff who is a passionate triathlete, Ricky, and by an old friend of mine from my Boston days who is a fellow triathlon enthusiast.  It so happens that many lessons from this sport have parallels and applications in my professional life as a software developer.

Triathlon is a multidisciplinary sport much like software development. It’s not enough to be a good runner or swimmer, or a strong cyclist. Sure, everyone has their strong suit but to be really effective you must develop a substantial competency in each area. Likewise in software, we have multiple disciplines— development with its sub-specialties, product management and user experience, project management, and of course, general business or domain expertise. The most valuable and effective people develop their skills across these areas and high-functioning teams must have all the bases covered.

Finishing is Everything

Steve Jobs once said to the team developing the original Mac, “Real artists ship!” This is a reminder to those who are prone to endless perfection, discussion, and revision that delivery is the most important thing. Software projects that culminate in an important product launch have a finish line, much like a race. In Ironman, finishing is everything. The time matters, of course, but finishing usually matters a lot more.

Triathlons follow the three-part story of human drama—they have a very clear beginning, a middle, and an end. Good software projects also follow this pattern. There should be a clear beginning, a middle, and a well-defined end that can focus all the energies of the team.

Everything is Training

Whatever you do, you are training for something. If you are not training to do something you are training to do nothing and you will get better and better at it. Training to lift heavy weights, may be helpful for triathlons but probably not much. I spent a period of time focusing on strength training earlier this year and switched to endurance training only two months ahead of race day. I raced heavier than I would have liked and without as much recent mileage. I am not sure if it hurt me but it certainly did not help much.

At work, as I have remarked in my book, Level Up, if you keep social networks open in browser tab and/or check them multiple times per day, you are training yourself for distraction. Even if you are in a lull period where work may allow for some slack, if you train like this, your powers of attention and focus will be “out of shape” when they are once again needed. Always be mindful of what you are training yourself to do.

Get Out of Your Comfort Zone

The reward in life comes from struggle. To make a difference, to make a change, to level up, you have to get out of your comfort zone. You must take on projects you do not know exactly how to complete.  If you do know how to complete it, then you should set aggressive deadlines for extra challenge. It is scary, but the skills you are training for here include “dealing with the unknown” and “rapid skill or knowledge acquisition.” Software developers need these skills—all the time. If you already know how do your job, then you are probably coasting to some extent and not developing yourself as fast as you could.

Not everyone has a competitive spirit. That’s okay.  When I get to choose my teammates for a challenging endeavor, who will I choose? I will choose people with some spirit—some “fire in the belly.” I will choose teammates with ambition and something to prove about themselves.

Ironman is only competitive in the usual head-to-head sense for people who pursue it professionally or at the elite level. The vast majority of participants are only competing with themselves. They are there to put themselves to the test. In the crucible of competition we find what we are made of.

Every Time is Different

Every course is different. The weather is different. The competitors are different. The only constants are the rules and you. You can’t change the rules but you can change yourself.

Software is even more varied. Projects do not come in neat sizes with well-defined rules. Every organization is different, the people are different, the constraints are different.

With experience you will know what is typically involved but you cannot expect that everything will work just as before from one time to the next. Adaptability is key.

The Second Race Will be Harder

You will have inflated expectations. You will not train as hard or as carefully. If everything went smoothly the first time, you will not realistically assess risks and plan for contingencies.

The analogy in software is the “Second System Syndrome or Effect.” This common situation occurs when a small team achieves an impressive result and overconfidence leads the organization to attempt a second project or system with vastly over-inflated expectations or increased complexity.

I completed my first Ironman 70.3 in early March with a time that surprised and pleased me. I thought to myself: “6:53 and I walked most of the ‘run!’ Not bad for a first-timer! Why all I need to do is run or jog the whole run and I will make 6:30 or better, maybe even 6:15!”

During my last big training day two weeks ahead of the race, I rode my bike for two hours in the hot midday sun of Reno, NV, which I told myself must be more difficult because of the altitude. Then I ran about 18K, which is almost 21K, and my time was not terrible. I didn’t walk at all. “Surely, I have this in the bag.” But that training is not quite the same as giving your all on a 1900m swim and then riding hard for four hours before starting your run. When I trained for my March race, I first always tried to squeeze in a swim before getting on the bike to simulate the whole thing. That added another hour or so bringing up my peak training session to five hours. This was more realistic.

Things Will Go Wrong

Everyone who has stepped up to develop software on an ambitious schedule or chosen to compete in a few races knows that things go wrong. If you did not perceive that anything went wrong, you may simply have been lucky. Perhaps you are not taking a critical enough eye. Something probably went wrong but it did not impact you because of some other good fortune. Problems that impact us usually have multiple cascading causes. Planes rarely crash and boats rarely sink due to pilot error alone. It is a cascading series of errors that results in disaster. The animus of root-cause analysis and the “5 Whys” method is to get past the surface explanations for events and understand where things really went wrong.

During this second race, I swam a decent swim. I started in the fast-swimmer group and I was passing people the entire time. I took to counting how many strokes it would take me to pass someone. Ten—easy. Twenty—they are fighting. Only one or two passed me but I passed dozens. I came out of the water with people who will finish the rest of the race well ahead of me. Most of the field was behind me. This knowledge buoyed my spirits as I pedaled over the bridge from Mactan to Cebu and prepared to face a serious headwind for the next ten miles. Just as my bike hit top speed on the downhill from the bridge, I noticed that something felt different. I looked down at my rear wheel. Oops! Flat.

I pulled over to the side and took off my wheel. I pulled out the spare tube, tire tool, and hand pump. A crowd of children and spectators gathered. As I struggled with removing the tire a race marshal arrived to help. He struggled too. I had never practiced this routine on this bicycle. In fact, it’s been ten years since I changed a tire tube on the road, and now I paid for it. Eventually we got the tire off the wheel enough to get the tube out. Then we got the new tube in. After struggling with the hand pump and adapters, trying both his pump and mine, struggling with a slight language barrier, eventually another marshal showed up with a full pump and was able to get the wheel to one hundred ten psi. All the while, I watched masses of bikes pass me at top speed. The field that was behind me was leaving me behind. As we started to put the wheel back on, a marshal pointed out that I had not attached the derailleur correctly with the cable outside the frame so this necessitated a further time- consuming adjustment before I could pedal off and resume my race.

I don’t know how long I spent there fiddling with all that stuff under pressure but it cost me—not just in time but in psychological energy. Getting passed by fast people while you are in the front of the field dropping back to the middle beats struggling to pass slow people to work your way up to the rear of the mass of riders.

What happened there? Sure, I had a flat. That explanation is easy but it is not sufficient. Flats are a known risk. You can prepare for them. Flats can happen at the worst moment such as the beginning of the race at a place where everyone is still close together and moving at top speed. Nothing you can control about that. So, why did this take at least ten minutes longer than it should have?

I was sort of prepared for a flat but I had not practiced changing the tubes on this bike. Next time, I will practice changing tubes multiple times until I can get this down to just a couple minutes. Even without practice this could have been fixed much faster if I had my CO2 cartridge with me. I accidentally packed my bike’s underseat bag not with the bike which was checked luggage but with my carry-on luggage. Airport security would now allow me to take it on the plane. When I arrived, I did not attempt to beg or borrow one, even though there were probably hundreds around somewhere. Even in the exhibit hall, I'm pretty sure I could have tracked one down. I saw some bikes carrying two cartridges. They know what’s up.

Root cause: lack of preparation for a known likely contingency. Next time: prepare.

When Things Get Tough, Focus on Your Cadence

Later in the race, when the struggle is on and you have to start digging deeper, stop thinking about the whole race and just focus on your cadence. Every pace, every stroke delivers some mileage. Divide the segment you are on into smaller segments you can tick off frequently enough to keep a regular feeling of progress. Ride the next mile. That should only take you three or four minutes or whatever. Count the cadence. Breath in unison with your cadence to find a comfortable, sustainable pace. Inhale, 2, 3, 4, exhale, 2, 3, 4, inhale, 2, 3, 4 ...

While your mind is suitably occupied, you will find a sustainable pace and surely get there.

So it is with software. When you are in the hot seat for delivery, all you can do is focus on delivering the next bit and then the next bit and so on. In agile teams, this is the way. The project owner or manager needs to accept items almost as quickly as they are delivered to keep the team moving at top speed. Otherwise everyone gets bogged down with questions of “Where are we?” and “When is this whole thing going to be done?” when the team focuses on this to the detriment of delivering little bits in a continuous stream, they are losing awareness of the very information that could answer those questions. That’s why we call it “velocity.”

Avoid Negativity

When you are chunking along maintaining a good sustainable but challenging pace, and your mind turns to happy thoughts of some kind, you may continue running or pedaling for a while and your mind may more easily return to the task of racing. You may even get a speed boost and ignore the growing exhaustion or pain in your muscles.

However, if you let negative thoughts enter, you will find that you stumble, that your pace breaks, you slow down, you give in to the temptation to walk or stop pushing. You begin to think you are tired or become aware of your exhaustion. This creates a self-perpetuating dread. How will I ever finish this when I am already this tired?

Nip negativity in the bud. If a negative thought enters your mind, return immediately to cadence. Or if it works for you, get angry and take that anger out on the course. Pedal harder and get back in the zone. Pick someone ahead and pass them in anger, because you’re angry and doing this thing and want to get to the finish sooner.

I frequently get angry at code, or at developers—usually long gone and usually not our own—who’ve left a mess somewhere, or at myself for shortcutting something. Anger may not work so well in software but certainly avoiding negativity will yield benefits.

Some Life Lessons

Most people participating in these events are not really in competition with the others. They are competing with themselves—using their minds and bodies—trying to push them further, to throw off physical and mental limitations.

Recently in my feed, some have made hay over the strange idea that in the game of life some get to play “on the easiest setting.” I’m not sure there is such a setting. Humans are very good at manufacturing challenges for themselves. People who have everything given to them often drown themselves in decadence and dissolute behavior and often do not amount to much. For those for whom life is too easy, perhaps they should consider doing something harder, set their sights higher.

When you get into this sport, because it is a business, and there is money to be made, there is a wide range of gear to spend on. It’s easy to catch a case of gear-envy. It starts with admiring all the fancy machines everyone has. Pretty soon, you may excuse your poor performance consciously or unconsciously because, “That person ahead of me has a nicer bike.” So what! Or perhaps even more problematic, “That other person has such a good body, surely they possess better genetics.” So what! I'm not really into the gear and I try not to let my body image factor into this at all. I take special pleasure in passing people whose bikes cost three to five times more than mine.  Sometimes it seems like everyone has a fancier bike. And there are plenty of high performers who do not sport visible abs and a few slow pokes who look like they could be fitness instructors.

Some people will cheat in little ways that don’t seem to matter but they kind of do. I started in the second fastest starting-group of the age-group swimmers. It was a rolling start and if everyone around me truly expected to finish their swim in thirty-five minutes, then I should not have been passing them left and right. We should have been roughly similar. Instead, the swim was like climbing a ladder as I passed one after another. Strange. I was already one group ahead of where I probably should have been. Now I feel I should start with the fastest of the fast because otherwise I will be stuck bagging slowpoke cheaters. Is it cheating?  It seems dishonorable to me. Now that everyone is apparently doing it though, it forces me to do the same. Or does it? We'll see which group I stand in next time. Maybe I can earn my place at the front of the under thirty minute group and forget all about it.