MATHIEU: 0:01

We are different than most other tech companies out there. I think we have less structure, but in the end, I think the result of the task is a real work of collaboration between a PO and a developer. That's why also it works well.

CHRISTOPHE: 0:17

We don't expect a developer to be a master warehouse manager when he starts doing MRP or master accountant, that's for sure. I think we'll guide them. It's part of the process.

OLIVIER: 0:27

Hi everyone and welcome to this new episode of planet Odoo. Today we share with you the second part of the discussion we had on Twitch. If you didn't listen to last episode, I highly recommend you do first. And if you already did, stay with us because we'll jump into the conversation right now. Ready? Let's go. Welcome back for the second half time. Um, so we were talking about the way the, the, the tasks, uh, appear in our, our pipe and how we start, uh, working, working on them. Uh, we mentioned a lot the, the, the constant discussion that there is, uh, around tasks. Um, and I would like to, to start before maybe, uh, getting into the, the next point. Uh, I have something to add about that actually, uh, it's, it's the impact it has maybe on the, on the way new developers will will will just interact with the rest of the team because of course, you know, when you when you're an experienced guy, uh, you've been there for years. Uh, I think you dare to speak with pretty much everyone. Hopefully. Uh, and so that's no problem to just try to, to push your ideas. I think it happens like that in every company. Uh, but for newbies, it's not like that. And I think this constant challenging that, uh, happens in the team has an impact on on newbies as well, right? Um, so I have an anecdote in mind with that. So there was that thing, uh, I will not explain the details, but, uh, something we didn't do, uh, for and hadn't been doing for forever. Uh, on on regarding the update of some data because it was deemed impossible, uh, at the time for various technical reasons. And and no one really challenged that ever. And then there was Claire, uh, entering the accounting team, uh, and, uh, and someday she she came to me. She was like, don't you think this is, like, super shitty, actually? And, uh, and so, uh, she suggested a way of doing it, and actually, she was right. It was doable. And so we did it, uh, And, um, I think she felt comfortable doing that and proposing this kind of things without being an ancient dinosaur in the team, because there was that fear, uh, around, uh, her. And she could see that it worked like that for everyone. I don't know if you guys had other stories like that.

MATHIEU: 2:47

Uh, yeah. I mean, for me, like, usually it's funny when a developer is developing a task, so usually they'll dig really deep into, uh, into what they are doing, let's say the master production schedule or the repairs module and something. And for me, in my team, I have often developers who come to see me and they say, oh, by the way, like I was, I was working on. So I'm doing the, the spec. Um, but actually this, uh, this field doesn't make any sense. Right? Or I was, you know, playing around with this or and I didn't like the way it felt and so on. And so could I change it, you know? And so, uh, most of the time it's, uh, it's an obvious. Yes. And, uh, and I think it's good when, uh, when, uh, developer, uh, takes that, uh, that, uh, um, um, that responsibility or that, uh, let's say, uh, how do you say, um, initiative, uh, to also bring and not be afraid, uh, to, to bring something in the worst case scenario, um, you know, we'll just discuss the, the feature, but, uh, if you're digging so deep into the, into the feature, most of the time you will actually find, uh, other areas of improvement. And so, uh, I can relate to that. Uh, for sure. Yeah.

LAURA: 3:53

Um, yeah, I had the same. Sorry. With expense, for example. Uh, um, I launched a specification, a task for it, and the developer, Julian, uh, was taken. The task told me actually the the code behind is not really great and it should be improved. So I suggest we do a technical refactor and so on. And it was right. And we did it uh, at the end. So the developer really takes initiative, uh, as uh, as you said and uh, every everyone is winning.

OLIVIER: 4:23

At the same kind of thing going on with the CPU module. Right.

LAURA: 4:25

Uh, exactly, exactly.

OLIVIER: 4:27

Yes, indeed. Uh, So let's just talk a bit more about development itself. So, uh, how does it go? So the task is done. So however it was born, it is born now. Um, how does it go? So the developer takes the task, of course, starts working on it. And then. Good question.

