Enabling engineers at scale
A journey through how we empower engineers at Skyscanner from day one
By Alex Simon
The North Star
At Skyscanner we believe that “speed of iteration beats quality of iteration” and we embrace this concept in everything we do across Engineering. We are moving into a world in which an idea from an employee in the morning can be in the hands of a user in the afternoon. With our current size, both employee and traffic wise, we are talking about shipping thousands of changes into production in a single day.
This approach brings an incredibly fast pace of innovation, lowering the barrier for experimenting in everything we do (not just traditional front-end features, but now also backend configuration changes for example). However, this has some implications: a big investment is needed in productivity/enablement engineering, as well as a conscious effort to facilitate internal open source. Furthermore, the company culture plays a key role in the success of the model. In our case, it is clear that the “you build it, you run it” way of operating plays in our favour.
But let’s be clear, this is the north star in Skyscanner Engineering, the place we want to be as a tech company (notice the “tech” as opposed to “travel”). Although I can’t say today that we have reached our destination, we certainly have already boarded the plane, taken off and we are safely en route to it. As an engineering manager in the Developer Enablement tribe (we follow the tribes & squads structure), I would like to take you through how we empower engineers at Skyscanner from day one.
The goal of the Developer Enablement tribe is to help Skyscanner engineers deliver business value at scale. This is, in essence, 10 different teams focused on every stage of the software delivery journey, purely looking at it from a productivity engineering perspective. This covers from creating a new microservice to deploying and operating it at scale in the cloud natively, in a fault tolerant and secure manner.
When reading the last paragraph, the word “DevOps” might have popped up in your head straightaway. And you are right, but that is only a small part of enabling engineers and designers. Our scope is much wider than this. We have created a bridge between the designers and front-end development which we call Backpack. With the same ease, our deployment tool Slingshot lets engineers deploy services and lambda functions seamlessly to AWS. We can push automated changes to hundreds of repositories at once to keep them up to date using an internal tool called CodeLift.
All these different tools have one thing in common: their goal is to reduce the time an engineer needs to spend in repetitive, boiler plate tasks. The productivity of an engineer comes from investing time on the features that have a positive impact on the traveller (what is often referred as “business logic”). Although this might sound logical, the effort required to make a service production-ready (logs, metrics, tests, making it resilient, etc.) surpasses by far the time spent on the business logic, the actual functionality of the service. Productivity engineering is all about inverting this time ratio, so engineers spend their time doing what they do best: delivering awesome features to our 60 million unique travellers.
Perspective from a new engineer
A step-by-step tutorial takes an engineer on the process of creating a new microservice, building and deploying it using all our tools and flows. The created service has implementation for experimentation, logging, metrics (including dashboards and alert infrastructure), credential management, fault tolerance patterns, testing… all out-of-the-box. And the best thing is that a new employee can go from zero code to a service in sandbox within 5 minutes in his/her first day.
Of course, the service won’t do anything, it’s just an empty shell. What is missing is the business logic. Time for that new engineer to become productive and deliver value to our traveller (after one day on the job)! Over 1.6K new services have been created during the last year alone, and although a large percentage of them are for prototyping, testing and training purposes, the time saved by not re-inventing the wheel every time is unquestionable. In the last 2 months, we have opened over 600 Pull Requests automatically to production services in order to keep them up to date.
We had to make some trade-offs though. For instance, standardising in the languages/framework each squad can choose from (we currently have support for Java Dropwizard, Python aiohttp and Node.js, as well as AWS Lambda). Rather than a limitation, we see this as a way of focusing our efforts without spreading ourselves too thin. It’s unrealistic for the tools mentioned in this article to support more than 3 different language and frameworks combinations (including sync/async variations) and keep the same level of quality and maturity needed by our engineers. In addition, we can’t ignore legacy code, since this is usually a big productivity “leak”.
Productivity engineering practices will allow us to push hundreds of experiments per day to production, to both app and website. This increases the speed of iteration and innovation, generating a huge positive impact to the user experience of our travellers. However, for this to happen, a serious investment in enablement teams, tools and practices is necessary, as well as having the correct engineering culture and organisation. This is the 39,000 feet view from our plane as we steadily approach our goal.
SEE the world with us
Many of our employees have had the opportunity to take advantage of our Skyscanner Employee Experience (SEE) — a self-funded, self-organized programme to work up to 30 days during a 24 month period, in some of our 10 global offices. There is also the opportunity to work for 15 days per year from their home country, if an employee is based in an office outside of the country they call home.
Like the sound of this? Look at our current Skyscanner Product Engineering job roles.
About the author
My name is Alex Simon, a Senior Engineering Manager in the Developer Enablement Tribe. Originally from Spain, I joined the London office over a year ago. Skyscanner represents a huge engineering challenge, not only because of the growth and scale we operate at, but personally for me coming from the videogame industry! My goal in the Tribe is to understand what engineering teams struggle with and provide solutions to make them more productive.