# How a Culture of Data-Driven Conversations Can Support Platform Engineering > Source: > Published: 2026-06-04 11:54:00+00:00 To provide SRE as a service, their team built a center of excellence, introducing Federated SREs, and roles like production manager and technical tribe lead, Sergiu Petean explained in the video [From Legacy to Sovereignty: Driving the Future of Insurance through Platform Engineering](https://www.infoq.com/presentations/insurance-platform-engineering/) from his talk at [Dev Summit Munich](https://devsummit.infoq.com/conference/munich2025). They created a culture of data-driven conversations where SLOs and SLAs were democratised. Surviving growing cognitive load meant continuously simplifying architecture and embedding sovereignty and resilience into every platform design decision. Platform engineering has to be approached from a socio-technical perspective, and shaped by all stakeholders, not just developers, Sergiu Petean explained in [Driving and Measuring the Impact of Platform Engineering](https://www.infoq.com/news/2026/04/measure-platform-engineering/). Platform success depends on written principles that endure change while embracing change as the main design force, to enable teams to build, run, and release software. In their platform evolution, to provide SRE as a service, they established an SRE team that had the assignment of redesigning the observability stack. They defined the process and the tools, which was easy, Petean said. It was much harder to have an exchange with the stakeholders who were consuming the new services: We had to become a center of excellence, and educate the organization on how to automate their needs into the process, and make the whole feedback loop work for them. They also started measuring the impact both operationally (DORA metrics) and financially (cost per change), Petean mentioned. Petean mentioned that during this SRE evolution, they had to define new supporting processes and functions: - Federated SRE: an internal community of software engineers spending 20% on Operational tasks (vulnerabilities mgmt, SRE, SLAs, CICD extension, APIs) - A new role - production manager: a technical person centralising and owning the full Incident Management process (reporting, reacting, improving, SLAs) - A new role - the technical tribe lead, a technical person sitting next to the business decision maker in a tribe The new roles had to be given the authority to go to the engineers and say what was important for the business and operations, to become platform evangelists, he explained: Through SRE practices and the new Federated SRE role, I created a culture of data-driven conversations where SLOs and SLAs were democratised for the whole organisation. That empowered the Federated SREs to better look after the business needs like costs, security, performance and compliance. They became our emissaries and supported the business case for a 20% mandatory investment from every business squad. When they created a reference architecture for AI cloud-native, the team became a multi-platform team. The team could not grow; they had to do way more with less: The same team had to take care of several platforms while we kept more or less the same size and talent. The cognitive load of the platform engineering team reached new heights. As a platform team, you have to become an influencer on digital capabilities (tech, business, integrations, security, and compliance) and operations (operational model) related decisions, Petean said. To survive, you have to continuously simplify everything, he explained: We destroyed and rebuilt our architecture at least four times. We seized any change opportunity: create a new tenant, support a new line of business or program, or migrate to the cloud. It worked perfectly for us. It gave us the chance to change things that normally never change, e.g., the platform architecture. Sovereignty and resilience need to be part of every conversation and embedded in the design of your platform, Petean argued. When you design your next platform, you should think about a sovereignty strategy and how fast and how expensive it will be to move from a hyperscaler to a private cloud or a data center. Digital sovereignty is a must-have to consider, he concluded. InfoQ interviewed [Sergiu Petean](https://www.linkedin.com/in/peteanusergiu/) about cost per change and sovereignty. **InfoQ: How did your cost per change go down, and what caused this cost reduction?** Sergiu Petean: A few things aligned very well for us: - Platform effect: we added more [services, tenants] with no extra computation costs nor talent costs - Expertise maturity: we simply had more senior platform engineers with the holistic view being more productive; our retention was 100% due to a great culture - Federated SRE: we designed our platform as a self-service from day one and invested massively in sharing and empowering our stakeholders to do more alone. - Massive business scaling: our business grew massively, serving more customers in more markets. **InfoQ: What can companies do to achieve sovereignty and increase their resilience?** Petean: A few technical and operational simple, yet extremely difficult, political actions, made the difference and set the course for sovereignty: - Innovation sovereignty: acquire the capacity to create. This means hiring internal talent and creating a culture of innovation. It is the opposite of treating IT as a cost center and always trading the quality for the fast gains. - Technical leadership on board level: add board-level stakeholders who fully own the strategic role of technology