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.

Coaching tool: The ORG team building model

How do you build high performing teams? In this article, I will describe the three-factor model which can help focus your attention.

The model is extremely simple to memorize, although it requires a lot of thought and attention to practice.

The model

Outcomes, Relationships and Growth are highly interrelated: Poor relationships lead to poor outcomes, whereas good outcomes bond the team, and growth is usually required to get the next great otucome.
It's impossible to separate the three, although managers often focus solely on process and outcome - a huge mistake!

Outcomes

Future outcomes are goals or side effects, and past outcomes would classify as achievements or failures.
With a new team, we have a couple goals. By turning them into results, we create a basis for inspection and adaption.

We can look at outcomes in many ways, just to name a few examples:

1. Performance: Value, Customer Satisfaction, Quality, ROI
2. Process: Behaviours, Practices, Tools, Flow
3. People: Mindset, Expertise, Happiness, Teamwork, Relationships (there we go, recursion!)

One important side note on process outcomes: Dysfunctional behavior is most often an indicator of at least one dysfunctional relationship, which is why behaviour (both of the person and the system) is classified as an "outcome".

Relationships

Relationships are the basis of every group effort. Healthy relationships propel performance, whereas unhealthy relationships constantly divert attention away from outcomes. Therefore, investing into healthy relationships both within and around the team is essential to success.

We can also look at relationships in different ways, here again some examples:

1. Trust: Reliability, Confidence, Mutuality
2. Psychological Safety: Addressing and resolving conflicts, allowing vulnerability, permitting mistakes
3. Collaboration: Commitment, Teamwork, addressing weaknesses and being supportive

Creating and growing a base of trust can be done by setting common goals (ref. "Outcomes") and achieving them together. 

Growth

As a wise person once told me, "We are all where we are, who we are and what we are. Growth is a lifelong process, but not everybody grows. Wouldn't it be sad to stand in front of the grave of an 80-year-old person and the inscription read: No growth. This person hasn't grown in the last 50 years?"

Growth areas we can look into might be:

