After all the buzz around Jeremiah Lee’s article “Failed #SquadGoals”, setting Spotify’s organisational miracle recipe as the worst example for tech companies to follow, it felt right that we should share our own experience at leboncoin. In under 2 years, we implemented the model all the while growing from 100 to over 250 engineers, 35 squads and 4 tribes. There was no miracle there either, just a bit of inspiration. Admittedly, we are not Spotify : we are much smaller and all the engineering is co-located in Paris, which also helped a lot with the implementation.

Choosing a matrix organisation

Back in 2017, we decided to leave our previous organization by platform technology (Back/Front) to operate a transformation into a feature-team structure (information here).

We looked into several organisational models, including Spotify. It quickly became clear that we had to choose between two management models: one matrix-based and one squad-based. At the time, neither seemed better or worse than the other, though we agreed that these two models did not solve the same problems. The matrix model designates a manager gathering under him collaborators with the same set of skills and thus making it possible to maintain technical coherence in the technological stacks. The latter allows the teams to focus on their deliverability.

During this time, leboncoin was in the midst of a technological transformation, moving from a monolith in C language to a micro service architecture in Go. At the same time, the front-end technology stack was evolving from PHP to React. Therefore, we had a strong need for technical consistency, and so we opted for the matrix model. And we did so with full knowledge of the facts.

A learning organisation and leboncoin’s own “TOO” model

leboncoin is a fast-growing company, with its workforce increasing as fast as its revenue, which is generally considered as a good thing. Nevertheless, we must anticipate some of the consequences:

• The organisation will soon have to be called into question because we won’t be able to bring in new employees without creating new teams.
• The model must be sustainable over time, but not the organization itself.
• The initial transformation was made from the bottom up, and we would like to keep this momentum for change. The organization identifies problems on its own and solves them with the support of management.

We strive to work in such a way that the teams themselves learn how to solve organizational problems in a transparent manner. To achieve this, we have experimented with several models over the months. We call our current model “Travail d’Organisation Ouvert” or TOO for short (in English : “Open Organisational Work”). It is based on the premise that anyone can report an organizational problem and anyone can help to solve it. So we have an open backlog and processes to integrate volunteers and solve problems with the benevolent support of the management.

This could call for a whole article just on this subject, so stay tuned.

Matrix organization + TOO = …?

Let’s get back to the matter at hand : a matrix organization. But above all, an agile and learning organization.

A year in, a large part of our technical issues were resolved. The strategy is now in place and technical refactoring is well underway, all the while making significant upgrades to our product.

One might have thought this would be enough, but it wasn’t. We kept wanting to go faster and faster. Focus on delivery, right? We also wanted to fix other structural problems. For instance, the fact that managers struggled to manage 20 engineers in 15 teams with very different scopes. Also, because we wanted a real team cohesion in the squads and not just a set of specialists who are physically close but not jointly accountable for what goes into production. The example mentioned by Jeremiah Lee about a meeting with 3 chapter-managers, 1 PO, 1 product director and 1 engineering director… Yes, we had the same type of meetings and we didn’t want that anymore. All right, then let’s adapt our organization…

As it sometimes happens, top management adds a ticket to the TOO backlog and lets the magic happen. Collectively, we decided to switch from managing teams by technology to squads.

Mind you, changes never just happen overnight, we took the time to explain these decisions and convince skeptics, but in January 2019, we switched all of our management and left the matrix behind. This was carried out mindfully and with strong guidelines for managers and POs. We build together and each decision is made at the lowest level of the organization by the Product / Engineer duo, most legitimate to address the matter at hand.

Interesting feedback on this point : it is essential that the PO/EM duo must get along and work well together, otherwise the team will quickly run into internal and external problems.

And so, how does it work for chapters?

So we implement the model, therefore we have a notion of chapters like in the Spotify matrix.

If you have been following closely, initially it is our functional team managers who manage the chapters. At the time of the switch, we had to adjust this as we needed one (or more) pilot in the plane. Otherwise, technical consistency would be lost.

