> Back in the day, front end, back end, operations, and DBAs separated because they needed different skills. Now we accept that a software team needs all the skills. We group by responsibility instead — responsibility for business value, not for activities
> We once layered by serving data to software. Now we layer by serving value to people.
This is a nice narrative for the rise of developer products, where there used to not be a market.
You get large advantages in having teams built around specialized functions, however at the cost of lower cohesion.
Business verticals will trade all sorts of advantages for that cohesion.
There's tension in finding the right mix, the book covers it much better than I can but it's interesting to see parallels in tech stacks as well.
Is that cohesion within the team, or across teams (in the company as a whole)?
If the problem domain is adequately handled by generalists that's not a problem. But in situations requiring specialized skills it means needing to rely more on specialty contractors who keep your system from crashing when you go past the complexity threshold. As a specialist contractor it's very much in my interest to promote teams with "all the skills" because it means I won't be wanting for work.
This allows you to have a self-contained micro-team that can approach each value-add opportunity from the perspective of the overall solution, without any of the bureaucracy of communicating with someone outside of the team.
Dev products do not solve issues of bad architecture. It will be same struggle but in more strong form.