Organizing R&D to Backbone Software Innovation

Usually when you start a company, we advise you to focus to one thing and be excellent at it. The strength of Odoo was that it did the opposite of what a startup should do. It did everything at once and everything was bad. But after 1015 years, everything became good and all good together. They say that I act like a cowboy. I destroy stuff. And so we have a lot of projects that destroy everything and rebuild everything almost from scratch. And it's internally what we call apocalypse. You know, I cannot put a gun on the head of the developer and say, do this. He has to be convinced. The reason Odoo was successful, even if at the very beginning the application themselves were bad, the framework was good, the technical foundation were good. So it was very modular. It's the only ERP that is that modular. Welcome back For another tech and dev episode. Today we're joined by Anthony Lesuisse, CTO of Odoo. We'll dive into the groundbreaking approach Odoo has taken towards growth and technical at product level while still keeping a tight rein on R&D as the company expands. We'll uncover Odoo's unique R&D organization, which allows for flexibility and structure, empowering the team to make smart and innovative decisions. Get ready to explore the challenges and benefits of this approach and how it has led to a game changing product that has revolutionized the tech industry. Hello, Anthony. Hello. I'm really glad to have you here with us today because actually you're the one I work with the most in the different persons we welcomed here so far. So because you're the CTO of Odoo, you're in charge of the R&D. So could you explain us what it is exactly? Yeah. So my title is CTO, but actually my what I do every day is taking care of the R&D team. And the R&D team is the team that develops the new version of Odoo. So every year we release a major version and actually every two months we release a minor version. So we are a team of, I don't know, 300, 350 people, something like that. And my day job is to take care of that team and make sure everything advances smoothly. How do you do that? Yeah. Okay. You want to know what's my typical daily? We want to know everything. The thing is that there is no typical day. Okay? Because I have no planning. It depends on what are the issue of the day. So every time there is an issue about something, either something I would like to change some. There is some stuff I would like to push and change. Or sometimes people come to me and ask me because they have to make a choice between different solution and when it's something I want to change. Usually my job is to go and and try to convince people to change. And sometimes when it's the opposite, we have to think and make a choice. Usually I'm involved, when there is a choice. You often like trigger the dialog and then see what people say and how it can. I cannot you know, I cannot put a gun on the head of the developer and say, do this. He has to be convinced. Well, I mean, you could do that I could do that. I mean, hierarchically speaking, you could do that. Yeah, I could say, okay, do it if you even if you're not. But for developer, I think it doesn't work for developers. It could work for slaves pushing stones or something like that. But for developers, I think they need to be convinced that it's a good solution or at least they will work better. If you want to know the story, it happened maybe 1 or 2 times where we didn't agree on a solution and I asked the developer, okay, I know you think it's a bad idea, but please do it for me, you know, and we will see in two years. And if I'm wrong, I will apologize. But do it for me. But it only happened a few times. When it's phrased like that. How can you resist? I mean, it's not the same if you if you talked about it first, you know, both of you understood the point of view of the other and at the end of the day, a deicison needs to be done. So 90% of the tasks and the stuff, it's obvious what to do and people do it. But for ten or even the 1%, these are very hard. It's a lot of argument etcetera, about those 1%. And because the stuff I'm convinced that we should change, I think like a developer, I say, okay, if I develop it myself, it would be better and etcetera. But I cannot do everything. Of course, I'm sometimes convinced, but I might be wrong because, you know, when you are from outside the code, you think, okay, you can solve everything. And then when you go into the nitty gritty details of the actual implementation, you realize that actually they were right. You know, it's often more complex than what it seems, but it's part of the job. Okay. And how long have you been doing that? How did you end up being the CTO? So I met I met Fabien even before we started Odoo. I met Fabien at the university. I was not part of the fraternity, but there was a party organized in a fraternity at the university here in Louvain-la-neuve in Belgium. And Fabien was already a developer at the time, and he developed a software that was doing a fake stock exchange based on the price of beer. So, it was a party, and when you order one beer, the price of that beer would go up and the price of the other beer, other kind of beer would go down. Pretty original. And the funny part was that you had a secret key on the keyboard to trigger a stock crash where all the beers go to the lowest price. And then at that point, everybody, you know, at the party where would come to the bar to order the cheap beer. And there was supposed to be an event where they would destroy keyboard, they would take keyboard and crash them on the wall or something like that during the the event. And there was a actually a very nice collection keyboard from IBM. And I saw that and I was collecting old hardware also at the time. And I came and I said, No, you cannot trash this. You know, it's a collection item. You cannot destroy this. That was the first time I talked to Fabien. And that's how we met. He spared the keyboard and I still have it. And then after we became friends and we started to code together, develop, we were doing a demo. So there's something called the demo scene where you code graphical and musical, and the stuff we liked, for example, was doing four kilobytes demo. And how did you have the idea of getting into the ERPs and build something? Fabien already developed a software, there is a taxi company in Brussels and he developed the software to manage the taxi company when he was a teenager. So he was already interested in business stuff. We were mostly doing games and demo. It was the.com bubble. So we started to get interested into websites and we started to develop websites and he developed an auction website because his father was an auctioneer so people could bid. It's a bit like eBay actually, it was before eBay or maybe at the same time he had a lot of items on the website. It was called Auction in Europe. So we were doing websites and a lot of stuff. And at some point, I remember that we had the conversation about what cool stuff, what challenging stuff we could develop. And at the end we were thinking about SAP and this kind of software to manage all the. So it was really stuff driven by this, this feeling that you wanted to do something cool and something complex. Yeah, it was, it was something challenging and interesting. Okay. And how did you choose then and later on and how do you still choose now how to make it evolve? So first, maybe functionally speaking, so Odoo is doing a lot of things, it could do a lot of other things. How do you choose what to do and how? Okay, at the at the very beginning, we didn't really choose. We were doing a bit random stuff. And actually Odoo is the use case of what you should not do as a startup. So we did the opposite of what a startup should do and we had the freedom to do it because we didn't have investors. We were financing everything by yourself. Imagine that you do a startup and you had an investor and you would say, okay, present what you want to do, present the company and you say, We want to do 30 different apps for totally different fields. Because if you look at Odoo and ERP software in general, they manage a lot of totally different stuff like HR, accounting, money, inventory, physical items, you manage marketing, etcetera. So it's a lot of different apps that are together and we had the freedom to do it because we were doing it ourselves and we were doing a bit of consulting, installing the software to some So you had no one to convince that it was right to do everything at the same time. We did not have to convince, usually when you start a company, we advise you to focus to one thing and be excellent at it. And then maybe you can pick a second one. But first you have to to have one. We did, we did the opposite. We did a lot of feature, a lot of application, totally. And how did it go? And it was a very shitty all of them were totally bad, but, but we published it in open source and uh, there was a open source community that was able to leverage some part of the, the framework. Actually, the framework was good, but the application at the very beginning were very bad, but people could leverage it and use it anyway. And it's because of the open source community that we had some success anyway because nobody else. Maybe there was a few other items, but almost nobody, uh, did, did something similar in open source. And your question was more now how we choose what to do not to do, because at the time we didn't choose, we actually see we chose based on the customer that we had to pay for the rent and we had to pay, uh, the wage of the employee. So it was depending on the customer we had to implement. If the customer had some specific need, we would develop. But now it has become more well, way broader than that because we have a lot more. Customers and I guess they all have needs. Odoo works out of the box for many companies. So let's say for 60% of the company, they can they can go on odoo.com register and it probably will work perfectly for them. But we still do get a lot of feedbacks of things that we could add or a lot of feedback. And we usually don't do what the people who give the feedback want. And the reason is that when people give feedback, usually they are in a specific use case, they are in a specific business and they would love that. We would support their use case, but it doesn't apply to that many other companies. So we have to say no. But we even if we say no, we keep in mind the need that they have. And also another way to choose is we made the decision to do the stuff that small and medium company needs and not what big, bigger company wants. So if it's something that small company doesn't need, I take the example of a very complex access, right? If you have a company with thousands of employees, maybe we need to restrict their very, very strongly to write to every person. But if you are in a small company of ten person, a simple access write system would work. Say, okay, there is one accountant, one. Yeah. And anyway, for bigger companies they can do customizations, they can use record rules. The reason Odoo was successful, even if at the very beginning the. The application themselves were bad. The framework was good, the technical foundation were good. So it was very modular. It's the only ERP that is that modular? Yeah, because you're talking about the beginning, but it still is like this now, even if functionally speaking, now everything is working. But the if you look at the basic foundation of the module system, the the way we extend objects, etcetera, the way we extend views, it was already there from the very beginning and that's probably what made the whole strength of it. Listening to you, we might get the impression that Odoo is very conservative on what it accepts to do or not to do. Would you say it is so or no, it's not. I'm much less conservative than most of my developer. I think it's strange that I'm older than than you. I'm older than most of the developers and they are more much more conservative than I am. I'm a cowboy. They say that I act like a cowboy. I destroy stuff, etcetera. And so we have a lot of projects that destroy everything and rebuild everything almost from scratch, not fully from scratch. And it's internally what we call apocalypse. For example, in the accounting application, we did it at least two times and I think for the second time. And the way it works is that we have all those use cases in mind that people, the feedback of the people and we see the limitation of our of odoo and then we decide to change everything and it doesn't come directly from the user. Okay, But it's the sum usually of of a lot of feedback. And I explained that, uh, about the feedback of user to people that if you take Nokia, for example, the phone, the users of Nokia phone in the 2000 or something like that, they never called Nokia and say, okay, can you please remove all the buttons from the phone and, and put a big screen and that's what you had to do. They would ask for additional feature. They would say, Can you please add a button to do this quickly, etcetera. The users will give you a small improvement if you listen to them and do what they want. Yeah, we probably mostly improve your product step by step, but you will not do revolution. We do not go to the next phase. Something that people, non-developers, might not know actually is that every time you add a little feature like that, every time you add a button on the phone, it becomes more complex. And sometimes you have to put it somewhere where it wasn't planned at all, that you would have this additional button and you have to redo everything and complexify it. And at some point after doing this, more and more, there comes the time where it becomes ugly to just destroy the phone and build another one that is planned to have more buttons on it directly. But sometimes also there is the opposite that if you start from scratch after you will do the you will have you have to handle all the exception and the corner case that you you did before. Sure, sure. So it's always a trade off. I think it's for like the tax code. You know, before there was more revolution, you know, people would kill the king and destroy everything. But now we've been in Belgium for almost 200 years, and they only add new law. You know, they never refactor it. So we try to refactor and it's not just refactoring to make the code more beautiful. Usually when there is a big refactor, it's because we have a better paradigm. We have a better foundation for Maybe we can take, you were talking about the accounting pocalypse that have occurred a few years ago. So it was for V13 essentially, one of the biggest thing that changed there. So there were multiple things. There were things with the tax reports. But there was that thing with the account moves essentially when you had accounting entries, well, when you created an invoice before that, the invoice generated an entry in your accounting and then you could modify this entry under certain circumstances and in the end have something on the entry that was inconsistent with the invoice. And that was the case that we wanted to solve because a lot of people were facing that. And so essentially the solution for that and it was pretty hard to put in place was to to merge them both and have the invoices directly say. And say an invoice is just a very specific kind of journal entry in the accounting. And there is only one source of truth that's this one. And but it was a bit a revolution and some people were against it. I was for it and it was a bit painful for the users. Before you had the opportunity to do this that you don't have anymore, which is sometimes annoying, that you can have invoice with a lot of details, but on the accounting side you can merge all the command lines by product or by account and you cannot do that anymore. But the good thing is that when you do the statistics and you do the analysis on cost or something like that. You have all the details. Yeah. And it's just also just from the UI, it's more convenient. You have the one document and you can switch on the tab between the lines of the invoice and the entry itself in your accounting. So this was a big improvement, but indeed it required taking two steps back and be like, okay, let's change everything. We everything we thought was true is not true anymore and let's redo it. Yeah. And for another one we did last year was a coupon and loyalty. So we had a system for point of sale promotion system, you know, and we had another system in the e-commerce and in the sales order. And there was some feature in one system, some feature in the other system. We said, okay, let's do one big system that support all the feature that is more simple and available in both sales order, point of sale and e-commerce. And that was also a big refactoring that that we did. Another stuff that we did, it's the e-commerce, you know, there is no other ERP software that has a e-commerce integrated. So that's the strength of Odoo is to have everything in one single platform. If you look at the at all our application, you can find competitors, you can find startups that are focusing on that specific need. But the strength of Odoo was that it did the opposite of what a startup should do. It did everything at once and everything was bad. But after ten, 15 years, everything became good and all good together. So when we did the website, we added the website because at the beginning Odoo was client server and then we moved to a web version. So we had a web server running and we say, Why don't we use it also to serve the website of the company that we are managing the data. And I remember that at the time when I did the first version, we decided to do it because we had a technical idea on how to do it well, and we released the first version. And I remember our partners when I presented the new feature. They were angry because they were thinking we were wasting our time. I was full of shit. I remember I was. They insulted me. They were saying, You are full of shit, you waste your time, this is useless, etcetera. And the reason was not because they were bad person or stupid, it's just because there were some specific project. They had very critical issue like in the accounting, etcetera, and they were thinking that we were stealing resources to bug fix their, you know, day to day problem to do something that was for the distant future. But now that we have everything integrated, it's actually cool. And I have some of those partners who came back to me and say, Oh, actually it's cool that you did it. I didn't. I didn't like it when you released it. But now, I think it's cool. About now the choice of of technology. So you were mentioning the moment where we switched to to a Web based service. Would you have maybe advices on how to do that? Advice? No. Opinion? Yes. Okay. I have opinion. I think if you start a new project or a new company, I think you have three jokers that you can use. And a joker is when you use a new technology. And by new technology, I mean something that is not, I don't know, 50 years old or Something. That is not the standard that everybody would use. If I get it Tea you know, something that is battle tested and proven. Okay, for example, I to do we use we store the data in a relational database. This is a technology that exists in the mid 70s and it's proven it works, etcetera. So we don't do no SQL stuff, etcetera. Maybe the technology that we chose that was not fully battle tested at the time when we started because it was at the beginning of 2000 was maybe Python, Python was, it was already 12 years old, something like that. Indeed. Yeah. Because for, for someone listening to that, to this podcast in 2023, it might seem a bit, a bit weird because Python is used everywhere now, but indeed even for me and my student time is well, a long time ago, but not that much even for me. When I was a student, Python was there. It was popular, but it was not the thing that people would go for in the first place. And now it tends to become this. Yeah, I think on the the latest survey I saw on on Internet, it was like among the either the top one or among the top three in terms of popularity among the programming language. But so, Python was maybe a choice and also we develop our own ORM and we develop our own system of modules etcetera. We didn't use something. So that was maybe like part of the Joker that we decide. So I think you have to limit the hype stuff that you want to use. So the three jokers would have been using well making our own ORM, making our own JS framework and going rate based An actually the framework. Mybe that's one of the thing I'm the most proud of is the JavaScript UI of Odoo. And actually we didn't introduce it at the beginning because at the beginning it was client server and then it was Web 1.0 where you generate one page and then you submit a form and generate the page again. And I pushed for the web two. It was not called Web two at the time. Gmail was just getting released and I pushed Fabien to do it. He didn't want to do it. He said It's a waste of time and I told him, Fuck you, I will do it anyway. You have no choice. And I developed it for one week or a weekend or something like that. And I came with a prototype and he said, Yeah, it's cool, let's do it. And then I got our team and, and we developed the first version of the client. At the time, I think jQuery was existing. It was the only library that was existing in JavaScript. So you had no framework, so you had to do your own framework. Okay. So I suggest we now talk a bit more about Odoo R&D and the way it's organized internally. Typically, let's say you have one big task for something, so one big refactoring, one apocalypse to do. How does it go? What's the flow? Now we are organized in teams, so one team is responsible of one application. I make it simple. It's not like this, but it's mostly like a team is taking care of either one application or a group of applications. So it would be in that team. And when there is something like this and actually for every time, usually we don't involve a lot of people, it's usually a one person job or maybe two person. Why is that so? Because I think it's easier when when one person knows everything and at least to do the prototype and he would work alone. And then at the end, when you have something that is mostly running, he will need help and then the rest of the team will go on that project. But for the beginning. And you did a project like this, for example, about accounting reports and you worked alone for for 1 or 2 months or three months. More than that. And then you created a small team around you to finish the job and convert everything. And then at the end the team was maybe six person or. Yeah, yeah. And I think it's, it's very good working this way. And again to explain to people who don't develop themselves programming something big like that or refactoring, especially refactoring actually because when you refactor you have to keep the old behavior and keeping the old behavior or improve it. But you have to still have something where, you know, there was something before, there need to be something for that after. You cannot just say, Oh, we'll drop it, it's useless. Or at least with most features, it works like this and this is really hard and needs to have a complete understanding. Yeah, a full vision of the thing. It's like doing a painting. Actually. This iis very interesting because, it's possible At Odoo, for example, if you do the accounting stuff, the accounting reports, you can understand everything and work on it. Last time I saw a documentary about ASML. ASML is the company who's producing extra UV light machine to write the CPU. Okay, lithography. And they are in in the Netherlands. It's the biggest technology company in Europe. They are the only one in the world that can can that can do this machine. And we don't use the machine in Europe. We ship them to Taiwan and to South Korea. The interesting thing about them is that they were explaining that the machine is so complex that there is nobody in the company that knows everything about the machine. So the the they said that the cool thing about this company is that we we are like a, you know, a mind made of multiple minds. And it has to work this way because it's impossible for one person to know everything. Fortunately, it's not the case here at Odoo. And I can have, at least for one application, somebody who knows everything and he can refactor everything, which makes the thing much more easier. Okay. And so to go back to the to the flow of of the development. So you were saying one person in charge at the beginning and then if needs be more person can help, what happens then? So there's a prototype. What what happens to the development? Actually, it I don't know what happens. No, it's true. People are autonomous, so they organize themselves and they will ask their friend next to them to come work with them. Et cetera. So it's a bit organic. What is important is that we have to be convinced that it's a good prototype. Otherwise we give up and we say, okay, no, let's scrap it. I think it's a quote of Steve Jobs or something like that, that says that usually you don't need to manage people because they are if they are intelligent, if they have a common goal and they know what what's the goal they will organize themselves to succeed. And I think that's what happened. At the same time, I do the opposite. I micromanage. When something is my pet project or something like that, I go and I micromanage and I go to see all the details sometimes. And Fabien does the same also about some stuff. So we go to see all the details and we let also people very autonomous. So it's a bit of a paradox, you know, because we say, okay, everybody auto organize and then we go and we focus on small details. But it's interesting because I mean, experience shows it works at least with Odoo at the moment. It works. Nobody knows why, but it works, one might say. But it's crazy because you would imagine that there are plannings and there are deadlines everywhere for this kind of things. And there's nothing like that in R&D, right? Yeah, it's very it's not the anarchy. There is no planning. The only planning that we have we know that we freeze a version every two months and people decide if it will go in that freeze or not. So we have some deadline. And then there's the new version every year, which is also, of course, like an implicit deadline. So we have some deadlines, but our people manage themselves. We don't have a waterfall strategy. We actually we say we use Kanban. So we still have a kind of agile approach, but like very agile, right? Yeah, very agile because we don't have the equivalent of scrum meeting and every task live its life in, in the pipe. We use a pipe with Kanban task, you know, to manage our pipe. Maybe for people not familiar with it even though it's very popular. So you can Google it a little bit. But Agile and Scrum are basically you open the project application of Odoo and you have this thing with the cards. Each card represents a task. Each column is a state for that task and that's how you keep view of your project. Basically Scrum is based on that and it's using that tool to. Scrum actually is not based on that. Scrum is based on regular schedule like two week period, and people commit themselves at the beginning of the period to do some of the different states corresponds to these meetings. And you know what I'm going to do for this sprint, for the sprint after what is in the backlog and is waiting for another sprint. So yeah, it's a bit it's a bit like this. And also we have some kind of process about when a task is done, it's tested and then it's reviewed. There is some process about that, for example. And also there is a process because we have a continuous integration platform which is called Runbot and it enforces a lot of constraint. We have a test suite that has to run. So basically if people go to run Bodog.com and they see it's red, it's bad. Yeah, it's bad. If it's green, it's okay. It means the tests are passing. But normally it's always green because we don't merge something unless Yeah, but you can follow our development and you can see all the development branches. And we have also so we have the developer. But you have also what we call the product owner, which are the functional person who follow the project test and work with the developer to ensure it will be a good task. And what is their responsibility exactly? So,in R&D, they are the developers and they are the product owners. So the developers will get what they do. What do the product owners do exactly? They decide what we do and what we don't do, and they do it with Fabien and me and but also the developer because like I told you before, the developer has to be convinced that it's good that the task is improving no matter otherwise, if it's not convinced it will Yeah, indeed, it goes well with what you were just saying about the philosophy behind the the organization of R&D and the fact that people are more free and need to be to organize themselves so well they need to be convinced to do that because otherwise it's just not the same. Yeah, they have to be convinced. So for us there is two way to, let's say, spin the development. First is to convince people or put somebody else who is convinced. And it happens sometimes. We know that the developer is not very will not be convinced and we ask another one to do the prototype politics in it as well. Yeah, that's the politics. We ask somebody else to say, Oh, we work with somebody who is convinced to do the prototype, and then after we convince the other one with the convinced. Yeah. And sometimes it doesn't work. We made some prototypes and then at the end we say, No, it's bad. It's a bad idea. Yeah, but that's the R in R&D. Yeah, that's the are in R&D. Okay. About the scaling maybe now of the R&D because Odoo is growing a lot. The R&D, of course then is growing a lot as well. Isn't it difficult to to keep up with that? I think it's okay because we have a different applications and different if you if you go on Odoo and you see all the icons, maybe 50 different icons. So imagine that you have a team of ten person behind each icon that would be already 500 or 600 people. So until we reach that point, I think it's easy to say, okay, one team is taking care of one application. It stays at a human scale because a team of maybe ten people, everybody knows each other. It's okay. The. Problem is when we have development that are in the framework or are cross-team. We have to change something among all the applications so all the team have to synchronize. Of course that's a bit more difficult now that we are bigger, but I think it works. Every team is now self-organized at this own area of expertise or is application and inside the teams. I don't know how the magic happens. I don't know how the magic happen. I think it it happens like it happened at Odoo before, but you are more, you know more about it than me. I don't know. I know my team, not the other ones. We have some teams that are big, like like yours. So yeah, accounting is like 30 something people. So it's everybody still knows each other, but it's getting big and so you have a sub teams but they are not fixed. It's like I think in Valve they did that also were involved they had moving desk and because people like to keep their PC on their desk they are doing games so they have to have a big PC. The reason they are moving desk with you know, wheels is that they can move around and if they work on a project for two weeks or one month, they work together. And I think what it happens in when I visit the different office always people move from one desk to another and depending on what they work. Yeah. And the time they arrive at the morning. Yeah. Okay indeed as well. So as the last question I would like to ask you, what is the typical profile of a developer at Odoo or a product owner, by the way? Because why only developers? Because you said a lot of things on the philosophy of the R&D. Yeah, but I would like to know who we want. Most of the people we hire, they just graduated from university, so they usually don't really know. And I don't want to say you have to have this way of thinking. It doesn't matter. What matters is that you are smart. Yeah, but what is the smart people and and also interested, For example, as a developer, you are interested in programming, etcetera. You like it. I think it has to be something you really enjoy to do, you know, because if you chose this because you think you will earn money and you are not really into programming, you don't enjoy it very much. You have to care. Actually. Yeah, you have to care. And um, we are a big team, so there is a place for many different kind of person. We have very technically minded people, but you have also people who are who care about the user and and and knows and can put itself at the place of a lambda user, which is not, you know, not every developer can do that. Both are okay. You have people who prefer to work on the framework part and we never see them. And we have people who like the UI and do something that they can show their parents, okay, this is, you know, my button, my stuff that is visible on the screen. So the conclusion might be, come as you are, as long as you care. No, no, come as you are. As long as you are smart and you enjoy programming. Okay. For example, we don't hire people who will manage people. We don't hire managers at all. I have a interesting thing is that I have sometimes, uh, senior people, they come from another company and they come because they want to go back into the code and they were working in a company managing people and not doing any code anymore and say, okay, I want to go back to the code. Of course, if you come as a senior people in Belgium at Odoo, you will you will code. Thank you, Anthony, for all your answers. Thank you for having me. My pleasure. And that's a wrap for this episode. Thank you for tuning in. I hope you enjoyed discovering the essence of the R&D at odoo. If you'd like to stay for further insightful tech and depth discussions, go explore the rest of our episodes. Until then, see you next time. Cheers.