Recruiting Software Engineers for TransferWise

Within TransferWise we do a great deal on sharing insights in what we are building and the why behind it, this inspired me to write this blog post to give an insight on what I have personally achieved and experienced to date here at TransferWise.
I had an overall idea of TransferWise as a company when I was a customer, transferring HUF to EUR while living in Budapest. When I joined last year in October as a Technical Recruiter the expectations were clear: Hire Full Stack Engineers for TransferWise into their Tallinn office.

Once I finished my onboarding, met all the lead engineers and developed a basic understanding of what exactly is going on and what the need actually was, I got my head around all the different tools that were in place for recruitment and I got to work. I was looking at a massive backlog of applicants with little to no structure in place. However I realised that my lead was taking care of three locations by herself before my colleague in Budapest and myself were hired. She did an amazing job, but the workload was tremendous to be handled by just one person.

In TransferWise we believe in autonomy. It doesn’t mean that people can do whatever they want but it means that people/teams are empowered to make all the decisions how they can help our customers the most.

Recruiting isn’t only the recruiter’s job

The above line is somewhat a negative connotation, but this is what most recruiters are up against. Even though I am hiring Software Engineers, I am not one of them. One of the biggest challenges is understanding what ‘good’ means in the TransferWise context. That requires a lot of input from the engineers here at TransferWise. It took me about five months to wrap my head around what a TransferWise engineer looks like and what a candidate needs to get to the finish line.
What I want to say is recruiting Software Engineers at TransferWise is pretty unique. Traditionally, a lot of companies work with recruitment as a service. The VP sets out a plan, recruiters deliver and hiring managers get to wait and sit back until there is a stack of candidates to pick from. At TransferWise, each team works with you- whether this is pre-screening candidates, pitching TransferWise to passive candidates (yes our VP of Engineering does this as well), up until the point where they are sourcing candidates with you and guide you what to look for on a technical level. This makes working as a Technical Recruiter in TransferWise challenging and interesting. The trust you are given means that engineers listen to recruitment, trust our judgement on candidates and allow us to grow the engineering department in the most efficient and nice way.

Defining the hiring process

I came from an RPO / sourcing background where I was used to use data to provide insight to my customers and statistics on whether or not it is feasible to even hire into a location. It seemed natural to me to start tracking the time to hire. This told me how efficient my hiring process actually was and it identified where I could improve. At my previous company, this was buried by layers and layers of managers before getting approval or opportunity to change anything directly.
I started with a basic Google sheet tracking the amount of days it took to offer accepted. On average it was quite ok, but the reality was shockingly slow. In an industry where the demand is significantly higher than the supply of professionals it’s key to move fast. I started to gather more data on where I could improve, and realised that by setting deadlines to candidates for completing their take home test and holding myself accountable for speaking to any applicant within five working days. The results changed drastically, the average became much closer to reality. Gathering all this data also gave me a stronger case to implement changes into the process. As much as you can have your opinion or thoughts on how to improve things, data can transform not just your approach to solve problems or improve certain aspects. The facts are hard to ignore.

Beyond speed

After improving the speed of candidates moving through the process, getting my head around all the different teams and their multitude of needs was my next point of action (alongside operational recruitment e.g. sourcing, interviewing, offer negotiations, applicants). At the time of writing, Transferwise has 20 engineering teams in Tallinn alone, each operating as a small start-up with full autonomy.
What we had in place as advertisements when I just joined was just this:

“Full Stack Developer — Tallinn” and “Java Developer — Tallinn”

This meant that during each interview I had to explain all the different teams within TransferWise as I couldn’t give them any indication of which team they might end up in after a successful interview process. Having a flat structure is great for many reasons, which I will not list now, but for interviews and candidate experience it resulted in unclarity and an overall messy process. People ending up in teams with people whom they haven’t spoken with during their process wasn’t something I wanted anybody to experience. After all, my process was with all the people I still work with until this day, so why wouldn’t it be the same for talented engineers?

Having autonomous teams and not a classical top down decision making structure in place meant I had to sit with each team and communicate with them on all the company channels to figure out how to get talented engineers hired into their teams. This was a challenge, as nobody gets told what to do (e.g. “this decision has been made, now choke on it”) I had to convince people the benefit of having team specific job descriptions. After some hesitation teams slowly started to write their job descriptions and now not just internally, but externally there is a much better overview of which team takes care of what exactly within TransferWise. It helped me to approach people using specific knowledge of the role, and made the teams more directly invested in hiring.

You might think I created more work for myself by splitting two job ads up into several, instead it helped me attract diverse talent with the basic skill requirements TransferWise needed. It also created a point of reflection for teams on what it actually is they are facing in terms of technical challenges and what additional skills they could benefit from. Today, most candidates, when applying for a role in TransferWise, know which team they eventually might end up in. Same goes for teams, when they talk to a candidate, they might talk to their soon to be colleague. As simple as it might look, and other companies have done this for years and some still could do it, it pays off in the end. We still have our generic ones open for people who can; ‘do it all’ and could be great for any team. As a side note, it gave me a better chance to research different industries and markets to ‘shop’ for talent.

Forecasting

Because Transferwise has a product engineering culture, it’s tough for any team to predict who they would need a year from now.

When I started, there was a clear aspirational headcount number to achieve., However what wasn’t clear was which team and when. For us within our engineering recruitment team we had the task to hire and track this somehow, but it was scattered amongst many different tools and sheets. Something that can be seen as ‘legacy code’ from a small startup to a decent mid sized startup. Forecasting was something that could use some streamlining.

I wanted to implement clarity, so I moved towards a simple request form for our teams, which would auto populate a sheet with basic questions and information (e.g. how many people, which team, what skills, which quarter and which location). Instead of having to go into a lot of different meetings and waiting for the VP of Engineering to hand over a plan to recruitment, we gave the opportunity for teams and team leads (in order to get a clear overview and don’t interfere with autonomy) to fill out these forms, and once they did we as a recruitment team had a clear overview of what actually the need was and what particular skills were needed, backend, frontend, full stack etc. In return we tracked if we met the need (e.g. hired in the requested quarter, cost per hire, location etc). Not only gave this a better workflow for both parties (even though it was something everybody had to get used to) it also gave us a clear overview of what the actual time to hire was per location, if the demand was something which we could meet, which location do we struggle to hire in and which positions are difficult to hire in the markets that we operate in. Having all this information centralised created transparency as it is accessible for all the engineers in the company and decreased noise on all the internal comms. Less e-mails or open chats make engineers happy.

Getting to the point

At TransferWise you’re not a recruiter who just serves the hiring manager, you’re integrated with the engineering department. You are surrounded by people who are involved, proactively coming up with solutions, and genuinely care about hiring. Most companies preach that they give you autonomy but this is usually confined by flexible working hours and working from home. Having autonomy within TransferWise for me means that I get to build MVP’s for technical recruitment and not only focus on getting talented engineers on board, but build structure and processes that do not damage our autonomous working culture, are aligned with our values and most of all make it a pleasant experience for candidates and our teams. All the things I listed in this blog were core things that needed improvement, and I got to improve all of these points. I have autonomy, but I am not alone. I am backed up by a great team of smart people, the wider recruitment team and the engineering team. Recruitment at any company isn’t rocket science, you can work with fancy sourcing techniques, attend events to learn and listen to thought leaders in the industry. In the end it’s all about the people you work with, and if you have enough drive to get things done.