Simon Maurin - Équipes, métiers et plateformes @Leboncoin

[00:00:03] thank you for being here for this last round of conferences. today, I'm here to talk to you about business teams and platforms, and platform teams and business platforms at Le Boncoin.
[00:00:18] My name is Simon, I worked at Le Boncoin from 2012 until last January. And I held the role of lead architect, and with this hat, I'm going to try to tell you this story. So I suggest we start by defining this term. I don't think anyone will fall off their chair after this, we're at Flocade.
[00:00:38] but for that, we need to travel back in time and go back to 2017. And at that time, Le Boncoin undertook a major reorganization of its department. drawing inspiration from Spotify's work on the matter. And so at that point, we opted for teams that we wanted to be as autonomous as possible. we were really convinced by the approach because, at that time, we had a technological department organization. there are a lot of dependencies between the teams and we could clearly see that it had an exponentially negative impact on our ability to deliver due to the number of these dependencies. So we said we want autonomous teams, for that we're going to make them small, pizza team and all that, and multidisciplinary. So we're going to make sure they have all the technical capabilities, like front-end, mobile, back-end, ops, to be able to build their software and deploy it autonomously. These teams will therefore be distributed across business domains, which are coherent functional sets whose ultimate goal is to create value for the user. We're going to set a rule: for each business domain, we'll have only one team that is responsible and clearly identified, the idea being to avoid having orphaned corners of the codebase for which no one takes responsibility. So what we want to achieve, at that point, is a distribution of the different business areas of the codebase that allows it to be fully covered and for the different teams to work as much as possible in parallel. So at that point, we arrive at this organization, this breakdown. So we have product teams that will roughly divide up the major user journeys we have at that time. That is to say, we have a first team, the classified ad team, which will manage ad submission, the management of small ads, which is our main business. Then, we have a Search & Discovery team which will be responsible for connecting buyers and sellers, for matching supply and demand if you will. Uh, and then, we have oh, it worked.
[00:03:09] 100 minutes.
[00:03:13] We're off again. So I was saying search, which will take care of matching supply and demand. The contact part, which will handle the connection between the buyer and the seller, and the transaction part, which will allow for negotiation, payment, shipping, and so on. Uh, what's cool is that these different domains, uh, they overlap little, they have few dependencies on each other. They generally have a dependency on the previous model, on the previous domain, apart from the transaction which has two, and so roughly speaking, we saw the gains we hoped for quite quickly. by switching to this organization, meaning the teams process very quickly in parallel. definition on these different domains. And it's cool. And it even works well.
[00:04:07] uh, because it allows us to scale in a satisfactory way. So when we make this move, it's 2017, this in green is the workforce with the scale on the right, we see there are about a hundred when we make this move.
[00:04:24] in blue, it's the total workforce of Le Boncoin with the scale on the left. And so in 2018, we pass the 130 mark, and in 2019, we double. uh, and in 2020 we gain a small 15-20% and, uh, basically, this model works quite well. What we do is, when new teams arrive, we create new business domains. we invest a lot in many things on the B2B side and so on, or we cut existing business domains into smaller pieces that we give to different teams. And so, it works well.
[00:05:03] Until the day it stops working. Uh, that day arrives in 2020.
[00:05:09] Uh, at that moment,
[00:05:13] So Le Boncoin is a classified ads website, and its DNA, even in 2020, is truly that of a generalist site. That means we offer classified ads in many different categories, ranging from real estate to jobs, including holidays and consumer goods. But broadly speaking, we differentiate these different markets very little; the user experience is generally the same everywhere.
[00:05:45] However, we have many competitors who are specialized in one of these markets. or one of these verticals, I might use both words somewhat interchangeably in this presentation. Uh, and so we realize, especially because we are quite strongly attacked by some, uh, that we need to pivot from this position uh of specialist, or rather generalist, to a position of multi-specialist. So this is Antoine, our CEO, who is asking us at that moment to make sure that we can advance on the markets in parallel with a specialized experience for each of them.
[00:06:23] These are the product mock-ups at the time. So the idea is to still have something that is relatively homogeneous in terms of look and feel, but on which we can truly, uh, by market, uh, adapt the experience, for example, by having listings with very large images when we are on the holiday section, search on a map when it makes sense. Uh, the construction of the classified ad page also has to be specific to the vertical. Again, here, we see on one side the mock-up of the holiday classified ad and on the other, the job ad. We see that the image size is much larger on the holiday lock, the localization comes first, the parameters are not managed the same way, we have things that are specific to the market. for example, here on the job side, we have a video that offers to introduce you to the company where you will obviously be applying. so the idea is really to have blocks that are relatively harmonious but that we can arrange differently by vertical, and also blocks that are specific to a market.
[00:07:37] such as, for example, the availability calendar for the holiday section and so on. Same thing for transactions, because we don't buy a pair of socks in the same way we buy a car. or that we rent a villa in the south to spend our holidays with Antoine. we must be able to diversify the funnels on the transaction part. So roughly speaking, the idea is to have a harmonious common framework, but with diversification by market.
[00:08:11] So what we do, well it's simple, we do what we've always done. We say, OK, now the priority is to have, to have, how to say, to focus on market specialization, we are growing a lot, what are we going to do? We are going to create teams to whom we will give this responsibility.
[00:08:29] So we create a product team for jobs, one for real estate, one for employment, one for motors, and also one for consumer goods management which I didn't include because it was overflowing. but you get the idea. We say, well, we continue to increment the model, the new focus is the markets, let's go. And that, that blows up in our face. So, that's a bit, that's a bit direct because there are about 15 seconds between the two slides. In reality, it took more than a year to blow up in our faces, meaning after a year, we realized that the vertical teams were delivering truly in pain and at a really, really degraded pace compared to others. We think something is wrong. We look a little closer and realize that our beautiful property of limited dependency, on the vertical side, we actually kind of blew it up. Why? Well, because each vertical has to potentially modify the ad deposit, the search experience, the contact initiation, and the transaction. And so these teams will spend their time chasing after the others. What's more, it's funny because we're a very agile company, we make 3-month roadmaps for the team, so everyone has their own plan. And so you have to negotiate with everyone. local optimization, global optimization, all that stuff. Uh, and so there are a few small symptoms, especially from the vertical's point of view, that are interesting to observe. Strangely, there's a lot of work in progress, so many tasks that take 3 months to go through the different dependencies, even on simple things. Like, we had an example where we wanted to put the salary on the job ad, so for submission and to make it searchable. And that took 3 months. Not 3 months of active work, 3 months to have.
[00:10:30] the employment team that asks the search part, or rather, the ad part first, to add that to the data model, they wait, it eventually gets done, they retrieve that, they file a new ticket with the search team so that it's indexed in the search engine, they wait, it eventually gets picked up, and at that point, they can make their own modifications. And it chips. But so suddenly, if on very simple things, it takes 3 months, you can imagine that on complicated things, it's complicated. So, uh, on slightly more ambitious features, there's a phenomenon uh that develops across all verticals: there's an intense negotiation system uh that gets created during roadmap planning.
[00:11:15] between the vertical teams and the teams, let's say "journey" teams, those who manage the four initial blocks there.
[00:11:24] Uh, and uh, this symptom is actually quite vicious. Uh, because of that, it burns a lot of energy uh from the teams. Uh, they try to secure as much as possible, so they will align the teams' planning, but as soon as a part of one team's roadmap moves, which happens all the time, well, everything shifts. Uh, and so to try to limit the 'risk' in quotation marks, we do ultra upfront grooming and design at that moment, knowing that developments sometimes happen 3, 6, 9 months later, and of course, nothing falls into the right boxes. Uh, so, uh, all of this has a really deleterious effect both on delivery and also uh on team relationships and on the roadmap exercise where no one wants to go anymore. well, that's the roadmap exercise.
[00:12:16] Uh, and uh, if we put ourselves in the shoes of a developer who is in a market team. We realize that the cognitive load is enormous because he must, like all other developers, know his own system, but since the code cohesion is dreadful, meaning that there is logic from his market within other teams. he must also know uh, well, the structure of the codebase of the other teams, and in fact, it's really not easy, especially when you join a company, because these are teams we just created.
[00:12:51] Uh, and so, there's also a kind of scope ambiguity because who is responsible for the logic when one team owns the market and another owns the journey, who decides when the two are in disagreement.
[00:13:08] Uh, and finally, all of this means that we really see the codebase degrading. Insofar as when there's logic everywhere, you're asked to understand everything, and simple things are complicated, well, you tend to bypass whenever you can. or duplicate. And it's normal and it's quite worrying.
[00:13:29] Uh, and so, we understand that fundamentally it comes from the fact that our little mantra, uh, of having one domain, one team. to uh avoid over-synchronization, well, in fact we a little bit uh we went back on it without really realizing it and so, we pay for it. But ultimately, the final diagnosis is that we have a systemic problem. Uh, there's a mismatch between our strategy, our strategy which is based on verticalization, so creating more and more features specific to a market, the way we are organized, and the way the codebase is structured. And so I'm telling you this calmly 4 years later. at the moment, well, our emotional state was more like this.
[00:14:23] Uh, and that's when we come across well-intentioned people. who tell us not to panic, read Team Topologies, maybe it can help you.
[00:14:34] It just came out at that time. Uh, so I'm going to do a very short presentation of this book, I think about 90% of those I've seen here. uh, who has read Team Topologies or is familiar with the concepts behind it. Okay, that's about two-thirds of the audience. Uh, so,
[00:14:54] in Team Topologies, we are invited to reflect on these questions of flow in organizations that produce software. And there are roughly two sets of axioms that structure this reflection. The first one is the interaction modes between teams. I'll go over it quickly. But broadly speaking, we distinguish three modes: collaboration, which is when teams collaborate directly with each other, they exchange, often they have a common goal. Uh, collaboration, or rather, interaction in 'as a service' mode, so the idea here is a bit the opposite, meaning we will synchronize directly as little as possible, actually, we will avoid synchronizing directly with another team, we will consume services or tools that it offers available off-the-shelf in self-service. And so the idea there is really to be the opposite, to limit direct interactions between people in one and the other. And we have the third mode, which is facilitation, where we have a team, usually of experts, who will send resources to uh one of our product teams, generally to help it overcome a specific difficulty.
[00:16:11] So next to this series of actions, we have another one which is the four types of teams.
[00:16:18] So we have, uh, what in the book they call stream-aligned teams, which are our product teams. The idea is that these are teams uh that follow a workflow that allows them to create value for the end user and that are organized around domains and are designed to be as independent as possible. That's our product teams, in reality, we almost only have that. in the organization. And then the other three teams have only one goal: to help the stream-aligned teams be as efficient as possible, and therefore, in one way or another, to alleviate their workload. Uh, so we have the enabling teams that are there for, who are teams of coaches, experts, etc., ops, architects, you name it, who have specific business or technical knowledge that can help teams produce somewhat complex things. We have the complicated subsystem team, well, they manage things no one wants to manage because they are very complicated and not very 'abstractable' (it's not a word), but in any case, they require a very specific and very deep technical knowledge, or very deep business knowledge, or both at the same time. And uh, consequently, we're not very keen on approaching those things. And finally, uh there's a fourth type of team, which is the platform team. And the platform team, its goal is to facilitate the lives of uh stream-aligned teams by providing them with a platform.
[00:17:57] So, what is a platform? What's very funny is that there are many different definitions. I particularly like mine. A platform is software that helps make software. Start end. Uh, so I don't know why in Teamologies, they preferred to base themselves on Vaher's definition, who in my opinion was paid by the word, who talks to us about "Foundation of Service, services, knowledge and support which" I'm sorry for the accent "as a product delivery team." teams, so our little teams, our teams can make use of the platform to deliver product features at a higher pace with reduced coordination. Uh, at least about this definition, it's very comprehensive. We see that a platform is actually composite, it's a bunch of things whose ultimate goal is to lighten the load, including the cognitive load, for product teams. A first pattern we can think of for a platform is, therefore, CI/CD. It's really the standard thing, it helps friends ship faster, they press the button where they used to have to do horrible things with SCP and so on before, so they can focus, move on to other things and also be more agile. So that's really, uh, the platform that's somewhat, uh, business-agnostic and that we see everywhere or would like to see everywhere.
[00:19:37] Uh, of course, there are other platforms we can think of, like cloud providers. at the first layer, meaning the resources part, network, etc., it's really typically that, they also offer some top-level services that we could put in the same category. Uh, the question we ask ourselves at that point is, 'Okay, fine, but could we have a business-specific platform?' Uh, so we say that simply because we think we've done that, it's not great. But is there a world where we could ask the teams managing the core journeys to pivot and suddenly create software that helps others create software? So tell them, you're no longer facing the clients there, you're facing other developers, and your goal is to simplify their lives by providing them with tooling that allows them to easily build deposit journeys, search and discovery, conversation, and transactions. Uh, the question we're asking ourselves at that moment is, okay, fine, but could we have a platform that is business-specific? Uh, well, we say that because we simply say we've done this, it's not crazy. But uh, is there a world where we could ask the teams managing the central journeys to pivot and suddenly create software that helps our friends create software? So tell them, you're no longer facing the clients, you're facing the other developers, and your goal is to simplify their lives. by providing them with tooling that allows them to easily build uh the deposit journeys, the search and discovery, uh the conversation, and the transactions. So, uh, a good friend of mine, this gentleman named Grégoire Hop, who writes things that are quite relevant very often. Uh, he says yes, that he even calls them business capability platforms. And in nature, actually, we find plenty of them. Uh, so here are a few small examples that I chose more or less at random. Uh, we have OneLogin or Conito here, which can help you manage account management. We have Algolia, which can help you manage search, Stripe and Paddle for payment, Miracle or Shopify, uh, marketplaces. Uh, so I say okay, well, it doesn't seem, it seems doable. uh, and there seem to be things on the shelf, do we build or do we buy something to put in place of what we built in 15 years. Uh, knowing that, well, what we built is classifieds, search, discussion, and transactions, things that do payment and things that do search. There you go. Uh, there are two small problems with that at that moment. One, it's the abstraction fit, meaning these platforms are designed with a, well, a strong bias. uh, which makes their interface very specific. And our system, it evolved organically for 15 years, which means that if we want to integrate, uh, for example, an external payment system, in reality, it's uh, a job of migration and uh, integration that is very, very, very long and very, very hard. So most of that, that removes quite a few options for us. The second element that goes in the direction of the build. Uh, it's that as much on the part uh, well, it's a core domain chart. The idea is to try to reason uh on the inherent value to your business domains in what you build. Uh, and the idea is to differentiate on two axes, how complex the business logic is, how much it allows client differentiation. And so, we put in there the different business domains we need. So typically, for example, account management and so on, it's quite generic. Uh, there are things that can be a bit more advanced, like billing or payment, which are a bit like support items. And then there are the things that are really what differentiates you. And we, for example, consider that our search, for example, is a differentiator and it's a bit the heart of the machine, well, one of the hearts of the machine. So, in this case, uh, if we want to have the ability to do custom work and follow our strategy, well, we can't be dependent on a third party. Uh, and so we're going to do it. Okay. So, we're saying, that's good, we have a plan. So we're going to transform our teams, a part of our product teams into platform teams, they're going to help the verticals by providing them with business platforms. The question is, where do we start? Do we ask them to build the platform, and once their platform is built, then we put it? Or do we tell them, "Alright, you're platform teams without a platform, have fun." Uh, so this gentleman is Melvin Conway, so this is the Conway point of this presentation. Uh, this is also an axiom that is somewhat central to all of Team Topologies' thinking. Uh, it's Conway's Law, which is this gentleman who works or worked at MIT. And who proved in the 70s, I believe, uh, that organizations that build complex systems, like us, uh, are constrained to reproduce in their design the communication interfaces uh, between the between the teams of that organization. Uh, and that's quite funny because actually we can turn that around. That means, basically, if you don't change how teams behave with each other, you'll have trouble making them change the system's design, hence the architecture. And so, there's a way to take this thing as an actionable thing in the other direction, meaning, okay, well, we can do the opposite, we can make sure to modify the interaction mode of the teams with each other. by explaining to them where we want to go, of course, uh, so that they are more inclined to build the architecture that fits. And so we do that, so what it consists of then is to say yes, yes, okay, me. We change the product teams into platform teams overnight, uh, we give them dedicated resources, uh, we tell them, well, start from scratch and iterate and normally, it should go well. Uh, how did it go? So here, I'm going to give you a, I'm going to explain to you, let's say, a succession of steps through which most of these teams go. Uh, so these teams that need to transform their products into a platform.
[00:25:55] Uh, the first step is migration, quite simply. So here, the objective is really to design the platform and refactor the existing one. because we have a 15-year-old codebase, there's a lot of stuff, so where do we start? Uh, the way it happens in terms of collaboration is that the platform team leads.
[00:26:18] And it's going to look for uh business logic snippets in the codebase and migrate them in-house uh to turn them into platform features. And it manages a little bit of everything.
[00:26:31] Uh, and generally here, uh, there are one or more product market teams that are pilots. uh, to help the, to help the platform team to work and think. The interaction mode then is really collaboration. Here, we try to have people on the platform team side and on the product team side who are as close as possible. And so we're going to use pairing, mobbing, and at times we're even going to cross-train the teams. That is, we're going to uh mix resources, people, uh who come from platform teams and market teams for a long time, uh and ask them to bring out the first platform functionalities.
[00:27:23] Uh.
[00:27:27] So, the key point at this stage is that these people choose within the platforms what needs to be harmonized and what needs to be uh left free. And that's, that's a, that's a slightly complicated exercise, but Grégoire tells us that if we do it well, there's a good chance it will go well. Uh, what does it look like? So, what we do is we reverse engineer the journeys we've coded. And so it's reverse engineering, it's not just tech, it's really even business, functional, and so on. So we do giant event storming, uh, and then we map that and we think about the needs of the different market teams, that is, what level of latitude they need on which piece of business in front. Uh, we end up with a, a, a, this. This is a bit our compass, we found it afterwards, of course. We did this in a completely emergent way, and then 3 years later we can say, oh yes, actually if we had thought of something uh to rationalize the whole thing, it could have been this. Uh, broadly speaking, we realize that uh, throughout the journeys we need to platformize, there are many places where the market teams need to do things. But these things can be classified a bit on two axes. Uh, either they are global, meaning they all need to do the same thing, like for example, the data schema, they all need to manage their data schema. There you go, go figure why. Uh, or specific needs. In this case, uh, for example, uh, they might want, uh, we'll talk about it later, but to integrate transaction information uh into the search engine or into the lifecycle of their consumer goods objects. Uh, so there you go, that's the first axis. And there's a second axis, which is the fact that, well, the needs, let's say the changes, are either recurring or exceptional. So exceptional means an end, here, it's completely one-shot, here, it's two, three, four times a year. And at the top, we are potentially every week or every day. And so, depending on these two axes, we realize that we shouldn't build the same things. Uh, and so, Mr. Butcher's definition is not silly. because within the same platform, we'll end up with code that is forked, often on the front end. Uh, shared libraries when there's complex business logic that needs to change all the time and in a very specific way for the vertical. And a part uh of uh and a part of service. Sometimes just configurable services, just something where you put a config and you can change the color, you can add a hook and that will be enough for the market's needs. Uh, and sometimes, uh, we have to really make SaaS, we make internal web apps that help the dev to drive uh the business. Uh, because broadly speaking, we have recurring needs, but we don't have a simple abstraction in 'yes/no' mode by such and such or come back here, but we really have a slightly more complicated abstraction uh above the business. An example, because what I'm saying might seem a bit esoteric. This is the search before. So we have a kind of monolith, well, it's a microservice, but it's a micro, yeah, a monolithic microservice. Uh, which manages the data schema, content aggregation, ad lifecycle, indexing, search, scheduling strategy, cache, ad lighting, alerting. And we have nice people who manually manage the infra and the failover strategy. That's actually managed by the same team, so well, that's their baby, and that's what they do manually because they don't do it often.
[00:31:38] And at the end, actually, of our migration plan, we cut it like this. Uh, so the blue bits are snippets of code that are executed directly by the market teams. The orange bits are things for which they interact with services, either really internal SaaS, or services on which they can modify the config. And the gray remains global. because there are a lot of things that have no interest in being specialized by vertical. Uh, and so these cutting lines, uh, we really think a lot about them and we use this, well, this little pattern uh to adapt them. And so we can say that this is our, well, this is our choice of abstraction, or rather our choices of abstraction because ultimately we offer many, it makes something that is, in this case, more monolithic but modular.
[00:32:40] So once we've done that, uh, with our, generally with our small pilot vertical, uh, we go find the others and say "Hey guys, we have a platform that works, uh, come on, we'll deploy it for you." And so, at that point, uh, the main objective is the upskilling of the market teams, the product teams. So, in this case, uh, at that point, it's the market team that really takes the lead and chooses in its roadmap when it will do the integration on the platform. Uh, at that point, we change, we've changed our collaboration mode. We've moved to facilitation, meaning the platform team makes itself available to the product teams that will migrate. Generally, it happens uh like this. Either there are people from the product team who come to the platform team and who, uh, for one, two, three sprints, uh, come and code the migration with them, and they are trained, of course. Uh, either it's the same thing but in reverse, either there's an ambassador from the platform team who goes to the product team uh to help them. But in both cases, the goal is not just to do the dev, it's to upskill uh our colleagues. And it's also a good time to validate our abstraction. Because we coded it usually on a use case, the first market we addressed, and so that allows us a first validation, a first test uh of the abstract.
[00:34:21] Uh, still on search, so this period, this phase, to go from employment to employment plus real estate plus uh vacation rental plus car plus consumer goods, that took about 12 months. Uh. 12 months during which we primarily invested in the system of, well, basically the onboarding methodology for developers. And uh, we were able to try and validate our cut, which we saw earlier, the cut held up quite well, even very well in this phase. However, there were scaling steps for the platform, actually. because we started with employment, a design is a small market on Le Bon Coin, it's 70,000, 80,000 ads. Uh Real Estate, well, the real estate part, it's already 2-3 million, uh, and uh, consumer goods, it's 60. So, uh, necessarily, there were there were adaptations to scale uh at the client level, but since we integrated them little by little, it was able to happen gradually and the abstraction held. There are other places, actually, at that point, we see that the abstraction doesn't fit and we actually go back a bit to the previous phase, we redo a bit and then. Uh, the next phase, so here we can really start to focus on value creation, until then it was a bit about migration and adoption. Uh, and the next phase, well, the market teams can really start to build new features on top of the platform. So either completely autonomously because we left them code to execute and as long as it basically ensures that the interaction contracts are all by themselves. Or sometimes, by making some changes in the platform to adapt it. Uh, in that case, we are still on a facilitation mode at our scale, uh, here, normally the knowledge transfer has actually occurred. Uh, what happens is that we will often work in pairs. Basically. So we're going to have the people who came to do the integration uh and other colleagues if if they were able to share a little bit of knowledge, uh who are going to make changes in the platform's codebase.
[00:36:46] Uh, and so either they're very comfortable, yeah, we let them do it, uh, that's notably the case for the people we initially teamed up with to build the platforms; typically they participated in building them, so they are perfectly capable of committing directly to them. And that's cool because it goes very fast. Uh, either they are a little less comfortable uh and in that case uh, well, there's a review system uh and we exchange on their on their motives. So, here we're talking about code modifications, it can sound a bit pompous and scary, sometimes it's just config modifications precisely to uh change the operating mode of certain services.
[00:37:26] This is the moment, however, when we will once again validate that the abstraction holds. Because here, uh, people are starting to build things that could not have been anticipated. It's really the new products arriving. Uh, in the search example, for instance, uh, examples of things that were not anticipated in the use of what was provided in the platform. On the consumer goods side, uh, they merged the transaction cycle with the listings, it went well but it wasn't intended for that.
[00:37:59] Uh, on the vacation rental side, they used the synchronization mechanisms we had given them for the search engine to perform information synchronization between their legacy system and the part that was with them on Le Bon Coin. Again, we didn't think of it at all for that, but it worked. Uh, and on the vacation rental side, they refactored all their reservation management part and so on, which was a bit of a horrible legacy piece for them, and similarly, it actually had almost no impact on the platform's usage. So in this case, we were able to validate that it went well, it was. There's a great Step 4 which is also focused on value creation but which is value creation driven by the platform team. It also works in that direction. Uh, so this is when the platform team will add new features.
[00:39:00] Uh, the collaboration mode here is service-oriented. That is, generally, we add features to things that verticals already use, that market teams already use, and they will then be able to benefit at a lower cost, if they wish, from these functionalities. I'll just give one example, there are many, but I'll take just one example on search. Quite early on, we invested in the entire AB testing part, uh trying to optimize the, what we call the scheduling of ads in the search engine. It's really the core business, we first did that with what I'd call simple technological building blocks, well, available off the shelf, I should rather say, in this case it's Elastic Search for us and we did syntactic search. But then what we did is that the platform team invested heavily in machine learning to uh maximize sorting, to enable semantic search and not just syntactic search. We arrive at a rather complex architecture with several layers of models, where we'll ask Elastic Search for sorting but we'll redo our own on top, and which we can completely customize by vertical. And that, basically, allowed us to have a search engine that is extremely powerful and yet completely diversified and specialized by vertical. And the only thing it asks of the vertical teams, ultimately, is within the configurations to activate these options to deploy these models or the AB testing that allows them to evolve. We arrive at a quite complex architecture, with several layers of models, where we will request filters from Elastic search, but we will redo our own on top, and that we can completely customize per vertical. And in essence, this allowed us to have a search engine that is extremely powerful and yet completely diversified and specialized by vertical. And the only thing it asks of the vertical teams, in the end, is to activate these options to deploy these models or the A/B testing that allows them to evolve. There you go. So that's the little recap of the four steps: migration, adoption, evolution, innovation. The two are actually overlapping, right? Uh, in reality, we have value creation coming both from the vertical teams and from the platform side, when we get there. Uh, did it work? Well, if I'm here, it means it kind of worked. Uh, already our symptoms, roughly speaking, have mostly disappeared. Uh, our initial KPI, which was to increase the delivery of verticals, we estimated, wet finger, that we almost tripled our delivery speed for the feature part, which wasn't necessarily the most complicated thing in the world. We started from a low point. Uh, if I now take, to get to the end of the example, the search part, and I'm talking to you now about user impact, or rather value creation. Uh, the key KPI on the search engine is the percentage of searches leading to a contact, and over the 4 years of platformization, we gained 40%. On this indicator and it's, well, it's huge. I say bravo to the teams because it's something we weren't even expecting. It was done in stages, of course, it was precisely thanks to the various innovations and the fact of specializing, of specializing the approach by market. Uh, and so, as a result, we were able to move it very strongly. And the second KPI we put forward, because we have supply and demand on Le Bon Coin, is the number, the percentage of ads contacted. And for that, we achieved a +160%. That is, we managed to be much more efficient in the way we matched supply and demand. But in addition, we managed to distribute, to much better distribute the buyer proposals or buyer contacts on our inventory. So we also greatly improved the value for sellers.
[00:42:55] Good. So that's the happy case, of course. But no, if we try to lift the rug and see the slightly shadier stuff underneath.
[00:43:01] there's no shortage of that. The first is that there is a heterogeneity in the level of maturity among the teams that make up the platform. We can ask why, and there are several, there are several answers. Uh, there are teams that have been, it's far from the initiative. Uh, there are also teams that have reached an intermediate level of maturity and don't have an incentive to go higher, notably because, for example, the level of abstraction they have achieved is sufficient relative to the number of demands coming from the verticals, they don't need to go much higher in complexity to manage delivery in an interesting way. And then, there's the whole group of teams that would like to be more mature but haven't managed to be. And there, broadly speaking, there are two solutions, or rather, sorry, there are two underlying reasons for this. Uh, the first one, so, uh, that's Mr. Pidson, from whom I essentially borrowed most of the diagrams for this presentation, there you go. Who wrote a little, a little article for Martin Fowler, "How Platform Teams Get Stuff Done," which is really interesting. I'll pass over that a bit. And this gentleman tells us that, roughly speaking, the platform teams depend on the number of clients they have, you know, roughly. Uh, and so, consequently, a key thing is the ability of these teams to collaborate with others. Uh, and really, uh, also to have code modifications, as we've seen, that go in both directions. Uh, but then, it really demands a significant mindset change when you've been a product team for uh 5, 10 years, uh, you've seen your domain and so on. Suddenly moving into this mindset of, "Okay, now I build software for my buddies and I'm going to go find them and roll up my sleeves so that we understand what they need." Uh, sometimes we're tempted to say, in fact, I know what they need and I'm going to code it for them. Uh, so there, that's, that's, that's really important. What's funny is that it also works the other way around, well, it's a virtuous circle, that is, the more the platform teams are good at collaborating, the more they collaborate. Uh, and the more efficient the whole thing is, and code changes happen with the least synchronization possible, and also without synchronization on the PO, PM, roadmap side, all that. Uh, a second point is that it can be important to have dedicated resources. Uh, these are actually very ambitious projects, and so, uh, it's difficult to move them forward on a best-effort basis. And there are teams within that, uh, who were (or still are) under very significant business pressure because they are somewhat at the heart of the strategy, especially, I'm thinking of payment teams, transaction teams, etc. And so, uh, these teams often found themselves having plans but not having the capacity to act on them. Small tips. Uh, well, I'm a bit biased on the question, but uh, swarming helps a lot in both these cases. Both to shift the empathy of platform teams towards their clients, but also to pool resources between platform teams and their clients, and thus to cut, to cut the cord a bit. Uh, swarming is mixing people from several teams, but in a prolonged way until they reach an objective. For example, the platform migration. Uh. So, yes. I'm speeding up a bit. We thought we were building something like this. We thought, the platform teams will serve the product teams who will serve the clients. In reality, it's false. We built something like this. We have business platform teams that served clients for years and continue to serve clients, and who, on the other hand, have also pivoted in relation to their peers. Uh, and so, in fact, they're in a bit of a hybrid situation. At first, we were like, "Ah, it's sad because it's not clear, though." Uh, but actually it's not clear but it's good. Uh, we realize that those who resist best manage to find a kind of balance between the product part and the platform part. Between the investments a bit on the user experience and on the developer experience. And often, behind that, there's a trio or a quatuor with a tech lead who represents the platform, a UX who will have the user's voice, and the PO and engineering manager who will be arbitrators. And it works very well. In fact, we get the best out of it that way. Uh, so, what's next, very quickly, what are we going to do? Uh, the things we need to get through now, is uh, the main thing, is to understand that the platform is a product like any other, or a meta-product in this case. And so, we need true product rigor around it, we need a true vision, a true roadmap for the platforms, user interviews, KPI tracking, etc. For all of that, we are really not mature, we take it too much as something technical, in fact. Uh. And so, the long-term vision is really to have a kind of self-serve. Uh, of all the basic user journeys that are coherent. For now, it's still being sketched out. With different levels of maturity. There you go, Le Bon Coin is in the middle of a group called Adevinta and which is in the process of merging a part of its brands in Europe. And roughly speaking, it's Le Bon Coin's platform that hosts them, and the idea is to go beyond the vertical, to be able to manage these platforms as well, a notion of market and a notion of brand. So that's what's, that's, that's the thing right behind it. A small wrap-up, then. Uh, for teams that would like to pivot and become teams that build business platforms. Uh, some advice from our own experience, I don't know what it's worth, all contexts are specific but. Uh, one piece of advice: go with an iterative approach, the mindset, especially the willingness to discuss with your clients, to understand their needs, etc., is much more important than having a plan. Uh, we can really do it in a somewhat emergent way. Uh, you have to understand early on that uh we must have a critical eye on the abstraction we're going to put on top of our business and try to get as much feedback as possible on it to adapt it. And that requires having strong opinions on what we harmonize with our platform and what degree of freedom we want to leave. And so those are the first questions to ask yourselves with the internal clients. Uh, there you go, and then, uh, the things, uh, the not-so-simple thing, accept the tension between product and platform when you have business platforms because, as a result, we are necessarily in a hybrid state, it cannot be pure, and it's even better that way. And finally, that's what we preach, but we don't do it ourselves. Having a rigorous approach around these tools, when they are critical and strategic, would undoubtedly be the best. Paul, at the end, uh, to our friend Grégore. Uh, there you go, who wrote a, who just released a book on the platform strategy part, and who tells us. The platform Paradox is that platforms allow us to overcome the perceived dichotomy between harmonization and independent innovation, and that's really cool. And it's true. There's a lot, a lot, a lot of content on this platform engineering part, it's relatively trendy, Team Topologies, platform strategic which just came out from this gentleman, there's a platform conference with lots of brilliant people talking. Uh, we find a lot of content on the internet, there are also the Octo guys who have a dedicated team. Anyway, uh, if the topic interests you, it's, it's really, uh, yeah, it's, it's really cool. There you go. Thank you.
[00:51:07] I.
[00:51:24] Hello, thank you, it was great.
[00:51:26] Thank you.
[00:51:27] Uh, a question, uh, you may have talked about it a bit at the end. Uh, I'd like to know more about how you managed to solve the problem of creating a roadmap. To align these teams because there are still dependencies. Yeah.
[00:51:45] So. Well, that's a very good question. In cases where it works best.
[00:51:50] Uh, in cases where it works best, uh, you don't have roadmap synchronization, you don't have synchronization at the manager and PO level. It's done directly at the dev level. Uh, and then, depending on the complexity of the feature, it will go up a level, either we'll do a small grooming, or it will be something important, and we'll potentially have to code something new into the platform, and that will go into the roadmap. But this last case, in fact, it happens quite rarely, well, if the level of abstraction is well chosen, in fact, this case will be quite rare. And so in the end, we're going to do a lot of dev where precisely there is no synchronization of the roadmap, they are done just in direct.
[00:52:32] And in fact, it's one of the properties that is really interesting precisely if the platform teams collaborate well with the internal client teams. It's that there's a kind of increase in the company's social capital, there are many more things that can be done without having to plan or lock in, and directly from dev to dev. who will, in a much more spontaneous way, go and, if necessary, make changes to each other's codebase.
[00:53:08] There's no conflict between, for example, the dev and the dev.
[00:53:15] Yeah. Sorry.
[00:53:18] Uh, my question is, maybe there's no conflict, there are conflicts, maybe not often, but... If and Motors want to do something in Q2 and there's a conflict in the team or whatever, transaction, in a platform team, there can be a schedule conflict, meaning the platform team can't do both.
[00:53:39] Yeah. So, that, that continues to, that continues to happen, but then the idea is that the occurrence is much lower. And uh, well, there's also something we didn't have time to talk about: that uh the platform also makes a choice of functional coverage, and we tried to make choices of the smallest common denominator and to do as little specific as possible. Uh, which limits this kind of initiative, well, it limits this kind of problem because there are many times when we say, "Well, in fact, at worst, build it on your side," or "Do something specific for yourselves," too.
[00:54:14] Thank you. Uh, I would have liked to know.
[00:54:18] Yeah.
[00:54:19] You introduced yourself as a lead architect. What place did the architects ultimately take in this big project, and especially the place they didn't take?
[00:54:27] Uh, that's a good question. So, in fact, the thing is that it lasted over 4 years, so already the company, when we started, we were about 400 in tech, now we are on the project we are currently on, we are 1200. So that has changed quite a bit. Uh, initially the approach was launched by an architect, by me, in fact. There was an evangelization period, in fact, it was done with. In fact, the part, let's say, strategic reflection, was done with the Diretech, so the CTO and the technical directors, and then at that moment, we had a process called TeO, the green organization work, which was a work of a permanent reorganization tool. And so we went through that. We did workshops with, roughly speaking, it was about 70 people at that time, the teams that were concerned. And we discussed the options. Uh it lasted about 2 months, I think. In real time, it felt like 6 years, but, well, it was a bit intense. Uh and then, we got a go to start testing the approach on some use cases that were a bit derisked, and from that moment on, it started to pass into the hands of the teams. Uh, I think one thing we could have done is to have a bit more evangelists, uh, anyway, because, as a result, there's another factor that is important and differentiating, which is precisely the proximity of people who led the initiative, proximity to the teams. Those who are quite low, often, uh, well, there wasn't that side, uh, uh, coach or evangelist nearby to help. Uh, that, in fact, over the 4 years, we managed it a bit better because as we grew, we formalized our paths and our roles as individual contributors at Le Boncoin quite a bit. So today, there are, we are a bit better armed, there are several, well, there's an architecture group, there are staff who can totally be, well, who carry this kind of approach. Uh, so there, we are a bit more, we are a bit better armed because we are a bit better organized.
[00:56:29] Hello, thank you for your presentation.
[00:56:31] Thank you.
[00:56:32] Uh, you just provided some answers, but I was wondering how long the adoption phase took and ultimately how you manage to handle evolutions that may occur elsewhere during this migration phase.
[00:56:43] Well, that's a very good question. In fact, there's a double run, so, well. So, I'm going to talk about the search because it's the case I know best and it's also the happy case. Uh, there was a double run first, and we released a, we released a vertical that didn't weigh much in terms of revenue and didn't weigh much in terms of ad volume to de-risk, to de-risk the business a bit. Uh, and we still arrived with a promise for the product. That is, the goal at that time, on the search, for example, we sorted by date of recency of the ads, and the idea was to take a first step towards relevance, A/B testing, and thus better performance. Especially on a category where not managing synonyms or intentions, etc., is a bit penalizing. Because if you don't, if for you a noodle and a child care are something different, it can be a bit like that. And uh, so, uh, we started with that, that is, having a kind of win that was both product and tech, but on something that wasn't on the company's priorities to have a little time. Uh, then we created a system, a double system, well, we put a kind of proxy that tapped left and right, and then as soon as we validated the model and said, "Okay, it's good, we're going into adoption." There, the first thing we did was kill the thing so as not to have the double run during adoption. Uh, there you go. And and so, what happened is that the platform team took all the vertical pieces themselves, killed the old stack, and then re-dispatched them to the clients as needed, adapting them as needed. You're welcome.
[00:58:19] Thank you, Simon.
[00:58:21] Thank you.

Transcript (Translated)