CHRISTOPHE: 4:48

Well, uh, as we've said, like usually you have a base specification so the developer knows why he's doing something and what needs to happen at the end. But but then comes in discussions already. Sometimes, like the developers take the task and he sees two points that needs either clarification or maybe are wrong. Or maybe there's a even better way of doing it than what we imagined. And so, right from the get go, the developer can come to the Pio and say, okay, this is wrong, this is dumb. And I propose this work. And this also might surprise the newbie. Sometimes when they start working at Odoo, like they can go to the Pio and say, I think you're pretty dumb, that that's a way better way of doing that and.

LAURA: 5:37

Not like that.

CHRISTOPHE: 5:38

I always love it when they do that, but it's like, that's enriching that that's where you learn. Even us as PO, we also we we need to be humble. Sometimes we can be humbled by developers that have better ideas than we have.

OLIVIER: 5:53

So it's the same for us. I mean, um, uh, when your developer, sometimes you like. Come on, that thing is useless. Why do we need that? You come to the PO. Like, do we really need to keep that stupid thing there? Because that's just making the code super messy. And it has tons of consequences everywhere. And then the PO for ten minutes explains you why this is absolutely necessary, and then you feel a bit stupid. Okay, that's that's life. Huh?

CHRISTOPHE: 6:17

Yeah. So so so so to come back to to your question, right from the get go of a task, discussions can happen. And there's no like pure hierarchy between a PO and and a developer. We all both have the responsibility of making the task going forward, and so we can discuss it from the get go. And for the rest, I think the process is actually like very light at Odoo. Uh, as usual, um, developer wants he knows what he needs to do. We'll start this task. Uh, so doing the development, once he figures out that it's probably doing what's intended, he will ask PO then to test for a first functional review where the object is functionally like met. Um, but then that's interesting because once the PEO agrees that the functional testing is okay, um, it will go to, uh, sometimes pretty lengthy review where the code will actually be reviewed by a senior developer. So the interesting thing in there is that it's not the PO that has actually the last thing into whether a task or not will be done. It's actually a probably more experienced developer that will have the final, more experience.

OLIVIER: 7:33

Into.

CHRISTOPHE: 7:33

Whether that thing will be done or not. And again, it happens really often in review that an experienced developer can come back to, even to the functional specification to maybe tweak or challenge if needed. And again, there's no problem doing that. We are we are always open to discussion because.

OLIVIER: 7:51

Indeed, in some situations it can happen that the more experienced guy sees what has been done is like, hmm, it's kind of working. But first it could break this, that and that that we've just forgot about. Uh, and um, maybe there is another way of doing that that is just more simple. Yeah. Uh, and uses something that was changed recently or some deeper thingy. Uh, uh, it happens quite often, actually, that you have things like discussions like that. Uh, um, and I think this whole thing makes the, the process and makes the development more dynamic as there is a lot of back and forth, uh, all the time. But so the developers also can be more reactive. And you have a crazy anecdote with that, right?

LAURA: 8:30

Ah, yes. Yes, exactly. Um, so for example, in accounting we work a lot on EDI. So it's an electronic invoicing.

OLIVIER: 8:39

And basically that thing you need to connect to to send, send invoices, tax informations, whatever so that the government can track everything you're doing.

LAURA: 8:46

Exactly summarised version. And it's the case in, uh, in Kenya and in Kenya. We need to get certified uh, to be able for user to, to use Odoo basically. And uh, so we had to do some demonstration to the government to show, uh, okay, this is the business flow, uh, the business flows and so on. We developed for specific Kenyan customers. And uh, during the demonstration to the authorities, uh, there was something that needed to be changed. And usually what the authorities expect, expect is that after the meeting, uh, with the developer, make the modification, and then after we need to plan another meeting and then we need to do another demo, and all that process can take two weeks at least minimum two weeks.

OLIVIER: 9:34

Yeah. More. Uh.

LAURA: 9:37

Or more.

OLIVIER: 9:38

