What Is an AI Player-Coach?
May 22, 2026
What Is an AI Player-Coach?
The senior leaders who stay hands-on with AI aren’t going rogue. They’re building the credibility to lead what comes next.
Published May 2026
Summary: An AI player-coach is a senior leader — Director, VP, C-suite — who stays personally hands-on with AI while leading a team. Not to become an engineer. To close the gap between what you're responsible for and what you actually understand, and to build a culture where experimentation and even failing in public are modeled and rewarded.
What's in here: what it is, what it's not , how it shows up in practice across 9 real leaders from organizations like Superhuman to Nike to NEOM to the U.S. military, and how to start.
A VP of Product I know noticed her team was drowning in repetitive admin work. Status updates, ticket triage, weekly summaries — the kind of work that quietly eats 10 hours a week and nobody questions because “that’s just how it works.”
A 'pure manager' might have commissioned a process audit. Maybe bring in a consultant. Maybe add it to next quarter’s roadmap under “operational efficiency.”
She did something different.
She engaged her team in an audit of where they were spending the most time on admin. Took the top scenario and tried a few tools herself. She prototyped a solution in n8n because it was more visual — better as a strawman to react to. She documented her understanding of the process as she went.
Then she brought it to the team’s weekly automation hands-on meeting. Not as a mandate - as a draft.
In the meeting, the team reviewed her prototype, adapted the prompt, discussed edge cases and success criteria together. Later that afternoon, someone on the team let her know they’d already whipped up a version in Cowork — including the evals and edge cases, based on their discussion. She asked them to lead the demo in next week’s meeting.
She wasn’t the best builder in the room. She wasn’t trying to be. She got close enough to the work to ask the right questions, modeled what it looks like to try, and created the conditions for her team to take ownership.
That’s an AI player-coach.
A better alternative to 'the super-IC' for leaders
In their recent layoff announcement, Coinbase used “player-coach” to describe what they wanted from their managers during a round of layoffs. Skeptics were quick to jump on the framing as justification for cutting headcount. "Do more with less". Picture the manager who codes again because there’s nobody left to delegate to. And how can someone be a first-class individual contributor AND manage an ever-growing span of control (15+ direct reports, as mentioned in the Coinbase announcement)? It sounds like managers are being set up to fail.
That’s not what player-coach means. Not in the way it matters for AI leadership.
The real player-coach shift has been happening quietly for the past two years, and it has nothing to do with headcount reduction. It started when senior leaders — Directors, VPs, CPOs, CTOs — began getting hands-on with AI themselves. Not because they had to. Because they realized that leading AI without touching it is like coaching a sport you’ve never played.
I’ve been watching this shift up close. Over 61 episodes of The AI Product Leader podcast, I’ve talked to senior leaders across every industry — from Nike to Grammarly to NEOM to the U.S. military — who are living this transformation. The pattern is unmistakable.
The leaders who are making the best decisions about AI are the ones who build with it. The ones who are falling behind are the ones who still think leadership means delegating down and reviewing up.
What an AI player-coach actually does
An AI player-coach is a senior leader — Director, VP, C-suite — who stays personally hands-on with AI while leading a team. They prototype. They evaluate tools themselves before approving them for their organization. They learn alongside their team. They maintain enough technical fluency to ask the questions that matter, catch the problems that would otherwise ship, and make decisions with real understanding instead of secondhand summaries.
This is not about becoming an engineer. It’s not about writing production code. It’s about closing the gap between what you’re responsible for and what you actually understand.
Ailian Gan, Head of Agents at Superhuman, put it this way:
“There’s always this pull to just trust the team, hand it off. But with AI, if I’m not in it, I lose the intuition. And once you lose the intuition, you lose the ability to make good calls fast.”
That word — intuition — is the key. You can’t build intuition about AI by reading about it. You build it by using it, breaking it, evaluating it, and watching what happens when you change the variables.
“I can explain it better if I’m hands-on”
The most common version of the player-coach story I hear goes like this: a senior leader who has been around technology their entire career realizes that AI is fundamentally different from every technology wave that came before it. You can’t just read the analyst reports and set the strategy. The technology moves too fast, the failure modes are too unpredictable, and the gap between what AI companies promise and what the tools actually do is too wide to manage from a distance.
So they start building.
Bruce Randall spent 20+ years selling AI at Oracle, AT&T, and enterprise startups. He could pitch it, describe it, sell the ROI. Then he realized that selling it wasn’t the same as understanding it from the inside.
“I can explain it better if I’m hands-on than if I just read it in a book. I’ve been very successful in explaining that to people in ways that make sense because I’ve done it and I understand it.”
Bruce had never built an application before. He used Lovable to build a local SEO tool — a website scanner that returns keyword recommendations. “I never thought that I would build an application,” he said. “And by the time I was done, I had a functional application.”
Denise Hatzidakis, a CTO and CPO with 20 years in healthcare technology, went further. She enrolled in a Kaggle course that required building a RAG implementation in Python — a language she’d never written. She describes it becoming “a personal vendetta” to finish.
“I put my hands on it. I’m an active learner and I think especially with AI — especially for engineers — you have to do it, because it’s a different way of thinking about solving the problem. You’re very conditioned to if-this-then-that and we’re not conditioned to explain what you want as the outcome.”
Why would a CTO with a background in computer science, physics, and electrical engineering go back to writing code from scratch? Her answer is the player-coach thesis in a single sentence: “I lead engineering teams and I think it’s important to be able to understand what they’re doing, what they’re talking about, what their challenges are — and help guide because it is different.”
The meeting that changes everything
One of the clearest patterns I see across these conversations: the moment a senior leader shows up to a meeting with something they built, the entire dynamic changes.
Rebeca Assunção, a Senior PM at NEOM — the Saudi-funded project building a city from scratch — had stakeholders who were unclear about what complexity a booking system actually required. She didn’t write a memo. She didn’t schedule a follow-up.
She built a working prototype herself. In five minutes.
“I created some prototype that was working. For example, the first one was like a very small, easy kind of booking website… I did this in five minutes. So with your expertise now, we can do it better. So let’s do it together.”
That last line is the player-coach move. She didn’t build the prototype to prove she could do the vendor’s job. She built it to set the terms of the conversation. “I did this in five minutes. With your expertise, we can do it better.” The vendor can’t hide behind complexity when the leader has already demonstrated what’s possible.
Zak Wiatr, a product leader at Transact Campus and former Air Force intelligence officer, took this even further. At a conference, with no laptop — just his phone — he opened Claude and generated a working dashboard with drill-downs and clickable tables.
“I just had Claude whip up an artifact and you’d see the lines of React code running and there it is on the phone — the dashboard, the drill-downs, the tables, the details, the clickable. And that was another ‘have you heard the good news?’ moment. Just to prototype it on your phone in real time. It’s crazy.”
The prototype wasn’t the point. The point was that the person in the room who understood the problem best could now show it, not just describe it. The gap between “I have an idea” and “here, look at this” has collapsed. Player-coaches are the ones who have closed that gap.
“No matter your level, you will gain by being hands-on”
The player-coach shift doesn’t require a technical background. Some of the strongest examples I’ve seen come from leaders who had never opened a terminal.
Kelli Klein spent 14 years at Nike in operations and technology management before pivoting to nonprofit work on wildfire safety. She had never written a prompt.
“No matter your level, you will gain by being hands-on.”
Kelli personally built and tested a wildfire home assessment advisor, starting with ChatGPT. She hit its limitations herself — “we almost immediately start running into a few limitations” — then evaluated Voiceflow and Typeflow as alternatives, and made the platform decision. Her entire learning arc — from “I didn’t understand what a prompt was” to evaluating AI platforms for a mission-critical application — happened because she chose to do the work herself.
Maggie Mae, former CPO at Tomo and AudioEye, had a similar starting point. “I had never used a terminal before Claude Code. Like, I had never opened one.” Now she runs four Claude Code terminals simultaneously on different client projects, and moved a client to the top of AI search results in approximately one hour using tools she personally built.
Her principle is direct:
“You cannot consult on something you don’t personally build with. Your clients will find the gap.”
That gap — between what you claim to understand and what you’ve actually done — is the gap AI player-coaches are closing. And the people on the other side of the table can tell the difference.
What player-coach is NOT
Player-coach doesn’t mean:
“Do everything yourself.” The VP who prototyped the admin automation didn’t build the production version. She built enough to ask the right questions, then created space for her team to take ownership. The player-coach prototype is a conversation starter, not a final product.
“Become an engineer.” Bill Takacs, a VP who leads both product and engineering at his company, described committing code for the first time in years using AI assistance. His framing was precise: “By no stretch of the imagination, a developer in that context.” The bar isn’t engineering-level skill. It’s enough hands-on fluency to collapse the distance between your decisions and their consequences.
“Headcount reduction disguised as empowerment.” This is the Coinbase version — and it gets the causality backward. Player-coaches don’t emerge because you cut their teams. They emerge because AI has made it possible for senior leaders to directly engage with the technology they’re responsible for, in ways that weren’t possible two years ago. The best player-coaches have full teams. They’re more effective leaders because they build, not instead of leading.
“A phase you grow out of.” Staying hands-on isn’t a temporary measure until you “get up to speed.” Ailian Gan runs her own model evaluations every week. “Every week I try something new. Even if it’s just playing with a new feature in ChatGPT or running a test in Claude. Because if I stop, I fall behind. The gap between where the tech is and where my understanding is grows really quickly.” The technology moves too fast for one-time immersion to be enough.
The player-coach advantage in three moves
Across 2 years of podcast conversations, the player-coach advantage shows up in three specific ways:
1. You catch what others can’t see.
When you’ve personally used the tools, you develop pattern recognition for failure modes that no status report can give you. Patty Boland, a VP in hyperautomation, exemplifies this mindset: “I won’t recommend a tool to a client or to my team until I’ve tried to break it myself. I want to know where it fails, what the edge cases are, what the prompt engineering looks like in practice.” (Episode 16)
2. You set the terms of every technical conversation.
When you can prototype, you’re no longer at the mercy of vendor timelines, engineering estimates, or consultant recommendations. You have your own data. Rebeca’s five-minute booking prototype changed a vendor conversation. Zak’s phone prototype changed a conference hallway conversation. Dave Stys, a PM at Aweber, personally added an MCP tool integration to a live product, demoed it at the company’s demo day, and an engineer picked up his code in the next sprint. (Episode 41)
The prototype shifts the conversation from “could we do this?” to “I already did a version — how do we make it better?”
3. You model the behavior your team needs to see.
Your team watches what you do more closely than what you say. When you’re the most senior person in the room and you’re willing to be a beginner at something new, it gives everyone else permission to try.
Patty Boland again: “When I’m figuring something out at the same time as the people I manage, that changes the dynamic in a good way. They know I’m not just telling them what to do from on high.” (Episode 16)
Dave Stys describes his team’s culture: “Be competitive. There’s a couple of us at work and we get mad if somebody else did the prototype before you did.” That culture didn’t come from a mandate. It came from a PM who puts Netflix aside a few nights a week and instead spends time building in Cursor — not because anyone asked them to. (Episode 41)
How to start
The player-coach shift isn’t a skill. It’s how you show up.
It’s the willingness to prototype something imperfect and bring it to your team instead of waiting for a polished solution from someone else. It’s choosing to be a beginner at something new while being the most senior person in the room. It’s knowing that your team watches what you do more closely than what you say — and acting accordingly.
The leaders I’ve seen make this shift share three things: curiosity that overrides their ego, persistence through the discomfort of not knowing, and a genuine excitement about building — even when (especially when) they’re not the best at it.
You don’t need to be an engineer. You don’t need to quit your job. You don’t need permission.
Pick a tool. Pick a problem. Build something. Show it to someone.
That’s how it starts.
Polly Allen is the founder of AI Career Boost and host of The AI Product Leader podcast. She spent years leading AI at Amazon Alexa before building the AI Career Boost Blueprint, an 8-week program for Director+ product leaders becoming indispensable AI player-coaches. Subscribe to The AI Player-Coach newsletter →
