When a remote team does not work, and what to do instead

A remote team does not work when nobody on your side gives technical direction, when nothing is written down, or when what you really have is a two-week job. In those cases, fix something else first or choose a different setup. We place developers from Serbia with clients ourselves, so I am not entirely neutral. I would rather say upfront that it does not fit than after three months.

Nobody on your side gives technical direction

A new developer needs someone who says what to build, makes decisions and reviews code. If you have no CTO, tech lead or experienced developer, the new developer will start deciding alone. Sometimes that goes fine, but just as often you get tidy code for the wrong problem.

So sort out technical leadership first: a fractional CTO who joins a few days a month, or a lead you hire as your first developer. We offer a fractional CTO too. How to divide the roles is covered in fractional CTO and remote team: who does what.

Nothing is written down

Some teams run on feel. Requirements change in the corridor, nobody records decisions, and whoever was not in the room does not know. In an office that sometimes just about works, but remotely it grinds to a halt.

Start writing things down, also for your current team. A decision belongs in a ticket or a short document, so it still exists after the conversation. Boris describes what belongs in writing and what can go in a call in async work: what to write down. If your product still changes direction every week, put a small team together in one place first, until the direction settles.

You want to save money but have no time to onboard

Saving money is a fine reason to work with a remote developer, but onboarding, preparing work and reviewing all take time from you or your team. If you do not have that time, you pay for a developer who waits.

So count your own time before you start: a few hours a day for the new developer during the first two weeks. If you really do not have that time, wait until you do, or have the work built as a project. What a developer costs in total, including your own time, is in hiring in-house or nearshore.

One remote developer next to an office team

I find this harder than a team that is fully remote. The office team talks at their desks, decides over coffee and forgets to invite the remote developer. That person misses context and, over time, only executes tickets.

Agree that discussions move online as soon as someone remote is involved, and that decisions go into a ticket or a channel. Or bring in two remote developers, so at least one colleague is in the same situation.

The work has to be on site or in the local language

Some work cannot be done remotely, such as work on hardware that sits on site or daily contact with end users in their own language. Our working language is English, with a Dutch point of contact. For a developer who talks to Dutch, German or French-speaking users every day, that is not enough.

Your own client contracts can also set requirements, for example about who may access which data. Read them before you start.

Keep the part that has to be local with your own people, and see whether the rest can be done remotely. Perhaps the backend or an internal platform can be built remotely, while contact with users stays with your own team.

The job takes a few weeks

Onboarding a developer takes time, even a good one. If the work takes two or three weeks, you finish onboarding just as the job is nearly done.

For a short, well-defined job, hire a freelancer who already knows the stack, or have it built as a small project. I would only add a permanent remote team member when there are months of work ahead.

You want someone to take over the whole product

Placing developers in your team is different from having a product built. In the first case you steer: you set the priorities, and you or your lead review the code. If you want someone else to own the design, the planning and the delivery, you need more than individual developers.

Then have it built as a project by a partner who is responsible for the whole thing. We do that too, next to placing developers. How placing developers works with us is described under how we work.

If you are not sure a remote developer fits your situation: the first two weeks with us are a trial, and if it does not work out, you pay nothing.