Once again, it’s our TOO system that got the job done. A certain number of Tech leads were already present in the organization, but we decided at that time that we needed to distribute them on each chapter and above all we redefined their role.

They do not manage the engineers of a chapter, but are in charge of driving the evolution of the technology stack of the chapter in question. To date, we have about one lead per technology for every 10 engineers. This seems to be the right ratio for us, knowing that leads have a double role, each is both lead and developer in a squad at 50%. The load for them can sometimes be a bit heavy, so this is something we will monitor and act on in the coming months.

And is this enough?

The answer is no. The Spotify model described a squad like a micro enterprise, autonomous and accountable. To reach a desired level of autonomy, it is also necessary to bring into the equation all the principles associated with the DevOps movement. The team must also be accountable for its infrastructure, roll-outs and incident resolution. “You build it, you run it”. We are strongly committed to this notion, which led us 4 years ago to create a tooling team for developers (Mainly CI/CD, but not only). It also encouraged us to review our standards for hosting our platforms : it should be as simple as possible for a developer to deploy a new service. And so, Docker/Kubernetes/Terraform/Zuul/Concourse were part of the answer. But above all, we dedicated teams to maintaining our services architecture so that engineers in the squads might have only one focus: providing value to our users.

The CTO’s bonus tip

Focusing on delivery also means facing more difficulties in dealing with cross-FT technical matters. A good example would be the redesign of the component managing network calls in our Android application. No squad alone can take this on, it doesn’t fall into any one team’s scope. Nonetheless, it has to be done, and if we do it, it directly impacts all the squads in all the tribes. For that purpose, we created a Core team at leboncoin dedicated to dealing with this type of subject. The team is made up of technology experts whose roles are to address complex cross-chapter technical problems and which are not in line with the product’s needs.

Cross-team collaboration

Anyone who says that cross-team collaboration is never a problem is a pathological liar. The more human interaction there is, the more room there is for misinterpretation and misunderstanding, and the more difficult it is in the end to find common ground. In an organization like ours, where each team is told that it is autonomous and responsible, I will let you imagine the complexity of a project involving 3 or more squads.

We devised two solutions, although imperfect, that do work in this environment. First, we established a quarterly roadmap process in which management sets and communicates priorities, and then the teams, once given access to these priorities and to the list of all requests for third-party functionalities, can define their own roadmap.

During this process, several meetings take place between the teams to discuss their respective dependencies and try to align them in the quarter. Once this is done, the content of the roadmap is communicated to all teams and top management. Everyone is then aligned with the expectations of the quarter. This process works most of the time. However, larger projects sometimes require an additional layer of coordination. This is why we appointed 2 PMOs to help us on these structuring subjects.

Are we done?

We are far from being done. As I was saying before, our organization is constantly evolving, and what we describe today will probably be wrong tomorrow (sounds familiar?). Here are a few interesting topics that are of concern to us at the moment:

• Should squads all be perceived as feature teams or should we also consider other types of teams, such as component teams or enabling teams (see Team Topologies)?
• Is our organization aligned with our business strategy and architecture to maximize our efficiency? We’ll surely have the opportunity to talk about it some other time.

leboncoin, like any tech company, is a complex system (see the Cynefin framework by Dave Snowden). We have to observe our situation at a given point, pinpoint and prioritize priority issues, move forward to tackle some of these problems, and finally analyze the outcomes. And we start all over again.

Once more, it’s not about “best practices”, it’s much more about finding solutions little by little and continuously along our journey as a company.

“Today’s problems come from yesterday’s solutions.”

(The Fifth Discipline, Peter Senge)

Key Learnings

• No one organization is perfect, no one model is perfect. It is necessary to adapt to the context, internal and external, the market, the competition, etc… And not hesitate to regularly revisit the model.
• The Spotify model can work.
• It works at leboncoin because it is associated with our TOO model, DevOps principles and our services architecture.
• However, inter-team coordination remains a challenge.
• The collaboration between Product and Tech must be very solid and balanced. Both have the same level of accountability, are co-responsible and work hand in hand, from the PO / EM duo to the CPO / CTO.