1. Organizational: Team, Company, Market
2. Personal: Skills, Understanding, Social
3. Professional: Salary, networking (see - we have relationships again!), achievements (and there's outcomes!)

Healthy growth picks up people where they are, happens at a pace people can bear with, and helps them move into a direction they want to be.

Time orientation

The model is applied differently in past, present and future orientation.

Future

Since a new team starts with a future, we'll look at the future first:

1. What will be the desirable and probable outcomes of our actions?
2. Which relationships would we want to have (within and outside the team)?
3. In which areas do we want to grow?

Even this can be separated into subsets of Near Future, Mid-Term and Distant Future.

Present

In the present, a possible set of questions would be:

1. Which outcomes are we currently working towards and what are we getting?
2. Which positive and negative aspects do our relationships have?
3. In which direction are we growing and where should we be growing?

Past

The past helps us understand why we are where we currently are:

1. Which outcomes did we get, which were desirable and which not?
2. Why are our relationships the way they are?
3. Where did we grow and where didn't we?

Analyzing the past is about finding change potential to move into a better direction from now on, so while positive aspects help us identify drivers, negative aspects help us identify areas with need of attention.

How to use the ORG model

As a process

The meta process is quite simple and contains an infinite loop:

1. OUTCOMES: Start by defining goals, i.e. "indended outcomes".
2. Bring people together to achieve those goals (the team).
3. RELATIONSHIPS: Let the people figure out how they want to achieve those goals.
4. GROWTH: Observe where issues arise and work towards beneficial change.
5. OUTCOMES: If goals change or new goals (e.g. growth or relationship goals) become necessary, set new goals.
6. Repeat at 3.

In team building

When setting up a new team, remember: You have no outcomes, growth or relationships to build on yet.

1. Define the long-term OUTCOMES for the team, i.e. "Why the team exists".
2. Set clear, achievable short-term OUTCOMES to achieve in a short period of time.
3. Bring the right people together and see which RELATIONSHIPS form.
   Strengthen desirable relationships.
4. Generate team GROWTH while achieving these OUTCOMES.

I have seen great leaders define the main goal of a first iteration with a new team primarily as people outcomes: Build relationships, get to know each other and the product vision. Performance outcomes are still important, but achieving these can wait.

Inspect and Adapt

As mentioned in the "Time Dimension", we can constantly reflect on past-present and future ORG states, refocus and make adjustments as needed. A Scrum team might want to use ORG during Planning, Reviews and Retrospectives to determine a course of action, learn where they got and adjust course.

Coaching

Your coaching effort can be distributed across the three different dimensions of ORG.
Ideally, you balance out all three dimensions, neglecting none.
In practice, this will be a pendulum swinging between all three, and the one with the least attention is the most likely to become your next problem.

As a coach, if you realize that you're neglecting one dimension, you can pro-actively plan your next steps to build a higher performing team.

Download

Printable materials for ORG workshop facilitation can be found here: Download.

The IOWA-Number - a tool for team building

Not every person contributes equal amounts on the team, and that's often okay. But there are some cases, where a conversation is needed. I devised the IOWA Number as a tool to identify these cases.

Applying the tool

The IOWA Number can be used in the "Gather Data" stage of a Retrospective with the question: "How do you feel about your team members?" This does require a certain level of trust within the team to work properly, and be clear that the tool isn't meant to highlight people as problems, but much rather to help the team find itself properly. There is no score that's inherently good or bad, just some scores that will lead to further conversation down the road.
Most importantly, only apply the tool when you have a feeling that there are some outliers, as the tool is merely intended to open up a conversation on becoming better at collaborating!

Extremely low scores

In some, rare cases the team will feel that a person's absence will actually have a positive effect on outcome.
The most notable case of this happening is usually when said person is lacking so much knowledge that their questions disrupt the others' flow of work. A good way to strengthen the team would be to put delivery work a bit on the backburner and work intensely to bring the person back to speed.
Another common case would be that said person doesn't really understand the impact of their own way of working on the team, often due to being unfamiliar with others' self-organized ways of working.

In any case, team members with extremely low IOWA score need the team's support to rise to higher levels and the team should have an open conversation which behaviours are reducing IOWA score and which behaviours would increase it.

Moderate scores

Anything between 3 and 7 is usual. There's not much to discuss, unless there are tendencies towards an extreme. But since IOWA numbers are nothing more than a snapshot in time, it would be better to use the extreme value right away, as it doesn't make sense to defer a conversation.

Extremely high scores

There's no way to sugar-coat it, high IOWA scores are a risk, potentially even a threat to the team's sustainability!
People typically do not choose to have high IOWA score, they receive that score because they have superior understanding of a subject matter and a strong drive for action. Usually, they feel they are helping the team and the organization by working this way, and in fact - when it comes to getting stuff done, they help a lot.
Unfortunately, all of their help us unsustainable, as the team immediately falters when they aren't available and if for some reason, they should be out (e.g. sickness, family issues etc.) their absence could bring the entire team and whatever the team was working on to a standstill or collapse.

As I wrote in my book, "Extreme Agility", my suggested course of action would be to relieve the person from the responsibility of doing whatever they do so well and instead coach and support the rest of the team in this. It should be exceedingly clear that they aren't taken out of the delivering function because anything is wrong with them, but because they are needed as multiplicators in order to grow the team.

Conclusion

IOWA Numbers are a conversation starter when the team is on uneven footing. It's not intended to judge or condemn the work or contribution of any individual, much rather it is intended to bring people to a more equal footing in order to increase the team's sustainability.

In some cases, it may even be worthwhile to create IOWA Numbers for people in the team's close vicintity, such as traditional line managers. If this is done, be sure to include them in the Retrospective (which is rather unusual).