Team archetypes: basic setups

 "Which kind of team setup should we choose?" - a common question in many organizations with the luxury of having an IT department bigger than a single team. First of all: there's no universal best answer - the choice is often constrained by factors outside the teams' control - such as HR, legal,  company politics and so on. Irrespective of such details, let's explore what the archetypes are.

As long as there are only enough people for a single team, the question "which setup do we choose?" is - fortunately - moot: build a team and get to work. Approaches like Skunkworks, which predate software development, conclude that a single team is always less overhead than multiple teams, and the overhead can become a performance killer - down to the point where a single, effective team can outperform half a dozen teams struggling to get their act together.

This entire article is written under the premise that a single team isn't enough to get the job done, and that we already exhausted all feasible options of doing the same with fewer people - hence: there is an indisputable need to set up a multi-team structure.

Four Team Archetypes

Let's take a look at the team setup chart. For simplicity's sake, let's just assume that the only functional specializations are Analysis, Coding and Testing. The key points of the article don't change if we have further specializations, such as Frontend/Backend/Database development or include Operations. If anything, the problems caused by specialization would be exacerbated.

Component Teams

One of the most common setups for organizations with just a handful of teams is the Component Team: each team consists of the people required to deliver a single component. This works splendidly as long as there are only few components, and they are loosely coupled. In that case, each team can perform their work independently. It becomes an entirely different ballgame when components are tightly coupled, interdependent - or worse: co-dependent.

Key questions to ask when setting up component teams include:

• Will each team have all the skills and means to complete the delivery lifecycle of their component? If the answer is "No," component teams will quickly find themselves blocked and unable to consistently deliver value. Proceed only if the answer is "Yes."
• How close is the coupling between each component? If the answer is, "Tight", component teams will likely find themselves rendered ineffective. Proceed only if the answer is, "Very loose."
• How dependent are the components on each other in delivering end user value? If the answer is anywhere on the scale from "Master-Slave" to "Closely interlinked", at least one component team will be a bottleneck, and overall delivery performance will depend on the constraining team.

Specialist Teams

The staple setup in corporations with hundreds, potentially thousands of IT people is the Specialist team: each team consists of specialists performing a single function in the software development lifecycle. In case of very large organizations, we often see a double specialization - each component having their own specialist teams performing only a single type of task. 

This kind of "industrialized, conveyor-belt delivery" process optimizes resource efficiency over effectiveness, and typically ends up with massive bottlenecks diminishing flow efficiency of value delivery close to Zero: Regardless of how many people are involved, "there are always too few people." The problem is less the amount of work than the immanent optimization favoring workload over results.

Key questions to ask when setting up specialist teams include:

• Where will the bottlenecks be? You will have at least one bottleneck, and if it's not where you want it to be, you won't understand why your organization is so ineffective.
• How do we keep flow across teams balanced? Managing flow in specialist teams requires understanding the intake, throughput and flowback rates of every single team. If these are out of balance across teams, work will get stuck.
• How will people communicate? The classic Waterfall-style "communication by document" is slow, inefficient, ineffective and error-prone. Proceed only when you have a feasible solution for communication flow.

Feature Teams

The key reason for feature teams is to reduce the cross-team friction caused by delivering unusable component work which requires integration efforts at a later point in time. Feature teams minimize the handovers across team boundaries which lead to additional communication and waiting queues. 

Neither component nor skill boundaries will stop the flow of work from demand to delivery in a feature team. The way of working in feature teams is very natural - people sit together, do whatever it takes, and get the job done.

Key questions to ask when setting up feature teams include:

• Which organizational impediments prevent us from setting up feature teams, and how do we overcome them? The barriers are often more centered around management, structure and contracts, not at shop floor level.
• How do we keep team size low and still make sure people know what they're doing? Feature teams require a lot of initial learning as every team member is confronted with a vast amount of things they don't know.
• Which engineering practices will we use to ensure that teams won't constantly step on each others' toes? If you have no solutions, you need to find these before proceeding.

