Engineers, BlaBlaCar is more of a tech company than you’d think!
Influenced by 10 years of carpooling, BlaBlaCar sounded more like a community than an attractive tech company to me. But that didn’t stop me from joining the company at the very beginning of the year and understanding that I was wrong.
Here is what I discovered as a Mobile Software Engineer with 4 years of experience joining the Publish Squad.
The “Spotify model”: balance between tech and product
The organization of the tech teams is based on the Spotify model. That means you’re part of both a squad and a chapter.
A squad is a multi-stack team focused on a specific product scope.
The chapters are teams composed of all the people who work on the same platform as you (iOS, Android, Web, …).
As a squad, we focus on delivering features to our users.
As a chapter, we ensure that our respective codebases are homogeneous and that we keep learning and sharing. But there is more to it than that: we provide a secure, performant, efficient and reliable platform for squads to develop high-quality features.
This setup enables efficient product delivery, but it also allows us to develop a long term vision on cross-functionality and on pure tech topics.
We all benefit from more low-level “enabling” teams like Engineering Productivity, QA, Infrastructure, etc., to give us everything we need to ship our carefully crafted code into production smoothly.
We also leverage strong in-house processes that guide us from a feature’s ideation all the way to its delivery.
As Software Engineers, we of course get to share our feedback during the product discovery, but more importantly, we are at the center of the technical discovery.
This means that we get to discuss with all the technical stakeholders to make sure of two things. One, that every team affected is aware ahead of time of the potential impacts in their scope. Two, that the chosen technical options will fit everyone’s needs and best practices, and closely align with our target architectures.
In terms of developer experience, it also means that ready-to-implement features simply fall on your lap at every sprint. Another developer colleague is driving the initiative and has prepared key elements in advance. Said features are well-designed, split into manageable milestones and rely on our design system. They have specified feature flags (for A/B testing or country-based rollout, for instance) and data monitoring. By the time they reach a developer’s hands, a broad test plan is often already on its way.
This lays the foundation for proper work distribution between all technical stakeholders: backend, frontend (mobile and web), data, QA, … Everyone knows what to do, when and how. And since everyone shares a common vocabulary and medium, further adaptation and discussion are made easier.
Value-driven adoption: jumping on the right bandwagons at the right time
Having an up-to-date stack seems easy: trash everything every two years or so and build from the ground up, right? But you can’t do this when you intend to be the world’s leading community-based travel app. Or just sane, you know? So, you have to adopt things gradually.
Within the Android chapter for instance, we have moved from MVP to MVVM presentation layer architecture, from Dagger to Hilt, from Views to Compose, from Rx to Coroutines & Flow, from handwriting our data model objects to having it automated using OpenAPI’s Generator, and adopted the Clean architecture, all at once!
I’m just kidding, of course not all at once. We are doing it gradually and this is where part of the challenge lives. Some of these migrations are almost done and others are just getting started.
To initiate such technical projects, we first conduct a discovery phase during time dedicated to chapter topics. This comes in the form of either weekly office hours or quarterly “chapter projects”. This allows us to PoC things before discussing them altogether and making a collective go/no-go decision.
We need to be efficient in allocating our precious time. So we first assess whether such a project is worth our time: does it unlock robustness? Performance? Ease of use? Delivery speediness gains? If it’s just fun, it’s not likely to make the cut 😞. (But it could become a subject for the Coding Night, our internal hackathon). We then prioritize the most high value projects and proceed with their implementation!
A current in-discovery project is the adoption of Jetpack Navigation’s Compose integration 🎉
How do we keep up with technical innovation? Are we always stuck with a backlog of rapidly aging concepts to implement? Not quite! We also have a strong culture of:
1. Technological watch, with findings shared during our weekly chapter meetings
2. Growth sessions and trainings, either in-house or by third-parties
3. Attending conferences (since I joined BlaBlaCar, there has already been two of them for the Android Chapter: Android Makers and Kotlin Conference)
Monitor and document: getting the right info when and where we need it
At BlaBlaCar, we know that enabling engineers to focus helps them deliver better code in sometimes very short timespans.
One of the ways we achieve this is by avoiding unnecessary re-discoveries of complex subjects. We have a strong culture of building and maintaining thorough centralized documentation.
This spirit is fostered from your first day at BlaBlaCar: you’ll be given access to a lot of docs to help you. You’ll be encouraged to update them, refine them and add to them. This eventually helps us focus on delivery: we have much less effort to spend in discovering pitfalls and lifting the fog of war: it has already been documented.
There’s also our investment in monitoring that helps us stay on the ball. We don’t have to regularly check by ourselves that our feature is performing as expected, we get notified when issues arise. No news? Good news! You can keep on writing code.
Let’s take the concrete example of our Android chapter. We have our incident-handling tool integrated with our SLOs. But it goes much further, we also monitor the migration progress of our architecture, dependency injection, design system, modularization, UI toolkit, etc., up to the Fragments and components level!
Team spirit: our most important asset
Last but not least: if BlaBlaCar is a tech company, that is mostly thanks to its employees.
Everyone here is truly willing to help others, and I’m not only talking about fast and well-done pull-request reviews.
There is also:
- A cross-platform willingness to ease each other’s work: defining REST contracts together, tackling common technical problems for different platforms…
- A real team spirit shared across squads via the chapters
- The aim of T-shaping engineers so that everyone can be of help to anyone (we’ve been training web and mobile engineers to write backend-for-frontend code, for instance)
- And more!
Team spirit is also cultivated through trust and responsibility. This is true for the things we build as engineers (“you build it, you own it” is one of our core mantras), but also true for the way we’re organized within our teams.
Like most tech companies we strive to be agile, but we’re also perfectly fine not being paragons of an official Agile framework rulebook. Our teams own their way of working: each contributor is trusted to have enough maturity and insight on the methodology to challenge it, refine it and adapt it to the company’s goals, without relying too much on “the book”. Our managers help ensure we stay aligned and that our processes fit our needs. This team spirit is strongly encouraged: we work collectively to make each other’s life better.
This is fostered as early as possible, it’s even part of what is looked for during the recruitment process.
Is BlaBlaCar the right fit for you?
Having read up to here, you probably now understand that the way we work is the result of our commitment to continuous improvement. It’s not only a spirit we foster: it also has important effects in our daily life. This is something worth considering when making the decision to join BlaBlaCar.
At BlaBlaCar, we’ve rolled out structured processes. That’s the natural counterpart to the several documentation-first safety measures and the “Spotify model” we adopted.
Moreover, it comes with strict design guidelines, which can be boring to some, but is also a by-product of our strong product culture.
For our classic long distance carpooling product, we currently experience a long-term innovation cycle. This means no day-to-day innovation but rather focus on delivery and squad-related exploration. Product-discovery and tech implementation are two very distinct steps; and given the trust we have in our product team, engineers have a limited role during the first one. We’re no longer a startup where everybody is involved at every step of the way.
But the good thing is, there are several other products that are developed at BlaBlaCar, with a nearer-term innovation cycle. This might better fit your preferences. Diversity is a bliss!
We sometimes take shortcuts to make things fit within allowed time. Our mobile platforms have simplified targets, for instance (such as no first-class support of tablets or wearables). Some might find this to withdraw part of the fun. But we see this as an opportunity to focus on other interesting parts of our job!
And finally, crafting code at this scale implies that our codebase just can’t be 100% coherent. But hey, this comes with the major benefit of having battle-tested code in production. Patterns have emerged, we had time to iterate on our ways of working and writing code. We tend to consider maintaining this code a pleasant challenge.
Final thoughts
Joining BlaBlaCar made me understand what a larger-scale tech company can look like. I tried to give you an overview of how it works internally.
If what you read tickled your curiosity, well, join us! We can’t wait to hear your thoughts about all this and start building together!
Thank you Benoit Rajalu, Cyril Cadoret, Guillaume Clochard, Mélanie Pimentel, Simon Rimbert, Victor Rubin, Vincent Audino and Yohan Bittan for helping me write and structure this article, your contributions were invaluable.
And special thanks to Olivier Bonnet for the article suggestion in the first place!
