How to Build a Global Engineering Team

How to Build a Global Engineering Team

Your small founding team has worked hard and has managed to get your idea off the ground. You are starting to get some serious traction and need to do more, faster.

You can’t clones yourselves and you can’t add more hours to your days. Instead, you have hire more people, grow your team.

Fierce Competition

In the old days you could ignore the competition. You had the only cool company in town and wanted the very people who didn’t fit in the corporate environment of the day.

Today you have to compete with the big guys and the not-so-big-guys. And they all have more of everything than you: more brand, more mindshare, more money to offer, liquid stock, their products are used by zillions of people, etc.

So, what are the alternatives?

Think Outside the (Geography) Box

First of all, think outside your office. Do you really need everybody in your team to be sitting next to you?

Think outside your city. Does everybody in your team have to live in your city, so they can come to your office, and sit right next to you? Really?

For example, in Silicon Valley we believe that the people here are the best and brightest. And that’s a convenient myth, but a myth nevertheless.

Most of us are definitely self selected. We’ve moved here, away from friends and family. Most of us have a pretty high tolerance for ambiguity, and risk taking (sometimes to the point of gambling).

But we are not the bestest and brightest.

Consider Joy’s Law,

No matter who you are, most of the smartest people work for someone else.

Attributed to Sun Microsystems co-founder Bill Joy.

He said this about a company, but the same principle applies for any boundary,

  • Your office
  • Your city
  • Your country

Whatever the boundary, most of the smartest people are elsewhere.

There’s a whole world of talent out there. Embrace it as your own.

People live where they live for a number of reasons, including,

  • The high price of city living
  • They want to raise their kids elsewhere
  • With a better, less dense school system
  • Close to family

Some of these “other” places are well known as a source of talent outside the US. They are the traditional “offshore” destinations, like Eastern Europe and India. And places like Vietnam and Philippines. In Philippines, for example, college grads speak English. Finally, closer to home, we have all of Latin America.

So, the talent is “out there,” and it can definitely be made to work for you.
But there are differences, and you have to consider how they will play into your plans.

Project or Product?

The first to be clear about is whether you are looking for help with a few projects or whether you need to grow your development team to expand your product or platform.

If we are talking about projects, then,

  • It is a short term engagement.
  • “They” can work on their own, without a lot of contact with you.
  • It’s probably simple enough that it can be specified in a short document.
  • Because it is a short-term engagement, cultural fit is not an issue.
  • Your main concern is to spend as little as possible.

When you add it all up, temporary contractors may be the right choice for projects.

In this case, Elance-Odesk or Craigslist may be just the thing for you.
To be fair, I’ve known people who have put together fairly serious software over time using this model, at times having three or four people working separately. However, that’s the exception, not the rule.

You may need to deal with, say, less than desirable experiences,

  • People “go away” halfway through a project.
  • Sometimes “the person” you start the work with gets replaced by another developer and you don’t find out until it’s too late.
  • When it comes to quality, “your mileage may vary.”
  • You agree on a price, but halfway through the project the price goes up considerably.

If you on the other hand, you need help with your product, then you need a persistent team of skilled, committed people who share your values.

A few years back, a business guy had an idea for an iPhone app. He thought of it as a one-time project. He posted it on Craigslist, and a bunch of people responded. After talking with the most promising ones, he ended up contracting with a developer who had no experience developing mobile apps or Objective-C.

On the other hand, this fellow was otherwise a very experienced developer, very stable, and (AND) he was very up front about the fact that he didn’t know the iOS platform but wanted very much to learn it. He had been laid off recently (ca. 2008) and took it as an opportunity to learn a new, upcoming platform.

Long story short, they’ve been working together ever since.

So, what had started as a short-term project, ended up being a long-term relationship. And these are a few of the reasons why it worked,

  • They were both Americans and culturally aligned with each other and their market (i.e., the US).
  • They shared key, important values.
  • They were only two time zones away from each other (i.e., one in California, the other in Illinois).
  • They were also close enough that they did visit each other every so often.
  • They were honest and fair with each other from the beginning. For example, once their first app started to make money, they decided to change the model and actually shared the upside.

When you look at it this way, it is not a surprise the relationship worked. On the other hand, whenever any of these elements are missing or weak, then things will probably not work (i.e., even if you share an office).

Co-located or Distributed?

Do you want your remote team to work out of a single remote office? Or can people work from their home or in a coworking space?

The co-located model is the standard model, so we know that works, albeit with some disadvantages.

Distributed Open Source Projects

We also know that the distributed model works because every Open Source (OSS) project out there uses it successfully. From Linux on forward, OSS projects are built by people from every corner of the world.

