Coaching U12 Baseball In The Netherlands Taught Me More About Feedback Than Any Tech Job

From dugout to standup

I coach a U12 baseball team in the Netherlands. Twelve-year-olds. Mixed skill levels. Mixed languages. Big feelings.

It quietly rewired how I think about feedback loops for engineering teams. Not from theory. From standing in the rain, trying to get a kid to stop short-arming the ball while three others chase a butterfly in left field.

I have led dev teams for years. I have read all the usual management books. They helped a bit. The U15 dugout helped more.

This is what changed for me. And how I now structure feedback on engineering teams because of it.

Feedback in baseball is brutally fast

Baseball gives you feedback whether you want it or not.

You drop your elbow at the plate. The ball pops up to the pitcher. Everyone sees it. You pull your head on a grounder. The ball rolls through your legs. Everyone sees that too.

On a software team the feedback cycle is often absurdly slow. Spec. Design. Build. PR reviews. QA. Release. Maybe a user complains three weeks later. Or they just silently churn, which is worse.

On the field, I cannot wait three weeks to fix a throwing motion. If a kid is spiking every throw, I have about five throws before the frustration hits and the learning window closes.

That forced me to get obsessive about the timing and size of feedback. Short loops, small corrections, immediate signals.

I now treat engineering work more like bullpen sessions and less like quarterly projects.

One variable per loop

Early in the season I made a classic mistake. I tried to fix everything in one go.

A kid would be hitting and I would yell from behind the cage:

• "Hands up!"
• "Stride less!"
• "Turn your hips!"
• "Head still!"

Shockingly, this did not help. You could almost see his brain segfault.

So I changed approach. One variable per loop.

Same hitter. Different pattern:

• Round 1: Only focus on starting position. I literally ignore the result of the hit.
• Round 2: Lock in stride length. He already owns the stance now.
• Round 3: We care about contact. I stay quiet on everything else.

The progress jumped. Not because my coaching got smarter. Because the loop got simpler.

I realised I was doing the multi-variable mistake at work too.

PR reviews that try to fix architecture, naming, style, product thinking, and performance in one mega comment thread. Retro action items that combine process, tooling, and interpersonal issues in one vague bullet.

Now I try to match my coaching rule: one variable per loop.

• One objective per feature slice. Ship just that.
• One main theme per PR review. Maybe this one is about data flow. Next one can be about testing culture.
• One concrete experiment from retro. Not five. One.

People learn faster when feedback has a single purpose. Kids or seniors, does not matter.

Reps beat explanations

With fourteen-year-olds, long explanations are useless. If I talk for more than 20 seconds, I lose half the group. If I talk for more than 40 seconds, I lose all of them.

The best coaching sessions are basically just reps with tiny corrections inside them.

Take infield work. I can either:

• Explain proper fielding mechanics for 5 minutes.
• Or hit 50 grounders in 10 minutes and coach one micro thing per player while they move.

Option two wins every time. Even when my explanation in option one is technically better.

Engineers like to talk. I say this as one of them. Design reviews, architecture docs, strategy meetings. We treat thinking as if it only happens in writing or Miro boards.

Coaching forced me to remember something basic. Understanding is not the blocking issue most of the time. Lack of reps is.

So I changed a few things in my engineering workflow.

• I push for smaller spikes that end with a working prototype, not a doc.
• I run more live pairing sessions instead of long review comments. Especially for juniors.
• When someone learns a new pattern, I try to line up three quick real-world uses of it within a week.

Knowledge sticks if it rides along with repetition. The U15 field makes that brutally obvious.

Emotion gates the feedback loop

One Saturday, our shortstop booted three balls in an inning. You could feel the shame hit him harder than the grounders.

Technically I knew exactly what was wrong. Feet flat. Not moving through the ball. Glove too deep. I could have broken it down on video.

None of that would have mattered. He was done. Brain locked. Feedback loop closed.

So I walked over between innings and told him two things.

• "You are still my shortstop."
• "Next ball, only think about getting your feet moving early."

He nodded. Not happy. But reachable again. Next inning he charged one and made the play. Same kid. Same mechanics. Different emotional state.

Engineering teams like to pretend we are hyper rational. We are not. Shame and fear wreck feedback loops in code just as fast as on a field.

The standout patterns:

• Public callouts in Slack kill curiosity. People stop asking questions because one bad take got ridiculed.
• Harsh PR comments make juniors default to copying patterns instead of thinking.
• Big post-mortems with heavy blame language make people hide risky information.

On the field, if I destroy a kid after an error, I basically delete my ability to coach him for weeks.

At work, if I blast someone in a retro or a PR, I do the same thing. The loop breaks at the emotional layer, not the technical one.

So I started doing what I do with my shortstop.

• I separate role trust from event feedback. "You are still the tech lead. This one decision, I think we need to unpack it."
• I give people a tiny focus for the next iteration, not a personality critique.
• I raise most sensitive feedback 1:1 first, then decide whether any of it belongs in a wider channel.

I am not talking about being soft. I care about performance more than ever. I just finally respect that emotion is part of the system, not noise around it.

Kids expose your broken incentives

My U15 team taught me an uncomfortable thing about metrics.

We started the season obsessed with winning games. Scoreboard thinking. I subconsciously coached to that. Bunt more. Avoid risky plays. Keep the ball on the ground. Hide the weaker kids on the bench in tight spots.

Short term, that works. You steal a couple of wins. Everyone feels like a genius.

Then you hit a team that is actually better. Taller. Stronger. Deeper. Your safe, conservative habits collapse. The kids that sat too much have no reps. The ones that never tried throwing hard cannot suddenly find the extra velocity.

