How Booking.com 2Xed Team Performance
Find out how to improve team output without the need to hire more engineers.
Here’s a harsh truth for most engineering teams.
Your headcount is continuously increasing.
But the productivity graph is going downhill.
Deployments are taking longer.
There’s more technical debt than ever.
And guess what? Hiring more engineers won’t fix the issue.
In most cases, the root cause is generally bad habits and flawed processes that develop over time.
Maybe there’s no incentive for developers to deploy frequently. Or perhaps the processes are set up such that it slows down the release cycle.
In today’s edition, we’ll explore how Booking.com doubled their team’s productivity in a year without increasing the team size.
This example covers one of their teams in the fintech business unit. The functionality was originally a monolithic application which was later dismantled into smaller microservices.
You can’t improve productivity if you can’t measure it.
The Booking.com team turned to DORA metrics for performance parameters.
They decided to track Deployment Frequency and lead time for changes to monitor productivity improvements. This approach enabled the identification of critical improvement areas within the organization's technical and operational practices.
Central to this transformation were two major interventions: the revamping of backend services to address code manageability and the adoption of microfrontends for the user interface (UI).
These efforts were aimed at not just accelerating deployment frequency but also ensuring a robust, scalable, and agile development environment.
Backend Services Improvement
Deployment Frequency Challenges
The deployment frequency for the backend wasn’t healthy to begin with.
Lower deployment frequency meant developers had to wait a lot to see their work in action. And who likes that?
The core issue stemmed from the codebase being intricate and resistant to changes.
This complexity resulted in prolonged lead times for deploying changes, a scenario that was far from ideal for a fast-paced technology company.
Strategy for Addressing Code Complexity
Refactoring and Test Automation: The strategy to tackle the unwieldy codebase involved a comprehensive approach that emphasized refactoring and enhancing test automation.
The objective was clear: to make the code more understandable and easier to modify. This initiative was guided by the "Boy Scout Rule," which advocates for leaving the code better than one found it.
The application of this rule meant that every code change or bug fix was an opportunity to improve the code's structure and increase unit test coverage.
Continuous Learning through Refactoring Katas: Recognizing the skill gap in effective refactoring, Booking.com encouraged its engineering teams to engage in refactoring katas.
These practice sessions were instrumental in sharpening the team's ability to identify and address code smells, thereby gradually elevating the code quality and maintainability.
Emphasizing Small, Reviewable Changes: A shift towards smaller, more manageable merge requests (MRs) significantly improved the code review process.
By prioritizing code reviews and advocating for incremental changes, the team was able to reduce review times and streamline deployments, contributing to a noticeable improvement in deployment frequency and lead time for changes.
Source: Booking.com Engineering
Adoption of Microfrontends for UI
Decision Rationale
The decision to adopt micro-frontend architecture was driven by the challenges associated with the monolithic architecture of the UI.
The tightly coupled nature of the monolith made deployments cumbersome and risky, discouraging frequent updates and slowing down feature development.
Implementation of Microfrontends
Micro-frontends, akin to microservices but for frontend development, provided a path towards decoupling the UI into smaller, independent units.
This architecture facilitated more frequent deployments and enabled teams to iterate on individual components without the overhead of coordinating with the entire application.
However, even after they adopted the micro-frontend architecture, the lead time to change was still close to a day.
Upon further research, they found that merge request review process was more complicated in this case. It needed approval from an micro-frontend expert community outside the team.
They contacted the community and figured out how to reduce the time for approvals. As a result they reduced the merge request approval time from 17 hours to 8 minutes.
The transition to micro-frontends involved a detailed migration project that not only improved deployment frequency but also reduced the lead time for changes by allowing more agile and focused development efforts.
Booking.com's strategic focus on improving backend service manageability and adopting micro-frontends for the UI underscores the importance of targeted interventions in overcoming technical debt and enhancing software delivery performance.
By aligning with outcome-oriented metrics and addressing the most constraining factors head-on, Booking.com was able to unlock a new way of working that emphasizes internal quality.
It also fosters an environment conducive to experimentation and rapid iteration. This journey highlights the critical insight that organizational improvements often stem from addressing systemic issues rather than merely scaling resources.
You can read more about the details in their engineering blog here.