Yes.

LAURA: 9:39

And uh, the developer just, uh, was there was like, um, okay, uh, keep on the demonstration. I'm making the modification live right away. And in ten minutes he made the change and then it was done. We didn't have to plan another demonstration for for this fix. And it was. Yeah. So impressive and so nice.

OLIVIER: 10:00

How did the guys from the government react when they saw that? Because that's pretty surprised. Yeah. It seems unusual.

LAURA: 10:06

Positively surprised.

OLIVIER: 10:09

So yeah. Okay. So yeah, we can see the added value of this kind of of process. And again uh, just did that because he was in the meeting. So that meeting was I mean, if you were in a super hierarchical structure, what would the developer be doing there? It's just demonstrating functional things. So no need. Uh, but actually there is an interest in doing that. Uh, um, exactly. Okay. And so, um, yeah, essentially we can summarize it, uh, you know, there's that, that, that, that sentence, that quote you made when we prepared the episode, but I'm stealing it from you. I'm sorry. Uh, the dev owns his stars during the whole process, and I think that is pretty, pretty pretty true, actually, uh, because dev is responsible to make the thing, make sure it gets much mature, make sure it gets challenged. Uh, if it's forgotten at some point, because there are other priorities. He's also he's also going to be the one pushing for it. Uh, so essentially it's more involved. And I really think that, as I said earlier, a lot of people often forget that this job is a passionate people's job. Uh, and so if you keep people interested in what they're doing and involved, it will just go way, way better.

CHRISTOPHE: 11:17

We could maybe even add that it could. It can lead a junior developer having to discuss this task with the CEO or the CTO, because those guys we know Fabian. Fabian describes himself as the first peo like, he really likes to say that 50% of his time is is dedicated to make the product better. So if at one point he also wants to get involved in a task, it can happen. And so yes, as there's no like huge hierarchy at Odoo, yes, a developer that is three months old at Odoo can really start like having a discussion with the CEO about the specific task if that needs to be done and the discussion will happen. Um, so of course, when there's a discussion with the CEO, there's two people trying to convince themselves. And and at the end, if nobody can, like the CEO can always use probably not an authority but experience and you know and vision to to continue the discussion. But yes, a developer can discuss a task directly with the CTO or with Anthony, which is the, the CTO. Um, like, uh, on details and, and they will each of them trying to convince to get to an agreement together. It's not going to be like a big authority hammer that will come directly.

OLIVIER: 12:36

Maybe it's worth, uh, recalling for people not knowing that. Who knows, maybe you're new, uh, that, uh, the the CEOs of Fabian, uh, is a developer. And at the beginning, Odoo was like him alone, uh, coding as a student. Uh, and so, so, of course, uh, it's possible to have a technical discussion with him, and, and that happens quite often all the time. Uh, actually, uh, and indeed, I think I don't know how they manage to do that, quite frankly, because there's a lot of developers, there's a lot of people. And I mean, when you're a CEO, you have other things and other responsibilities that you need to take care of. Uh, uh, but they still manage to, to stay very, very available for that. And I think it's in Fabian's opinion, I think it's really the most important thing is the direction the software goes to goes into, uh, because if it's better, if it's objectively better, well, of course you can sell it more. And that's, uh, that's how it goes. Um, so indeed, uh, often they, they will be involved on, on big tasks like that. Um, uh, that brings us maybe to the, to to the next point, uh, the communication itself. Uh, so sometimes we need to involve the CEO and the CTO in it, and not all the time. Sometimes they involve themselves into it as well. Um, would you say that the communication with developers, um, has something special, uh, compared to communicating with, uh, people from other backgrounds, from other jobs. Uh, is there a difference?

LAURA: 14:11

I would say yes, especially when you don't have, uh, computer science background.

OLIVIER: 14:17

But you follow the Python course, so you cannot say that anymore. That's true. That's true.

LAURA: 14:21

