Silos vs. Ownership
What's better, a very narrow, well defined scope or ownership of a problem? The answer to that, like so many comparative questions, is it depends. But first, what do those terms mean?
The term silo goes way back to when agriculture shifted from just in time/sustenance farming to commercial farming. It was a place to store all of a certain thing, and a place for everyone else to get it from. If you wanted grain, you went to the grain silo and bought/traded for some. You didn't need to care how it got there, and the people who filled the silo didn't care what you did with it. A very clean separation of responsibilities and both sides could focus on what they did best. The farmers handled filling the silo and the bakers turned the grain into bread.
In this context ownership is about the responsibility for something. It means you know who's responsible for getting something done. It shouldn't mean the person/team is doing everything.
Given that, what is better? Mostly it depends on how you define better. If you define better as "How can my team move the fastest?" then you want a really strong silo. You know what your inputs and outputs are, and you just build the best system for converting the former into the latter, You don't need to worry about anything or anyone else. It's up to those other folks to get you what you need and to take what you produce and do something with it.
On the other hand, if you define better as "How can I deliver my favorite feature to the customer the fastest?" you want to control everything. You want to control how the inputs are made (and everything that goes into them) you want to control how the feature is delivered. And you probably want to control the selection of features as well.
But there are problems with both. Silos, in the extreme, lead to building the perfect instance of whatever it is your building. That's good. As long as you're building the right thing. But if you aren't aware of what your customer is doing, you're probably building the wrong thing. And if all you do is demand a set of inputs, what happens when they're unavailable, or not available in the right ratio? You end up limiting what you can do because you're starved for inputs.
The other things silos lead to is a loss of responsibility. Everyone is responsible for their part and no-one is responsible for the whole thing. When you try to find out who is responsible for a change you want/need you don't get a straight answer. You get a lot of redirection and finger pointing that often turns into a circular dependency.
On the other hand, ownership has the opposite problem. It concentrates responsibility into one place, and that place becomes a bottleneck. Regardless of how much we tell ourselves we can multitask, there are only so many hours in a day, and there is a limit to how much can be done by that bottleneck. Context switching becomes hard, Things get lost in the context switch. Work gets serialized to make each part more efficient. At any reasonable product scale one person can't be responsible for everything and still be able to respond quickly.
So what's a developer or org to do? As I said at the beginning, it depends. You have resources and constraints and you want to maximize the output (customer value). Once you know what maximize means then it's just an engineering problem. And that's what we're really here for. To solve the engineering problems and maximize our customer value.
We do that by balancing silos (reducing blockers and cognitive load) with ownership (scope) so things keep moving AND continuing to re-evaluate the silos and ownership so that they work in service to the goals, not in opposition.
