I’ve been playing adult recreational hockey (Beer League as its more commonly called) year round for about 5 years now. Currently living, and being born and raised, in the Deep South always gets me some odd looks when people ask what my hobbies are. Hockey just isn’t popular down here, and nothing can touch the juggernaut of Football.
In those 5 years I’ve: won league championships, skated so hard I thought I might die, seen tempers flare, shared in the excitement in the locker room after a big win, sat in silence after a hard loss and, have fallen on the ice more times than I can count.
I didn’t pick up hockey until I was well into my 20’s. I’m definitely not what you would call “impressive”. But, it’s one of the most rewarding parts of my life.
During the day I’m a Senior Software Engineer, a career I’ve happily been in for almost 10 years now. I love development, its also another majorly rewarding part of me life. Much like hockey, development too, is a team driven sport.
Here are some the of lessons I’ve learned about team work during my (extremely) amateur hockey career and, how it applies to my actual career. For those of you who aren’t familiar with hockey, don’t worry, I will break down the intricacies of the sport as best I can and how they relate to a real world software development team.
Everyone Has A Role To Play
Hockey is an extremely team oriented sport, with out a healthy team dynamic and culture your team simply wont perform its best. I believe this to also be true for software development teams. In a healthy team, everyone has a role to play and no one person can do it all alone.
Understanding the strength and weaknesses of the team makes a huge difference in how well your team plays. Positioning your team to take advantage of as many strengths and cover as many weaknesses as possible is a sure fire way towards success in both sports and engineering.
Knowing your strengths and weaknesses, knowing your role on the team and how it changes over time and, being honest about these things with your teammates and leaders can help build a super productive team. As much as us developers like to think we are super geniuses, we don’t know everything. You have to be honest with yourself and your team. Covering the gaps in skills can only help you in the long run. Allowing the team to be more productive and gives you the opportunity to learn from others and make that skill gap less large.
Put The Team Above Yourself
While it’s important to stand out and build a reputation for yourself. No one wants to play with a puck hog. Putting yourself above the teams needs, only doing things that make yourself look good and, throwing your teammates under the bus is not a recipe for a winning team on or off the ice.
As in hockey, the same is true for software development. Putting yourself above the team only builds resentment, ruins team dynamics and, creates a toxic environment. If everyone is only looking out for themselves it’s going to be hard to build a great product or deliver a critical feature.
Assists are just as, if not more, important than goals. Gretzky, Ovechkin, McDavid, these are all big stars in the NHL. Even if you aren’t a big hockey fan you probably recognized at least one of these names. These guys put up big numbers, score lots of goals and, most importantly, have earned the trust and respect of their teammates.
The respect and trust of their teammates is exactly why they’re so great. Its true that these guys have immense hockey talent but, without the backing of their teammates they wouldn’t be stars. They also recognize the importance of that teamwork and know when its better to support a team member instead of hogging the puck and trying to get a goal themselves.
You have to put the team above yourself. You’re all in this together. Being a good engineer isn’t just about how many features you can slam out, how many bugs you can fix or, how impressive your boss thinks you are. A good engineer should always be concerned about the team. The team’s wins are your wins and the team’s losses are your losses.
This of course, also means you can’t always be the Star player. Its better to give an assist and back up your fellow teammate(s) who might be better positioned to solve a problem. And to trust that they will do the same for you when the circumstances are different.
Once the team starts thinking of themselves as a collective, rather than a bunch of individuals fighting for the limelight, life gets a lot easier and work becomes a whole lot more fun. The team will be better aligned with its goals, ideas and solutions will appear more easily, team member turnover will drop, and it will be harder to rock the boat when the unforeseen critical issues rear their ugly head.
Call for A Pass
Hockey isn’t a quiet sport. The sticks slapping on the ice. Bodies and pucks slamming into the boards of the arena. These are all common sounds you’ll hear at a hockey game. Another one you might notice, if you’ve ever gotten the chance to watch a game in person, is that hockey payers yell… a lot.
They don’t yell in anger though. They’re communicating.
“Heads up!”
“Watch the crease!”
“Boards!”
They’re talking to their teammates to let them know what they’re missing or what they’re about to do.
While you probably shouldn’t yell at your teammates in the office or over Zoom (No one wants to deal with that). You should keep that same spirit of communication. Open a dialog with your team. Let them know what you’re about to do. Tell them you’re struggling with something. Share your ideas and solutions so your teammates can offer suggestions.
The last thing you want to do is build a silo. Communicate openly and honestly with your team to help foster collaboration and knowledge sharing. Not only will it help your team come up with better solutions it will make your work more enjoyable.
Protect Your Teammates
Hockey is famous for its fights. Searching for “hockey fights” on youtube will bring up hundreds of videos at all levels of the game. But why do hockey players drop the gloves and trade knuckle sandwiches?
It’s all about protecting your teammates. In hockey there is an unwritten Code. A set of rules of behavior that players instinctively know and follow. When another team’s player breaks those rules it can put your teammate in a dangerous situation, and consequences are sure to follow.
Now, don’t misread this, I’m not advocating for violence in the work place. The important take away from this is that you should strive to stick up for your teammates and expect them to do the same for you. We’re all human, we all make mistakes.
Sometimes things happen. A bug made it past testing or someone misunderstood the impact a particular change will have. If you haven’t caused at least one major event in your career your either lying or the luckiest person in the world.
You should strive to build a zero blame culture for mistakes on your team. Instead of throwing your teammate under the bus look at why this particular issued happened and what you can do, as a team, to ensure it doesn’t happen again. The only real mistake is one you don’t learn from. Discuss what can be done better next time. Do you need to add some more tests around this feature? Is there a process change you can implement to better understand the impact a change will have?
You want to build a culture where it is okay to make mistakes, a culture of trial and errors without fear of retribution. An engineer who isn’t in fear of his livelihood is going to be more innovative and productive. When they know the rest of the team has their back they will seek out different solutions, be more willing to experiment, and stick around longer.
Stay Disciplined
In hockey a “disciplined” player is a player that has few penalty calls against them. Penalties are measured in minutes, 2 minutes for a minor and 5 minutes for a major. A player with a high penalty minutes stat is considered “undisciplined” and thus harmful to the team.
In software should endeavor to make your team as disciplined as possible. If we consider critical issues, bad deployments, and other such things as “penalties” you should strive to create processes and tools to stop as many of those penalties as possible before they happen.
Unfortunately, there is no one single roadmap to accomplish this. A disciplined team will look different at every company, and even within a single company. There are a few things I think apply universally to a disciplined team however:
- A straight forward “definition of done”. What does it mean to call a task finished? Is it when the code is deployed? When the PR is merged?
- A clear testing strategy and, an automated testing suite. Your team needs confidence that the big refactor they just finished didn’t break any existing behavior or, that the new feature actually does what its supposed to.
- An honest peer review process. Rubber stamping change requests does nobody any good. The review process is the time to point out any pitfalls the author may have missed. It’s also the time to praise the author for their clean or innovative solution!
- A battle tested rollback strategy. When things do go wrong (not if, when) the team needs to be able roll back changes easily and quickly to get everything back in working order.
When something does pop up, you want the team to have the comfort in knowing they did everything they could to prevent it and that they have the back up and support of each other. Remember, protect your teammates.
The +/- Stat
Hockey is a chaotic, fast paced game. You’ve got a bunch of people with knives strapped to their feet slamming into each other at 10 to 20 miles per hour (16 to 32 kilometers per hour). In all this chaos its sometimes hard to know if you’re truly having an impact on the teams performance.
Hockey has an interesting stat called the +/- (plus-minus) stat. Its a pretty straight forward way of looking at the impact an individual player has on the team. For every goal scored for their team while that player is on the ice they get a +1. For every goal scored against their team while the player is on the ice they get a -1.
Instead of just tracking how many goals or assists a player has, you can look at their +/- stat and see what actual impact they have for the team overall. Everyone has a role to play and it isn’t always scoring goals or making assists.
Unfortunately, we don’t have official stat trackers in the engineering world. So it falls to us. Its important to understand your impact on the team at large. Your own personal +/- stat. This helps hold you accountable and helps you see any problem areas you may need to focus on or, may want to ask your teammates for back up with. It also allows you track your wins, the things you’ve helped with to bring the team to victory. Which can be especially important come annual review time to get that well deserved raise or promotion.
Conclusion
Whether its hockey or software the dynamics of a healthy team have a lot in common. Putting the team above yourself, knowing your role and the teams strengths and weaknesses, building a culture where its okay to make mistakes, and sticking up for your teammates are all building blocks to building a great team culture. A good engineering team will be able to tackle more challenges and be more productive than a dysfunctional one.
But what do you think? Do you play sports? What other lessons have you learned in your professional career from your hobbies and activities?