Bazball: Lessons for Product Managers
Unleash your inner Kiwi
I love cricket, and Brendon McCullum is a bit of a hero of mine. He’s only about a year older than me, making that a moderately embarrassing admission, but really B-Mac should be your hero too.
Anyway, he recently became the coach of the England test team, and has overseen a sudden and substantial improvement in their fortunes. In cricket the captain does much of the work that a coach would be responsible for in other sports, like team selection or on field tactics. Consequently a cricket coach is more hands off, and rather than managing the team directly deals with strategic issues; building a positive environment, putting in place structures to support the captain, and helping them identify and resolve problems.
In my mind at least, this is not dissimilar to the relationship between a technical lead and a product manager. The tech lead is the captain, running the team day to day, assigning work, and helping them meet their immediate goals. The product manager is the coach, shaping the strategy, and helping the captain build a positive environment, but not telling the team how to do their jobs. Given that, I think there are some lessons any PM could learn from Brendon’s impact on the England team.
They get the credit, you get the blame
If the team wins, the players speak to the media. If the team loses McCullum does. They get the credit, he gets the blame. Wise Product Managers will follow this example, if the team messes up you need to take the flak for them, if someone in the team does something great, you need to make sure they get the credit. That may not sound very fair, but:
- Too bad
- This is an instance where doing the right thing and your own self interest are actually in alignment
Yes as PM you are the face of the team to higher-ups, but a product manager without a development team is just a man with a laptop, some sharpies and a pile of useless how to do agile books¹, so it’s only basic courtesy to make sure the team gets due credit for its work. Furthermore, if praiseworthy things start to happen more frequently after you arrive, you’ll get the credit for the overall improvement anyway, so don’t go hogging all the glory.
(Honest) Failure is allowed
A new mantra of the England team is that players will be given the freedom to fail, and won’t be dropped because of one bad performance or stupid mistake, the belief being that this will improve the overall confidence and performance of the team.
Fair enough, everyone makes mistakes, even software developers². The difference is that mistakes in test cricket are easy to spot, they happen on live TV and in stadiums full of thousands of people. In software the only way you might know a mistake has happened is if the person who made it is prepared to own up. This is why as the product manager you need to be prepared to take organisational flak for the team, it will help developers ‘fess up when a mistake has been made as they’ll be less worried about being pilloried for it, and will build trust within the team.
Be yourself
The final tenet of Bazball? Don’t micro-manage, let players play their “natural game”, let them decide their own practice and warm up routines, don’t treat them like children. Sound advice, but it has its limits. If a players natural game was to purposefully run out their team mates, or their warm up was downing a bottle of vodka, then I imagine they might find themselves out of the side.
The same goes in a development team. As PM your job is to keep the team focused on its goals, so don’t micro-manage, it’s pointless, counter-productive and bound to generate ill-feeling. However, this should not be mistaken for allowing destructive or unprofessional behaviour.
¹ Yes I am aware of the irony
² I know, shocking, right?
