If you Google on ‘remote teams’, you get many articles about startups engaging remote teams. What isn’t clear in these cases, is at what stage those ‘startups’ engaged remote teams.
I am a strong believer of one thing: it’s best to have remote work in your company’s veins from an early stage. But I also believe you shouldn’t do it too early. To engage with right remote players and to get your work done, it is not wise to just hire few startup employees. Moreover, the challenge would be to look for workers who have good experience working remotely. The stage at which you pick the right remote players takes your enterprise to the next level. Let’s take a look at some categories of remote setups we see in the market today.
- Enterprise Offshoring
The funny thing is that in the startup world, people talk about ‘remote work’, not about ‘offshoring’ or ‘nearshoring’. Some still call it ‘outsourcing’, but that term seems to be outdated as well. The past two decades, we saw the big corporates move work offshore. For the newspapers, this is great stuff to report about, because it usually goes along with firing people at home. The company tries to achieve cost savings or other benefits and therefore lays off people that work for them. They replace those people with offshore equivalents.
Today, this seems to be ‘business as usual’. Most companies don’t necessarily talk about offshoring, but when they send out an RFP (Request For Proposal), the big IT companies with offshore locations, by default bid on the projects. Usually, these contracts are multi-year multi-million deals.
The hard part in these constructs are the transitions. People need to adapt new behavior and processes need to be adjusted. Somehow the remote teams need to integrate with the existing structures.
- Digital Nomads
At the other extreme, I see the rise of remote entrepreneurs who contract ‘digital nomads’. According to wikipedia:
Digital nomads are individuals who leverage telecommunications technologies to perform their work duties, and more generally conduct their lifestyle in a nomadic manner. Such workers typically work remotely—from home, coffee shops, public libraries and even from recreational vehicles to accomplish tasks and goals that used to traditionally take place in a single stationary workplace.
While many of these nomads are freelancers who get work through global freelancing sites or networks, there are also quite some startups. People seem to gather at co-working spaces all over the world and from these meetings, startups evolve. By default, such startups are virtual and everyone works remote. Joanna Riquett, Founder & Editor-in-Chief of Hayo Magazine lists attractive coworking spaces in Asia, looks great options for remote teams.
- The Distributed Company
While there’s overlap with the previous category of startups by digital nomads, I think this category has some differences. The virtual startup’s co-founders started the company from one location but chose to hire people globally. I think the most striking example is Automattic, the creator of WordPress. They have over 350 employees, working from 250 locations all over the world. They have systems and structures in place that enable them to hire the best people for any job any place on earth. And the whole system seems to work since the company is valued at over a billion dollars. Here’s an interesting interview with Sara Rosso, which gives an insight into the distributed culture the company created.
This category of companies deliberately organizes almost 100% distributed. There’s no clinging to the idea that an office location is the best way to organize work.
- Startup With A Remote Office
Then there are startups who set up a remote (development) office from the early stages. A couple of weeks back I found an interesting Dutch case: Vicancy. They decided to set up their development office at Bali from the beginning. Their reasoning was that they would be able to attract the best programmers around the world. So they ran an Ad on Odesk and asked who wanted to work for them, relocating to Bali. They got a lot of applications and picked the two best guys. One of the co-founders moved to Bali, rented a house and the team moved in.
Image Source : WordPress
This category of startups basically has 2 office locations. Usually, the business and marketing team is ‘home’. The development team is in a lower cost location (or a tropical island :)).
- Mature Software Company With Remote Team
This type of company is similar to number 4, but the stage at which they started with a remote team is different. Typically, the company has over 50 employees, exists for a couple of years and has a solid turnover and profitability. They have started their company in their home country, all people in one place. At a certain point of time, they grow fast and can’t attract enough programmers ‘at home’. They then select a partner to build their remote team or they set up their own offshore or nearshore team. This has some of the pains described in the first category: you need to change behavior and processes, while in most cases, these companies don’t lay off people at home. It is an expansion strategy, not cost saving.
An example is one of our customers Woodwing. They started over a decade ago, have over 130 people employed and have a development team of 7 people in our Ukrainian office and a team of 20 testers in Delhi.
Back to the question at what stage it’s best to engage remote workers for your startup? For the digital nomads, this is not even a question since remote work is what they do. For the other categories, my experience tells me that the right answer is ‘somewhere between having traction and growing a solid organisational structure’.
In one of my articles on lean startups with a distributed team, I shared my experiences managing a remote team for our startup Ekipa.co. We chose to build the product with a team in our Indian office from day 1 which puts us in category 4. Here are the two main constraints we faced:
Even the MVP (minimum viable product) was developed in India. Currently, Ekipa has a team of 2 marketers in India on top of the development team. A couple of challenges we experienced launching this new product with a remote team:
- No programmer sitting beside you
The programmers are far away with a 3,5 to 4,5-hour time difference. As a consequence, you get:
Ideally, your founding team has a programmer in it. When you get out of the building and speak to customers, you get back to the office and discuss the feedback with your programmer. He then implements the changes while you’re watching and the next day, you get back to the customer to show the changes. This is simply harder with a team far away.
In general, you’re part of a process and this process can take longer with a remote development team. Working from different locations requires more thinking about how you’ll collaborate and communicate. You need to develop a strong collaboration structure, implement the right routines and tools. Because you’re doing this while at the same time launching your new product, it might slow you down.
- Routing feedback through the team
An important part of the lean startup is generating feedback from users to build the right product. You need to go through the ‘build-measure-learn’ loop continuously. As Ekipa is a business to business online marketplace, it relies on personal interactions with customers. In a business to consumer site, it is easier to generate a lot of traffic in the short term (through AdWords). Business to business takes more time; few people are searching to ‘buy now’ and because deals are larger, nobody is interacting with your site right away (the process to get convinced that this is the service you need to buy takes time).
Based on this experience, if I had to start a new product from scratch, I would choose to first find a technical co-founder who can develop an MVP (minimum viable product). The period during which you need to prove that there’s demand for what you’re building is crucial. You need to be able to iterate and change your product fast. With a remote team, this is harder to do. In my ideal scenario, I talk to some potential users in the morning, return to the desk of my programmer at lunch, he makes some changes to the product based on the user feedback and I return the new version to the users in the afternoon. That agility is simply not possible with a team in India.
As soon as the MVP (minimum viable product) has helped us prove that we’ve got a scalable, viable business, I would build a remote team. This is the moment you start to build a real product and you need good programmers for this. Those are hard to come by in the US and EU. And it’s also crucial that you keep your programmers for a long time because they’ll gain deep knowledge about your product. You’ll build the architecture and code base with your own remote team, which is easier than having to engage remote developers at a later stage.
Of course, this isn’t to say that if you’ve got a successful software product built by your development team ‘at home’, you shouldn’t engage a remote team. Anything that helps you to scale is important. If your constraint is good programmers, by all means, engage them remotely. But ideally, engage a team from an early stage.
Scrum User Group Bali Meetup
Bali Scrum Crash Course
Scrum User Group Jakarta Kick Off
Jakarta Scrum Crash Course
Read Next >> Why Outsourcing Software Development is Right for Startups