Building better teams with a simple thought experiment

What kind of world would we want if we did not know what circumstance we were born into?

This is a thought experiment called the Veil of Ignorance by philosopher John Rawls. All of the research into this thought experiment shows the same result: people end up with systems that have respect, equity, compassion, humanity, and justice at the core.

Joost Minaar recently wrote a blog about translating this to the corporate world and ultimately to teams with the modified thought experiment:

What kind of team would we want if we did not know what roles we would play in the team?

I really like this idea and I thought it would be good to document my thoughts on how teams would work differently.

Respect

I've heard people call designers "the colouring-in department", testers have been belittled as low skilled, developers are often characterised as introverted and socially-awkward. Are there roles in your team that demand more respect than others? How can we get team members to remove the unwritten stereotypes and hierarchies to understand and appreciate the input of everyone? After all, it takes a team to build a great product.

Compassion

Have you ever heard of the acronym PEBDAK - Problem exists between Desk and Keyboard? I've talked to many teams where they are almost hostile towards users. But if you're just building what you're told to build it isn't really your fault if it is not usable or wanted anyway. How can we design teams to really care about the challenges that users face to the point that they will take on extra work to make life easier for users?

Equity

I remember being bitter that a colleague got a promotion because he shifted his focus to work on an opportunity he was interested in which left me, and the rest of the team, to pick up the slack he left behind. The lesson we all learned from his promotion was that it is better to put yourself above the team. Do your teams reward the "hero", or do they reward the teams that deliver?

Humanity

Stress isn't just caused by having a lot on. Feeling helpless is a much bigger cause. We ask teams to provide estimates, which they begrudgingly do with lots of caveats. The estimates are then padded using a finger-in-the-air methodology to try to cover the caveats. But even then we are mostly wrong and teams are held to estimates that they knew were wrong.  Burnout is a serious and growing issue in tech. How could we motivate teams to push themselves but still have them in control?

Justice

I worked at one place where our stage gates were killing us - the amount of documentation required was a huge burden. But the functions within the team insisted on it because the documentation was how you avoided blame when things took longer than expected. When the self-fulfilling delays occurred everyone would point fingers at everyone else. How could we design a team where individuals weren't held responsible for a team failure and the team was focused more on delivery than covering their ass?

How empowered product teams solve these issues

Empowering product teams and holding them accountable for results instead of outputs can solve a number of these issues. Teams need to be really understand their users if they want to achieve the behavioural changes that would lead to the desired outcomes . Wasteful activities are removed when the team learns that the team is responsible, not individuals, if goals aren't hit. And estimates become less important. The objectives that the team are accountable for provide the motivating force, not artificial deadlines.

For product teams to be successful it is critical that everyone knows what needs to be done. The team works as one unit so you need to approach it from a systems perspective to ensure you are optimising in the right areas. This increase in awareness of the contributions of each team member helps to build respect and camaraderie.

And finally, but very critically, you need to design your incentives to reward the team over the individual. All your good work can unravel very quickly if self-interest and team-interest aren't aligned.  

If you want learn more about how you can structure product teams checkout our training course on Enabling Autonomy.