👋 Hey folks, I'm looking for a couple of feedback 1. I'd like some feedback on a possible setup for a platform with two distinct teams: one focused on maintaining the current capabilities, and the other on innovation, building new capabilities and, once adopted by the company, handing over their maintenance to the first team. Could this work? 2. Another question: when it comes to managing specific tools (e.g., message brokers or observability tools), would it be preferable to have a single team responsible for the end-to-end, or is it an acceptable setup to have split ownerships based on different layers? (e.g., an operations team that updates the agents of a specific tool across various K8s clusters, and another team managing the actual use of the tool across the company).

1 is what happens quite often. Yes it works. No, it’s not a good setup

Thanks for your reply! May I ask you why?

Because results are that the team that build new capabilities often don’t have enough knowledge how to build them to be maintainable as they don’t maintain them, and don’t even have interest to build them maintainable as they don’t maintain this. And the other team - that maintains this, get projects to maintain when it is very late to do any significant improvements. And you won’t have good engineers for this other team as just maintaining is boring work, often quite manual (also because the first team, who made the project, didn’t do it to be maintainable), and because doing maintenance is almost never honored well in a company.

To add to what @Mykola Dzham said, this set up has been applied in product development a lot - often because R&D can be accounted differently to maintenance, or from the belief that the "best developers should work on innovation". The handover of innovation to maintenance is one of the symptoms of the mistaken belief that the code is the value. The best teams have worked out that the knowledge is the value. While you can hand over code, there is no lossless way to transfer knowledge. There may be documented explicit knowledge, but also plenty of highly valuable tacit knowledge that will simply be lost. This sometimes looks like either the innovation team not thinking of long term maintenance, or the maintenance team not being as good at development. Often neither is true, it's simply what happens under these conditions... 1. The innovation team never gets the feedback that would inform maintainability, the pain loop isn't closed 2. The maintenance team doesn't have the deep knowledge or confidence to bring code they don't feel they own into a maintainable state, so they just apply fixes in situ The environment is preventing learning and action to improve this.