I’ve spent a lot of time in youth sports—not only as a parent of two boys aspiring for the big leagues, but also as a coach, and even a president of my local Little League. This experience has given me a unique view into what makes all teams—not just sports teams—successful. Whenever I consider the successful teams I was a part of, I always come back to four basic lessons.
1. No one starts out as an all-star.
The best teams understand developing their players is vital to long-term success. Going for the short-term win can put you in a position where you’re relying on the star player to score the goal or get the strikeout at a crucial point in the game. This leads to your star players getting more playing time, while the players that could really use the additional time are stuck on the bench. The result is your best players get better, while everyone else only gets discouraged.
Skill development isn’t limited to sports—it’s applicable to all teams. In the case of software development teams, it’s common for a “star developer” to have complete and exclusive knowledge of large swaths of a codebase, often because this person originally wrote the code or has worked with it for a long time. Leadership can view having anyone else work with the code as risky, which leads to problems when the “star” leaves the team.
2. Know when it’s time to step up to the plate.
There’s nothing worse than watching coaches, parents, and players blame a loss on a bad call by a referee or umpire. I would argue that bad calls—whether real or perceived—provide the most teachable moments in all of youth sports. After all, life isn’t fair, and learning how to recover from a setback is a key life lesson. When the best teams lose, they focus on what they could have done better, not on poor officiating.
Blaming external forces is not uncommon for developers, either. Whether it’s blaming one another for bugs, customers for changing their minds, or users for doing something different, finger-pointing is disturbingly common. The best teams understand these problems are a fact of life, and they take the opportunity to learn from the situation. Maybe the problem is impossible to completely avoid, but perhaps there’s a way to reduce the likelihood of it arising again.
3. You can’t fill the bench with one position.
Often, good players aren’t a good fit for a good team. This can happen for multiple reasons: only so many players can play at a particular position, a coach’s style may be too disciplined or overly casual, or a player may feel overshadowed by his or her peers. The best teams are made up entirely of players that are in the right situation, where everyone feels like they belong.
This is true of software development teams as well. For example, a developer may not be interested in the product being produced, or perhaps he or she really dislikes the technology being employed—sometimes personalities just clash. These situations can make team members question their self-worth and keep the team from operating at peak efficiency. The best software teams identify people who are marginalized—whether through actions by the team or by the individual. Then they work to integrate them more effectively into the team, or, failing to do so, decide to part ways.
4. A good coach can change the game.
Good coaches are the nuclei that hold good teams together. Without a good coach, there’s no one to guide player development, no one to teach the team accountability, and no one to make sure a player isn’t relegated to the bench.
Software development teams benefit greatly from a good coach for the same reasons. Maybe this person’s title isn’t “coach,” but they are responsible for holding the team accountable, developing their skills, and getting the most out of every developer.
When I first got involved with my children’s sports teams, it was because no one else was willing to coach. I’m glad that I took that opportunity though, because now I realize how the act of stepping forward made a big impact on my professional career.