Speed vs Correctness: What Youth Baseball Umpiring Taught Me About Production Deploys

Umpiring broke my developer brain

I started umpiring youth baseball because our club needed bodies and I already coached. I thought it would be easy. I watch a lot of baseball. I know the rules. I write complex web stuff for a living. How hard can calling balls and strikes be?

Very hard, as it turns out.

Umpiring reset how I think about technical decisions under pressure. Especially production deploys. When you stand behind the plate with a 12-year-old on the mound and two dugouts full of parents and kids, you learn fast what it means to make irreversible calls with incomplete data.

That is the same headspace I am in during a risky deploy, a hotfix, or when I have to pick the least-worst option in a broken system. Different stakes, similar mental load.

Calling a pitch vs shipping a change

Here is the basic constraint of umpiring: you have a fraction of a second to see a pitch, process where it crossed the plate, compare that to a mental 3D strike zone, ignore the noise, and speak one word. "Ball" or "Strike." No pause. No replay.

Once it leaves your mouth, that call is history. You cannot roll it back. You can only make the next one better.

A production deploy has the same structure, just stretched out in time. You rarely have perfect information. Logs are partial, metrics are noisy, people are slacking you, and a product owner is asking, "Can we ship this today or not?"

In both cases you live inside three constraints:

• You are under time pressure.
• The information is incomplete or fuzzy.
• Your decision is effectively irreversible, at least socially.

Everyone loves to say "measure twice, cut once". That sounds nice in retros. On the field, the pitch is already in the catcher's glove and the runner is stealing second. Measure time is over.

Incomplete data is the default, not the exception

One of my first games behind the plate, there was a borderline pitch at the knees on the outside corner. From where I stood, it nicked the zone. I called strike three.

The batter froze. The parents behind him exploded. The pitcher grinned. The catcher said nothing, which is its own kind of feedback.

In the moment, I saw maybe 60% of the truth. My angle was slightly off. The catcher had shifted. The sun was in my eyes. No replay. Just vibes and training.

That 60% feeling is basically the baseline for production issues. Logs come in late. That one critical metric was missing from the dashboard. The error rate is up but only in one region. You do not get 100% of the data. You never do.

I used to think I should wait for better data to make "correct" technical calls. I try to fight that instinct now. Most of the useful decisions die while we are hunting for one extra log line that does not actually change the outcome.

Speed is not optional when other people are moving

In a youth game, the play continues whether you decide or not. A runner is rounding third. A throw is coming from the outfield. You have to step into it and make a call at the plate.

If you wait for certainty, you create chaos. Both coaches start yelling, runners keep going, and kids stop trusting that anyone is in control. A late "safe" or "out" is worse than a fast call that might be slightly wrong.

Production is similar. The rest of the system does not freeze while you think. Customers keep clicking. Other services keep sending you garbage. People keep merging PRs.

Slow decisions create their own failure mode. You get:

• Extended partial outages because nobody is willing to pull the plug.
• Half-shipped features that sit behind flags so long they rot.
• Teams building local workarounds since the "real" decision never lands.

I am not saying "move fast and break things". I am saying "move fast and own things". If the system is already in motion, pretending you can stand outside of time and think your way to a perfect answer is fantasy.

Irreversibility is mostly social, not technical

Here is a twist. In software, we love rollbacks and feature flags. We tell ourselves that most decisions are reversible. Technically that is true most of the time.

Socially, it is not.

Once you ship something that sales has already promised to a big customer, rolling it back a week later is not just a git revert. It is a loss of trust. Product loses face. Your team looks unreliable.

Once you approve a risky deploy on a Friday afternoon and it explodes, your CFO does not care that "we rolled back in 12 minutes". In their head the deployment is already filed under "those devs make bad decisions".

Umpiring made that feel very real. Even if you technically can correct a call in some weird edge case, 99% of the time you do not. You eat it. Because walking back a call destroys the one thing that matters more than accuracy: trust in your consistency.

That shifted how I think about production calls. I now assume that any decision that is visible to other humans is sticky. So I treat it as if it is irreversible, even if the code is not.

Consistency beats perfection under pressure

Umpire training drills one idea into you: be consistent. If your strike zone is a bit high, keep it high all game. Everyone will adjust.

Players and coaches will accept a lot of human error if it is predictable. What drives them crazy is randomness.

Software teams are the same. They do not need you, as a tech lead or senior dev, to have magical perfect judgment. They need to know how you will make a call.

For me that looks like:

• Defaulting to shipping small, reversible changes fast.
• Blocking big releases close to key dates, no matter how tempting.
• Requiring one clear rollback plan for anything scary.
• Being explicit about what metric matters most for this deploy.

People learn that pattern. They can predict my calls. They know when I will say "ship" and when I will say "nope". That predictability matters more than squeezing out an extra 2% correctness on any single decision.

