The notion of teams: The importance of well-defined teams in an organisation

Published in

Bolt Labs

8 min readAug 10, 2022

Teams and team formation are a fundamental part of any organisation. Working in a badly set up team doesn’t get you far, and before you get it right, there might be a lot of mess-ups along the way.

Horia-Mihai Coman, the Director of Engineering at Bolt, has managed, bootstrapped, and reorganised a fair share of teams and has made all the possible mistakes on the way.

To save you from making the same mistakes, Horia has written several internal guides and adapted and published them for a wider audience. This knowledge will be useful, especially if you’re working in a management position — you’ll know what to look for and what to avoid when you’re in the process of building a team.

In tech organisations, the team is the unit of product delivery. It has a perennial lifetime in an organisation. It has complete control over a product vertical. It has corresponding control over the engineering components. It consists of a small group of people working in a coordinated manner. That’s when the team is done right.

Let’s unpack this.

The unit of software delivery

The team is the unit of software delivery. Software in a business setting is a team activity. It’s built and maintained, and operated by teams of people.

In contrast, it’s not individuals or squads that build software. Nor is it large-scale structures like divisions or the whole of “engineering” that build software. These are not safe, sustainable, or efficient configurations in the long run. For one, a team can do more and think better than a single individual. On the other hand, a team doesn’t get drowned by coordination and synchronisation costs as larger groups do.

Perennial lifetime

The team has a perennial lifetime in an organisation. It abstracts away the individuals who compose it. Not in the sense of hiding them, but rather giving the rest of the organisation a handle that withstands the movement of people, temporary issues, vacations, etc.

In contrast, you can go the short-lived project teams route. Or do swarming on projects, or try the consultancy model. But these are not teams in the sense above and should be used for specialised tasks.

Teams can start and end, but as long as we have a particular product need, we should have a team handling it.

Complete control over a product vertical

The team has complete control over a particular product vertical. It can be a very narrow vertical, but it needs to be something distinct and non-overlapping with the other parts.

Control of a domain here means that the team is tasked with solving a particular problem and has the autonomy to set objectives, establish metrics, devise strategies, prioritise and execute, own vendor relationships, etc.

It’s subject to limited oversight from the rest of the organisation, mostly expressed as reviews, alignment to strategic objectives, budget/ROI constraints, etc.

In contrast, having a top-down approach to these aspects is neither scalable nor efficient. The higher levels of the organisation offer context and strategic direction but should not manage at the team level. Shared or diffused ownership is a recipe for trouble. When things are good, team members will struggle to work on things, and when something goes wrong, the hot potato will be passed along.

The effect we wish to achieve in the end is to minimise dependencies with other teams and maximise the ability of the team to work independently. When coordination is required, it’s achieved by providing a service, rather than a tight “collaboration”. Amdahl’s law applies just as well to teams as it does to computers.

Complete control over engineering

The team has complete control over the specific engineering-level systems that power the corresponding product vertical that the team owns.

Control of the domain here means that the team is tasked with building and operating whatever aspect of the product they need to meet their product objectives.

It’s subject to limited oversight from the rest of the organisation, mostly expressed as reviews, following best practices, using the common infrastructure-level tooling, aligning with wider architecture constraints, participating in migrations, etc.

In contrast, we don’t want distributed ownership here, with specialised mobile or DBA or data teams working in a “consultancy” or “per-project” fashion. It doesn’t scale, it’s not efficient, and it’s subject to bandwidth limitations of the provider teams.

For example, at Bolt, systems that a team would normally own are:

Services: includes the application servers, as well as operational DBs, Redis instances, queues, and all the other resources attached to a service;
Admin panels: the micro frontends which allow operators to control and inspect the operation of the systems;
Special internal apps: special internal apps that allow specialist operators to perform their specific jobs;
External apps: the micro frontends or whole apps which allow external users to interact with Bolt;
Mobile apps: the Android and iOS apps that our users and partners predominantly use to interact with us;
Dashboards: the Looker dashboards and associated code (SQL) for them;
Spark jobs and analytics systems: the various Spark jobs, periodic SQL scripts, and others that crunch data in the background and publish it to services, admin panels, dashboards, etc.;
ML models: the various ML models the team employs to make decisions, help with predictions, run detections, find anomalies, etc.