I realised I was optimising for the wrong metric. The scoreboard is a lagging indicator of something else. Skill acquisition. Confidence. Decision quality. Communication.

So we changed the incentives.

• We tracked hard-hit balls, not just hits.
• We tracked good pitch selection, not just walks or strikeouts.
• We tracked aggressive, smart baserunning, even if it sometimes ended in an out.

Then I noticed: this is basically the velocity vs quality debate we have in software, just with cleats.

Story points, tickets closed, lines of code. These are scoreboards. They are seductive and mostly garbage as targets.

So I started borrowing from the baseball sheet at work.

• I pay attention to how often a dev seeks product context, not just how fast they ship.
• I look for reduction in rework rate over time. That is our version of better contact, not just more swings.
• I care about how many incidents someone helps resolve, even if they did not cause any of them.

Teams become what you reward. Kids just make that visible faster.

Feedback that sticks is physical and specific

One of my players could not keep his front shoulder closed when hitting. We talked about it a dozen times. Nothing changed.

One practice I grabbed a resistance band from my car. I hooked it from the cage to the back of his helmet. When he opened his shoulder too early, the band tugged his head gently. Immediate, physical feedback. His brain went "ah, that".

We used the band for 15 swings. After that, no band. Shoulder stayed closed more often. Something rewired.

That session reminded me how useless abstract feedback is compared to sensory, specific feedback.

In engineering, the closest thing to a resistance band is instrumentation.

• Feature flags plus metrics that move in near real time.
• Continuous profiling that shows the actual code path and cost.
• Visual diff tools for UI changes that show pixel shifts, not just CSS.

If a junior writes an inefficient query, a generic "watch out for performance" comment does almost nothing. A concrete profile screenshot that shows their query burning 80 percent of the request time is the head-tugging resistance band. They feel it.

I have started to ask myself a stupidly simple question when giving feedback at work. "Where is the resistance band here?" Meaning: how can I make this feedback show up automatically, through the system, not only through my mouth or a comment?

Usually the answer is some mix of logging, alerts, tests, or visual checks. Once in place, those tools coach everyone, all the time. It stops being personal.

Different kids, different loops

I have two boys on the team with almost opposite personalities.

One is all swagger. He wants the ball, the bat, the spotlight. You can push him hard and he feeds on it.

The other is quiet. Very technical. Very precise. I have to nudge, not shove. If I push him the same way I push the first kid, he shuts down.

They respond to different loop cadences.

• Swagger kid wants instant feedback and visible challenges. He likes competitions. "Hit five line drives before we stop."
• Quiet kid wants time to process and a low-pressure environment. He prefers, "Try this for the next ten swings, then tell me how it felt."

We talk about tailoring leadership styles in tech, but I think we underestimate how different people’s learning feedback loops are.

Some engineers thrive on rapid-fire reviews and frequent check-ins. Others do their best work when left alone for a day, then get one deep, structured review with clear themes.

So I now ask my teammates straight up: "How do you like your feedback loops?" Not as a fuzzy culture question, but as an operational one.

• Do you want async comments as you go, or a big block at the end?
• Do you like pair sessions or written notes?
• Do you prefer high-frequency tiny notes or lower-frequency deeper restructuring?

On the field I would never coach every kid identically. That would be lazy. Same thing at work.

Practice, game, and season maps to day, sprint, and roadmap

One last crossover that clicked for me.

In baseball, you naturally have three layers of feedback.

• Practice: micro loops. Fix a swing path. Try a new pitch grip.
• Game: meso loops. Did our strategy work? Did players apply practice skills under pressure?
• Season: macro loops. Are we actually developing better players, or just winning because one kid hit puberty early?

Engineering has the same layers. I just did not label them as clearly before.

• Daily work: code-level feedback. Tests, linters, PR comments, pairing. Tightest loops.
• Sprint or iteration: team-level feedback. Retro, metrics, demo reactions.
• Roadmap or yearly: system-level feedback. Customer retention, quality trends, team health.

Problems show up when you confuse the layers.

If I try to fix season-level strategy in the middle of an inning, the kids look at me like I am insane. "Coach, there is literally a runner on third. Maybe talk about long-term roster development later."

At work I used to drop macro product strategy feedback into daily standups. Or I tried to solve low-level code style issues in quarterly planning.

Now I am stricter about level separation.

• Daily standup: only micro feedback. Blockers, next steps, tiny process tweaks.
• Retro: meso feedback. Patterns that repeated. Experiments for next sprint.
• Quarterly or roadmap reviews: macro feedback. What the market says. How our architecture is aging.

Coaching forced that discipline. The field punishes you if you mix the layers. Product kind of does too, just slower and with fewer screaming parents.

Why I trust the dugout more than the boardroom

I do not think baseball is special. Football, martial arts, music, whatever. Any craft with visible performance and regular practice will teach you the same lesson.

Feedback is not a meeting. It is the system you build around reps.

Coaching U12 in the Netherlands just stripped the theory away for me. Kids do not fake understanding to look smart. They do not nod through a bad plan because of politics. They try, they fail, they succeed, they cry, they cheer. The loop is raw, noisy, real.

So when I design feedback on an engineering team now, I ask:

• Where are the reps?
• What is the one variable we are touching?
• How fast does the loop close?
• What is the emotional tax?
• Where is the resistance band?

If I cannot answer those, I stop pretending we have a feedback culture. We just have opinions with better vocabulary.

The U12 team does not care about my vocabulary. Which is partly why I trust the habits I learned with them more than whatever the next management book will say.

Grass stains are a pretty good filter.