Coaching and Coding
I've been coaching my daughter's soccer team for more 3 and a half years now - 7 seasons in total.
We're just hours away from her first first game for the fall season and I've been struck with an epiphany: coaching is very much like coding.
For the last month we've been hard at work making sure we cover the basic requirements, and wrap things up with test scenarios.
As we grew more confident that we'd covered the happy paths, we focused on edge cases and broadened our test suite.
We've made a lot of assumptions about the depths of what we should cover - but, given the set schedule and hard deadline, we did the best we could in the time we had.
And now, we're ready to deploy into production. Or...maybe we aren't ready and we'll find out.
But ultimately, as any good coder knows: if things fail, they should fail gracefully. When things go wrong, we'll be learn from it, build on the experience, and continue to iterate. We've set ourselves up to fail-forward.
The truth is, the first game is usually rough. For both sides, generally - but one side may struggle more. When they're young kids, it takes a moment to adjust from practice-mode to game-mode. One of my favorite moments as a coach is when you see things "click" for the team. All the drills, all the reminders about where to stand, where to run, when to communicate, what to communicate - suddenly make sense, and they start functioning as a collective, as a team.
Coaching isn't just like coding. It's like management too. In fact, any good manager should see themselves exactly as a coach. Your success as a coach is determined by the autonomy of your team during the game.
If they're still looking to you for the basics, if you've failed.
If they're covering the basics, but you have to step in to help them adapt and adjust, you're doing ok - but you're still too invovled.
If they're covering the basics, adapting as needed, but you help coordinate - you're doing much better, but there's still work to be done.
When the team is covering the basics, adapting, and coordinating with each other - that's when you're successful. You've created a self-organizing team, and given them the tools to make you largely redundant.
Redundancy isn't a bad thing. Redundancy means you've created capacity. Managers turn to leaders when when they start looking at how to use that capacity. What problems are tackled - and how do you address it such that you're building the same redundancy that creates more capacity.
Rinse and repeat.
I started this about the similarities between coaching and coding and turned this into a post about management, because at the root of all these is the same question: Are you focused on the superficial output (Winning games, writing amazing code, organizing a team) or are you focused on impactful outcomes (empowering team members, building the right product, making work easier)?