See, Producing Open Source Software, by Karl Fogel.

Distributed Commercial Companies

The distributed staff model also works for commercial companies. For example, here’s a list of 22 companies with distributed staffs, including well-known, successful ones.

This list was put together by Scott Berkun, author of the The Year without Pants.

See also REMOTE, by Jason Fried and David Heinemeier Hansson or 37Signals.

Mixed: Worklist

Somewhere between the OSS distributed model and the private, co-located model at opposite ends of the spectrum, is the Worklist approach.

The neat thing is that it supports a mix of,

  • Full-time employees and part-time freelancers.
  • Co-located or distributed.
  • Public and private IP (e.g., Product Backlog, source code, etc).

Worklist is the invention of Philip Rosedale, founder of Linden Lab, the maker of the virtual world platform Second Life.

Philip has used Worklist in his other projects since leaving Linden,

Like an OSS project,

  • Your Product Backlog is public (i.e., all or much of it).
  • Ditto for your code.
  • Employees and freelancers choose what tasks they want to work on (e.g., coding, code reviews, documentation, etc).
  • You accept a “bid” and the person now works with the rest of the team to deliver it, hopefully on time.

Unlike OSS projects,

  • People get paid.
  • They may even get equity.

Engagement Models

Assuming that you are going to grow a persistent, long-term team, then you need to consider the different ways you could do it at a remote location.

Are you going to do-it-yourself and hire them directly or will you get help from a local third-party?

If you do it by yourself,

  • You own recruiting at remote location (i.e., you have to find people there).
  • If you are going to co-locate them in an office, you have to find a place, with connectivity, etc.
  • You must know the rules and regulations of the target location. For example, in Mexico, you have to pay severance to any employee you let go. In theory, you can skip this if you are letting the person go for negligence, but … you’d have to prove it, etc. So, in practice, whenever you let somebody go, you pay the severance.
  • You’ll have to learn to parse resumes from that part of the world. When I first started looking for people south of the border, I was totally misreading their resumes. People write CVs differently in different parts of the world, and I was, let’s say, naïve about it.
  • Also, you will miss out on good talent if you use English in every interview. For example, we first do an interview to make sure people can hold a fluent conversation in English. But then, we do the Profile interview and the Pair Programming exercises in Spanish. We want to get to the bottom of what the candidate knows, how she works, etc,
    • Does she know basic CS concepts well?
    • Does she know how, and, more importantly, “why” things work?
    • Does she know how to leverage her team or does she has to invent her own wheel every time?
    • Is she overly needy and can’t do anything unless somebody tells her how?

Interviews are high pressure situations and the “second language” factor adds to it. Worse, it prevents you from finding out about this person you are going to be working with.

You learn more about the person you are interviewing in their native language, no matter how good they are at their second language. Stuff comes out in their native language that would never come out when using their second language. Even people who are very, very fluent in English at work, may have a more limited vocabulary for topics outside work (e.g., their personal lives). And you want to learn about that as well.

In any case, we tried it both ways, and we found that once the person is past the “interview” stage and is now an accepted member of the team, then the focus goes back to the work to be done and the language comes natural.

If you you decide to work with a third party, what do you expect from this company?

  • Do you need somebody to just provide infrastructure (e.g., office, connectivity, etc) and maybe help sourcing candidates?
  • Or do you want to partner with a company that works as an extension of your company and your vision?

Consider that, as a startup, working with a partner you can learn from can help you reduce costs, avoid mistakes, and save time in the long run.

Closer Is Better

Eventually, you will be pushed to “go offshore” to save money. The problem is that traditional offshoring does not work for software product development.

Product development is different from other forms of software development. It is a team sport and the team needs to stay in contact all the time. There are too many things that are discovered only through the creative process of building a new product, things that cannot be neatly written in a spec.

From that point of view, the traditional offshoring places are way too far in time, distance, and culture,

  • India: 12.5-13.5 hours of separation; 22+ hours by plane (plus a couple of days of jet lag, both ways).
  • Eastern Europe: 9-10 hours of separation; 18+ hours by plane (ditto for the jet lag).
  • South America: once you get to the American continent, it starts to look more doable. I first looked at Argentina but it is four to five hours away from us and it’s pretty far and expensive to get there.
  • Central America: I considered Central America, but it has a tiny population that’s not well educated, and lacks in English skills. Costa Rica is the exception to this rule.

    Costa Rica has the highest quality education system in the region. English is pretty prevalent in San Jose (i.e., it has the highest percentage of American expats per capita). But it has a population is 4 millions people, 1 million of which is in San Jose, the capital. So it didn’t seem scalable to me.

