I share the same experience. I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "bac

I share the same experience. I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "backend/frontend", "dev/qa", "dev/ops" ,"engineering/business". For me the most effective thing that I see are cross-functional product teams that have their own goal to ship things and all roles within that team. Unfortunately not all software can be built that way and there is a lot of productivity loss, because you might not have enough work for some roles. Like ops engineer you will need at the beginning to setup infra and then he might be helping out here and there, but it is not going to be full time job on one project. Then QA might have "quiet days" because devs will have to work on things for couple days before delivering something. I understand huge enterprise companies that they want to have "QA" "Dev" "Ops" just as a pool of reusable people, because they have to hire them full time and keep occupied. What I see in the wild is that there are some long running projects that evolve all the time and those can be such teams as described earlier. There are ad-hoc projects that might pan out or not, maybe it would be better to hire freelancers, see if project turns into long runner and if yes, hire a proper team to work on it. All of that requires unfortunately a lot of knowledge and work and a lot of political power inside of a company...