Hi, we're Aaron & Amy! We’ve been managing tech teams for a combined 14 years, and over this time have learnt (often painfully) what does and doesn’t work. When it comes to building tech teams, we’ve learnt there’s no “one size fits all” approach, but there are some useful questions you can ask yourself in order to build the perfect team for your company.
Note - we’re using the term “team” to mean an autonomous group of people working to solve a specific problem. This may be a cross-functional product team working to increase retention, or it could be 3 developers working to make the database scale.
The Big Three!
Think you want to build a team? Great! Before getting into the details, start with The Big Three questions:
Where’s your product headed?
It’s hopefully rare that you’ll need to build a team to solve the problems of today. Usually we’re creating teams to set ourselves up for the future, so take the time to focus on what you’ll need in the next 6-12 months.
Do you have a well-defined product roadmap and a stable tech stack, and you’re looking for developers who can join your team and solve incremental problems for the business? Or perhaps you have a very unknown product future, and you need a team who can move quickly, ship lots of hacky prototypes, and validate ideas? Or maybe you’re somewhere in-between. Your answers to these questions will shape the type of team you need.
Work closely with your product owner to answer this question, they will be able to help you understand where the product is headed.
Have you validated the problem?
It’s easy to think that adding teams is always a good thing; that having more teams magically leads to getting more things done, but that might not always be the case! Before diving into the design of a full team, make sure that the problem exists, has been validated, and covers a technical domain that a team can own.
Not all validated problems deserve teams. Sometimes they’re too small, too vague, or simply not valuable enough to work on right now. If you can’t see a clear path to solving the problem then it can be better to wait – teams are expensive.
You can’t validate without doing. Form the smallest possible team to identify and answer the biggest open questions, and incrementally grow as you prove the team’s impact.
Do you really need more people to achieve this?
Sometimes there’s more work to be done, but the mission or technical domain is closely tied to another team. This could be a sign that the work should be tackled by your existing teams rather than by hiring more people. The more people involved, the higher the communication overheads, and you can end up moving more slowly as a result.
Start by assessing how easy it is for your existing teams to achieve their goals and try to optimise here first. In many cases the teams themselves can find smart ways of working to achieve bigger goals without needing more people. If this still isn’t enough, and an additional team would reduce existing team autonomy, then it might simply be about making some tough prioritisation calls to achieve your most pressing goals.
Unless the autonomy is definitely there we prefer to re-prioritise work rather than accidentally create a team that needs permission to perform.
The ‘Design your team’ checklist
Once you’ve answered The Big Three, it’s time to get into the details of what your team setup looks like.
How many people should you hire?
Once you’ve answered The Big Three, it’s time to think about how many people you should hire into your team. Often the budget will have been set before you reach this point, and your team size will be pre-determined based on what you can afford. If this isn’t the case, then you’ll need to decide what the right team size is.
It can be tempting to hire as many people as possible, but proceed with caution! Adding more people means scaling up the support system surrounding them, you’ll need more managers, more onboarding capacity, more office space, as well as the technical ability to run more teams in parallel.
We generally try to create teams with 3-6 developers per team – this is manageable from a communication perspective but big enough to create peer support and cover holidays and sick leave.
Permanent or not?
Hiring permanent people isn’t the only way to increase your team size. We’ve seen great results from teams that include contractors, consultants, and even interns. If you’re not totally sure that the problem needing to be solved will still be relevant in 6 months, then a not-permanent person could be perfect. These people tend to come in and start adding value quickly - they’re used to starting in new teams, and in many cases they’ll bring experience and skills that might be difficult to hire for.
The main gotcha to watch out for is that these people are not permanent. This is fine if the problem they’re working on is something that can be solved now, but if they’re working as a team member, make a plan to allow them to eventually leave without leaving a huge gap in your team.
If you're not sure whether a role should be permanent or not, err on the side of hiring contractors. Remember, these are humans, not resources! Hiring permanent employees is hard (and painful) to undo.
Generalists or specialists?
There are two broad categories of developer; full stack generalists and stack-specific specialists. Neither is “better” or “worse”, but one is almost definitely better suited to your needs.
Full stack generalists are perfect if you’re finding your feet or want the team to focus on lots of different parts of a problem. It can be easier to prioritise the work that needs doing rather than trying to find work suitable for specific people, and people in the team get the opportunity to learn new tech skills.
Stack-specific specialists work best once you know your direction and can commit to the technology stack. They have deep, and often niche skills that are critical for highly specialised, or high risk problems.
Unless we obviously need specific skills or experiences we prefer to go with generalists to give greater agility.
How are you going to build a diverse team?
No matter which way you look at it, diversity matters.
People with different backgrounds, life experiences, and opinions bring fresh perspectives to the problem. If you want a team that’s able to think outside of the box then you need to be hiring and retaining a diverse team.
Hiring processes are often biased toward people who “fit”, in the worst cases this boils down to selecting people based on their looks, hobbies or even, interest in drinking beer. Of course people should be able to work well together but thinking about how a candidate contributes to the culture rather than fits the existing one is a good place to start.
It’s never too early to start working on team diversity.
What additional skills does your team need?
All teams need to decide what to work on, and how to work together, as well as write code, test it, and release it to production.
Some teams succeed without dedicated experts setting vision and ensuring quality, others struggle. Dedicated experts bring skills and experience that can quickly get a good process running but again, adding more people increases the communication overhead as well as the demands on the overall company support systems.
If you don’t choose dedicated experts make sure you know who will be picking up the stuff that still needs to happen. What are they dropping to make space for this?
What levels of experience do you need?
As you hire a team you’ll need to choose the right level of experience for each role. More experienced people are great at solving bigger, more complex problems whereas more junior people often enjoy getting the day-to-day stuff right.
Hiring only experienced people is an expensive approach, but although junior people cost you less money they need proper support and training to help them become the experienced team member of the future.
Everyone, no matter what level, wants to learn and progress. For more junior people this is usually straightforward, giving them increasingly complicated problems as they grow. For more experienced people you might need to think a bit harder about how you’ll mentor and grow them.
We like to focus initially on hiring an experienced, core team. Later these people will be able to support juniors and grow your team.
To recap
Start with The Big Three. Once you can confidently answer those, you can start designing your team.
Two things to remember:
- Hiring is not the default – if you’re not sure, it’s probably better to not hire. Remember, these are humans, not resources. Hiring is hard to undo.
- The finer details are more forgiving – it doesn’t matter if you don’t get the smaller details of your team exactly right the first time round. Your team is a smart group of adults, trust them. You can course correct as you go.
Building teams is hard! But if you’ve read this far it means you’re taking it seriously, which is good – great teams don’t happen by accident!
Get the latest posts delivered right to your inbox.