The conclusion is that, at least for California, Mexico is the preferred location for growing your development team.

  • Mexico aligns well with our time zone.
  • Traveling to Mexico is relatively cheap and quick.
  • Jet lag is non-existent/insignificant.

Mexico, like most of the rest of the world, there were plenty of skilled, passionate engineers who are also fluent in English, share our values, etc.

Most importantly, these folks speak up, self-direct, and show initiative. Which is, BTW, a key quality for people in a remote team.

Latin America Tech Companies

Costa Rica Avantica 250 people; software development.
Panama LogicStudio Banking and Corporate solutions.
Colombia Asesoftware 270 people; Develops in Azure, .NET.
Koombea 100 people; mobile, web apps; UI design.
Chile Tecnocal* 15 EEs; hardware design.
Argentina Epidata 100 people; Open Source, software architecture; software development in Java and .NET.
Anotek 30 people; software development in Java and .NET.

Total Cost of Engagement (TCE)

Costs are one of the most misunderstood aspects of building a global engineering team. Myths abound.

The basic thing to keep in mind is that your total costs include more than just the basic hourly rate. Sometimes, a lot more.

Intangibles, like cultural friction, miscommunications, and turnover quickly turn into very tangible costs.

These impose a significant loss of efficiency for the whole team. Typically, for every three engineers in the US, you need four in India to get the same results. Ant this is not for lack of smarts or skills.

The loss of efficiency comes from higher rework. stress (e.g., people losing patience the people “on the other side” because of constant misunderstandings). These result in lost time and frustration for your team.

People have tried to do daily Standups with their people in India or Eastern Europe, but this actually adds to the stress because either somebody is staying up late or or somebody else is getting up pretty early.

Even when this is forced to happen, the team needs more interaction than 15-30 minutes a day.

All of this increases your costs, in more ways than one.

Travel

A certain amount of face-to-face is indispensable. So you must consider travel as part of your costs.

  • The bigger the time delta between you and your remote team, the more you’ll need to travel there and have them travel here.
  • The further apart, the more expensive it is to fly there and back.
  • Travel time.
  • Jet lag at both ends.
  • The longer the trip, the longer you will stay to amortize the expense in time and dollars. Which makes it even more expensive, overall.

Hourly vs Flat

Hourly rates work for short-term, temporary engagements. For long-term relationships a flat rate is more reasonable and more inline with professional work. However, when it comes to working with offshore vendors, hourly rates have become the accepted norm. But it can be surprisingly costly.

Hourly,

  • Beware of “blended” hourly rates. It sounds low, at first.
  • You’ll have to pay for every hour worked. But it’s software development and the norm is that it always takes a little more than expected. That “little more” can add up to a lot.
  • The time you spend policing the “hours” is part of your cost (i.e., opportunity cost or time you could have better spent doing something constructive).

Flat,

  • Look for a weekly or monthly flat rate.
  • You don’t have to waste time as “hour police.”
  • Make sure there are no other hidden “fees.”
  • You can calculate your budget from day one.

Example

This example compares a “blended” hourly rate (i.e., $29/hour) at a far away location, versus a flat weekly rate (i.e., $1,700/week for developers and $1,400/week for manual testers) at a nearby location.

The model does not include things like cultural friction, stress, or turnover. It does include an “loss of efficiency” factor as a rough approximation for extra rework and lost time due to miscommunications.

For this example, we use 25% which is to say that for every three developers in the US, you need four in an offshore location (i.e., far apart in time and distance).

Using the raw rates, the cost of staff is slightly higher in the flat+near case, but surprisingly close to the hourly+far case.

However, once we apply the “loss of efficiency” factor, the costs flip and the hourly+far case is now higher than the flat+near location.

Once you add in the cost of travel, the hourly+far costs jump up significantly, while the flat+near costs go up only a little bit.

If you’d like access to the TCE model, please, send [email protected] an email requesting access (i.e., sorry, but it is the only way we can do this with Google Drive documents).

Become a Talent Magnet

Competition for talent is fierce all over the US and everywhere else in the world. Your challenge is not only to find great people but to get them to join your team.

The candidates you want already have offers from other companies with more of everything than you have.

If you look at it from their perspective, what they hear constantly is, “Work for me!” … “I’ll pay you more” … “Free massages” … “Free food.”

To stand out from the crowd, you need to communicate a different, more exciting, and memorable message that speaks to candidates at an emotional level, not the transactional level.