All of the above are organised in ways that allow multiple teams to own separate sections of the codebase, even if they’re working in an otherwise monolithic system.

Given that, ownership here means that:

The team designs the system;
The team codes and builds the system;
The team operates the system in the short term, which translates to looking at metrics, responding to alerts, thinking about sizing, participating in on-call, etc.;
The team continuously improves the system as a result of product and engineering-led developments;
The team operates the system in the long term: plans capacity, prepares for 10x scale requirements, migrates to new technologies, etc.;
The team does this across all the various compute contexts — from services to ML models.

Depending on how a particular engineering organisation is set-up, there are natural boundaries that occur. One is towards the infrastructure layer as maintained by a “platform” or “tools“ group — teams build their systems using the tools provided by this group. Where they are insufficient, there’s a discussion about going off the beaten path, which may include explicit plans to contribute any developments back to the wider community.

The other boundary is towards the product layer represented by more distant teams who code in an older monolith. In some cases, a team builds inside monoliths owned by other teams and needs to be mindful of that.

A small group of people

A team is a small group of people working in a coordinated manner. The ideal team size is between 6 and 10 people. As long as the team works together in a consistent manner and considers themselves as a unit, they can belong to multiple reporting lines.

When a team is too small, in contrast, it doesn’t have enough power and is susceptible to people’s movement, and it can’t accurately provide an abstraction to the rest of the organisation. On the other hand, a team that is too big is swamped by coordination costs and fights against human psychological limits.

The ideal team composition is determined by the team’s ownership needs. It can consist of: a product manager, an engineering manager, a data analyst, a designer, a number of backend engineers, a number of mobile engineers, full-stack engineers, a data scientist, a data engineer, a QA engineer, etc.

The reporting lines don’t matter as much, and it’s normal to have 2 or 3 of them completely separate up to VP or CEO level. What matters the most is that everyone works as a team with all the attributes from above.

There are a number of responsibilities across the engineering and product spectrum, and while some individuals are primary owners of some, everyone has some shared ownership here. An engineering manager needs to care about the product direction, even if they’re not the principal owner of that, just as much as a product manager needs to care if a team member is having performance issues.

Even in this ideal discussion, we need to acknowledge some realities:

There might not always be enough work in a team, or enough organisational maturity to support all types of contributors in a team;
The core group of a team is traditionally formed of a product manager, an engineering manager, and the backend/mobile engineers;
Other types of contributors can be shared from a pool of people associated with the wider group.

The guiding principle is that these specialised teams should be placed closest to where they are needed and evolve to move to where the needs are. Historically we have done the following:

Initial stage ⇒ vertically aligned backend teams, with a global pool of mobile devs, QAs, data scientists, and other roles helping out;
Scaleup stage ⇒ vertically aligned backend teams, with product-line pools of mobile devs, QAs, data scientists, and other roles helping out;
Current stage ⇒ vertically aligned group level teams, with local pools of mobile devs, QAs, data scientists, and other roles helping out;
Final stage ⇒ significant numbers of full-stack teams, with domain-level pools of mobile devs, QAs, data scientists, and other roles.

The graph below shows the structural evolution of our organisation:

Other types of teams

Above, we discussed the “stream aligned teams”. These are the classical teams that own a very narrow vertical of the product.

In addition to them, there are also other teams that you can find in organisations. For example, “platform teams” or “complicated subsystem teams”. Regardless, most of the same principles above apply here.

We won’t go into too much detail here, but if you’re interested in this topic, the book “Team Topologies” explains other types of teams.

Additional reading

If you want to learn more about teams and their structure, here are my further reading suggestions on the topic:

Join Bolt!

Bolt is serving over 100 million customers in 45 countries across Europe and Africa.

You can bet that there are fascinating engineering challenges involved with this kind of growth!

If you’d like to join us in building the future of urban transport, visit our careers page.