I shouldn't have said that. Um, but I think, uh, what's different is that we both make effort maybe to be on the same page. For example, uh, when I started, uh, Christoph with developer at the beginning, uh, made me an introduction and an onboarding for technical, uh, terms. And so I, I manage with the, with the years, of course, and uh, with the formation and stuff to, to to learn more, more about technical terms. Uh, but the developers also make sometimes effort to to be sure we are on the same page. So, for example, I have a small anecdote, uh, for that, um, I was working on the reports and on the reports you have a date filter and currently it works. Not as expected, uh, being that when you click on a date to apply the date on the report, you are. You need to click outside the box after so the date apply to the filter, which is not user friendly. You don't want user to do that. And what I want is that user click on the date and after a micro delay then the date filter is applied. But there is an issue with that. What if the user needs to click just after on on on the on another date on the on the filter. And there is some technical constraint related to that. And the developer I understood them them. But to be sure that we were speaking the same language, the developer used a comparison that I find kind of funny. He told me, okay, Laura, it's like, I want you to get some pizza with your car, but then after five minutes I don't need the pizza anymore. So we have two solutions. Either you come back and you have a useless pizza with you. Either we make the car explode and I was like, okay, that's a nice comparison. I understand the issue, you see. So yeah.

OLIVIER: 16:21

That was pretty accurate.

LAURA: 16:23

The communication is is particular in in that way when we have different background. But at the end we both make efforts and we managed to understand each other without a problem.

OLIVIER: 16:33

Um, indeed. Uh, there is a lot of technical jargon involved. Uh, there is a lot of, of so, you know, sometimes even in my day to day life, uh, when speaking with my family or whatever, uh, I try to explain something, and the first words that come are maybe not technical words, because, come on, I'm not such a nerd, but still, uh, the way I'm going to phrase it, it's like. It's like I'm talking about the model behind some, some some, some technical object, whatever. And and, you know, that's the moment you're like, dude, what are you doing? Because that's just normal for you and people doing your job. It's not they will not they, they don't know that. Uh, and um, and so indeed I think using metaphors sometimes it's interesting, but uh, uh, it must be quite challenging. Yeah. Uh, to, to just come in the middle of, of all that. And so you were talking about this, this, uh, this introduction that, uh, you were given when you entered. So about git and so on. Could you explain maybe a little more. What's it?

CHRISTOPHE: 17:34

Well, yes, I think it's going to be very obvious to all the developers that are in hearing.

OLIVIER: 17:39

Maybe some people are not developers here, but you need to explain everything again here. But you have five minutes to do the introduction. Right, right.

CHRISTOPHE: 17:47

So all developers that need to work in a collaborative environment use some sort of technology to make sure they can push code and not conflict with each other when they are working in parallel. Usually that's done with via the, the git uh specification, which, which is more like a standard. Um, and by doing that the workflow of the developer, the day to day of the developer is really, like unconstrained by all the git logic that happens. And so when a as we are working day to day with the developers, when we as a PO need to like ping a developer to say, where is that? It will often answers in a weird jargon that only developers can understand is like.

OLIVIER: 18:32

Saying.

CHRISTOPHE: 18:33

I've done my changes, I've committed them, but not pushed. And maybe my PR is not.

OLIVIER: 18:40

Needs to be.

CHRISTOPHE: 18:42

Whatever. If you don't understand that part like you don't even you're not even able to follow what he's saying and work together. This is where I think the the POs that are not not all technical, uh, based need to do the effort to understand that part, because we are not asking them to do git branches and pushes and commits and reverts and all that stuff. That's not the pure responsibility. But as it governs the day to day of the developer, if they want to interact and be able to speak together, at least the concept needs to be understood by by the PO. And so we that is the part where we need to do the effort to make sure that we on the same level and we can we can talk together.

OLIVIER: 19:25

Mhm mhm mhm mhm mhm mhm mhm. Yeah. Indeed. And I think it's very important to do something like that because as you say git is a so it's, it's like it's a tool but it's like it builds the whole process because you, you need to work within the bounds, the boundaries that it, that it gives. Uh and it's fine. But again, uh, for someone coming from outside of it, Gita used to say it's perfectly impossible to understand, except if you already understood it. Uh, so that summarizes it.

