[laurowyn]

> when developers also think about how the app will run, the outcomes will be the best

Absolutely agree, but that becomes "engineering" in my view. I'm talking specifically about implementing functionality, not long term views and project direction etc.

> Even if you don't pick the platform yourself, you should make sure that the app integrates with it smoothly, hence the 12 Factor App principles can help for many of these cases.

Which is the role of the system integrator - to integrate the app with the platform it's to be run on.

> In my experience, this leads to knowledge silos, problematic communication, not thinking about Ops concerns during development either due to a missing set of skills or just not caring due to a lack of ownership about the outcome, and just generally a slowed down pace of development. > Now, there probably is a lot of benefit in specialization (e.g. Ops specialists that consult across different teams and projects to make everything more consistent), but in my eyes everyone should know a bit of everything and communicate freely

Absolutely agree. And I hate that this happens, which is why I try to learn about all levels of the tech stack and not just one domain. But I do feel like this is a people problem, not a tech problem or project problem.

If the team cannot communicate effectively, they're never going to produce the best product, regardless of who knows what, budgets, etc. Ultimately, these roles aren't a waterfall structure. Developers shouldn't throw things over the fence to system integrators, and similar to operations.

Instead, the whole team works together, in the same space, on the same backlog. If ops has a problem, it gets prioritised on the backlog. If developers are unsure of how to approach something, they talk to the integration or ops people. In an ideal world, the teams would rotate between roles regularly, so that everybody is aware of the issues being faced that can't be seen from elsewhere.

Based purely on my own experience, far too much priority is put on budget constraints and making money instead of making a product that a customer actually wants. And this often leads to the one person, many hats issue, which then cascades into a mashup of roles and chasing our tails. I've had a lot more success on projects where we've clearly defined who owns which layers of the stack than when the team are just left to fend for themselves.

> That said, "rockstar devs" or "DevOps" specialists (or whatever the current term is) also carry risks in regards to a low bus factor (everything hinging on them in certain orgs, vs spreading the knowledge), so it's all probably pretty situational and scalable to different degrees

Specialists absolutely have their place, but are not a fixed requirement. Just because a project chooses k8s, doesn't mean it needs a k8s guru to own that layer, merely that the project needs some knowledge in that area to assess the scale required and make the call on keeping it small and manageable, or getting a consultant in for a short time to design and upskill the team, or getting a dedicated DevOps person to make the impossible happen.

But again, there's no reason why all of this couldn't happen with a team size of 1, with that 1 person wearing many hats. The important thing in those situations is knowing which hat is which and prioritising appropriately. My suggestion is a high level model that can be morphed to fit the situation, not a fixed framework that everybody must follow until the end of time.