Building a Global Engineering Team
What are the benefits of building a global engineering team? How does global engineering supplement your in-market team?
Cost is no longer the primary driver, it’s now access to a larger talent pool – it’s not only software development skills like React or Python that are available globally in high quality, but also skills related to Finance Tools, HR Tools, ERPs, and other systems. There is a global talent pool that is highly capable and independent—and the pandemic has proven the viability of these models. Cost is no longer the primary driver for outsourcing, it’s become just as important to find highly-capable talent.
Global engineering should supplement your team with independent highly-autonomous workflows – we recommend global engineering teams operate autonomously with their own goals and roadmaps. Empowering teams to take ownership of their work to meet the vision of the company improves their work and engages the team at a deeper level. We’ve seen discrete staff augmentation work, it tends to leave individual engineers on an island without a team.
Where do global engineering teams make the most sense?
Systems and software that need consistent refinement and enhancement – global engineering teams work best when you task them with software and systems with long roadmaps, and software that consistently needs to be enhanced and maintained. This way, the global team has a chance to build a deep knowledge base and feel ownership.
Software that has to comply with and adapt to local rules and regulations – if your product is always adapting to new requirements and regulations in a global market, it makes sense to use an engineering team located in that market to accelerate those roadmaps.
Where shouldn’t you use global engineering teams?
Early-stage companies doing exploratory work, especially if the founder isn’t technical – if the founder is going to work closely with first engineering hires, a local setup works better than trying to cross time zones. Smaller-scale teams doing exploratory work will be more efficient when they’re directly tied to the founder.
IP and legal – IP and legal elements of software building need to stay in the market the software company is headquartered in.
What leadership, processes, etc. do you need to have in place before you take on a global team?
The home team has to be open to it – the home team needs to be culturally open to working with others and should not feel threatened by the remote team. It’s very helpful to have a group that’s excited about the possibility of a global team and to get buy-in before you start.
Get your Agile and Scrum development processes in place – your processes should be mature enough that some level of planning and execution is documented. If the business currently relies on people communicating with each other verbally in a physical office with little or no written documentation or process formality, extending that process remotely will be difficult.
Don’t get hung up on documentation – some organizations say that the code is the documentation. The goal of the systems and processes is not to document everything, but to build the systems and processes to reach the goal. Your engineering manager should spend most of their time building software, not building documentation.
Note: You could employ a technical writer for documentation – employing a separate technical writer for documentation activity can help you speed up the onboarding process. You might ask them to document Setup Guides, Development Guides, or workflows on Scrum and Agile processes.
What kind of skills and performance can you expect out of a global engineering team?
Expect the same skill level from global engineers as your home team – if you treat teams equally regardless of location and hold them to the same level of standards, you invite similar outcomes. If the global team is treated second-class or given unreasonable timelines with little support, they won’t perform, and churn will be an issue.
Hot tech skills are always the most abundant globally – for example, mobile development is popular all around the world. It may be harder to find international talent in older or more obscure languages and stacks. Engineers are drawn to the technologies that affect their everyday lives.
What is asynchronous engineering? What are the benefits of it and what kind of engineering organization does it make sense for?
Asynchronous engineering is work that occurs without live communication – typically because of time zone coverage, asynchronous engineering works particularly well for maintenance and support type organizations where you’re following the sun and supporting a 24-hour time clock.
Asynchronous engineering works well if:
- You are handling support or servicing → particularly if you require 24-hour support or service
- If you have international operations → you may want asynchronous engineering in each locale that you operate in
Asynchronous engineering doesn’t work well if:
- What you work on requires lots of conversation → this is better done in the same time zone. You’re going to have conversations and continue to build and enhance the platform.
- You’re doing a lot of problem-solving → asynchronous engineers tend to have a lot of back and forth that requires a delay because of the time zone. It leads to a lot of misunderstandings.
- You don’t have proper technical architecture and infrastructure management → if multiple teams are working on adjacent code bases and people are working on the same source code files, you have to have the processes and architecture to organize and handle changes.
What kind of engineering needs can be successfully outsourced? What processes need to remain with the home team?
The home team needs to handle executive interactions, budget, and legal – patent filing, executive interactions, and all of the legal activities involved in publishing and running your software need to be at home.
Any development processes can be outsourced globally – for an engineering team that’s open to pushing to different parts of the globe, all disciplines in engineering, software development, testing, and even firmware development can be outsourced globally.
Traditionally, lower-value engineering functions are outsourced – most firms look to global engineering for cost savings on low-value development needs like support desks or QA—but this is rapidly changing and organizations are using global teams for high-value, complex needs.
Slice off a portion of your roadmap and give the global team ownership – using global engineers for resource augmentation typically doesn’t end well. The outsourced team needs its own objectives and ownership of moving the platform and capabilities forward very quickly. Empower a whole global team to be fully capable.
Don’t use global engineering for surge capacity – you can’t just pick up an engineering team for a big project and drop them when you’re done. You’ll end up with high turnover and low engagement if you plan to hire a bunch of engineers as mercenaries for 11 months. Outsourcing is an opportunity to give new engineers a chance to step up, learn, and take ownership. Also, you’ll need to support and adapt whatever you build—and who better to do that than the engineers that developed it?
What regions can you source engineering teams from? What are the pros and cons for each?
*NOTE* Nimble Gravity founders have built teams in nearly every part of the world. Here are some notes from what we have found, keeping in mind that these are generalizations.
| Central & South America | ||
| Time zone | Aligned with US | |
| Skill Sets | Wide array of skill sets | |
| Cultural compatibility | High degree of compatibility and widely available English language skills | |
| Fully-burdened cost relative to the US | 40-65% | |
| Political risk | Low | |
| Other notes | Only one other language (Spanish, besides Portuguese in Brazil) makes utilizing these at scale easier | |
| North Africa | ||
| Time zone | Medium difficulty (5-7 hours ahead of ET) | |
| Skill Sets | – Limited (but growing) talent pool. – High quantity of talent available for simple tasks (data entry, data cleanliness) | |
| Cultural compatibility | High cultural barriers | |
| Fully-burdened cost relative to the US | 20-50% | |
| Political risk | High, a lot of political instability | |
| Other notes | A lot of the UX ideas are very different (because of the language differences) and don’t translate to the US | |
| Eastern Europe | ||
| Time zone | Medium difficulty (6-7 hours ahead of ET) | |
| Skill Sets | – Wide set of skills – Medium quality for most skills with occasional pockets of highly specialized skills | |
| Cultural compatibility | Medium, Language barrier | |
| Fully-burdened cost relative to the US | 40-75% | |
| Political risk | High political risk (Ukraine and Russia) | |
| Other notes | A lot of companies are shying away from Eastern Europe because of future uncertainty | |
| Western Europe | ||
| Time zone | Moderate difficult (5-6 hours ahead of ET) | |
| Skill Sets | High quality | |
| Cultural compatibility | High compatibility | |
| Fully-burdened cost relative to the US | 75-100% | |
| Political risk | Low | |
| Other notes | Some very stringent countries like Germany can be difficult to set up an entity in | |
| Eastern China | ||
| Time zone | Very difficult (12-13 hours ahead of ET) | |
| Skill Sets | Mid-to-high quality | |
| Cultural compatibility | Large cultural and linguistics barriers | |
| Fully-burdened cost relative to the US | 35-55% (typically more expensive than Western China) | |
| Political risk | High – setting up a legal entity here is very difficult | |
| Other notes | – Would not recommend unless it were an absolute requirement to develop here – Google and all of the typical resources developers are accustomed to are not available there—requires a lot of trust in the local developers – A lot more firmware and hardware engineering talent is present | |
| Western China | ||
| Time zone | Very difficult (8-11 hours ahead of ET) | |
| Skill Sets | Mid-to-high quality | |
| Cultural compatibility | Large cultural and linguistics barriers | |
| Fully-burdened cost relative to the US | 35-55% (typically less expensive than Eastern China) | |
| Political risk | High – setting up a legal entity in Mainland China is very difficult | |
| Other notes | – Would not recommend unless it were an absolute requirement to develop here – Dealing with the Great Firewall is very difficult – Google and all of the typical resources developers are accustomed to are not available—requires a lot of trust in the local developers – A lot more firmware and hardware engineering is present | |
| Greater Asia | ||
| Time zone | Significant differences in time zone | |
| Skill Sets | – Low quality – India has come a long way on skill sets in the last 10-15 years | |
| Cultural compatibility | Large cultural and linguistics barriers | |
| Fully-burdened cost relative to the US | 30-45% | |
| Political risk | Moderate risks | |
Where should you look to find potential global engineering partners to work with? What are the steps to running an evaluation?
You can use staffing agencies or third-party team builders – firms that operate like staffing agencies aren’t going to be as effective. They’ll likely be less expensive but they won’t look into quality or cultural fit. “Toe dip” type engagements also tend to fail – they don’t require either party to commit and set a poor cultural foundation.
Select the partner that fits your goals and business plans – selecting engineering partners is not a one-size-fits-all exercise and is largely dependent upon the type of work to be done and your readiness to use a partner.
When evaluating a team, understand very crisply who will be working on your account – otherwise, you may interact with very impressive people who were assigned to your account long enough to win the work before they’re moved to the next project.
Characteristics to evaluate a global engineering team include:
- Technical Capabilities – simply put, can they do an amazing, high-quality job? Better yet, can they bring new skills and ways of working to the overall engineering organization?
- Cultural Fit – there’s more to work than just bits of code. Culture is at the heart of retention, productivity, engagement, communication, and motivation.
- Drive – do they understand the mission of the company and get excited to execute the roadmap? Or to help (if required) ideate new items for the roadmap? Is any business empathy exhibited or is this purely a mercenary organization?
- Access – does the team work as an extension of your own with very little to distinguish what badge they have, or are you communicating purely with a project manager? Can you visit them for in-person workshops? Or will they visit you?
- How they position themselves – how an organization talks about itself will tell you a lot about how they work. A prime example of this is the organization that leads with price. Are they competing by being the cheapest? Does that mean they assume all engineers are equal? What does this say about their hiring priorities?
Should you select and build teams in a single location, or can global engineers be fully remote and spread out? How many engineer locations can an organization support?
Try to focus core team members in one metro area – other team members should be in the same country or a nearby country. Let people live and work from their desired location, and ensure you don’t lose top talent and someone who shares your mission because of location.
Bring teams together at least a couple of times per year – bring everyone to a location for a week or weekend and get the team on the same page. This bonds the team. Working side-by-side is valuable and the more you can make that happen while not restricting people to particular locations, the better.
What legal/administrative steps are required to employ an engineering team abroad?
You have to set up an entity – you can either do this yourself or use a company like Nimble Gravity. Ask how much time you want to spend administering a different entity, setting up a business, and establishing relationships during travel. Companies like Nimble Gravity have those pieces in place already.
Once you have a global engineering team, how do you onboard and train them?
Treat the team with the same approach as a local team – give them training and processes in written and verbal communications. Tie new employee success to existing employee goals. Build team relationships so that communication can flow freely and easily.
Use the application as much as possible – expose team members to the diverse problem set that the organization faces. You want your global engineering team to be connected to the problem-solving that will move the ball forward for your organization.
If possible, send the home-market engineering manager to onboard – it’s not possible to onboard every employee in person. But as often as you can, the home-market engineering manager should go travel to a new global team and work with them for a week or so.
What kind of routines and tools do you need to have in place to align your global team?
Technical Project Managers or Scrum Masters should lead each pod – you should have a project manager in the market of your global team so they can help with the asynchronous integration of projects and roadmaps.
Have Agile and Scrum development processes solidified – having the processes and procedures around Agile and Scrum will eliminate the need for more involved meeting and management approaches. Your processes should create alignment.
Scrum, Agile, and Roadmap tools – use tools like Monday.com and JIRA. There are a lot of tools that can help you organize your development work, backlog, and roadmap.
How should you track and monitor the performance of your globally outsourced team?
The same way you would with a home market team – for teams using Scrum and Agile processes, they should be evaluated and tracked the same way you would track your in-market team—on the velocity and quality of their software delivery.
Monitor speed and quality metrics to gauge performance – monitor velocity by looking at the Committed/Completed ratio and monitor quality metrics like defects found in production.
If your global performance lags, send in an Agile coach – have them show up and discuss how they define “done” on their software. Were all the boxes in the development process checked? What were the goals around speed and quality when delivering that software?
Despite the cost savings, expectations shouldn’t be lower for a global team – you should expect your global team to have the same level of ownership and capabilities as a team based in the US.
Who should be responsible for managing the global engineering team locally? Who should be responsible for them at home?
An engineering manager in your home market should manage global teams from abroad – they should connect the global engineering pod to the team that’s in your home market and manage and monitor their performance from afar. They should integrate the team with higher-level decision-making to help accelerate the capability.
A technical program manager should report to the engineering manager from the global market – they’ll be the day-to-day engineering manager located in the same region as your global engineering team.
For smaller companies, a CTO/Head of Engineering may handle the global team – if you’re just building out your engineering department, the CTO may be the only role in the home market equipped to manage the global engineering team.
How should you expect the all-in costs of outsourcing to compare to building out that team in your home market?
Cost really depends on location – the fully burdened cost of each region relative to the cost of the same team in the US is:
- Central & South America – 40-65%
- Africa – 20-50%
- Eastern Europe – 40-75%
- Western Europe – 75-100%
- China – 35-55%
- Greater Asia – 30-45%
Understand that fully-burdened employee cost is a lot higher than salary – the fully-burdened cost of an employee is a lot more expensive than the salary that the employee takes home. Full burden in a global market includes:
- Salary
- Benefits – professionals expect to have health insurance for them and their families.
- Employment lawyers – you need labor law counsel if you’re setting up an entity.
- Transfer costs – you usually need to show a profit within a country you’re operating in, and there are costs to this as you can’t just shuffle all the money back to the US.
- Taxes – you’ll need to pay the applicable taxes in whatever country you set up operations in.
- Ancillary – there are plenty of unusual expenses that global engineering teams incur. For example, in Mexico employees get food coupons provided by employers that pay for their lunch.
Traditional outsourcing charges by the hour but ends up with worse results – if you contract with a firm in a race to bring down the cost of engineering, you’re not going to index for quality and buy-in.
What are the most important pieces to get right?
Hire people that are good communicators – luckily in Central and South America, there are growing English skills and a desire to grow English capabilities is a major motivator to work with a US-based company.
Find engineers that are cultural fits and invested in the mission – hire engineers that are going to grow because of the opportunity. The more you hire based on engineer buy-in and reward it, the more you can build the confidence of the global team to help you accomplish business goals.
Maintain accountability of the remote team – this helps them take ownership of deliverables and avoids “spoon feeding” of small, unrewarding tasks. If you treat the global team with respect, they’ll reward you with results.
What are common pitfalls?
Make sure there’s not a class system in your engineering org – there shouldn’t be engineers who feel like they can do certain things but not others because of their location. If you bring global engineers into the fold and don’t task them with solving real problems, it causes problems down the road.
Using global engineering for resource augmentation – generally, trying to add 1-2 people to an existing team doesn’t work very well vs. trying to build entire new teams. Adding single or small numbers of people to existing teams creates a different motion for intra-team communication that can often lead to those resources being under-utilized, unproductive, and unhappy.
Creating unequal participants and not sharing information – don’t hide or protect certain pieces of information from the global team because you don’t think they’re capable. Exposing your whole organization to as many of the problems as you can put more brains on the problems and helps you solve them.
Responses