How I handle deployments

I'll admit it up front: I have a soft spot for deployments. Planning a new app rollout or a sophisticated system upgrade is the part of the job I actually look forward to. There's something deeply satisfying about taking a thing that could go sideways in a hundred ways and walking it through to a clean landing.

The picture I always come back to is a Formula 1 race. Everything happens fast. Blink and the car's already past you. But none of that speed is improvised. The car has to be in perfect condition. The driver has to be sharp, physically and mentally on point. And the crew has to be on standby, ready to fix a problem or change all four tires in seconds, sometimes less. That's the bar. The race looks effortless precisely because of everything that happened before the lights went out.

That's how I think about shipping software. Below are the kinds of deployments I usually orchestrate, roughly in order of how much planning they demand.

Routine deployments

These are the bread and butter, the laps you run over and over until they're muscle memory. Most of them are regular, frequent back-end deployments. Then there are data upgrades that don't touch the front or back end, which are about as low-drama as it gets. Feature drops are a notch up: they still need to be announced and planned according to corporate policy, so nobody downstream gets surprised.

My job on these is to keep the machine humming. I set the schedule, get the paperwork submitted, coordinate the moving pieces, and then watch production once it's live. 

Brand new app rollout

This is the full pit-crew operation, and it's where the planning really earns its keep. A brand new app doesn't go anywhere until it's cleared security, architecture, legal, and the personally identifiable data committee.

From there it's about getting everyone ready for the thing to exist. The Service Desk gets trained and prepped, and the engineering team lines up white-glove support for the early days. On the technical side, we run a code scan and a pen test so we're not finding surprises after launch.

Then comes the part I genuinely enjoy: the pilot. We plan it carefully and, just as importantly, plan how we'll collect and act on feedback, because a pilot you don't learn from is just an early launch with extra steps. During the rollout phase the team stays close and supportive, and then we go national, preferably in waves, watching performance and scalability as the user base grows. And because new software almost always means new ways of working, we plan the process changes for the users too, so the app lands as a help rather than a homework assignment.

Deployments with complex dependencies

The last category is the trickiest: deployments tangled up in sophisticated dependencies, with lots of teams in the mix and real changes to the business riding along. These need special planning, careful sequencing, and a lot of conversations across team lines.

Here's the happy plot twist, though. As I've worked through simplifying our architecture and untangling dependencies, these heavy, high-coordination deployments have been happening less and less. The best way to make a hard deployment easy is to do the unglamorous work upstream so it never gets hard in the first place.

Why I almost always release in waves

If there's one thread running through all of this, it's my preference for releasing in waves rather than flipping a switch for everyone at once. In practice that means canary releases: you roll the change out to a small slice of users first, your "canary," and watch closely, widening the rollout only once the signals look good. Error rates, latency, and real user behavior all get a chance to speak up while the blast radius is still tiny.

If something's wrong, you've affected a handful of people instead of everyone, and rolling back is quick and cheap. If everything's healthy, you keep opening the gates to more and more users, monitoring and assessing as you go. It's the same instinct as the F1 crew: move fast, but never faster than you can react. Ship deliberately, watch everything, and let the rollout earn its way to the finish line.