squads, tribes, contributors and everything else

Knowing when to scale and how to prepare your application are important steps for your product's success, but there is a point that often gets ignored: the team needs to scale too.

There is no use having state of the art microservices, automated pipelines and blue-green deploys if behind all of it you have a team buried in rework, without visibility, permanently putting out fires.

In part 1 we talked about "why scale?", and in part 2 about "how do you prepare to scale?"

a team that puts out too many fires ends up burning out

it is not just about hiring more people

The first idea that comes to mind when we talk about scaling a team is bringing more people in.

But if you only add developers to the project without changing processes, the chaos and the headaches scale right along with them.

As the classic The Mythical Man-Month put it: nine women cannot make a baby in one month. In practice, more people does not mean more speed; it means more communication paths and more chances of rework.

As the team grows, communication between people grows quadratically (n * (n - 1) / 2). And if you do not take care of that, the bottleneck stops being technical and becomes human.

Scaling a team involves many things, and without the proper attention the team stalls, and so does the system.

documentation is your best friend

Scalable teams share knowledge. It is not an achievement for one specific developer to be the only one who knows there is an if written in 2019 that breaks the whole system if you comment it out.

Make it clear where to find deployment manuals, onboarding, infrastructure configuration and, above all, the business flows, and how to run them.

However senior the new developer is, they might be the Java wizard but they may also have left the crystal ball at home and have no idea how to run that version of react native with all the libraries broken and unsupported since 2022.

Setting up an environment like that is not trivial, but it should be!

Use tools people actually use and have access to: notion, markdown notes, github issues; even a paper bag solves a lot. But if you hand your newly hired developer a Docusaurus built from the material produced in recent plannings, they will get a good picture of what is happening inside the company.

Document enough, with real examples, without bureaucracy. And if that does not usually happen, then you either build that culture or over time the information gets lost.

The questions from a newly onboarded developer should revolve around:

• How do you run the system end to end?
• How do you run the tests?
• What are the rules? What is table X for?
• Are there triggers? Procedures? Side effects?
• What is the flow to build a CRUD?
• Is it possible to reproduce the production environment?
• How does the deploy flow work?
• How do the team's rituals work?

If this is so common, be prepared to answer these questions asynchronously. That way you save hours of work for several teammates, because if someone asks you the same thing twice in under a month, it should have been written down somewhere.

dividing responsibilities

Over time, it is normal for the system to become too large for one person to understand entirely. It matters that parts of the system have owners (not necessarily the Product Owner) with the freedom and the responsibility to maintain and improve what they touch.

That avoids the famous "who did this?" in the chat at 3 in the morning.

And worse than that is not knowing who did it, or having nobody to ask. Be very careful with turnover on the project.

You do not want your team blocked for months because you lost your most valuable senior engineer.

communication and alignment

Even with agile squads and a colourful kanban, if communication does not flow the system will choke where you least expect it. Some Scrum practices help with these gaps:

• An alignment ritual covering the business view, the technology and the project vision.
• Availability to answer questions.
• Context passed properly before starting any process.

Teams that talk to each other build better. Everything that can be delegated should be delegated. But the principle of being able to delegate means you already know what has to be done and how it has to be done. Would you invest your money in something you do not understand?

autonomy (with responsibility)

A scalable team needs autonomy to test ideas, change direction and adjust processes. But it also needs responsibility and visibility.

Autonomy is not doing whatever you want. It is knowing what to do without having to ask permission all the time, but with the support you need.