When projects take longer despite your organization gaining more expertise, when developers share frustration about “process hindering progress”, the problem may not be the people or the technology. It may be time to look at team boundaries.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
This is what the Agile Manifesto suggests, and it is often how organizations start. Small teams move fast, make decisions quickly, and deliver value. When organizations grow, however, there is a natural tendency to specialize and organize teams around technology and expertise. A team of frontend developers here, a team of data engineers there, and a team of operations engineers to keep everything running. It seems logical to keep the growing number of people manageable.
But this is where velocity starts to suffer.
Solutions are well-known and much discussed: stream-aligned teams from Team Topologies, Amazon’s two-pizza teams, Scrum teams. They share the same core principles. Yet the problem keeps recurring. Organizations forget these principles as they grow, and rediscover them painfully through experience.
In this blog post, I want to distill what these approaches have in common and what I’ve seen work in practice into three core principles. Together, they form what I call self-contained teams — in reference to self-contained systems, organized not as layers but as vertical slices that minimize dependencies.
Principle 1: Eliminate Dependencies to Foster Flow
The first principle should be to decouple teams. Teams must be able to deliver value without coordinating with multiple other groups for their normal project workflow.
The need to reach out to other teams is a major factor in slowing down software projects. Every necessary meeting, every e-mail that needs to be carefully crafted breaks the flow of work. Yet, they are needed when project activities stretch across multiple groups of people. So, the fewer dependencies there are between teams, the fewer context switches and alignments are necessary, and the higher the focus and velocity.
And there’s another reason called Conway’s Law. It states that architectures of software systems reflect the same communication structures as in the organization of the development teams. So by splitting up teams into smaller groups, we create architectures that are more complex.
Team interactions should be dominated by dynamic cooperation on topics where targets are aligned, not by strict dependencies.
Examples
I’ve worked in team settings that were close to this and where we could achieve amazing speed and satisfaction.
But I’ve also worked in an opposite extreme: Back then, we worked on a new data warehouse system that should be able to aggregate a company’s sales data and provide insights to the business. The project was large, so we were split into three teams: One for the frontend, one for the backend and one for the business intelligence. For a KPI to become visible on a dashboard, the data needed to be correctly processed by the backend engineers and displayed nicely on the frontend. However, the knowledge about the actual meaning of the data being processed was in the business intelligence team, which ended up being caught between talking to the business, creating the dashboards that were their core focus and being bug-hunters for the database backend. And there was a lot of meetings and emails and official sprint artifacts. The project timelines were repeatedly extended, the reasons for the delays were never clear and as a countermeasure more people were added to the project. Eventually, the project was cancelled in favour of an entirely different solution.
And there are smaller examples, one being an API Gateway available to us. I’ve seen projects using it in two modes: the “communicative” mode is where no-one from the team configured the gateway, but rather asked integration engineers from the gateway team to do it for them. This worked, but took a long series of meetings and e-mails and about two months time for an essentially small task. The better mode is where the project team configured the gateway themselves. Of course, the team needed one person who knew or learned how to do it, but then it was fast and easy to iterate on the gateway configuration.
In both cases, the issue wasn’t that individuals were slow or unwilling in any of the involved teams. Instead they just struggled to overcome the hurdles of the organizational setup.
Principle 2: Give Teams Autonomy
The second principle is to trust teams with autonomy. Cooperation with platform teams should be “X-as-a-Service,” not ticket-based. Development teams need self-service capabilities to move fast. And they know best what they need to create value, so they should be free to choose the right tools and services for their needs.
Over-reliance on tickets can inadvertently encourage passing responsibility — especially for timely delivery. Ticket-based workflows create artificial dependencies and slow down progress. Teams end up creating a papertrail and waiting for others to do work they could do themselves if given the right tools and trust.
The alternative is to provide platforms as self-service capabilities with automated guardrails instead of manual gates. Development teams should be treated as customers who can configure and use services independently, within well-defined boundaries.
Examples
What I’ve seen in many occasions is the compulsive hoarding effect that automatically happens in the absence of autonomy. Teams start hoarding objects that can only be gained by collaborating with other teams. They would keep storage volumes, databases, permissions, whole cloud projects, just because they were afraid to not get them back in time in case they need them again. They don’t do it because they are irresponsible, but they work under time-pressure and need to deliver and don’t have time to coordinate every change of resource needs. This is a waste of resources introduced by the absence of autonomy.
Another small example I’ve encountered is the Logging Sidecar anti-pattern. A platform we were using back then offered a rigid logging solution that couldn’t be configured by development teams. Parsing structured logs was for example not possible, but we needed it to create both business insights as well as a good level of visibility for incident support in our dashboards. So, instead of using the existing log aggregation, we built an additional aggregation pipeline based on sidecar containers and log files. The logs were duplicated into a second database where they were nicely structured and visualized. I think, we made a rational decision given our constraints, but it led to a wasteful architecture for the company.
Principle 3: Create End-to-End Ownership (No Dev/Ops Split)
The third principle is to establish clear end-to-end ownership. One product should be in exactly one team’s responsibility. This may be the most important of the principles, but it is only possible if the other two are given already.
When responsibilities overlap or boundaries are unclear, the incentive to own the outcome is reduced. Issues and delays become “their fault” instead of “our problem”. True ownership means one team owns the service from the prototype to decommissioning. They become the subject matter experts for the service and in case of incidents or user questions, they truly understand the context. Because the team is solely responsible, they can (and have to) make the necessary decisions. This reduces the risk of lagging development or half-hearted work that often result from responsibility diffusion.
Example
A classic anti-pattern is the “operations handover” approach. Developers build an application, then hand it off to an “Ops” team to run. The Ops team hardly has the chance to understand the business logic; the original developers lose touch with operational reality. Code becomes unmaintainable.
Both teams may deliver what they think is expected from them — the software ordered by the business versus a stabilized version of what was handed to support. But together they fail to deliver a product that is both maintainable and satisfies the business, especially by allowing to react on user feedback with further development.
The structural fix is simple: You build it, you run it. No “Ops team” as a siloed receiver, but Ops people who are involved with the business and understand their needs and Devs who are involved with operations and have a natural incentive for carefulness. There is no need to change the people or to bother them with detailed checklists and policies, they just need to be grouped into different team structures.
The Ideal: What a Self-Contained Team Looks Like
When the three principles come together, they create a powerful team structure. A self-contained team has a clear business goal and is stream-aligned to deliver value directly to customers. The team is cross-functional, bringing together Dev, Ops, QA, Security, and Product skills under one roof. This means they have both the end-to-end responsibility for their product and the skills to build and run it.
Their interaction with the rest of the organization is characterized by consuming platforms via APIs, not tickets. They work with high trust, high autonomy, and high responsibility. The tools to build their product — autonomy and trust — are given to them. Platform teams and external specialists (e.g. for security or legal) become enablers and coaches, not gatekeepers and obstacles.
Working in such a team is not about living in a developer utopia. Sometimes having the full responsibility can be a challenge. But it creates purpose and ownership, so that work becomes more satisfying. This has positive effects, both on morale as well as on customer satisfaction. The outcome is tangible: What was planned on Monday, they can deploy on Friday afternoon without asking permission, because they are the ones on call.
Self-contained teams are the engine of a true DevOps culture. They eliminate the organizational friction that slows down software delivery and replace it with flow, autonomy, and ownership.
References
- The book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton & Manuel Pais (2019), whose key concepts are available on their website.
- Conway’s Law
- The Magic of Self-Managing Teams: Nice blog post explaining the shift in leadership style in an organization of small self-managed teams.
- Amazon’s Two-Pizza Teams: Amazon’s famous approach to team organization.