Don’t silo your team

I have worked in teams where a product manager (or someone equivalent) assigns tasks to developers. On paper, that works. And it’s likely done in the name of parallelizing work – “look at all the projects we’re working on at once!”

But in my experience, that top-down approach to assigning work has a huge downside: it discourages team collaboration.

When a product manager assigns tasks, every developer feels responsible for “their“ amount of work – especially in a company that rewards developers who finish more tasks. And that destroys collaboration.

I often see that lack of collaboration play out in code review.

When developers are measured by the number of tasks they complete, and when those tasks are assigned by a product manager, you’ll quickly find that developers aren’t doing as much code review as needed. Everyone wants their pull requests to be reviewed, but no one wants to do the reviewing. So, pull requests remain open for longer than necessary, and you’ll probably hear about it in retro.

Your team is divided because every developer is out for themselves. And of course, it’s not ill intended (or at least, it may not be). But your team’s incentives are working against collaboration.

By contrast, the best teams I’ve worked with see programming as a team sport. They share ownership of the codebase. And they see the team’s progress – not individual progress – the goal to be attained.

In those teams, tasks aren’t assigned. No developer is responsible for a task unless they take it upon themselves. And who better to know which task each one should take?

Many times, a task still lands on a single developer. Other times two developers choose to pair on a task. And yet other times, several developers collaborate to solve the difficult parts together but then separate to parallelize menial tasks.

A product manager can help list the tasks in terms of priority: the most important task is at the top, then the next, then the next. That is essential information for the team to have the most impact on the business.

But developers don’t need to be assigned each individual task – filing in line to receive their orders. Instead, trust the developers to work together to complete the tasks needed. That encourages the team to work on the solutions in whatever way they see fit.

When you do that, you will find that people are more comfortable doing code review because they’re treating progress as a team sport – the team is trying to finish the tasks, not each developer their own.

Of course, not assigning tasks to people won’t automatically make your team great at collaboration. There are other things needed – good communication, a willingness to work together, etc. But at the very least, you’re not hindering your team by creating a structure that actively works against collaboration.