Should you hire developers in the US? (Part II)

In the first part of this series on hiring technical talent in the US we shared the insights from our research in to some of the factors that should be considered when deciding when to hire developers in the US. In part II we explore the respective pros and cons of each of the following options:

• Keep development team in home country and do not move or hire technical staff in the US;
• Keep development team in home country as well as to start building out technical capabilities in the US;
• Move the whole technical team to the US; or
• Implement a distributed technical team.

Move whole tech team to the US

To move an entire technical team to the US can be a risky move and should really only be considered if a company is in its early stages with a small team that have the ability and willingness to relocate. Whilst a high risk move, there are some scenarios in which this would make sense. If it is known at an early stage that a company’s client base is going to be almost entirely in the US and that in the long term the company will inevitably gravitate towards the US, then moving the tech team early — whilst disruptive in the short term — will allow the company to then quickly refocus and build out a tech team in a single location to the rest of the company that is close to its client base after the initial period of disruption. Beyond the founders and maybe one or two employees it becomes a lot harder to relocate fully — and nor would it likely be wise to relocate a large team.

Keep tech team in home country but make first tech hires in the US

Not wanting to completely uproot a team in its home market but also wanting to setup a technical team close to its clients, a company may opt to create a small tech presence in the US — a base from which it can then grow. From our conversations, there are a number of risks to this approach. Namely that when the US team is ancillary to the main team there is a risk that culturally the two teams will diverge and that without proper specialisation of roles, the ancillary team becomes more a disruption than an advantage. Additionally, a company coming to the US without an established brand is going to find that they will have to send a senior engineer over from their home base to seed the team and that without an established brand it will be very hard to hire even a couple of engineers without incurring significant costs. As such, compared to hiring more engineers in a home market, the opportunity cost of setting up an ancillary US presence is extremely high.

Eventually as a company grows it will reach a point where it makes sense to hire technical staff in the US. However, this should be driven by setting and then meeting very specific US revenue and sales milestones. Additionally, from our own experience and the feedback received from our interview we consistently heard that the first technical staff that are hired should be sales engineers who can provide technical support to US clients as opposed to core engineers.

Keep development team wholly in home country and not move or hire technical staff in the US

In such a scenario, the technical team would remain in its home country but other teams — such as sales and support — would be built out in the US. This may be a result of it being decided that the cost of a move is too high or that the technical team is already of sufficient size such that it would be impractical to move. Of the European companies that we spoke to who have successfully expanded into the US this was typically the strategy adopted. For a mature company, this is generally the most practical option because key technical staff will often have already been hired and disruption is wanted to be minimised. Compared to setting up a technical presence in the US, keeping technical staff in one location allows there to be focus and simplicity in managing communication channels. Instead of having to manage comms between technical teams, the CTO can concentrate on ensuring seamless communications between the sales and product teams — who are more likely to have been relocated to the US.

Whilst this approach will help keep costs down, in the long term, if a company’s market is primarily in the US, the development and potentially product capacity of the company are separated significantly from those on the front lines selling the product which can risk causing friction later down the line. As such the CTO needs to work with product teams to develop process to ensure seamless communications channels — this only becomes harder as a company grows and if not managed properly can cause considerable friction between respective teams. However, for a company whose clients are more evenly spread internationally, this is not as much of an acute problem and additionally, with the proper processes and buy in across the organisation, can be made to work successfully — as demonstrated in the case of a number of companies we spoke to.

Setup a remote technical team

Remote working can seem like an extreme option when it comes to dealing with how to arrange a technical workforce and it is true that it is hard to get remote working right. The risks are that without buy-in from the wider organisation and without the correct processes in place, the necessary communications channels are not opened up between the relevant individuals. However, this is not to say that it is not possible to successfully operate a remote work force. From our conversations with companies it is clear that even with large differences in time zones, it is possible to successfully operate remote working teams and that this is a viable option for start-ups with the right planning.

Not only is it possible to operate remote working teams successfully but there are a number of nuances that result in some surprising advantages. Provided that a team is able to be establish stringent processes for keeping communication channels open — for Instance mandating daily all hands meetings for the whole tech team — the quality and rigor with which developers must work can and must dramatically increase. The reason for this being that if an engineer is tasked with completing a task and does not complete it satisfactorily, does not document it properly or ships it with bugs, then they waste the time of individuals in the product team because it will be another day until the issues can be raised with them at the next all hands meeting because of the time zone difference. As such, remote working if done right can result in more stringent approach to writing, documenting and shipping code. Additionally, it places additional emphasis on the product teams being able to successfully spec out work for the developers and communicate requests. If a team were to be co-located there can and often is a temptation to let processes lapse. There are limits to the extent of the distribution though, if the difference in time zones in which everybody works from the earliest to the latest is more than 7 hours then having a daily meeting becomes impractical — risking the whole remote working arrangement.

Maintaining team culture is at its hardest in the context of a distributed workforce. Approaches that we have seen deployed by some companies successfully include requiring new joiners to travel to and work from the company HQ for a number of weeks and running quarterly trips where the whole technical team meet in a single location. Some companies such as Big Heath have been able to make remote team works for them to the extent that they have all of their engineers working remotely. However, this approach requires strict discipline that many companies will find hard to pull off successfully.

Concluding

The best way to go about tech hiring will vary depending on each company’s specific circumstances. In making the decision of whether or not to move, the above factors should be carefully considered. Generally speaking, a founder needs to accept that building a technical team in the US is going to be considerably more expensive than in Europe — even in cities other than the tech hubs of New York and San Francisco. As such, it should be considered if a company is looking to hire industry specific talent that can only be found in the US because if not, whilst it is logistically harder keeping technical talent in Europe working closely with commercial teams in the US, the cost of moving technical roles to the US is excessive.

If a company’s main market is going to be in the US in the future and the company is sufficiently small (i.e. pre seed with a couple of founders and employees) then it may be an option to move the whole team such that you can then build out from a single location. However, if the US going to be ancillary to other global markets then such a move may be unnecessary especially given the cost massive advantages of keeping technical talent in Europe.

Generally speaking, already established European companies should look to keep the tech team in one central location in their home market. This is typically the path of least resistance and allows for communications within the technical team to be optimised and disruption minimised. It is not usually a good idea to setup an ancillary technical office in the US because of the addition processes and burden it requires of the — usually larger — team in the home market to support the smaller US team. Exceptions to this may be when specialised talent needs to be hired — that may only be available is certain locations — or when technical sales talent must be hired. In these instances, the teams should be seeded with employees from the home market and founders should proceed with caution as it may be advisable to only make these hires when a company has met a clear set of sales and revenue objective and then wishes to hire sales support engineers in the US to interact and provider tier 1 and 2 support to US client. It most instances it is not advisable that these US based engineers work on the core product.

We would like to thank the CTOs of a number of companies who contributed to our research: Artesian, Big Health, Antidote, Elliptic, YPlan, Medisafe, Eve Sleep, Behaviosec and MIRCL.