CHRISTOPHE: 19:55

There's the standard git and but even for technical people, there's the way git is used at Odoo. And sometimes they, you know, like the R plus and the gunboats and all that stuff that is Odoo specific. And that also is worth explaining to PIOs because they need to master that.

OLIVIER: 20:09

Mhm mhm. Yeah indeed. Because those are so for viewers uh internal tools that we, that we use to coordinate the way we develop and that like that are put on top of git, GitHub and, and all that. And of course if you don't know that, uh, you don't understand the thing of what's going on. Mhm. Sure. So would you say that converting leader are also things that developers need to get in the jargon that you could be functionally using? Uh, my answer is yes, but just to give you a hint. Go ahead. Uh uh uh um, and and how does it work for them to, to learn that then? Because, I mean, if you're a developer and you come to a accounting team, that's that's a typical example. Accounting is a is a world of its own, and it has a lot of concepts, a lot of things that are uh, and uh, I that's also something I used to say a lot, especially at the beginning. I think if accounting had been invented by engineers, it would be very, very different. But so it's not uh, and uh, and, and and so, uh, there are a lot of even ways of thinking sometimes that seems perfectly logical for someone with an accounting background, but when you're a dev, you need to, like, take two steps back and be like, it's like a foreign language, actually. You just need to get used to that and be like, hmm, ah, yeah. Actually, yeah. But why did you phrase it this way? It's more simple, but like this, uh, because it's just not the same way of thinking.

CHRISTOPHE: 21:37

Uh, you should tell us, Olivier, because you probably needed to, to learn accounting. I can maybe talk a bit about it as well, because I didn't didn't know anything. But this is part of the process. Yeah, I think this is part of the learning process. We don't expect a developer to be a master, you know, uh, warehouse manager when he starts doing MLP or master accountant, that's for sure. And so I think we'll guide them. Um, they will they will start start by, uh, learn by doing as well. So maybe start with a small task which is covering one aspect. And then if he doesn't understand it, come to the PO. And because we have the responsibility to to try to explain them what they are doing and why, and so also learn with the colleagues, uh, because they are just right next to you and you will be probably, um, I think the developers between themselves, they help each other all the time. So a newbie will be coached by a more experienced one. So there's there's that part. So I think you will learn by doing and with the colleagues that are right next to you. Um, that is for sure. And you will learn. It's part of the process.

OLIVIER: 22:43

Yeah I agree for, for for me it was a bit special because it was really hard work. But it was in ancient times, like seven years ago. Come on. Uh, and uh, ancient times, uh, there were still dinosaurs and all that, but they they died since then. Yeah. Uh, in case you didn't notice, um, and, uh, and and. Yeah, uh, for me, it was really the hard way because it was. Okay, take a task, though, this one. And then you read the thing, you understand what you can you go discuss with the PO. I took the habit of going discuss with the PO directly when I get the task, actually, uh, because because it's easier for me. I need to rephrase it for myself to make sure I understood. Uh, and, um, and, and and. Yeah, if there are things that I don't know about. Well, I ask for an explanation at that moment, and, uh, that's that's how it went. And, well, was pretty okay. So far. I'm doing good.

CHRISTOPHE: 23:31

But again, it highlights the expectations that we have for developers. We need people that, you know, you know, want to learn, uh, you know, have some proactivity in the tasks that they're doing and not like guys where we have like a pseudocode of a function and they need to write it in Python. Yeah. And I think.

OLIVIER: 23:49

But I think it's, it's really rewarding. Uh, because again, as a developer you like to solve problems. Uh, so here you're not just solving them. There's also, you know, you feel that you're gaining experience with that kind of things because, uh, so there's been a few years now, but, uh, uh, I personally, I'm pretty proud, uh, you know, of being able to discuss with the POs on tasks from purely functional things, knowing that I understand what they're talking about. Uh, most of the time. But I'm not telling you, uh, and, uh, and, and and that's, that's that's pretty cool, actually, because, uh, you can feel, well, what you got from the whole journey, you you made so far, uh, and you can get implied in more things and differently and give different insights. And so that's that's very interesting I think.

