How (and why) to democratize decision making in your dev team.
If the musical Hamilton is to be believed, there were only 3 men in the room when the decision about where the federal capital and national bank for the fledgling United States would be placed. The decision came down to a compromise between the 3 men, and the rest of the country had to live with their decision.
Nowadays, it seems that everyone wants to have a say in how decisions are made, not just in governments but in businesses, sports teams, and schools across the world. Of course, effective democracy still requires that a hierarchy be established so that decisions can be made quickly and absolutely. Successful governments & organizations find ways to receive input from their constituents without getting bogged down in bureaucracy and long decision cycles.
In a traditional development team, the hierarchy is well established. The Product Manager talks to stakeholders and customers, defines the roadmap and team priorities, and also guides the team with their day to day work and operations. This works well because there are clear expectations between team members on who is leading the team and who is responsible for key deliverables. Like coaches and politicians, successful Product Managers are able to involve their team in these decisions despite the fact that they will be responsible for the success or failure of the product.
As a new PM, I found this to be a difficult part of the job, mostly because of my disdain for open discussion and lengthy meetings. Being raised in the world of startups, I was taught that the faster we come to a decision in a meeting, the faster we can all move on and get back to work. Disagree and commit, as soon as possible. Right?
I found that the way I ran meetings with my team, however, ended in me deciding everything and hoping everyone was okay with it. And when I did open the floor for questions, the team was often too intimidated to challenge my decisions. So, in the end, I was faced with a dilemma: How do I create a space in my meetings for input and objections without resorting to unstructured discussion?
This is where team involvement begins. At the end of the day, the majority of product decisions are made based on customer feedback. In order to get your team involved in decision making, they need the context of how the product is being used, and it’s best to hear this first hand.
In our most recent round of user testing, I gave my team the chance to sit in user interviews & testing — I was still responsible for organizing and facilitating the interviews, but the fact that they got to witness the upside and pitfalls of the product from customers first hand gave them a new sense of product ownership and involvement.
There seems to be a growing movement these days, particularly in the startup world, to remove meetings all together and replace them with workshops. Companies like AJ&Smart have been pushing initiatives like this for a number of reasons, including the fact that your team can be in the room when the decision is made instead of just hearing about the decision through a meeting, Slack message, or Jira ticket.
Of course, it becomes hard for your team to share their unique perspective on customer issues if they only hear about them from you. At the same time, giving them context for decision making without structuring discussion through the form of a workshop might still lead to a lack of involvement and participation in meetings.
Working in some workshops in the place of your regular team meetings may take some creativity, and you will have to choose these moments strategically. After all, not every meeting can (or should) be replaced with a workshop. But provided with the right context, it will bring out the best in your team and bring up customer insights you yourself may have missed during the interviews and customer research.
Of course, not everyone will be as excited about the extra work and involvement that comes with sitting in interviews and coming up with creative solutions to customer problems. They may even argue that these extra tasks are outside their scope and that the PM shouldn’t be trying to skirt their responsibilities. There are many teams that function just as well with a strict hierarchy in decision making, after all.
To these people, I would point to the fact that team involvement is about more than just product success and team buy-in. It’s not even about leveraging the diversity of your team for insight & problem solving. It’s about career development and personal growth for your team members. If your team is never in the room where decisions are made, how are they going to grow professionally? If you truly care about your team’s personal and professional development, you should give them the chance to be part of the big picture, get context for decision making, and know where their work is coming from.
Time to let them into the room where it happens.