You need to tell your story. Speak to them about your company culture, its values, and long-term vision. Talk passionately about your noble cause, your company’s WHY?

Most importantly, tell about how this is an opportunity to make a positive impact the world. And tell it in a way that it can be a source of meaning and purpose for the candidate. Help her see herself as part of your journey.

Deep inside, most of us are Boy and Girl Scouts,

Always leave the campground cleaner than you found it.

Just think of much mileage these companies have gotten from their emotional messages,

  • “Don’t Be Evil”, Google
  • “Think Different,”, Apple
  • “Delivering Happiness,””, Zappos

Your message may not be so polished and snappy, but it has to be powerful and speak to the heart.

Tech company examples,

 

 

 

 

And the great-grand-daddy of them all,

  • John Lewis Partnership. Similar business model as Walmart, but without the blood-sucking practices (i.e., quite the opposite).

Purpose, Meaning, Governance

A compelling story of purpose and meaning will help you and your team to,

  • Grow in a scalable way, and
  • Run your company in a sustainable way.

Nearsoft’s own governance framework includes,

  • Noble cause
  • Vision
  • Values
  • Principles

A noble cause keeps us aligned for the long term and gives our work purpose and meaning. Nearsoft’s Noble Cause is,

  • To promote technology entrepreneurship in Mexico and beyond.

Vision as a mid-term guide, a short list of stretch goals that are nevertheless attainable. Nearsoft’s Vision (2012-2017) includes,

  • To be recognized as a top technology innovator in Mexico.
  • To become a top international destination for professional and personal growth.
  • To become a source of happiness for our employees and our communities.
  • To reach a $40M market cap by 2017.

Values give us a support, a base to stand on. Nearsoft’s Values include,

  • Commitment
  • Leadership
  • Long-term relationships
  • Smart & gets things done
  • Teamwork

Principles keep us steady on the way there. Nearsoft’s Principles include,

  • Purpose + Vision
  • Transparency
  • Dialogue + Listening
  • Fairness + Dignity
  • Accountability
  • Individual + Collective
  • Choice
  • Integrity
  • Decentralization
  • Reflection + Evaluation

See WorldBlu’s 10 Principles of Organizational Democracy.

As David Vik (i.e., “Coach*rdquo; at Zappos) has said in reference to an explicit governance framework,

When everyone knows it, they can get behind it, and then they don’t have to be told what to do.

We treat each other as adults and don’t have to waste time babysitting people.

Source: “Zappos’ culture coach: how ‘squishy’ stuff like culture took us to a billion dollars in revenue”.

Further Reading

The Year Without Pants, by Scott Berkun.

“The force behind WordPress.com is a convention-defying company called Automattic, Inc., whose 120 employees work from anywhere in the world they wish, barely use email, and launch improvements to their products dozens of times a day. With a fraction of the resources of Google, Amazon, or Facebook, they have a similar impact on the future of the Internet. How is this possible? What’s different about how they work, and what can other companies learn from their methods?”

Producing Open Source Software, by Karl Fogel.

This book about the human side of open source development. It describes how successful projects operate, the expectations of users and developers, and the culture of free software.

The book is, of course, distributed as Open Source, but you can also buy a copy.

REMOTE, by Jason Fried and David Heinemeier Hansson.

“As an employer, restricting your hiring to a small geographic region means you’re not getting the best people you can. As an employee, restricting your job search to companies within a reasonable commute means you’re not working for the best company you can. This book shows both employers and employees how they can work together, remotely, from any desk, in any space, in any place, anytime, anywhere.”

Tribal Leadership by Logan, King, and Fischer-Wright

  • >Leveraging Natural Groups to Build a Thriving Organization
  • 2011
  • Five culture levels
  • Noble cause

Start with WHY by Simon Sinek.

  • How Great Leaders Inspire Everyone to Take Action
  • 2011
  • TEDtalk

The Noble Cause concept from Tribal Leadership is equivalent to Sinek’s concept of “WHY?” in that they both point to the need to provide purpose and meaning to our work.

Peak by Chip Conley.

Maverick and The Seven-Day Weekend by Ricardo Semler, Chairman of SEMCO.

  • Put employee freedom and satisfaction ahead of corporate goals
  • Employees set their own hours
  • No offices, no job titles
  • Emps endorse/veto any new venture
  • Grew from $35 million to $160 million in the last six years
  • Virtually no staff turnover
  • Laptops, cell phones, email have destroyed the traditional nine-to-five workday
  • Freedom to get your job done on your own terms
  • Blend work life and personal life

Drive by Daniel Pink.

Focus Mode

Contact Request

Close

We will call you right away. All information is kept private