How we cracked the engineering retention problem

Edoardo Turelli
5 min readFeb 16, 2016

--

As the technology ecosystem in London continues to grow, the ability to compete for the best talent has become as important as having the best algorithm, infrastructure or UX. Many employers in London have borrowed the Silicon Valley approach of offering fun perks to lure employees, such as free food and video games. Others are pitching the opportunity to be part of the next big thing, or implicitly identifying as “a safe place to be” during a downturn. For technology companies, both big and small, engineer retention is proving to be a challenge across the board.

Tackling the retention dilemma

It’s worth acknowledging that some engineer turnover is healthy. New people can help you spot problems that you might have missed and offer a new perspective. But more often than not, engineer turnover signals a bigger problem.

There’s a temptation to get despondent about retention concerns. If Google, with its free gourmet food, health insurance, kindergartens, gyms, 20% time and death benefits also has one of the highest employee turnovers in Silicon Valley, what chance does anyone stand? If your policy is to hire the smartest people, do you not guarantee yourself a high turnover rate? Should a high employee turnover just be accepted as a fact of life for technology companies?

But we can’t help but take retention personally. We believe that our engineers can do the best work of their life at Adbrain, and it’s important our engineers feel their work has an impact on the world. We take an optimistic view of the market, believing that engineers are not motivated by free transportation and free food, but genuine interest in their work.

20% Time off — is it a big lie?

Many have latched onto Google’s 20% time off idea as a potential solution. Google’s 20%-off time allows engineers to spend 20% of their time working on projects that are not related to their personal assignments. Intuitively, it seems like a good idea — even if some of that time ends up being unproductive.

However, there’s good evidence that even Google’s 20% time is a myth, with posters on Hacker News claiming that Google’s policies of measurement are not conducive to employees using their 20% time. There’s a joke within Google that 100% time is actually “120% time”, to indicate that while employees have the time to develop their projects, it’s often on top of their existing schedules. If you formalize the idea that 20% of your time is spent on cool and innovative projects, what does that say about the other 80% of your work?

We wanted to see how our own engineers felt, so we ran a simple survey that determined how much of their time was dedicated to working on something “cool” or “uncool.” Cumulatively, 78% of their time spent involved working on “cool” tech. Those aren’t the kind of results to be taken for granted, it’s a testament to our innovative culture.

Internal Survey: How does the work stack up?

How did we do it?

Rather than formalize a set amount of time that engineers could spend on their personal projects, we’ve structured our engineering team in a way that allows them to use new frameworks, learn and try out new stuff, and build out innovative solutions.

(1) Proactively use new technologies

For instance, we monitor the time it takes us to adopt a new technology after it goes 1.0, because we like to make a habit of using cutting edge technologies. It’s not so much that a new framework or language is inherently better, it’s just that new tech can provide new insights into classic engineering problems.

One example of this was our implementation of Orleans, the Virtual Actors framework from Microsoft. Orleans was open-sourced at the end of January 2015, and we adopted it in April, just three months later. We adopted Orleans because we had to work on a problem with high parallelism and concurrency concerns, so we investigated Actors Frameworks. We picked Orleans over Akka.NET mainly for the higher level of abstraction that a Virtual Actors approach brings, and a simpler conceptual model — allowing us to focus on the business value of the solution rather than on the details of the implementation.

Framework Implementation Timeline

(2) Provide the space to learn

If you’re an engineer today, a large and difficult component of your role is adopting new tools and learning on the job. This part of the job is more difficult if your team is not on the same page. Even the very best engineers have trouble picking up new tools and frameworks.

I firmly believe that when it comes to engineering, you should be able to choose the best tools for the job, rather than letting the tools define who you are and what you do. We try to create a culture where people have space to learn on the job — through good communication within the business, by fostering an underlying care for the success of the business, and documenting as much as we possibly can.

On a practical level, in addition to the usual stuff such as pair-programming, internal knowledge sharing, seminars, every engineer in the company has access to premium training content, for example, Safari Books Online and a Pluralsight subscription.

But we wanted to put it to the test. We asked our team “Which technologies and frameworks have you used for the first time at Adbrain?” Of the engineers surveyed, on average, the team encountered 8.3 different technologies for the first time. One person encountered as many as 15 new technologies on the job! That number symbolizes a lot of personal development, and we’re proud of that.

(3) Focus on problems, not solutions

We give our teams a problem to solve rather than a solution to implement.

We structure our team into three ‘concerns’ — functionalities, engineering, and R&D, and allow everyone the time and space to iterate on the problems they encounter.

The problem could be anything from a client needing help to unlock the value of their data, an engineering challenge to read from a data store at half a million requests a second, or to investigate how we can improve the precision of our algorithms. We don’t know the answers to these questions before we start out — we allow our engineers to find their way there.

Food for thought

At the end of the day, we are all looking for satisfying work, and retention issues are a sign that some needs are not being met. By focusing on mastery, autonomous cross-functional teamwork, and innovation, we’ve managed to create a stimulating dynamic across the engineering team. This approach is working for us, in regards to engineer engagement, and delivery impact. There isn’t a single solution to retention concerns, but clearly there is a lot of work to be done to keep smart people engaged, it turns out that technical innovation and a clear sense of purpose may be the key to a successful workplace in today’s market.

What’s been your experience with employee engagement, and the so-called 20% innovation time?

This post was originally published on the Adbrain engineering blog.

--

--

Edoardo Turelli

Exited Founder/CTO • Built world-record-breaking deeptech • Led multiple scaling | Advisor • Interim & Fractional CTO • Coach