CHRISTOPHE: 24:37

And I'm pretty sure the new POs that are coming now and that are entering like a team where there's the PO is gone or whatever, the new POs will actually learn a lot just by discussing with their we call them guru. So the the developer that took the lead into a specific team like the POs, I will do some introductions for the basic stuff, but then at one point is okay. If you want to learn what's happening in your team, talk to the guru. I'm sure those guys know probably pretty well what's going on, even on a functional level. Exactly. Mhm. Mhm. Mhm.

OLIVIER: 25:11

Okay. And so to go back maybe on the the challenges that could be in the communication. Um so we talked about sometimes involving uh Fabian and Anthony uh in discussions. Ah, it does not happen all the time because a they are human beings, so they have limited time. Uh, so far, I think we all agree. Uh, sometimes I doubt it, but I have no proof yet about the human.

CHRISTOPHE: 25:35

Being, you.

OLIVIER: 25:35

Mean. Um. Uh, and but what happens if the discussion that's been going on, on some tasks does not give any solution. So I don't know if we can call it a conflict, but let's use that word even if it's a bit too much. Uh, what would happen then? How would we would you solve that without going directly, uh, fetch Fabian or Anthony? Because, of course, you cannot do that all the time because not everybody agrees all the time that breaking news.

LAURA: 26:06

No joke.

OLIVIER: 26:07

What's the solution, then?

SPEAKER5: 26:11

Well, usually.

MATHIEU: 26:12

Go for it.

LAURA: 26:13

No, no. Go, go.

MATHIEU: 26:14

So you. I mean, usually, uh. Of course, I mean, for me, in, uh, in the scenario where we can come to an agreement, uh, it's rare, to be honest. Usually we do, uh, come up with a solution. Either we will, uh, get the, uh, usually the guru involved in the discussion. So he's the tech lead, uh, of the team. And as Christopher mentioned, he has both the the technical knowledge and the functional knowledge. Also, uh, to really, you know, um, uh, bring, uh, another level of discussion, uh, to the, to the problem solving. Um, but usually in those cases where we really cannot come to an agreement when, for instance, uh, the guru agrees, for instance, with the developer that, uh, it would be too complex, uh, to develop something. But the PO, uh, does not want to compromise on the functional specification. In my case, I will pause the task. Uh, for the time being, uh, as the developer, perhaps to work on something else, uh, and then get back to it. Uh, maybe when I have a bit more time to think about it, reevaluate it, and then think a little. Exactly. So sometimes you have to do it. Um, and there's nothing bad about that. Gives you more time to evaluate the importance of a of a task. Um, but yeah. And so I would reevaluate it and then we would have the discussion again with more elements in the, in the second scenario. Mhm.

OLIVIER: 27:36

It also lets more time to build maybe a compromise because that's often that's how you solve. That's it issues. That's it. Um and I think going involving like the guru or some more experienced guys also a good move because the more experienced guys, guys normally are used to making compromises or compromises. Compromises, uh, like like that. Uh, and, uh, and, and so they will know where to, to put a line or at least they will, you know, eventually be like, okay, we can do that, that, that. But this is an absolutely an absolute no go because of list of arguments. Um, so yeah, um, I think it's a third opinion strategy is uh, is working well as well. And indeed leaving more time for people to just think about it and be like, actually, maybe we can do your thing differently. Uh, but still do it. Yeah, that could also be.

MATHIEU: 28:31

And sometimes, actually, it happens that when we pause these tasks, sometimes the developer comes back to me after a while and he says, oh, by the way, actually I found a way to do it just happened yesterday, by the way. Um, and it was just a task that we paused because technically we thought it was not possible to accomplish the initial result we wanted. And I just had a developer contact me and say, oh, by the way, I've looked into it. I found a solution. And for me, that was that was great. You know, because, uh, don't have to compromise on the feature. Um, and.

