I’ve spent the better part of the last decade doing two things that, at first glance, couldn’t seem more different: maintaining WPGraphQL and coaching youth soccer.

One happens in front of a keyboard, the other on a field. One is about code, the other about kids. But over time, I’ve realized they’re surprisingly similar. Both are about people, systems, problem-solving, and patience.

And in both, I’ve wrestled with the same challenge: imposter syndrome.

On Imposter Syndrome

When I started coaching my son’s team nine years ago, the kids were four years old. Most had never played a sport before. My job was to explain the basics — which goal to score in, which color shirt was “our team,” and why running the wrong direction with the ball wasn’t ideal.

Fast-forward to now. I coach U13 soccer. 11v11, full field, tactics, and structure. The players are better than I’ve ever been. When the opportunity came to move up to coaching 11v11 (from 9v9), I was nervous. The field is twice the size, the stakes higher, and the emphasis starts to shift more from “teach the game” to “win the game.”

I told another coach I was worried I’d fail, that maybe I didn’t belong at this level. He said something that stuck with me:

“You’re a good problem solver, and that’s all these boys need.”

That hit home. These players don’t need a former pro athlete as their coach. They need someone who can identify problems and help them find solutions.

And honestly, that’s what building and maintaining WPGraphQL is too. Users don’t need me to be a perfect developer. They need a problem solver who listens, adapts, and helps them succeed.

On Belief and Empowerment

This past season, I set a personal goal for my U13 team: I wanted all 17 players on my roster, including both goalkeepers, to score at least one goal over the course of the season. While this felt ambitious, we achieved it!

That outcome didn’t happen by accident. I played kids in positions that weren’t their natural strengths, but gave them more because I believed they could handle it, and I told them I believed in them. That trust created confidence, and confidence created results.

One of my players scored his first competitive goal ever this season, in his fifth season playing competitive soccer. I’ll never forget the smile on his face.

It’s the same with WPGraphQL contributors. Many of them have submitted their first open-source pull request here. My job isn’t to do all the work myself, but to believe in them, guide them, and create a space where they can grow. When contributors see their code shipped to thousands of users, that same smile shows up, even if virtually.

On Failure and Learning

In both soccer and open-source software, I view failure as a First Attempt In Learning.

Failure is not only inevitable, it’s valuable.

When we lose a game, I don’t see it as the opposite of success. I see it as data.

Was our defensive shape off? Were we slow to transition? Did the other team simply execute better that day? Each answer gives us something to work on next week.

It’s the same mindset I use in WPGraphQL. A broken build, a regression, or a breaking bug isn’t a disaster, it’s feedback. It tells us where our assumptions were wrong.

The key in both cases is not to get emotional about failure, but to analyze it.

In soccer, I review match film.

In software, I review error logs.

In both, I ask the same questions: What went wrong? Why? And what can we do differently next time?

The worst kind of failure is the one you don’t learn from.

When players or contributors see that mistakes are just part of the process, they take more risks, they experiment, and that’s where real progress starts. Failure, handled well, builds confidence, not fear.

On Planning (and My Love–Hate Relationship With It)

Planning is one of those things I say I value, and in some areas of my life, I really do.

As a soccer coach, I’m almost obsessive about planning. Before every match, I build a spreadsheet with lineups, substitution rotations, and a log for goals and assists. It’s part data tracking, part fairness management.

If you made the team, you should get meaningful playing time. That’s my philosophy. I plan lineups carefully because I want the experience to feel fair for every player and parent. I want everyone to feel included and valued. Every player on my team has played the “9” at least once, for example.

But here’s the irony: when it comes to WPGraphQL, I’m not great at planning.

I’ve never been great at sticking to a roadmap. My brain tends to chase whatever’s loudest. If someone pings me on GitHub, Discord, or Slack saying, “Hey, I’m blocked and trying to ship this weekend,” that’s usually what gets my attention.

I’m a people pleaser in both worlds, but it manifests differently.

In soccer, that instinct helps me create a structured, fair environment for players.

In open source, it makes me a bit reactionary, chasing whatever community member needs help most, even if it means pausing the bigger plan.

I’m learning that planning and responsiveness don’t have to be opposites. The key is finding balance: leaving room for structure and spontaneity.

Some of my best coaching moments and best commits have come from unplanned situations, reacting thoughtfully when things don’t go according to the spreadsheet (or the roadmap).

On Feedback Loops

In WPGraphQL, feedback comes in many forms: GitHub issues, Slack messages, discussions, error reports, and even pull requests. They’re all signals that help improve the project.

In soccer, my data comes from a Veo camera. I rewatch matches, looking for moments that led to goals (for or against), or those “almost” moments.

One week, I noticed we conceded a goal because both center backs pushed forward after a throw-in, leaving no one to slow the counter-attack. We reviewed the footage, discussed it as a team, and adjusted our defensive shape. We didn’t concede another goal that way the rest of the season.

My take on version control for soccer: observe, analyze, patch, and release again.

On Leadership and Ownership

In both roles, I try to lead the same way: if we fail, that’s on me; if we succeed, that’s on them.

When the team struggles, I don’t point fingers. I ask myself what I could do differently to help them understand or execute. When we win, the credit goes to the players.

The same principle guides how I maintain WPGraphQL. If there’s a bug, I own it, even if the code came from a contributor’s pull request. The responsibility for quality and culture is mine. But when something great is shipped, I want contributors to feel proud of it.

Both Soccer and open-source rewards leaders who take responsibility and give credit away.

On What Really Matters

In open-source, we can measure adoption, stars, downloads, and traffic.

In Soccer, we can measure wins, goals and standings.

But my favorite metric in both, is joy.

A parent told me recently that his son, who usually burns out after the fall soccer season, wants to play indoor soccer this winter, the first time he’s ever wanted to keep playing. He said this season is the most fun his son has had playing soccer.

I want to create that joy in players. The love for the game.

That same feeling shows up when a developer tells me WPGraphQL helped them fall in love with WordPress again, or when someone new joins the community and says, “I finally understand how GraphQL fits into WordPress.”

That’s the kind of success that doesn’t show up on a scoreboard or a GitHub Insights graph.

Closing Reflection

After nearly a decode of coaching soccer and building WPGraphQL, I’ve learned that the two aren’t so different.

Both are about empowering others, whether they’re players learning to trust themselves or developers learning to build and contribute with confidence. Both require calmness under pressure, humility in leadership, and patience in progress.

And in both, the most rewarding part isn’t the goal or the release, it’s seeing people light up when it all comes together.

In soccer and in software, the real magic happens when people feel supported enough to take risks.

When they do, that’s when the beautiful game, and the beautiful code, come to life.