Generalist Teams

The generalist team is often considered the holy grail of Agilists. A generalist team is multi-skilled both in software engineering, and in the product domain: each team consists of individuals who can exercise multiple functions in the development lifecycle, and who are able to work on all relevant components of their product. Generalists hardly find themselves in bottleneck situations, and are always able to contribute value. Setting up generalist teams has a massive learning curve, requiring continuous multi-learning. In return, generalist teams minimize the concern of "truck count," and they are able to flexibly take on any feature that maximizes value.

Key questions to ask when setting up feature teams include:

• Where are currently our knowledge constraints? Generalist teams immediately expose where the number of individuals with either product domain expertise or specific lifecycle expertise are too rare to ensure each team has seed knowledge to get started.
• How much specialization is really required? If you're working on teams where lacking deep domain knowledge becomes a life-or-death decision, generalization may not be your primary choice. These cases are rarer than we would think. Based on the Pareto Principle, 80% of the work requires 20% of the knowledge - and generalists can do that.
• What does it take to set up generalist teams? How do we get started? Can we start right away, should we upskill feature teams or component teams? Do we need to re-organize entirely?

The most common concern towards setting up generalist teams is, "Not everyone can do everything." Indeed. It takes time and learning, and not everyone will specialize deeply in everything. There are two key points to ponder: the starting point, and the optimum point. 

At the starting point, we set out with people who may find themselves unable to contribute outside their specialization, and based on where the team's constraint is, that's what they need to learn first.

At the optimum point, team members can offer basic contribution wherever it is needed - and "wherever" isn't "everywhere." A generalist team is effective when there are no skill-related bottlenecks in the team, not when everyone is a master of everything. It could mean that a tester understands some basics of coding and can make simple changes by themselves - not that they need to establish profound coding expertise. 

What's the difference between generalist and feature teams?

Feature teams are a lower standard. We can easily set up a feature by putting an analyst, a developer and a tester into one team and giving them access to all the modules they need to work with.

Generalist teams should be feature teams. Only some feature teams are - or evolve into - generalist teams.

A generalist team consists of coders who can analyze or test, testers who can analyze and maybe write some code, and analysts who can also code or test. People who worked in smaller companies are often used to this way of working - people from a corporate environment are often unable to even grasp this concept as it's too detached from their reality.

How about Generalist Component teams?

Small teams of people, each of whom can do most of the work on their own components. This pattern is very typical in modern organizations opting for microservice architectures.

Dissolving specialization boundaries within teams is desirable to increase "truck count," and definitely useful. We minimize delays, handovers and information gaps within the team. On the other hand, the effectiveness of the overall development organization remains constrained by the lowest performing component team. Component team organizations can't solve this fundamental flow impediment, hence the teams' generalization ends up being a local optimization.

We can even find this local optimization working against us - the highest performing teams might create overload on other teams, further reducing the overall performance of the organization. High-performance generalist component teams might render the entire organization ineffective, despite best intentions.

What to choose?

In other articles on the topic of team archetypes, we will explore a little further what the implications of each archetype are. The topic is complex, hence there is no simple answer. The best answer is: "Caveat emptor." Know what you're opting for and what the consequences of your choices are.

What about Mix-And-Match?

Should every team within an organization have the same setup? Wouldn't it be better to mix-and-match? A few component teams doing bulk haulage, supported by a few specialist teams for Feature Analysis and End-to-End testing, maybe with a Task Force Feature Team for high urgency tasks? 

That's actually what we find in many organizations, so it's definitely a realistic scenario. Our question is less about "Can we do that?" than it's about, "Should we do that?" - and again: there's no simple answer. As a product matures and growth reaches a plateau, that's most likely what we're going to find. For emerging products, the suggested mixed setup is probably not going to provide the necessary performance to succeed. 

Where to start?

Try starting with the simplest setup, and only add complexity when inevitable.

And that simplest possible setup is a small number of Generalist teams. If you can, try that first.