No one cares how hard you throw ball four

No one cares how hard you throw ball four

For some reason, despite neither my wife nor I growing up playing a lick of baseball, we ended up with two boys who are completely obsessed with it. Both are on multiple teams, we’re always watching SF Giants and A’s games and almost everything they wear relates to baseball. Along the way, my oldest picked up this shirt which reads: No one cares how hard you throw ball four.

I love this quote. Not only is it a dig on the hothead pitchers who light up the radar gun but can’t find the zone, it also happens to be what I consider a great life lesson with near infinite application. That is: velocity only matters if you’re getting the right results.

The black box between plan and reality

In recent years I’ve worked in engineering leadership, both directly and in an advisory capacity. And I’ve seen the same thing many times. There’s this black box that exists around what a team plans to do and what the team actually does. Despite all the typical progress readouts showing green all quarter long, you still somehow find yourself staring at a QBR slide with yellows and reds three months later wondering how you got there.

To me, that black box was always the holy grail: not another slide full of manually updated green dots, but a real answer to a simple question:

When we say “this quarter we’re focused on X”… is that actually true?

Leadership is full of moments where you think you know, only to find out you didn’t. You see it in the QBR when the biggest initiative is behind and nobody can explain why. You find out when you realize that “quick win” somehow became a permanent lane. You find out when a steady stream of “just one more thing” ends up turning your roadmap into a suggestion box.

And the frustrating part is, in the day-to-day, it all looks reasonable. Everyone is busy. Slack is buzzing. Tickets are moving. The sprint board looks healthy. If you ask any IC what they’re doing, they’ll give you a convincing answer that tracks. If you ask a manager, they’ll tell you the plan.

But when you zoom out and you look at the actual work signals, you can end up with something that doesn’t resemble the plan at all.

That’s what the shirt is saying.

It’s not “velocity doesn’t matter.” Of course it does. It’s that velocity is only useful if you’re throwing strikes. In engineering right now, we’re in a velocity renaissance. AI-assisted coding and review, faster CI pipelines, better tooling…all real, all valuable. But a lot of teams are trying to throw 97 mph while missing the zone. They’re optimizing the how while the what quietly drifts.

Planning tools are maps, not footprints

And here’s where many well meaning people make the mistake: they assume their planning tools will tell them when it drifts. They won’t.

Jira, Asana, Linear (pick your favorite issue tracker or project planner) these are great at capturing intent. They’re maps, not footprints.

A planning tool is a pre-work artifact, updated through workflows that ultimately rely on self-reporting.

So if you want to know whether you’re throwing strikes, you need a different kind of signal: evidence of where the work actually went.

A lesson I learned the hard way

A few years ago at a quarterly planning meeting, my leadership team and I had done what most do: picked a handful of “must do” priorities, built a plan, aligned the org, and walked away feeling pretty good about it.

In the first few weeks, nothing looked obviously wrong. Tickets were moving. Standups were happening. But halfway through, I started getting that feeling that something wasn’t adding up. The priority map was still intact but the chatter was telling a different story. The P2s were getting too much airtime at the water cooler. The extra planning meeting mid-week was to resolve an unforeseen architectural design issue in a P3 initiative. It floats around in the back of your head. You assume “the team’s got it,” and they tell you as much, but the feeling won’t abate.

So I raised it. “Are we still primarily focused on our P1’s?” “Are we spreading ourselves thin?” “Are we context switching?” The response was expected: defensiveness, hand-waving, and a lot of well-meaning assurance that everyone was focused and working as hard as possible.

So we did the thing a lot of teams don’t do: we stopped arguing about intent and looked at actual work signal.

What we found was…surprising.

Across just a few teams we had 18 epics in flight with active work being attributed to them in a single two-week sprint. That’s not “agile.” That’s thrash. Even worse, our top two initiatives, the ones leadership would have sworn should account for 50%-60% of our engineering effort were together getting 33.2%. Meanwhile a “nice-to-have” epic that was supposed to be a background thread was consuming 29.2% on its own.

No wonder we were behind.

The interesting thing was, when we shared the numbers, nobody tried to debate them. There was no dramatic meeting. Things just…changed. Quietly, quickly. Work snapped back toward the priorities.

That’s what real work signal does. You don’t need to convince people. You just need to show them. And once you get that clarity, a lot of the usual management reflexes start to look like they’re solving the wrong problem.

What doesn’t work (and why leaders keep trying it anyway)

Here are the usual substitutes people reach for when they don’t have real work signal:

  • Planning tools (issue trackers, project planners). Great for organizing intent; weak at revealing reality.
  • Story point tracking. Helpful inside one team; almost meaningless across teams. Also, still just a squishy planning tool.
  • More meetings. The go-to response to uncertainty, and the fastest way to tax your best people. When leaders can’t see where work is actually going, they often compensate with more check-ins, more status docs, more steering meetings, and more process.

A practical way to start throwing strikes

If you want a simple, lightweight way to make this real:

  • Pick your top 1–3 initiatives for the next sprint or month.
  • Decide what work signal you’ll use to measure allocation (PR activity, deployments, incident work, issue throughput, calendar time, or a combination).
  • Review it weekly and look for drift early (before it shows up in the QBR).
  • When you find drift, treat it as a visibility problem first — not a motivation problem.

The easiest way to do this at scale is with a Software Engineering Intelligence (SEI) platform that can connect to the systems where work actually leaves footprints, such as GitHub, Jira (activity, not self reporting), AI tools such as Cursor and Claude, and more. (For transparency: I consult at Jellyfish, which is one of those platforms.)

Throwing harder isn’t the same as throwing strikes

Right now, the industry is obsessed with throwing harder. Faster coding. Faster PRs. Faster shipping. That’s fine. Speed matters. But it only matters if the work is actually pointed at the right priorities. Or, as a great colleague of mine often says:

Do the right work before worrying about how to do the work right.

Because no one cares how hard you throw ball four.