OLIVIER: 29:00

That's also a thing, uh, developers like to solve issues, and something they don't like at all is having a problem that they cannot solve. And so, uh, often when, uh, William does that a lot. Uh, hi, William. Uh, so sometimes when, when, when, when when, you know, there's something that seems impossible and like. Yeah. No, it's it must be possible. It should be possible. Uh, and so eventually they might come up with something. Uh, so again, good strategy, I think, uh, you're doing great. Okay. And, uh, with that, we are reaching the end of the episode. So as a conclusion, uh, outside of any football joke that I will probably make later, um, what would be your how does it feel for you this, this way of of of working the contact with the dev, the interaction. So everything we explained uh, today. What what does it does it bring something? To you? Uh, as a human being, as a professional, I don't know, uh, choose your answer. Uh, how do you feel about, uh, about that? Who starts? Laura, you start. You need. You seem to have something to say. Let's go.

LAURA: 30:06

Uh, no. For me, uh, I like that, actually. I like to be, uh, confronted also to, um, a world that I didn't know before. I mean the it, the IT world, and it makes me evolve in a good way because I learned a lot of things, uh, I learned to collaborate with people with different backgrounds. And, um, I love resolving complex issues with bringing simple solution, uh, while taking into out account, uh, UX, UI, uh, and so on. So for me, yes, this is, uh, all the parts in my job that, uh, that I love. Mhm.

OLIVIER: 30:44

Cool. Who's next?

MATHIEU: 30:46

Um, yeah. I mean, uh, for me, I also enjoy this, this way of working. I would say I definitely, um, we are different, uh, than most other tech companies out there. I think we have less structure, as we mentioned today. But in the end, I think the the, the, the, the result of the task is a real, uh, work of collaboration between PO and a developer. And I think that's why also it works. Well, uh, is because both are quite involved in that, in that process. Um, and um, and. Yeah. So I think it's, uh, it's, it's, it's a good way of working and um, and of course there are ways of always areas of improvement. Uh, but uh, but so far I think it's been good for us at least. Yeah.

CHRISTOPHE: 31:31

Well, yeah, for myself, I would say like, I don't like dump hierarchy. I like solving problems. I like working in a team. I like low process stuff that actually takes care of doing business. That's exactly how these working. And that's really the core of the, I think, the values at Odoo. I just love it. That's exactly, uh, that's exactly what I want to do with the work and here to do on top of that, what I also like to do is when I work with people, I see them grow, you know, to develop as better developers or they're proud of what they're doing. And we really I think we really do that.

OLIVIER: 32:09

So yeah, I agree I'm going to give my opinion as well. Why not. Uh I agree and and for me, you know, I've always, always been that that very passionate guy with, uh, I, I work on, on passion essentially. And so, uh, being able to do that at work as my job, actually, it's not at work. My job is literally doing that. Look what I'm doing here. Uh, and, um, that that is that is really great. Uh, and this constant challenge of having, like I said, this accounting world that you need to understand and sometimes make a bit of sense of because you're like, wow, what do they do? What is that? Uh, and that is super interesting to do. Uh, and yeah, um, I'm going to stay, uh, okay. Uh, and so that will be the final word for today. So Odoo unplugged will be on break for quite a while actually until the Odoo experience now. So it's like our first season that's finishing now. So congratulations guys. You were in the last episode. Uh, but we'll be back after Odoo experience, so I hope the experience happened at the beginning of October. So go and see us if you haven't booked your ticket yet, see you in the next season of Odoo unplugged. Cheers! And that's a wrap for today's episode. I hope you enjoyed it as much as I did. If so, don't hesitate to join us on Twitch next time! Having you on the live to interact with us would be awesome! The video of our discussion is also available on YouTube, so it would be nice if you could go there and hit the like button. And if you want to stay with us longer, we have dozens of other podcast episodes available. Until next time. Cheers!