Growing a remote team from one to five developers

Grow one developer at a time, and add the next one only when the previous one works on their own. With two developers you need review rules, at three someone has to divide the work, and at four or five you need a lead who makes technical decisions every day. Skip one of those steps and you will see it in queues and in code nobody has an overview of anymore.

I am assuming a remote team, like the ones we set up with developers in Serbia. Most of it applies to an office team too.

One developer: everything runs through you

With one developer you are the product owner, the reviewer and the person who answers every question. That works as long as you are around. Go on holiday for two weeks and the work stops, or the developer starts guessing.

The risk at this stage is knowledge that lives only in your head and the developer's. Use this period to write down the basics: how do you run the project locally, how do you deploy, who has access to what? A well-prepared first two weeks help here, see onboarding a remote developer.

Give the first developer a clearly defined part of the product. You will see quickly whether it works, and that person has something to own.

When to add the second developer

Add the second developer when the first one picks up and ships tickets without you steering every day, and when there is work ready that only needs more hands. If work is stuck because you have no time to specify it, a second developer makes that problem bigger.

With two developers, one can review the other's work, and you have a backup when someone is ill or on leave. Now you get problems you did not have before: two styles in one codebase, merge conflicts, arguments about naming. So write down how you review, how large a pull request may be and what the linter and tests catch automatically. Erik wrote more about this in code review in a remote team.

Three developers: someone has to divide the work

With three people several things run at once, and prioritising becomes a job of its own. Who picks up what? What comes first when there is a bug in production?

At this step, the tickets that only existed in your head start to cause trouble. Two developers could still ask you what you meant. When three developers all do that, it takes a large part of your day. So write tickets that someone can start on without you, with context and acceptance criteria. A short daily stand-up shows who is stuck where.

Also schedule a fixed refinement session once a week. Then there are always two weeks of work ready and nobody has to wait.

Four or five developers: you need a lead

The number of lines between people grows faster than the team. Between two people there is one line, between three there are three, between five there are ten. Count yourself in, and with five developers there are fifteen.

Around four or five developers that is too much to carry next to your other work. You need someone who makes technical decisions every day, does the important reviews and onboards new people. That can be one of the developers who is ready for it, or a fractional CTO who joins a few days a month and coaches the lead. How to split those roles is covered in fractional CTO and remote team: who does what.

Without a lead, the team makes decisions that are written down nowhere. Two developers solve the same problem in two ways, and the architecture slowly drifts apart. So appoint the lead before the fifth developer starts.

What to write down at each step

• With one developer: how to set up the environment, how to deploy and how access works.
• With two: review rules, the maximum size of a pull request, linting and tests in the pipeline.
• With three: a fixed ticket format, a definition of ready and a weekly refinement.
• With four or five: who the lead is, which decisions they make alone and where architecture decisions are recorded.

Each document can be a single page. What matters is that it exists before the next developer starts, so they can read it instead of asking you.

How fast you can grow

My advice is to let each new developer work on their own for a few weeks before the next one starts. You see what breaks at each step and fix it while it is still small. Starting two people at once can work, if there is already a lead who takes care of onboarding.

Our contracts run per month. You can add or remove a developer every month, and you choose who joins your team. The first two weeks are a trial: if it does not work out, you pay nothing. What a remote developer costs is on the page about building a remote team.

When not to grow yet

Sometimes you need to fix your process first. The signs are pull requests that sit for days, less than a week of work ready to pick up, or bugs that come back after they were fixed. Or you notice it yourself, because you spend hours every day answering questions.

In those cases an extra developer will not help. Fix the bottleneck first, with better tickets, smaller pull requests or a lead, and only then add people.