The biggest global tech companies have all grown by hiring globally. As it turns out, many of these remote big tech dev centers started as independent third-party entities. It was only later that they were “spun in,” via a business model known as “Build Operate Transfer”, or BOT.
The frictionless nature of cloud software development along with the economics of talent has companies big and small thinking expanding the bounds of the organization outside their own neighborhood. If you’re not doing it already, now’s the time to catch up. In this guide, we’ll tell you what you need to know to make it work — and get it right the first time.
- Mistakes to avoid: common DIY traps
- Taking the long view: How to make it an extension of your strategy
- The BOT model: what to bring to the table
- Planning for the contract: setting up a relationship for success
- Exit thoughts: beginning with the end in mind
Cloud, laptops, and ubiquitous Wi-Fi have lowered the barrier to setting up a team anywhere. Open-source software has leveled the playing field for individual talent. So many entrepreneurial-minded executives start with a freelancer in the “ROW” (rest-of-world) country with whom they worked in the past.
Or, maybe they turn to a good engineering manager who was recommended by their friends or an offshore recruiter who promises to hire the right people and provide local admin support. However, there are several fatal flaws in this “find a guy, get a team” DIY approach.
There are several fatal flaws in this “find a guy, get a team” DIY approach.
Myth 1: “All I need is Skype and Slack.”
It requires a considerable investment of time and attention to button down all the details of an organization on the other side of the planet, including legal, logistical, and cultural differences. Anticipate friction where the relationships you count on are relatively green. An intensive investment in setup takes a long time to recover, which counts on organizational longevity of your remote team of between 2 to 5 years
Myth 2: “Never heard of this place, but the rent is incredible”
Locations off the beaten path with relatively low real estate costs may seem to offer short-term cash flow advantages, but those advantages dissipate soon after you experience some success. Adding talent to your team in second or third-tier towns often means that you have to educate developers on how to work with a startup culture and global counterparts. The supply of big fish in a small pond is always limited.
Myth 3: “The culture will bootstrap itself.”
It’s easy to assume that a team of engineers works like a collection of “mini-me’s,” people like yourself, only younger and less expensive. A little arithmetic shows that the number of social connections in any group is exponentially larger than the count of people. Your attention will be in great demand to ensure team dynamics and culture are healthy and self-sustaining. Every time there’s little instability, it will all be on you to fix, across time zones and cultures.
Myth 4: “My remote site manager is a slick fixer and has great connections.”
In a 3-5 year horizon, particularly for a startup, adding and replacing staff is inevitable. Reliance on a “fixer” in a small market is not only risky because the local talent pool is shallow (see Myth 2 above.) There’s a real risk that the big-fish/small-pond scenario leads to the fixer walking out the door, taking your whole team with him. So you can add gaps in ethical standards to the list of risks.
In short, taking the DIY path to remote development can be more challenging than it has to be, especially when you think short term.
Thinking long term
Your software development team is a strategic asset. There’s no good reason for short-term bookkeeping to become the sole driver of its strategic viability.
The development team is a strategic asset, and there’s no good reason for short-term accounting to become the sole driver of the strategic viability.
When you think about it in terms of strategy, think about 2 to 5-year horizon, and think about the size of the talent pool.
The most successful tech dev centers in Eastern Europe, for example, operate in big cities known to be hubs of technical talent. For example, there are as many software developers in either St Petersburg, Russia or Kiev, Ukraine as there are in Silicon Valley. While bigger talent pools do come with more competition, it turns out that remote software development companies experience less attrition than their big tech companies in the US. A typical attrition rate in a major Eastern European technology hub? 10%.
Remote software development companies experience less than a 10% attrition rate — compared to a 25% at large technology companies.
Compare that to a typical 25% turnover rate for large technology companies. (US startups have an even more challenging retention problem.)
When you look at successful software development organizations in large cities, you’ll see the following patterns:
- Considerable time and attention invested in the quality of recruiting and HR
- Have built great employer brands over several years, and know-how to attract the best talent
- Know how to create and sustain a vibrant work culture reflected in a productive and pleasant office atmosphere
- Solid knowledge of local employment and business law and know-how to effectively solve problems with minimal impact on their clients’ business.
Most US/European technology and product executives are thrilled when they come to the offices of outsourcing companies in Eastern Europe. The office climate and workplace culture are comfortably familiar: snack rooms, goofy toys, sarcastic desk posters, plus collaboration-centric meeting rooms and facilities. That’s no coincidence. Many of today’s remote R&D and dev centers for US companies were originally built and delivered by local professional firms under the Build Operate and Transfer model (BOT).
Build-Operate-Transfer: What it is — and what to ask for
BOTs have classically been a generalized vehicle for a sponsoring entity have an engineering outfit put together a project for a set period of time. After key milestones, it is transferred back to the sponsoring entity.
Today, BOTs represent the most popular and well-understood approach to spin up a Remote Software Development Team (RSDT) to drive technology initiatives. The most common and successful practice is to rely on the expertise of local companies to build and operate as a BOT, combining the best management practices with the most compelling economics.
Let’s start with the goals of the plan: you want to identify an RSDT partner who can do the following
- to build a team for you, under your guidelines
- ensure that the team is productive and self-sustainable
- transfer the team and employees to you legally
- ensure that your team successfully operates as an entity of your company.
Next, set criteria for choosing the partner vendor; there are many to choose from. The strongest candidates can both grow a team for the long term, and demonstrate a solid understanding of US and international IP and employment laws.
Look for partners who have the experience to grow a team and command of US and international IP and employment laws.
Here are the shortlist criteria:
- Managers and decision-makers in the US or Europe who can legally sign contracts and understand the requisite responsibilities. This includes accountability for your (client) expectations and clear grasp of compliance with US law.
- A strong local management team. Some of those team members could become members of your leadership. You’ll want to see that their team and local employer brand can attract strong leaders.
- A professionally managed recruiting and HR organization that builds and maintains long-term career plans for employees. This is especially important as you grow the team
- Experience in managing team size of at least 2x than you plan to get from them as an output of the BOT contract.
An important caveat: Think twice before you sign up with big outsourcing mega-vendors. They generally manage contracts with hundreds of staffers for clients and projects substantially larger than yours. There’s a real risk that a mega-vendor deprioritizes you in favor of new and lucrative business opportunities — right in the middle of your contract.
Of course, as in all international business relationships, there is no substitute for good rapport on a personal level with the company owners and decision-makers. A strong mutual understanding of the business and business ethics is always important.
Planning for a contract
Once you’re through the shortlisting process and are ready to put together terms, you’ll need a clear idea of the scope and shape of the commitment for the RSDT. Remember: a contract lays the groundwork for the successful completion of the relationship. Consider the following parameters.
Team Size: What’s a realistic team size of the new entity? Given the effort required to operate as a separate group, operating or acquiring companies generally want a team of 40+ FTEs. Handling remote management of teams smaller than that can be tough. It’s not just that are smaller teams less stable. They often struggle to attract new talent to join the family, compared to a reputable employer with multiple teams and clear growth opportunities within the team.
Duration: What is the ideal time for such a transfer to occur? No one really wins when such a transaction happens in less than 18–24 months. It takes at least that long to develop the strategic expertise for you to transform it into your sustainable intellectual property. It definitely should not be framed as some glorified recruiting exercise. Good value is established through a stable, vibrant work culture that pays off for years to come. That takes time.
Team Composition: Think ahead 18-24 months. What players on the team do you consider essential vs. expendable for the transfer to occur? Naturally, you want to have a plan to retain those players who are core to your future organization. By the way, it’s perfectly fine if you don’t know yet. In fact, it’s a solid reason to start by creating your RTDT inside of an engineering-led software development shop (like ours) so that you can figure it out without the burden of costly overhead.
Fees: There are three important factors when it comes to fees.
- Direct ongoing charges by the partner for FTEs under their management as they build the RSDT
- The fee charged when RSDT ownership is transferred from partner to company. (It is typically calculated as a percentage of annualized billings at the time of transfer.)
- A prorated, per employee the transfer fee adjusted for the tenure of the FTEs at the time of transfer. (The shorter the tenure, the higher the fee.)
With these foundations, you are ready to begin remote operations and grow your RSDT as you grow the business.
BOT has proven to be a very effective model for building your own RSDT. You get your own entity and people for a cost to similar maintaining ordinary client-vendor relations.
It’s a matter of enlightened self-interest to treat your vendors as equals, with a focus on building lasting relationships. They are the ones hiring, training your future employees, and laying a foundation for your future office culture. Listen to the recommendations from your RSDT partner’s leadership; you’ve hired them for their expertise and their understanding of local culture and business. It’s essential that the relationship does not end when the work begins, especially in the context of startups.
Are you a start-up with eyes on an exit? Consider establishing terms within your agreement for triggering the transfer portion of the BOT earlier. The advantage of doing so can be substantial. RSDT is a strategic asset that boosts the value of the organization. When you meet with investors — whether for an up-round or in looking at selling your whole company — having a robust self-sustaining technical organization is better than a loose confederation of scattered freelancers. The RSDT becomes part and parcel of the company you are selling. It’s tangible value in your own organization from day one. And it can contribute enough to the valuation so as to more than double what you spent on the RSDT.
At exit, a robust remote software development team can contribute to your valuation more than double what you spent.
Even after completing the transfer, consider giving the partner responsibility for admin and recruiting support for your own entity after the transition. It helps head off possible post-transition problems. You can also set aside a portion of the transfer fees, tying them to agreed-upon KPIs. A contingency linking a part of the payment as bonuses those according to KPIs keeps everyone aligned for the long term.
One final point: any exit has transition costs between a startup and its acquiring company. Making that transition easier and less costly contributes directly to the valuation. The finance and legal staff at the acquiring company will appreciate the groundwork for a smooth transition. They’ll convey that appreciation to the people considering the valuation, and that gives you an even nicer exit.