How To Break Departmental Silos By Forming Feature Teams

Imagine a seven year old playing the piano. She hits every note like it’s the only one, taking long breaks between each note. The play drags and listening to the singular notes is a pain. Instead of music, all you hear is a bunch of individual sounds, each one rivaling with the others to be the loudest one.
Now imagine the same play performed by the same kid five years later. The notes flow like a river, the emphasis not on individual sounds but on the whole sequence at once. Listening to the piece is pure joy, because every note works together with the others to create a beautiful experience.
Distributing your software development through separate departments is like a seven year old playing the piano. Every department works on its own, rivaling with the others to be the most important. The output is a pain for your customers and the quality is really poor. But how can we create an organization where the individual parts play nicely together? One way of making departments play together are feature teams. Let’s see how this could work out.

Feature teams are cross-functional teams

They consist of team members from every department involved in feature development: business analysts, developers, quality assurance, operations, and so on. Ideally, they’re co-located – working in a big room together or at least in the next room. This shortens communication paths and speeds up necessary information exchange.

Feature teams are responsible for a certain set of features or a specific service. At amazon.com every part of the website like recommendations or reviews are separate services developed by individual feature teams. Each team is fully responsible for the feature, from idea to operations. Any challenges that arise within their specific feature must be solved by the team.

Solving challenges is simpler in smaller teams

If you form feature teams you should keep them small. A famous quote from Amazon: “If a project team can eat more than two pizzas, it’s too large”. Keep your team between five to nine people. This will keep the complexity of inner-team communication as low as possible. You scale your projects by combining multiple small teams – each one fully responsible for certain features.

Embed every required skill within your teams to create a successful feature. This isn’t possible with all skill sets, but you should limit external party support as much as possible. External dependencies always slow down a team and increase complexity.

It’s all about reducing complexity

Trying to drive a feature through multiple departments can be quite a challenge. Every department has their own goals which usually conflict with other departments. Even if they want to help, they have a hard time understanding exactly how.

Building feature teams tears down those departmental barriers and joins people from every department into one team. This helps to create empathy and, more importantly, trust – the number one factor to speed things up in complex environments. Without trust, blame games and CYA tactics are rampant. Only if people know each other, have the same goals, and work together are they more likely to trust one another.

That trust thing sounds great, but won’t work for us

Let’s say you already have feature teams. This is often the case in so called “matrix-organizations” where every employee is part of a certain department but works in multiple projects. And with multiple projects, the problems start. The employees are supposed to serve multiple bosses: the project leads as well as their department head. Because they’re assigned to multiple projects, they usually find home in their department and give it the highest priority.

But giving the highest priority to the department is not what you want. Therefore it’s important to assign people to one and only one project. Make that project (and the feature team driving it) the home for your employees. The department should mainly serve as interest group.

Feature teams take responsibility

They’re fully responsible – end-to-end – for a certain feature or service. They’re small, co-located and they have all the needed skills to be successful. Feature teams act as the home base for employees as departments fade into the background providing mentorship for honing one’s skills. But the main, business contribution happens in the feature teams.

If you setup your organization like this, you’ll begin to see a nice flow of great feature releases – like a well played musical piece.