Team Ownership

Micromanaging development teams never works well because software development is just too complex. The better model is to enable teams to take ownership over the software they develop. However, that requires the teams to have agency. Teams need to be able to take action and observe the results of these actions. They need a closed feedback loop. This requires clear boundaries and responsibilities. Handoffs between teams blur the attribution between actions and results and instead create large and slow feedback loops that span multiple teams and require coordination outside of the involved teams. Teams with ownership are not controlled from the outside but instead organize themselves while also listening to feedback from other teams. They take ownership over the following aspects:

Product Ownership

Development teams operate within the context of a bigger product strategy and need to align to it. However, a lot of product decisions are not strategic and can be made within a development team:

• Measuring product usage via telemetry
• Collecting direct user feedback
• Prioritization of features and maintaining a roadmap
• Coordinating the release of features
• Building up expertise and experience with user behavior

Architecture Ownership

Having to work with an externally planned architecture severely restricts the autonomy of teams. This is known as the "ivory tower" problem. The disconnect and the feedback loop between making architecture decisions and experiencing their actual impact in day to day development becomes too large. To make architecture discussions more efficient, empowered teams need to have some form of architectural ownership. It might require strategic alignment with architecture decisions made outside of the team, but a lot of architecture ownership can happen within the team:

• Architecture discussions within the team
• Reaching out to other teams to learn about their architecture decisions
• Explore trends and evaluate the adoption of tools, frameworks and services
• Proactively create and communicate software quality decisions
• Preserve and exchange technical knowledge through documentation

Operational Ownership

You build it, you run it - Werner Vogels

The essence of the DevOps philosophy is to acknowledge the close interconnection between software development and IT operations. Consequently, teams that take full product ownership also have to take responsibility for the operation of the software components they develop.

This can be organized in different ways though. It may involve a full alerting and incident response process with on-call shifts. It can also mean providing alerting and incident response resources such as runbooks for another team. The key idea is to be involved with the operational challenges of the system.