> ## Content Index
> Fetch the complete content index at: https://ghostbabble.jshlabs.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# All Talent, No Playbook
- URL: https://ghostbabble.jshlabs.dev/athletes-in-tech/
- Published: 2026-10-10T04:59:12.000Z
- Updated: 2026-10-10T05:06:33.000Z
- Author: Ghost X

The longer I work in tech, the more convinced I am that a lot of people have never actually been on a team before.

I don't mean they haven't worked on a "team." Obviously they have. I mean they haven't spent years in an environment where five, ten, or twenty people have to prepare together, execute together, communicate under pressure, understand their individual assignments, and then immediately know when somebody completely fucked theirs up.

There are a lot of incredibly smart people in tech. There are also a lot of organizations full of smart people that are absolutely terrible at functioning as a unit.

Nobody knows the play. Nobody knows who owns what. Nobody practices anything. Every production incident turns into improvisational theater. Processes exist on a Confluence page somewhere, but nobody actually runs them until something is already on fire.

And every time I see this happen, I think about sports.

I was an athlete for roughly 20 years of my life, and one of the biggest things sports teaches you is how to function as part of a team when execution actually matters. Talent is useful, but coordination, preparation, repetition, discipline, and communication are what make a group of talented people effective.

A lot of athletes are naturally drawn toward careers like sales, marketing, finance, or management. Those fields tend to reward competitive personalities and people who are comfortable working directly with others. Engineering attracts a different personality profile, and while that has plenty of advantages, I think tech organizations often miss some of the lessons that are completely obvious to anyone who grew up playing organized sports.

Take football.

A football team doesn't walk onto the field every Sunday and figure out what everyone should do once the ball is snapped. They spend the entire week preparing for situations they expect to encounter.

They have a playbook.

They practice the same plays over and over again. They know who is responsible for what. They study film. They identify tendencies. They prepare for different defensive looks. They establish fallback options. The quarterback knows when to audible. Everyone understands that the play may need to change, but they also understand the structure they're changing from.

Then game day comes.

The reason a team can improvise under pressure is because everyone already understands the fundamentals.

Compare that with how a surprising number of engineering organizations handle production incidents.

Something breaks and suddenly ten people are in a Slack channel trying to figure out who owns what. Someone asks whether there is a runbook. Someone else starts looking through dashboards. Three people investigate the same thing. Nobody knows who is actually making the decision. Someone proposes a change that nobody has tested. Twenty minutes later a manager joins and asks for a status update.

Imagine an NFL offense operating like this.

The ball gets snapped and the quarterback asks in Slack who is blocking the defensive end.

It sounds ridiculous because it is ridiculous.

Yet tech companies routinely accept this level of operational improvisation as normal.

Athletes understand something that engineering organizations frequently forget: you practice so you don't have to think about the basics when the pressure starts.

That means rehearsing failure scenarios. It means having operational playbooks that people actually use. It means clearly defined ownership. It means knowing who makes the call when something goes wrong. It means reviewing what happened afterward and then changing the way the team practices.

And most importantly, it means repetition.

Engineers sometimes treat repetition as wasted effort. Once you've explained something once or documented it somewhere, everyone is supposedly expected to know it forever.

Sports teams operate in almost the exact opposite way.

Professional athletes practice things they have done thousands of times.

An NFL quarterback who has thrown a slant route since high school still practices throwing slants. NBA players who have taken millions of shots still spend hours shooting. Baseball players who have fielded ground balls their entire lives still take ground balls before games.

Nobody says, "We practiced this last quarter."

They practice because execution degrades without repetition.

There is another lesson sports teaches very quickly: everyone has a role.

Not everyone gets the ball. Not everyone calls the plays. Not everyone is the star. But everyone needs to understand how their responsibility contributes to the outcome.

Engineering teams often blur this distinction.

Ownership becomes vague. Five teams partially own something. Infrastructure owns one layer. Platform owns another. The application team owns the code. SRE owns reliability. Nobody owns the entire outcome.

Then something breaks and the organizational chart suddenly becomes part of the debugging process.

A sports team couldn't function that way.

If an offensive lineman misses an assignment, nobody argues that technically the defensive end crossed into another responsibility domain.

You missed the block.

The outcome matters.

Athletes also tend to understand accountability differently because sports provides brutally clear feedback. The scoreboard doesn't care how clever your strategy sounded in a meeting. Either the play worked or it didn't.

Tech sometimes rewards activity instead of outcomes.

We built the dashboard.

We created the runbook.

We implemented the process.

We deployed the platform.

Great.

Did the team execute better when something actually went wrong?

That's the scoreboard.

This is probably why I've increasingly thought engineering organizations could benefit from more people who grew up playing competitive sports. Not because athletes are inherently better engineers. They aren't. And I'm certainly not suggesting every engineering team needs to start running Oklahoma drills in the parking lot.

But there are habits that become deeply ingrained after years of competing on teams: preparation, repetition, situational awareness, accountability, communication, and the understanding that individual talent has to fit into a larger system.

You learn how to execute a plan.

You learn when to deviate from it.

You learn how to communicate under pressure.

You learn that practice is supposed to be repetitive.

And you learn very quickly that when everyone improvises independently, the team usually loses.

A lot of engineering organizations have incredibly talented people.

What they're missing is a playbook.