Building complex products with a team of software engineers spread across the world was once akin to science fiction, but no longer.

Many companies are benefiting from a distributed structure in their engineering functions, meaning teams in different places are empowered to build products by cloud-first technology stacks and suites of real-time communication and collaboration tools.

However, with more companies introducing return-to-office mandates it can be difficult to determine whether a distributed engineering team will work for you.

This article helps to answer key questions about distributed engineering teams: what they are, how leading an outsourced engineering team (comprised of agencies and/or contractors) is different to managing a distributed team of employees, and why careful management is so important.

Companies may set up engineering functions in different territories for a range of reasons.

Motivations might include optimising for core competencies in certain locations, or ensuring that solutions engineers can get close to customers and build relationships.

Managing costs will often sit towards the top of a founder’s priority list, making access to lower-cost overseas talent highly attractive. So for many early-stage startups, opting to go lean and work with distributed contractors or freelancers is a tempting option.

Jeet Mukerji is CEO of HR tech startup Kinfolk. As Jeet and his co-founder, Kim, were building Kinfolk, it made sense to complement the core team in London with remote engineering talent, engaged as contractors. "When you’re at the earliest stages, it’s all about leveraging your network," Jeet says. "Right now, we work with individual contractors based in Poland, Georgia and Pakistan."

Did Jeet consider employing engineers, either in the UK or abroad through an employment of record service like Remote or Omnipresent? "Having looked at our options, the tax and pension costs of more employees felt prohibitive," Jeet says.

Ensuring long-term alignment with contractors is key – and there is more than way to make sure everyone’s on the same page for the long run.

"We worked alongside two of our contractors in a previous startup, so we go back a long way," says Jeet. "While I wouldn’t recommend this as a default option for other companies, we are looking at granting equity options to these contractors, so they can feel like they have skin in the game."

On the other hand, even with solid, high-trust relationships with contractors and agencies, founders shouldn’t expect projects to be executed in exactly the same way as they would with an in-house team.

"We were working with an agency a while back, and I gave them the go-ahead to start writing code too quickly, without doing all the testing and user conversations we should have done. This led to lots of painful code reviews and refactoring and wasn’t an efficient way to get work done," says Jeet.

For founders who may not have the right kind of relationships in place, and would prefer to avoid the risk of working with someone new, it may be worth investing in new non-distributed hires.

Although employing someone full-time is likely to cost more in salary and equity overall, this cost is often more than offset by the value employees add to their team and the wider business.

"It would be a shame if we let that knowledge walk out of the door once a project was complete, so we prefer to focus on employing top talent rather than giving the job to consultants or agencies."

Wise words. It’s worth remembering that at the end of an agreement, engineering contractors or agencies will walk away - potentially taking valuable insights with them as they go.

Successes and failures alike are valuable learning experiences, and engineers that are employed directly can apply the lessons they’ve learned to future projects. Startups that opt to focus on outsourced engineering resource may not reap the same benefits down the line.

Some companies are more likely to feel the benefit of having a single hub for the engineering function.

For Alan, certain business models may come under strain if team members are spread across multiple hubs. "If your company is dealing with sensitive data and highly confidential information, it can cause new difficulties if this data has to cross international borders in the regular course of business," he says.

"Plan ahead: which regulations could inhibit your ability to scale up internationally? It may not be worth the hassle to build a distributed team if it causes anxieties for clients and, potentially, regulatory authorities."

Even for founders and companies that are less exposed to regulatory risk, security will always be central for customers.

Francesco Cardi is VP Product Marketing at Remote, having transitioned into the role in 2024 following three years in Remote’s operations function.

For Francesco, "A fully distributed organisation can be more challenging for less experienced individuals, as it requires greater proactivity and self-learning. However, for startups looking to maximise speed and execution, global access to top talent is a game-changer."

Leading an engineering department across one or several hubs means making choices about how the team should work together.

"When establishing a new engineering hub in a previous UK-headquartered company, we moved very quickly to set up multiple offices in Europe, Australia and North America," says Alan.

"You need to make sure that the team members in those hubs feel supported and central to the company’s mission. Otherwise, you could find yourself dealing with a ‘two-tier’ system where engineers in a satellite office resent not having access to the most important meetings and decisions."

In this context, the early hires in a new hub are critical. "The people who are first on the ground in a new team are going to play a huge part in establishing the ethos and standards in that office," Alan says.

Sometimes, engineering leaders need to adapt to changing circumstances. "At Signal AI, we had intended to set up a Lisbon office for some time. However, an acquisition we made accelerated our plans, as the acquired company already employed a team of engineers based in Lisbon. That was a very positive development, but onboarding and integrating multiple engineers post-acquisition meant we needed to think on our feet. Making sure you’ve set out clear expectations for performance, development and ways of working will help you stay agile even as you scale up."

How does Remote ensure that team members will be a fit, and that they’ll add value in a distributed workplace?

"We also look for exceptionally clear writers. Our employees can’t pull people into phone or video calls whenever they want: there may be 10 time zones between two people working on the same project. So the quality of our employees’ documentation is critical."

Leaders need to think about how work will get done and prioritise hires with the required skillsets to succeed in a distributed environment.

The saying that "Great talent can come from anywhere" remains true of modern business, but founders are thinking creatively about how they scale up their companies.

A company aiming to create or dominate a category, scaling at warp speed, may need to ramp up the number of engineers it employs at pace. But this isn’t the growth story for every company. When cash and efficiency is king, founders need to optimise for a set-up that’s fiscally responsible but ambitious from a development and technical perspective. At an early stage, that could well mean a blend of full-time employees, contractors and agencies.

Culture is just as important in a distributed company as it is to a team working from the same office five days a week – maybe even more so. "People often associate in-person teams with greater speed of execution," says Francesco. "But if the company’s culture is only focused on speed, you might miss all kinds of complications that slow everything down in the long run."

Founders and engineering leaders contemplating building distributed engineering functions today need to devote care to getting this balance right.