Team Architecture

Team architecture is one of the major concerns of any engineering group in tech companies. How do we arrange people in teams so that the best outcome is achieved.

Definition of a team usually makes sense in the context of ownership. What is it that a few people can own to form a team for? This is the first question you have to ask when forming a team. What they will own and what happens to the product when the team vanishes.

Another aspect that make a team more effective is the reporting lines, e.g. an infra team that does not report to engineering but reports to the operations is just waste of their potential. This is a different topic I will get to later.

Below are some thoughts on the subject (with focus on software products) that will hopefully spark more thinking and discussions.

Patterns of Team Structure

The definition of the following patterns is not rigid at all. They have a lot of overlap, similarities and some even come under hierarchies. Some teams have different names in different organisation. A DevOps team in one company might be the Infra team in another company. I haven’t made much effort to classify them into a better grouping or structure.

In reality we group teams together all the time, e.g. CloudOps consist of cloud team, DevOps team and operations team; or a commerce team may consist of billing team, ordering team, etc. Teams similar to software can have levels of abstraction and hierarchy.

These patterns provide tools to ask questions on why the teams are formed the way they have and if there is a better way to re-structure them.

Product Team

An organization may have one or more products, e.g. Kayo, Binge, etc. Products my be for internal or external customers, B2B, B2C, etc.

This pattern has some variations:

• External customer: Product may be developed for an external customer. If the external customer has very tight timeline and budget constraints the long term support of the the products may face difficulties.
• Internal customer: Product may be developed for an internal customer. The company owns the product and the team has a better sense of ownership. Internal products usually receive more care and longer term support. Internal products may be a revenue generating product such as Kayo for Foxtel or an internally used productivity or cost saving product such as bedrock vending machine.
• Bundle of products: A team that works on a group of products.
• Product variation: A team that supports a variation on a product, e.g. Android team, iOS team.

For a product team to be successful they have to be cross-functional and own all of product + design + engineering. Product team’s goal should be solely customer focused.

Feature Team

A team that supports or owns a feature or a process within a product. A feature team is usually across multiple domains or applications. When a process/feature/journey/aspect is big enough then it requires a team to handle it.

Example: signup team, purchase flow team, user journey team, search team, etc.

Feature teams usually have many communication points as they interact with many other teams and applications. 

Processes may have sub processes and that might mean sub-process/feature teams.

Feature team may be a short lived team and has similarities with project teams below.

Teams by Conway’s Effect

Conways law states that the communication structure of an organisation influences the systems they build. That means they architecture of a system is affected by the team structure.

The effect of team structure on system architecture makes team building an architectural concern not a management or agile activity.

As a rule of thumb remember the Reverse Conway which focuses on a team structure that matches the desired architecture we want.

If the architecture of the system and the architecture of the organisation, are at odds, the architecture of the organisation wins. Ruth Malan

Spotify Model

It’s a famous model you can read about here. Since Spotify announced this model it was adopted by many organisations some of which took it too seriously unlike the Spotify themselves (according to Kingberg and Ivarsson on the original Spotify blog they partly implemented the model!)

One major problem with the model is that there is no regards to the team size. You have to be careful otherwise the tribes will grow too big.

One important measure for a team size is team cognitive load which is the amount data, information, task and process a team is capable of handling. This imposes constraints on the software architecture too because there will be limits to the amount of components you can realistically place into an architecture that a team is responsible for.

Sometimes too many bugs in a system is an indication that the system is bigger than the cognitive load of the team and the team is having difficulty figuring things out.

Spotify model also doesn’t talk about the dynamic interaction of teams; it’s static.

Platform Team

A platform team in digital companies is a basis that provides self service APIs and reusable tools to other teams to perform their duties. Example is DevOps team that builds CI/CD pipelines, application templates, etc.

Platform team nowadays is a capability that gives companies an edge. As a rule of thump if a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team.

If a reusable thing finds more than 3 users, then it may be time to consider this a horizontal responsibility and move it to a separate team

On the other hand, if the platform team is not self service and automated enough it will eventually burn the team or grow it unmanageably large. It is just pulled in all directions by many teams. Self sufficient teams that have a member from the platform team (capability) take this direct pressure off the platform team. Ideally other teams should contribute seriously to the platform and the platform itself should be flexible and extensible to allow such contributions.

The concept of platform team paves the way to define capability teams. Teams that are specialised and take care of an speciality across the organisation such as Kubernetes team, Identity team, etc.

Some do not like the idea of DevOps team and would insist on merging Ops and Dev and define DevOps as only the concept of affinity between the two but I doubt this is true anymore. Nowadays DevOps is an abstraction layer on Ops teams where they stay on their hardware/network/storage realm and DevOps take care of the necessity for more automation, container orchestration, GitOps, CI/CD, etc. More on the later.

