 Everybody, we're going to heat up, it's just 30, our next speaker is called Damien. Yeah, that's it. And he's gonna talk about the open decision framework as you can see. Please, a big round of applause. Thank you. Thanks a lot. Do I speak enough loud for everyone? Okay, so, this is about how to make everybody IP. Spoiler alert, you can't. So, a little bit about me, my name is Damien. I'm not a designer, I'm a database guy. And there's somewhat a long journey that came, bring me here. My story is that I founded a post-classical consulting company, anybody here using Postgres? Oh yeah, okay, cool. And so I'm also, so I'm kind of a director of a 30 people company. And I'm also involved in the Postgres community. So I've got this two minds on two spaces. Two more, two more about me. Just check out my GitHub account. So my story, we actually started like a kind of joke. We should make a company and do open source. And so we did, let's make a company like we make open source. So yeah, clear principles that we all know, transparency, open discussion, working remotely, a result of structure, et cetera, et cetera, et cetera. So on paper it's really, really good. When I explain this to people, they say, oh wow, this is cool. Until they come to us, to our company, they realize our decision workflow looks like this. No, actually we don't throw fishes at each other, but anyway, it's pretty much like this. So problems, well, consensus does not scale. When you grow the group, it's harder to get everybody on the same page and everybody agreed on the same questions. Something you see on open source communities is that, yeah, meetings and meetings and meetings, or which is not better, hundreds of emails. We reached a point where we would meet like two hours and at the end of the meeting, we were not even able to agree on if we had decided something. So we had people going out of the meeting saying, okay, we need to discuss this next time. And some people saying, okay, this was a good meeting. And so, total mess. This leads to someone which is more problematic, which is silent disapproval, which is terrible actually, because at some point people are so bored with the meetings, they just stop talking because, yeah, they don't trust the process anymore. And, yeah, they say, okay, let them talk and we'll do what we want afterwards. And also, you got to realize that at some point, not taking a decision is a decision. And you have people that are very skilled at the idea. If they don't want a decision, they can make sure that no decision will be made. So here comes an open decision from us. So it's not something I came up with. It's developed by Red Hat. It's published on GitHub. So I will give the link at the end. It was published last year, but I guess it's a long process for them to write this. And what we did is just we translated it in French, okay? So which is, by the way, a great way to contribute to open sources. You don't know where to start. Just start translating in your own language. It's a nice idea, easy to start. And so we forked this open decision from us to make our own decision from us. So yeah, I think I need there to be clear that I have no relationship with Red Hat and I'm not, anything I'm gonna say is in a way, of course, related to their vision of it. It's my vision of it. It's how we use it, of course. So let's start by definition. What is an open decision? Well, for another audience, I would spend more time on this, but yeah, if you're here, you already know what are the open source principle, transparency, inclusive, use a soundtrack. Yeah, just keep this in mind along the decision process. So what is it? It's just four steps, actually. Well, when I saw that, my first thought was, this is very poor. This is just, it's too easy. I mean, it looks too simple. But when we 12th edited, we found that there were principles and little ideas in every steps that are really, really helpful and powerful, actually. So first step, concept, define, plan, ideate. Just start with asking a few questions. What's the problem? What the problem is? How we will make a decision? Do we need to vote on this? Do we need, I don't know, some kind of a simple agreement or anything? Do we need lawyers to review the decision, et cetera, et cetera? Fine, who's likely to disagree? Who's likely to reject this decision from the start? And people that's likely to opt out, you know? You already know when you start tackling a problem that there are people that maybe don't want you to go there. Maybe people that have already tried to do this. So this is basically build a clear roadmap for your process. The first one is a tricky one because I find it incredibly difficult to state the problem within one or two sentences. Actually, it's very complicated. And, yeah, it can be revealing. And so, yeah, you got potential frameworks along the way, so these first steps is here to avoid these frameworks afterwards, okay? So communication channels where we will discuss, will we be public or not? Is it on IRC, is it on, I don't know, mailing list or is it on a forum? Do we need to do video calls or not? I don't know, will be the video calls recorded or not? And, of course, deadlines because some people, when they have a problem, they want you to fix it right away. Some people want to, you know, calm down with the things a little bit. So, yeah, be very clear from the start or how you want to go. Phase two, sorry. So, again, questions. Let's go back then. Let's see who already tried to solve this, what they tried, what they did. Let's look at, maybe there's another problem beyond this problem. It's a very common scheme. And, yeah, you get your feedback. You go to people and try to understand what is a problem. And, again, you try to identify all the different kinds of people that are involved in this problem. This is clearly the most difficult part because, and this is common but especially in tech people and open source people, they have a tendency to rush to the solution, to rush through the tools, to say, okay, let's just use this tool. It's perfect and everything. For instance, if I ask this question about a project of mine and I say, okay, I have problem managing my bug, my bug submissions. Yeah, lots of people will go and ask me, I say, okay, just use GitHub issues or GitHub or whatever ticket system there is. But that's not exactly what I'm my question. And you need to take your time and embrace complexity. I really liked the presentation before because it was about that. There's this principle in open source which says, keep in simple. But the solution must be simple. But you must not have a simple view on reality. Reality is complex. Humanity complex, human are not binary machines. So do not be afraid of complexity. And of course, maintain a safe environment so let people talk and don't judge them for what they have to say. And of course, take your time to explore the problem. Just don't rush to the solution, take your time, explore all the problem and all the complexity of it. Okay, design test developed. So yeah, just now you have put the problem in place. Just imagine, what if we had unlimited access to any kind of money? What if we were like 10 years ago? What if, I don't know, what if we start from scratch? Et cetera, et cetera. A lot of these ideas, you're gonna throw them away. But in the process of this, you will find some other ideas on other. And also again, identify people that will be early adopters and people that will give you feedbacks on your prototypes. So this is the fun part because you try to build a prototype, whatever that means. You're gonna search for alternative. You're gonna do some testing, et cetera, et cetera. And in the end, you simplify and reduce the obscurant. And also, prepare an escape plan because you might fail. So that's at this point, you might also want to just say what if it fails? It's interesting to think about this ahead of time. And in the end, launch deploy closed. So pretty much like a development process when you're putting your code in production. Just like that. You will ask your question about, well, did we answer the initial question? So a lot of time, we realize that we have maybe spent four hours of meetings and at the end, we found a great solution, but it's not the solution for the question. And it's really, really common. How do we monitor the impact of our decision? How do we know if our decision will fail or be a success? How do we make revision based on feedback? So our decision will have an impact on people. So we will receive feedback and what will we do with this? What will we leave to the future generation? We have found some things. So maybe later other people can use what we've done here and also what have we learned. And yes, just take a rendezvous for, I don't know, six months, one hour later, sit back again and just look back to what we have done. So again, very simple things, but be proud, it's difficult to take a decision. It's very difficult, especially in a decentralized environment where a lot of people have strong opinions. It's very difficult to cut it and come up with something. So tell the story. I have experienced that when you take a very difficult decision, people will accept it more if you explain that you have spent hours and hours of meetings, if you have spent lots of prototypes and everything. If people can understand how much you have worked to get this decision, they will accept it even if that's not their solution that has been chosen. And contribute us, which means, yeah, maybe again, you may have learned some things along the way. So push that back to other people and stay engaged with people, reject the decision. Again, you can't make everyone happy, but don't act like you have won and other people have lost, because in the end, maybe they were right, maybe you were wrong, maybe you took the wrong decision and maybe in six months, when you realize you failed, you will be happy to come back at them and say, okay, we had this idea, it failed, you were right, can you help us fix it? And if you act like you have won and they have lost, they will probably laugh at you, say, I told you so, and yeah, watch the end. If you stay engaged with them, saying, okay, I know you have this issue, I know you have this critic, we are monitoring it, we are following on it, yeah, it helps. So in practice, we use this framework for one year now, we used it in six different work groups, especially for marketing decision, which is hard because under 30 people in the company, we have like, I said 20 database guys, so not people already accustomed to marketing. And it steps to, yeah, like from one to four hours, each group was very small, and some people didn't like the framework, it found it was a bit messy, and others really liked it, and especially for newcomers in the company, it was really, really easier to get involved because there is a clear path, you know where you're going, you know when you can contribute. So yeah, it worked, we solved a particular problem that was bothering everyone for the last five years, really something, you know, big problems that we won't know about it, nobody knows what to do about it, we'll stop that. And we found the compromise, in another situation, we had two very opposite groups who say, we want A, and the other group say, we want B, and so kind of stuck in some clueless opposition, and we found some compromise, and it really worked well. And of course, it failed, and on some other decision we made, because it's not magic, but the idea is that they failed fast, and I wouldn't stress enough the importance of failing fast, yeah. You need to fail fast, learn, and go back at it. And so, instead of getting stuck on decision you can do, we did something, and we learned by failing, and we tried other things. So yeah, so I'm not telling you to do what we do, what we did, I'm just telling you to do your own decision framework in your community or in your company. So obviously Red Hat has done it, published it on GitHub. You have GitHub that has a great book that I would recommend, and they have a page on leadership too, and also Valve, the game computing company, which has a very interesting concept called Cabal. I don't have time to talk about this, but all three links are really, very worth it. And yeah, Acup company. I'm really interested in being, I spent 10 years being at the same time the director of the company, and at the same time the community members, and I'm very interested of what Open Source principle can do for corporate management, because the actual state of corporate management is garbage to be polite. I go in a lot of clients that I want name of course, but yeah, most of the corporate management practices I see are just mostly new men, and just disrespectful for people. So we have a common ground of Open Source principle that we can use to put inside our own companies. So obviously a company is not an open source project, but yeah, we can use a lot of this in our daily jobs. And that's it, and everyone is happy. Thank you. So this is- Can you do half of the minutes for questions? Great. That's okay, yeah. Now by the way, this is a bit new for me. I do most database talks. So if you can take a few times to give me feedback on what I did, it would be great. You should consider that there are alternatives. So I understand that why that's necessary. I mean, why do you have, you know, developing clients that are getting there? You shouldn't stop looking left and right, but doesn't that kind of reopen the gray area of the whole decision kind of? Yeah, the question is, if I understand, is that on step three, when you search for alternative, you can reopen questions that you have should have closed in the previous steps. Yeah, this is a common mistake. Obviously, this is, if I would say, if you did your jobs on this part, on the complexity, it doesn't really happen because we all, the problem has been clearly stated. So yeah, you, again, this is a very important part of it, let complexity be. And I'd say it's a risk, but yeah, you need to prepare for that before I think. If, so, but it's not, it's okay, you can go back. I mean, it's not like you failed your own process if you want to go back. I mean, you can realize that, okay, we missed that part of the problem that we did not explore. Looking at this solution showed us that, yeah, we must go back. It's okay to go back. Yeah, well. Okay, but first, first we translated in French. So as long as you translate it, it's not exactly the same. And then we kind of, we have our own handbook. So we change the format and we simplify the content so that it can be included in our handbook, which fully should be open source in a few months. We have a decision on this too. So yeah, mostly adapting things. And yeah, some things on phase one, phase two, there are some items we move from one phase two on another, but really it's not that big deal. We're pretty much stick to the thing. Yeah. I think you had the consensus, isn't there? Well, not a consensus. That's important too. Yes, that was my question. Because sometimes if you find a consensus, then it happens that both groups are really happy because they both have to concede at key points. Yeah. Sorry. Yeah, that was that one. Yeah, we don't, consensus doesn't scale. So we don't try to reach consensus at all costs. What we want is to recognize that some people are against this decision and acknowledge that and being able to go back at them if we need. But instead of everybody is okay with the decision, what we want is everybody can live with it. It's not the same thing. You can say, okay, I'm not okay at all with what you're doing, but I can live with it. It's not against my principle. It's just a bad idea, but I will continue to say it's a bad idea, but I can live with it. It's very different from consensus. Yeah. So the question is, did we, it's similar to project management and did we use it for project management? Not really. We don't do project management the way people would think we are because we're not a really project-based company. We're not a developing company. We're much a support company, consulting company, training company. So there's not that much of projects inside the company, but we did use it here for big projects, bigger decision that can be, I mean, looked at from outside like projects. Yeah. Yeah, everything starts with a problem and someone able to state the problem clearly. Which is not simple. So a lot of, yeah, a lot of people are very, sometimes are very unhappy with the situation and there are very, there are a lot of problems to express the real problematic behind it. So this is where phase two is important to give them confidence, let them talk and let them give them the time to explain what is their problem behind the simple expression of unhappiness. Sorry. Thanks a lot, thanks a lot.