How To Design A Team

A team isn’t just a group of people - it’s a design choice. Get that design wrong, and you’ll spend your days fighting symptoms that are easily confused with other causes. Remember that form follows function, so we must decide what we want this team to do before we can decide how to build it.

How do we decide one particular group of people form this team, and another group form that team? What should be the line between them, and how do we know if we should have two teams, three teams or just one?

Often managers will start out with predefined teams - our first role will usually be taking over an existing team, whether one you’ve been in yourself, or one you’re joining. But as we grow, we really need to start thinking about why that team exists, and whether it’s a good idea or not. Many day-to-day dysfunctions can come simply from a team being poorly defined, or being misaligned with larger organisational structures or strategy.

What is a team?

A well-defined team ideally has a number of characteristics:

Focus. A single, clear and strategically aligned goal.
Autonomy. Empowered to make decisions within their required scope.
Skills. Whatever is required to fully deliver within their scope, regardless of discipline.
Size. Big enough to deliver - small enough to communicate directly.

How do we pull off all those things? Let’s dive in to each in a little detail.

Focus

This is the single most important step in defining a team - without focus, without purpose, a team is just a collection of people doing work.

Oftentimes a team will come with a predefined set of responsibilities, or with preassigned KPIs / metrics / whatever. If you are leading this team it’s your job to continually assess if these are correct and proactively hone the focus of your team, indefinitely. There is never a “correct” end state to this, only periods of stability and alignment, which, depending on the nature of your organisation, you are likely to drift out of over time.

Do not sleep on this. How well you are able to do this will determine a lot for your team - their results, their job satisfaction, their career growth, and so on. It’s very easy to get swept up in that river of endless work, but without their leader - you - your team will end up fighting the current instead of being carried along by it.

How do we evaluate or define our focus? I use a system called GOST - Goals, Objectives, Strategies, and Tactics. Regardless of what your organisation calls them - perhaps Missions, Metrics, and so on - the core ideas hold. And most often, you’re starting from Objectives someone else handed you.

With your team, sit down and work backwards from the numbers to a Goal (sometimes called a mission, or a vision). Your Goal should be stated as an outcome or an end state. Crucially, it should be completely free of metrics.

For example, let’s say you are a customer support team, and you have been give some Objectives like:

closed support tickets; NPS; customer complaints

A poor Goal might be: “get to zero open support tickets; reduce customer complaints by 10%; increase NPS by 1”. There are milestones, not goals - they measure progress. We’re trying to define what we’re measuring progress toward.

A good Goal might be: “to ensure every customer has a positive experience with our product, even when it breaks”.

Which would you rather be doing: chasing numbers, or helping people? We’re not foregoing the metrics, they’re still there, but the purpose and focus of our work - the why - is much clearer.

Strong internal motivation rests on two sides of the same coin:

Service. We are wired to help each other - when people say they lack purpose, what they often lack is the feeling they are being of genuine service to another person.
Responsibility. We want to own things - when people say they lack meaning, what they often lack is the feeling they have an important role in the group.

So, if your team has a Goal that encodes how your team is of service to others and what they are responsible for, then you’ll have a rock-solid foundation for your team’s focus.

Autonomy

For a team to be highly effective it must be empowered to make decisions on-the-go without getting blocked waiting for approvals. If you are the manager above this team, that means you are responsible for putting a lead in place, or coaching that lead into place, with the goal of letting go, yourself.

If a team has no autonomy, it simply becomes a “resource pool” available to the organisational unit above or around it - this very quickly destroys any sense of responsibility that team might have. This is disastrous for motivation, kills growth, and leaves the team severely underutilised putting more pressure on everyone else.

This applies within the team as well - if you are a team lead and you do not trust your staff with responsibility areas in which they can be autonomous you will destroy their motivation, kill their growth, and put more pressure on yourself. This is a very common mistake for the brand new engineering manager who is often still trying using their engineering skillset to solve problems - they might jump in to “rescue” the team, or still solve the hardest problems themselves, which slowly but surely results in that team seeing you as an annoying bottleneck.

Without autonomy we cannot have earned success, only learned helplessness ¹, as the team’s progress is constantly blocked waiting to approve every decision, leaving them powerless to succeed without explicit permission.

Instead, give your team or staff a scope you are comfortable for them to fail in - and let them fail, if need be. Your job is not to control it is to manage. Your toolset is different now you are a manager, so stop using the old one and start using the new one. The sharpest tool in your kit is accountability. Learn it and use it. It takes time and practice, just like any other skill.

Skills

If a team does not have the right skills within its autonomous unit, then it will be stuck constantly trying to align schedules with external resources, whatever they may be. If your team requires design work to achieve its goals, give them a designer. If your team requires data, ML, product management, content writing, whatever, aim to give them dedicated resource within the team.

Of course this is not always possible, but it’s worth considering - if your org has “engineering” teams and “design” teams and “data” teams etc. you will have a coordination nightmare. What looks on the surface like 3 teams coordinating is actually 10 engineers, 3 designers, and 2 data scientists attempting to coordinate. Anybody who has tried to organise a group of adults even half that size will tell you that things quickly get out of hand.

This is an example of day-to-day dysfunction that will happily hide if you are not paying attention. Keep an eye out for people getting blocked because they’re waiting on someone in a different team, and consider if the team has all the skills it needs to succeed.

Size

Along with having the right resources is ensuring the team has enough. Size issues can always be addressed by playing with scope, however it’s a key consideration - are there enough engineers to get things done within timeframes that allow the team to align and support the rest of the organisation. If you are a platform team, for example, you might get away with just 3 engineers going slow - but if you have 15 other teams relying on this will obviously cause problems. You might think this is obvious, but you’d be surprised how often it happens.

The other key aspect of team size to consider is communication. The team should be large enough to be effective, but small enough that having the entire team communicate directly with each other is still feasible. This is crucial to ensuring the team can effectively mobilize the autonomy you’ve given it. There’s loads of “perfect team size” numbers about the place, but typically teams are between 3 and 12, give or take. The specific number doesn’t really matter, so long as the team maintains all the desirable characteristics we’ve been discussing.

This is another one of those insidious, day-to-day dysfunctions that likes to hide in plain sight. It’s also one that can easily be confused. We might look at a team that’s not performing as expected and think that maybe they need more people, but it’s always prudent to check for Focus, Autonomy and Skills first. Are they trying to do too many things? Are they constantly waiting for approvals? Are they held up because they have no dedicated QA?

Keep an eye out for arguments and frustration - this one, unfortunately, often shows up as anger or blame. Ideally things have not gotten this far, but it’s an easy one to miss until it’s actively causing issues.

Create Teams with Intent

Above all, teams should be built with intent. Don’t just lump people together and expect things to work out.

Design the team you’re looking to create using these principles, and revisit that design every 6-12 months. Organisations evolve; so should their teams.

If you get this right you’ll be set up to build teams that perform, grow, and attract further talent - because people know a good team when they see one.

I’m quoting Arthur C. Brooks who is a Harvard professor with a lot of great things to say, and some not so great. ↩