Feature Teams or Component Teams? Break silos instead!
Debating about Feature Teams vs. Component Teams is actually completely missing the point
What’s best: Feature Teams or Component Teams?
This is the perfect heated debate starter.
Everybody has a take on the topic. Of course Feature Teams are better because they focus on actual business value. Of course Component Teams are better because otherwise tech goes wild and technical debt accumulates.
Myself, I am a big proponent of Feature Teams and deeply believes that it is a better way to go than Component Teams because they help focusing on what really matters.
But getting Feature Teams to work is plain hard.
First of all it is hard because it requires a big mindset change from the people in the team. They got to think in terms of value and time-to-market instead of busy-ness. They got to start widen their abilities, not necessarily becoming jack-of-all-trades but at the very least just dismiss any inhibition that prevents them from going out of their core area of expertise.
And then it is hard because the product maintenance can quickly become a mess when everybody & every teams can touch everything from their own initiative and incomplete point of view.
These hard things are at the core of the arguments against Feature Teams. Indeed Component Teams allow an easy life where you don’t work differently, where you can keep thinking in terms of busy-ness, and where ownership is clear and thus maintenance is easy as pie.
That’s also why some will say that getting Component Teams right is the first step to get right before dreaming of amazing Feature Teams.
Well… It’s right. Getting Feature Teams to work is really hard. The thing is, the hard things are not tied to Feature Teams.
These hard things are actually what must be taken care of to really improve the situation. In short: it’s all about breaking silos.
I think we all agree that focusing on business value is much better than making sure that we are all busy.
Moving to Feature Teams without changing the mindset will only provide marginal improvements — if at all. I grant you, however, that structuring in Feature Teams will be a great catalyst on this mindset change.
Yet this is not specific to Feature Teams. Truly working Component Teams have adopted a service mindset, fully aware that they are not building value on their own, and thus putting themselves in the best possible position to help others getting to this value.
The point is, what you really want is to break silos between the various trades involved into building the whole product.
Feature Teams support this pretty well, but it is possible to create Feature Teams that fail miserably at it, and it is also possible to see an incredible mindset change that allows Component Teams to break free of these silos.
The real question is not about whether the most important concern is business (Feature Teams) or tech (Component Teams).
The real question is how do you make sure both business and tech are taken into account.
That’s why the solution usually looks like a matrix organization. For instance, in my opinion one of the most important elements of the well-known Spotify tribe organization is the chapter: while the teams (or squads) have a really strong focus on the business, the chapters make sure that individual developers share a lot with their peers in other teams.
Without the matrix organization, Feature Teams are bound to fail, because, yes, tech stuff is very important, but also very hard to get right at scale.
Likewise, there is no reason why Component Teams would not be able to strive if they also had a really strong governance geared towards business as part of some kind of matrix organization.
In the end, as long as you keep teams as separate silos, you’ll run into problems.
You need to facilitate this in order to not have the silos. That’s making sure your organization is a matrix organization focusing at the same time on business and tech. And both dimensions of the matrix must be really strong and living — both dimensions are essentials!
Arguing between Feature Teams and Component Teams is simple. It doesn’t change much if you don’t address the really hard topics.
Yet if you can address the hard topics, you’ll reap awesome benefits, whether you are using Feature Teams or Component Teams.
Don’t break silos to build other silos. Break silos and make sure there is no silos anymore.
I’m still convinced that Features Teams is the way to go. But it’s in no way magical: you’ll have to address the hard stuff anyway to get some real improvements. The biggest rewards are always hard!