We aren’t Google, and oxygen tents are no shortcut

Last week I did a race I’d spent the past eight months training for, ten to twelve hours a week. The bike leg worried me most and was the biggest unknown. It was my weakest discipline last year, so I spent a lot of my training on it. One change I made was to train using telemetry. In simple terms, you fit a power meter to your bike and do a test to find your maximum sustainable power in watts. In the race you aim for 80 percent of that power as a safe target and 85 percent as a ceiling, so you can still run a good half marathon afterward. In my case it was 255 W × 0.8 = 204 W for all 90 km. In the wind, uphill, or in pouring rain, you try to hold that power. A technical aside. Power is absolute. Speed, heart rate and other measures are relative. At 204 W uphill I might be doing 25 km/h. On the flat with a tailwind I might be doing 35 km/h, or perhaps 45 km/h if I tucked in behind another rider (drafting is actually prohibited). That’s why power is the main thing to watch. Speed is relative and doesn’t tell you much on its own.

Back to the race. After the swim I switched my watch to show power and started cycling. I tried to stick to the planned power, though I didn’t quite manage it. I was below target, which may have helped save energy for the run, but the ride felt fantastic. I passed other racers as if they were in slow motion. After 90 km with no other numbers to go on, I got off the bike thinking it had taken 2 hours 37 minutes. The actual time was 2 hours 54 minutes. I was furious. Any hope of a decent time was gone, and I had a half marathon ahead of me with nothing at stake but pride. I’m telling you this because there are plenty of lessons in it for what we do in DevOps.

If you come out of the swim with the losers, you’ll only pass losers. How it feels to pass them is beside the point. The people you want to measure yourself against are somewhere else entirely. We’ve had several successes in DevOps, but we can’t judge ourselves by showing up at a meetup and getting a pat on the back. We can’t stare at the power meter and ignore the other numbers that put it in context. Our release cadence is, without exaggeration, fantastic. In the Czech Republic? Maybe. Look at how many regressions we have or how much effort a release takes and it doesn’t look so great.

I try to pick up ideas from the best racers, but I can’t copy them blindly. If the winner sleeps in an oxygen tent to make more red blood cells, I could buy one too. At my training volume it’d do me no good. My wife might even throw me out or divorce me for finally losing my mind. We should look at Google, Netflix or Spotify, but keep our feet on the ground and remember their solutions fit the problems they have. We probably all sense that one enormous monolith is a bad idea, but blindly splitting it into a thousand microservices because that’s what Netflix does is a bad idea too.

That brings me to my last point. My philosophy comes from lean and kaizen. Improve things step by step, starting where it hurts most. When I was learning to swim, which I mention because it scares most athletes, I couldn’t imagine swimming more than 100 m freestyle. Two years later my sessions are regularly 2,500 to 3,800 m. It comes down to practice and focusing on swimming the next length better. At the beginning of the year our fast-track continuous delivery pipeline could deliver one release a day, and it took five hours and sixteen manual steps. Today it’s three releases and two hours. In six months it might be five one-hour releases, each with one click. We want releases that require downtime once a month instead of once a week. We’ll get there through daily practice and small improvements. We aren’t Google, and shortcuts like oxygen tents don’t carry over.