A model for building Service Teams inside a technology organization

The buzzwords around DevOps, microservices and service oriented teams have forced organizations to rethink their ways. The hardest part is to invent techniques that would help the organization to create structures that could embrace the uncertainities and complexities of service oriented teams. A large Monolithic team, is assumed to be coherent and can work well when the organization is small. When the system complexity exceeds the communication costs within a team, it is best to rethink how it operates. The key drivers for independent service team is to be able to have :-

  1. Full ownership of the planning, prioritization, implementation and delivery of the services.
  2. Responsible for all actions and outcomes of the services, thereby gaining deep knowledge about the domain and particulars of the service
  3. Freedom to make decisions, good and bad. This allows teams to learn what works, and what doesn’t, thereby making them in control of the fate of the service
  4. Accountable of their actions, especially when things go bad. This allows them to take the responsibility as a double edged sword.

Taking the above aspects into account, an Independent service must deliver in return of the benefits of having ownership, responsibility, freedom and accountability. For organizations, attempting this move, certain set of capabilities are needed that would help the teams to remain independent.


Each such capability is composed of processes, products, practices and culture (or people). Organizations require to work upon building these capabilities, in order to provide them as framework to teams. Using these capabilities, it is possible for the teams to remain independent. More importantly, these capabilities help in the time of crisis, when teams struggle, especially when the ghosts of past haunt the newly formed independence. We will define the concept of Capability shortly.

Before that, let us understand define the concept of a Service.


The concept of Bounded context is nicely explained by Martin Fowler. A Bounded context encapsulates the common functionalities that go hand-in-hand to deliver value. Moreover bounded contexts also have a shared change perimeter, meaning the changes are usually concentrated inside the context. Bounded Contexts must expose APIs that allow them to be consumed by other contexts.


From: Martin Fowler Bliki

A service team then is defined as following :-


What makes a Service team independent from others ? Before we arrive at the capabilities that organization needs, it is prudent to understand the features that define a single service team. A Service team should be able to have access to a range of features, that keeps them independent.


Apart from features, Service teams also have access to certain shared expertise and concerns that operate in an organization. These shared expertise and concerns remain outside the teams. The reason to have them shared, is to allow these concerns to continuously evolve without getting locked-in with each service's team scope. These concerns are shared assets inside an organization that require strategic investment and forethought.


Let us come back to Capabilities.

Capabilities are strategic, long-term skills that need deep investment and vision within the organization. One or more such capabilities provide the ability for teams to gain features. Such features allow the teams to remain independent, and deliver on their responsibility.


Some capabilities include :-

  1. Project Management

  2. On-demand Infrastructure

  3. Build, Deployment and Release

  4. Quality Assurance

  5. Service Governance

I think arriving at a model similar to this, is essential for a long term plan to restructure an organization into smaller independent teams, that deliver on the promise of DevOps, Agile and Microservices.

Credits :-

  1. Service teams at Spotify
  2. Two Pizza teams at Amazon
  3. Autonomous teams at Zalando