Last year I left Silicon Valley to join TransferWise as their VP Engineering.

SHOULD I LEAVE SILICON VALLEY?

As I took on the role of leading Engineering for TransferWise — the international money transfer startup — last summer, one of the biggest questions and (frankly speaking) fears I had when making this decision was “should I leave Silicon Valley?”

This fear was grounded in the fact that the valley still produces more successful high growth start-ups than the rest of the world combined, and being a technologist — the valley is the place to be!

Another question I had coming into the role was how would I build an engineering organization outside the valley? A large part of my TransferWise role is to scale the Engineering team — i.e. hire, build, foster a great culture and build an awesome product. Given my experience of only having worked in the San Francisco Bay Area, how would hiring be different in Europe?

Popular wisdom dictates that “if you’re a software engineer — no matter where in the world you are — pack your bags and head to San Francisco as there’s no other place to be.” But what about the rest of the world? What about those who can’t or don’t want to head over to the sunny South Bay or the foggy San Francisco shores?

TransferWise engineering team has gone from 48 to 90 engineers across 3 locations in the last 11 months. These are my learnings from scaling technology and product hiring over the last few months outside the valley — in Europe.

LOADS OF TALENT OUTSIDE THE VALLEY

When living in the valley bubble, like most people commuting up and down the 101 and 280, I thought the best engineering talent lived in the area. While it’s true the SF Bay Area has the highest density of uber smart, strong engineering talent, there are large enough pools of talented engineers outside the valley who have a strong desire to leave a big dent in the world. This pool is big enough for companies to attract and hire strong engineering talent.

In Europe, the free movement of labor across the eurozone has made it easy for us to attract talent from different countries without the need of a lot of visa paperwork. Anyone who has hired in the valley at scale has definitely struggled through the US immigration system to bring in talented developers given the caps and ridiculous lottery of the H1B visa program.

THINKING ABOUT THE CUSTOMER AND THE PRODUCT

At TransferWise we believe in engineers being product thinkers, not just code creators.

An engineer gets deep into understanding why a certain feature should be built and what impact it will have on the customer. Some of our engineers are our best product managers — because they’re close to the customer and the metrics to understand the why, how and what to build. While this is not a big surprise for most valley start ups, most engineering teams outside the valley have not embraced this idea. Yet.

The majority of the engineering talent outside the valley has never worked in a start-up. Instead their work experience lies in large corporations — banks, telco, retailers, trading firms — that can’t claim to be customer evangelists. Engineers at these large corporations are still used to running through a long product development cycle. They’re used to business owners, system analysts, product managers and project managers defining specifications in lengthy word docs before an engineer is assigned to a project to bang out 20 tickets to build a feature. The engineer is usually so far from the customer that she doesn’t understand the impact of the code she writes for the customer.

In fact, a lot of engineers are confused who the customer is. One of the questions I ask during the interview cycle is “who is your customer?” You will be surprised how often someone will say “my product owner, business analyst, sales team”.

Some engineers have not seen a customer in real life. This has been the toughest challenge in building a team.

But, this is changing.

With more and more start-ups popping up, and with the internet democratizing knowledge, engineers in Europe are following the same blogs and leading thinkers that the rest of the populace follows. What they want is a place to learn and practice this knowledge on a day-to-day basis. Some of these engineers self select themselves into hiring funnels like ours and seek us out. For the rest we need to actively educate them on how building software for the customer directly (without 3 middlemen) helps them have a bigger impact.

While it’s easy to get candidates excited and thinking about direct impact, it’s unfortunate that a lot of applicants fail to demonstrate the ability to think about the customer. This is where we have a lot of rejections in our interview cycle.

LOCAL PRODUCT EXPERTISE AND CUSTOMER EMPATHY

Building a global product requires local knowledge. As we scale our product globally, we have seen a massive advantage by having a team that comes from over 30 different countries.

The nuance of how a German user thinks about data security vs a US user can be big difference in building a mediocre product or a high NPS product. We have all used products which have idiosyncrasies due to where they are built. I remember during my days at eBay when we wondered about the low adoption rate of PayPal as a payment method in Germany. In fact we were trying to force PayPal as a payment method in Germany because we expected our German users to behave like our US and UK users (of course).

Understanding the German user psyche of why they trust or prefer their banking system, and how German users don’t have as many credit cards, requires someone who has grown up with the local banking system there.

SALARIES

This one is obvious. With the exuberance that the valley has gone through in the last 4–5 years, software engineering salaries have hit new highs and the SF Bay Area has become even more expensive to live in. Depending on where in Europe you are building your team, you could hire 2–3 high caliber engineers in Europe for the same compensation for every 1 engineer in the valley at current rates. Even better, for most locations, their standard of living at this compensation would still be better than in the valley.

FINALLY, FOCUS

Overall, if there is one big advantage that teams iterating on an impactful idea outside the valley have, it’s Focus.

The biggest downfall for start ups is when they get distracted and lose focus — whether it is by trying to solve too large a problem or expanding their product offering too quickly before building the main product. When building teams, this focus comes in the form of talent retention.

Like everyone in the valley, engineers suffer from the “shiny toy syndrome” — what’s the next hot company in the news raising funding, throwing in new perks, doing “cool” stuff etc. In fact I myself didn’t realize how much I talked and spent time on finding what’s “new, different, unique” until I stepped away. With the amount of VC funding that’s been thrown around in the last few years, coupled with the fact that good engineering talent is always hard to find, companies have to play the game of attracting talent not just based on the problem they are solving but also being the hot, new company in town. As a result, we see a lot of engineers in the valley hop from start-up to start-up every few years. While I agree that this is not true for everyone, company hopping is a common theme which creates a significant amount of churn through teams.

This seems to be less of a problem outside the valley. Given the lower number of successful start-ups and self selection of engineers who want to work for a start-up and focus on the customer, engineers tend to vet companies and problems they want to solve during the hiring process more. Once they join a company, people tend to focus and iterate on building. This means more time spent on customers, product and technology and less time spent on distractions.

I am not sure if this will change as more startups succeed outside the valley and more VC funding flows globally, but at the moment I think this focus is one of the biggest advantages non-valley startups have when scaling the organization.

IN CONCLUSION

Building a global product that delights users around the world requires local knowledge and the closer we get our engineers to our customers, the faster the learnings can be added to the product to make it resonate with our users.

My experiences over the past few months have definitely shown me that it isn’t as hard as I initially thought it would be to build a strong technology team outside the Valley. If you know the type of engineers you are hiring and can vet that in the hiring process then the talent pool, diverse backgrounds and focus can play to your advantage.