Designing Autonomous Teams: Reduce Collaboration Overhead for End‑to‑End Ownership

Key Idea

The core secret of organizational design is to reduce collaboration, i.e., increase autonomy: enable a person or a team to be fully responsible for a task from idea to production.

Collaboration between people is costly; communication and coordination consume time, especially when interruptions like holidays, accidents, or illnesses occur. Therefore, aim for tasks that can be completed independently.

Collaboration Between Functions

Applying this mindset to software development, the ideal is that a single person—or, if not feasible, a single team—handles the entire process from requirement to release. This is often called a full‑process team, cross‑functional team, or stream‑aligned team.

When Agile emerged, it emphasized that a single team should own requirements, development, and testing. DevOps extended this to include deployment, operations, and security (DevSecOps).

For a team to handle everything, it must be strong, which is challenging. An alternative is to make work easier by providing excellent tools and automation so that a person or team can independently manage integration, release, operations, monitoring, and related tasks.

Specialized functional teams focus on selecting and promoting development tools, building infrastructure, defining best practices, and coaching developers—essentially providing expert services without getting involved in daily delivery pipelines.

Occasionally, highly specialized problems (e.g., challenging algorithms) may require bringing in experts from other teams.

Team Division When Developing Features

Choosing between component‑based or feature‑based teams is not a binary decision. Teams should own a specific subsystem or component long‑term, gaining deep knowledge and responsibility, and respond quickly to new requirements or defects.

When a specific feature is needed, assign it to an individual; if one person cannot handle it, form a temporary feature team. If the feature spans multiple components, pull members from the relevant component teams. After the feature is completed, the temporary team dissolves and members return to their original teams.

The principle remains: aim for a single team to complete tasks independently, minimizing inter‑team coordination. Ideally, the system architecture is well‑designed and divided so that each part is owned by a dedicated team, achieving high cohesion, low coupling, layered design, and reuse.

Beware of Conway’s Law: the structure of the organization shapes the architecture of the software it produces. To achieve a good system architecture, carefully design the organizational structure to reflect the desired architecture.

Finally, consider team size, such as the “two‑pizza rule,” to keep teams small enough for effective communication.