The noise problem: parents vs stakeholders

Standing behind the plate you get a real-time stream of feedback from parents, coaches and kids. Every call has an opinion attached. Some of those opinions are loud.

There was a game where one coach decided my zone was too tight. After the second inning every pitch that did not go his way was "Come on blue, that is the same pitch!" He was wrong, but that is not the point. His noise started to affect my timing. I could feel myself hesitating for a few milliseconds.

That hesitation is expensive.

In production, the equivalents are Slack pings, Jira comments, and "quick" messages from sales. Everybody has an angle. Ship this because a demo depends on it. Do not ship that because someone is on holiday. Can we just try it in prod for that one client?

When I let that noise into my decision loop, my calls get worse. Not because their input is useless. Mostly because it is late and biased.

What helped on the field helps in tech: decide your criteria before the pressure starts.

Umpire version: before the game I tell both coaches, "I call the high strike. If it touches the letters it is probably a strike." That script does two things. It locks my own standard in my head, and it gives them a frame to understand borderline pitches.

Engineering version: before the release I say, "We ship if error rate stays under X, latency under Y, and we see at least Z% of traffic on the new path." Same thing. Premeditated criteria. That way when someone pings me mid-deploy with a different priority, I have something solid to push against.

Pre-decision work > heroics

People love hero umpires in movies. The slow dramatic punchout call in the bottom of the ninth. The reality is less cinematic. The good umpires are boring. They make routine calls, in a routine way, because they did their thinking earlier.

I started treating deploys the same way.

Instead of trusting in my ability to be a genius under pressure, I try to load the decision before it arrives:

• Write down the one or two things that would make me abort the deploy.
• Agree on a time box for "watching it live" with whoever is on call.
• Decide in advance who has veto power.
• Make a call on risk tolerance for this release, explicitly.

This is the equivalent of walking the field before the game, checking the lines, talking to the catchers, and aligning on ground rules. It is not glamorous. It is responsible.

When something weird happens in the fourth inning, you already know how you will treat it. When something weird happens 10 minutes after a deploy, you already know whether you are inclined to roll back or ride it out.

Owning the bad calls

I blew a call at second base once. Runner was clearly safe. I called him out. Terrible angle combined with a late tag that made a nice sound on the glove. My brain over-weighted the sound and under-weighted where the foot was.

Both coaches looked at me. The defensive coach smiled. The offensive coach said, "You sure about that, blue?" I was not. But I had already made the call.

So I did the only thing that still works in that moment. I owned it. "Coach, that is what I saw." Short. Simple. Final.

He shook his head, complained for another pitch, and then the game moved on.

In production, you will also make bad calls. You will ship something too early. You will wait too long. You will misread a dashboard.

The worst pattern I see in teams is trying to pretend those calls were good ones. People retrofit justifications. Blame the process. Blame another team.

I prefer the umpire approach:

• State the decision you made and the information you had.
• Admit the gap clearly, without drama.
• Adjust your pre-decision criteria for next time.

That last step is key. You cannot fix the old call. You can only upgrade the way you will make the next one.

Building a "strike zone" for technical decisions

The real payoff from umpiring was this: it forced me to define my own strike zone for technical decisions under pressure.

Not a checklist. More like a mental frame. Mine looks roughly like this:

• Default to action. If waiting does not clearly improve the decision, make the call.
• Protect trust first. Code can be fixed. Trust is slower to rebuild.
• Consistency over cleverness. Teams can adapt to a predictable pattern. They cannot adapt to your mood.
• Pre-commit to criteria. Decide the rules of the game before the first pitch.
• Own the outcomes. No hand-wavy blame shifting. Own the bad calls and update your model.

I am not saying my strike zone should be yours. It probably should not. Different teams, different risk appetites. But you should have one.

If you are constantly surprised by your own decisions during deploys, that is the same as an umpire guessing at every pitch. You might get a few right, but nobody will trust you as the game scales up.

Pressure is the feature, not the bug

Umpiring youth games did not make me fearless. I still feel my heart rate go up on tight plays at the plate. I still feel the weight of a big deploy heading into a weekend.

The difference is that I treat the pressure as part of the job, not as an error condition. You are supposed to feel something when you make irreversible calls in front of people. That energy can sharpen you if you prepare for it.

Standing behind the plate, mask on, kids yelling, parents humming in the background, there is a tiny pocket of silence right as the ball leaves the pitcher's hand. That is the window you live in. You see, you decide, you speak.

Production has the same pocket. Logs streaming, metrics bouncing, stakeholders pinging, and then that moment where you say "ship" or "rollback".

You do not get to pause the pitch. You only get to train how you call it.

Umpiring made me a little faster, a little calmer, and a lot more honest about how I decide under pressure. That has been worth all the shouting from the bleachers.