Empower teams
I'm a maker at heart. I love pushing things online to gauge the reaction and response it generates. Ideally making a positive impact on some people's lives along the way.
But I'm also a shaper. When conditions are not ideal for making, we product managers sometimes need to pick up the broom and shape our organization to become more human-centric and product-driven. I (and a lot of people more clever than me) believe that the solution to life, the universe, and everything are empowered teams founded on a few fundamental pillars.
In the last couple of decades, I have tried and tested various models and paid close attention to how the world is shifting in the way digital products are built. I have been a team member, leading a team, shaping a product organization, VP of product, and back to being a contributor. This leaf here in my digital patch is a collection of the staple pillars in my tool chest for fostering high-performing product teams.
Respectful Communications
This is the core pillar and foundation on which all else is built. If we can't communicate respectfully, life and work become so much harder to deal with.
Google conducted massive research trying to figure out what set their high-performing teams apart from others. All the data they collected was random at best until they shadowed a new team that was founded based on extreme vulnerability and emotional safety. So one of the first links I share with people on the topic of high-performing teams is this New York Times article from 2016: What Google Learned From Its Quest to Build the Perfect Team.
Back in the early days of Meniga around the 30 employee mark, we had Jimmy Janlén over. He's an agile coach and was on-site for a few days helping us shape up our way of working. I learned so many things from him besides the basic agile concepts. Jimmy focused a lot on the human side, emotional safety, and the team-building aha moment that lit up a big part of my brain when I saw it first. The Tuckman's stages of group development, the forming–storming–norming–performing model. All of a sudden so much of the pain I had experienced from some of the teams I had been on made perfect sense. Today when I'm working with a new team, I try to pre-empt the storming phase by walking through this concept and getting everyone aware of the fact that building a team is hard and will take time. I find that when people understand these phases upfront, we move through them with more ease.
The best stints in my product life have been when I work with teams of diverse talents that have the psychological safety to speak up. Debate and even a healthy dose of argument is fine as long as people respect each other and can settle their differences. Bringing one bad apple into a high perfoming team can be detrimental. So focus on the communcations first and everything else will be easy. In my tenure as VP of product at Meniga, I screened for communications first in all my hires.
I have made huge mistakes when it comes to communications in the past. At times I have this uncontrollable urge and drive to deliver. I have tended to drive people too hard or bypass when things are moving too slow for my taste. In many cases, I also assume that people understand all the mess that is in my head and jump straight from A to Z without explaining how to get there. This has all led to hard learnings in my career. I try to improve and feel that letting down your guard, exposing your flaws upfront, and working with your team to compensate is an amazing resolution. This can be challenging for many Product Managers as they assume that their job is to have all the answers and be all-knowing.
I don't know if it's a good idea to reference sitcoms in serious matters like these, but if you haven't watched Ted Lasso yet, give it a go. I connected on a deep level because it's all about building a team in that first series and there are only a few minutes on football.
Purpose
The second most important thing to me is to develop a clear vision. Bring the whole team on a journey where every contributor has a chance to impact it and understand their purpose in driving it home.
I'm drinking most of the Marty Kagan Cool-aid. His books Inspired and Empowered switched my brain on like blinking Christmas lights for all the connections I made to my professional career. His piece on employees in product companies being mercenaries vs. missionaries is something I quote frequently and there is no need to repeat it here.
Empowering the team to develop and own the vision is the strongest motivator. Too many startups tend to hand the vision down completely from the founders and never fully harness the potential of all the brilliant minds we hire. Too many times I have seen tickets trickling down the org chart to engineers without any connection to the impact it has on the product and the people who use it. This will never attract or retain the talent required to build high-performing teams.
Mastery
Most of us want to get better at the things we do. During my stints in people management, I picked up on this dimension of the importance of fostering and encouraging people to grow and build that internal drive.
Running meaningful retrospectives and dedicating time for the whole team as well as individual contributors to become masters of their trade is so important.
Autonomy
This is perhaps the hardest challenge I've dealt with in the past two decades. I seem to join companies that are about to outgrow the two pizza staff parties and stay through the painful growth challenges. I have done this a few times now, made many mistakes but also learned a lot. I see the same pattern every time. When the product team grows beyond 12 people things start to crumble. Communications break down, processes no longer work, and maintaining respectful communications becomes a bigger challenge. My favorite number is 7. I later found that the sweet spot for a team is that size. Then I found out about the Dunbar number and its associated theories. We humans are a fickle species and there seem to be some fundamental circuits that shape us on a deep level. So keeping teams at a size where they can form strong relationships makes sense. I'm not expecting everyone to be friends in and out of work. Just that while you participate in making something awesome with a team, it's easier if you can manage the relationships in your head. Team topologies is a fascinating book for people going through these growing pains and trying to figure out how to design their organization around empowered autonomous teams.
Design
This one is not on all the other lists you find online and I've always been challenged on this. It's something I feel quite strongly about though and keep claiming that everyone designs. I'll write more about that later. In a product team that delivers some sort of user experience, I feel that all team members should contribute to design. When I say design, I'm not just referring to sorting pixels in Figma and picking colours. Everything we make is designed, we pick names for our children, decorate our dwellings and compose clothing selections that represent our style. How other people perceive us as humans. On the same note, I expect the whole team to have an opinion on the overall design of the applications we make. I have lost count of the number of design sprints I've facilitated. Some variation of a design sprint is in my mind the best way to kickstart an agile project with a team. Decide on a problem to solve and get every contributor to participate and put their design caps on to shape the best solution we can muster.
This is my recipe for an empowered product team. Just five ingredients! Easy ;)
Books
