In the past 10 years I lived a shift of how software development teams operate. At the core of this shift a set of principles I choose to refer as "You build you run” following a common expression across different organizations. It is a consequence of a change of attitude of product engineering teams concerning the following principles:
Ownership: Teams make fast decisions but are contained to their domain. They own their decisions with all hands on deck, with everyone needed to make and support them. Engineers should have the same voice as Product, Design, Data and other disciplines.
Coordination: Teams are responsible of not causing harms to other teams. To do that they depend on external structures as Business Units, Focus Areas or Product Portfolio Management.
Platforms: Undifferentiated lifting is done by automation and code. From infrastructure to services that are consumed by other services and customers. All communication is done through clear APIs.
Autonomy: No model where development and operations are performed by distinct actors is useful. A service is like a pet: you own it, feed it, clean after it and make sure it is alive.
Awareness: Teams are responsible and aware of budget, input and output metrics and business impact. So they must have a way of track and influence them.
Direction: Go fast locally but with a direction that fosters evolution globally. Shared components, stack, databases, architecture approaches and documented decisions support the common evolution without hindering speed.
Teams are asked to move fast and deliver their objectives but they depend on many factors: to fence other teams dependencies and at the same time warrant what they need from them, organizational structure, culture, execution velocity and unexpected changes of market.
Advocates for Devops and its variations tried to show the value of breaking silos but they failed because you don't change culture without living its reality. Everyone understand the benefits of no silos but what can you do if your team is always catching up or if you work is oriented to due dates and legacy code ? Almost no “green field” projects come in and when they come, they fail.
There were still people to build and people to run, as shown by the common request of “We need someone from {devops, sre, cloud, production, ops} in the team to become agile and deploy faster”, meaning that software engineers could not spare the time to do these tasks. On the other hand, having each team to come with their local solution was too tribal to ensure a company was resilient and trustable.
These methodologies got stuck mostly because people advocating for them were not decision makers or were not involved on the ups and downs of such a big change. In some companies they weren't even in the critical product or customer path. It is hard to have such organizations and I saw Architects, DevOps evangelists, Cloud Engineers going away very fast after incidents or critical delivery times.
Production Ownership - given or acquired is the principle that emerged. Services, Product, Features that a team create or inherits have to be fully owned by them. That helps consider the time split between committing to big features, running services, tending to incidents. It is an incredible leverage that brings a team to the discussion table rather than execution channel.
That secret power changes how engineering team close to automation and infrastructure behaves. They become providers of Platforms and shared components, a stronger principle than just being gatekeepers of production. Instead of being the first contact on alerts and hands to deploy, they become builders of tools to support engineering teams to scale.
You would see software engineers moving to infrastructure teams, stacks that provided full automation and package management and the attrition between Dev and Ops around their “good practices”.
Building Platforms is the key principle to support Production Ownership outside of infrastructure teams. And Production Ownership is key for safe velocity and solid product decisions.
I've written a book called “The CTO Field Guide” that has a lot of actionable information and quick guides for tech leads. If you do, please check it at https://ctofieldguide.com. Cheers !