Project Team

A team that is formed for a project. These teams are usually short lived depending on the nature of project. Project teams usually have the role of project manager. Care has to be taken for the long term support, maintenance, ownership and upgrade of the created product or service when the project finishes.

As project teams are formed every time for a new project, they share the common problems of a new team such as personality clashes, etc.

Project teams are usually more constrained with time and budget. From personal experience showing a project plan or timeline to developers just makes them miserable! Just shield them from it as much as possible!

Component Team

A team that is responsible for a component (part) of a product or feature. This could be a considered as a variant of a product team as well. Component teams of function best as cross functional teams.

Example: backend team, front end team, watchlist team.

Even though a component might be a feature and vice versa but component team focusing on one well defined part of a system is usually the opposite of feature team working across many components.

Domain Team

If you have defined boundaries for each domain in your business context you can have domain teams, e.g. commerce team, content team, billing team.

Domain teams usually map to the capabilities of a business. A business with capabilities such as sales, marketing, streaming may have teams with the same names.

Each domain may have a manager and/or architect. Domains are hierarchical in nature hence this pattern has a logical variation of sub-domain team.

Cross Functional Team

This type of team has at least one member for any capability they need to make them self sufficient and to reduce cross team communication and dependency. It is also called self-sufficient team. These teams seem to be high performing teams due to less external communications and better internal communication (cohesion).

One problem with this type of team is that they might diverge from the standard architecture of the overall system that organisation follows and there should be ways to align and enforce such standards, e.g. using a self service platform.

HBR says that 75% of cross functional teams are dysfunctional. Read here why.

Functional Team

If cross-functional team is a thing then we should have a definition for a functional team as well. A functional team is responsible for or corresponds to a function unit or domain of an organisation.

A functional team has a lot of similarities with domain team and component team, e.g. accounting team, IT team, platform team, development team, billing team, test team, architecture team, call centre team may all be called functional team.

Technology Team

Specialised teams that build or maintain a piece of technology or a group of technologies. Example: Kubernetes team, front end team, backend team, UX team, Java team, etc. These teams are not self sufficient and many depend on them. They also usually do not map directly to an organisational value stream.

Consulting (Enabling) Team

Specialised team that is formed internally or hired externally for specific purposes, i.e. something that organisation has no knowledge of or does not want to spend time on. Example: cloud migration team. This type of team usually has a short life span and require close management to make the best out of it.

Outsource and Offshore Team

Many businesses nowadays outsource part of their workloads to onshore or offshore teams. Common problems include: culture differences, timezone differences and lack of present management. You organisation also loses the knowledge of that team when their contract finishes.

Matrix Organisation

This form of organisations are a combination of functional and project teams. An individual works in a project/product team and at the same time part of another functional/domain team, e.g. an architect is part of the architecture team and also works on a project.

Matrix organisations or teams is an old concept and is the basis for the Spotify model.

Temporary Team

A team that is formed for a short period of time in order to handle a time bound task. Care must be taken in terms of the ownership of end product once the temporary team ceases existence. Examples are project teams or task force teams. They have a limited life span.

Team Dependency Patterns

Teams depend on each other for different reasons. This is where team boundaries have to be defined and as said above as part of Conway’s Effect, the team boundary should ideally be dictated by system architecture.

1. Knowledge dependency: A team needs the knowledge of another team e.g. the billing team needs the DevOps team to setup CI/CD pipeline for them.
2.   Task dependency: A team’s output is another team’s input, e.g. a team is waiting for an API to be ready for consumption.
3.   Decision dependencies: A team’s decision affects the tasks of another team. Example: the way front end team wants to consume APIs will affect how backend team creates those APIs in terms of technology and granularity.

Team Communication Patterns

The teams communicate in many different ways. Remember that teams are made up of people and even though with teams we create boundaries but people are still free to talk to each other and this opens unlimited communication paths.

Ideally we want less communication across teams (low dependency) and more communication within the team (high cohesion).

1. Formal communication - collaboration based on their org structure, reporting lines and formal team boundaries and communication tools (chat, email, etc.) This type of comms usually include hand offs.
2. Informal communication - collaboration based on interpersonal and friendship relationships or how people influence each other beyond the formal titles and org charts in a personal level. Even though this sounds cheesy but a lot of tasks in organisations are actually performed via informal interactions. Sometimes this is an indication of wrong team boundaries, missing capability in the team or incorrect org charts (people are not where they should be)
3. Communication by Service - based on services provided by another team. A team provides a service (e.g. payroll or platform) and another consumes
4. Communication by API - based on an API provided by another team.

Benefit of communication by service or API is reduced human interactions or hand offs.