 picture. So this is Drupalcon Prague last time and I actually took that picture so that's why I'm not in it. And it's actually funny as a photographer it's quite hard to find a picture of yourself but I'm actually lucky to have a picture of three taking a picture of me. So that was also in Drupalcon Prague and for anybody that and who for the people that have been there they might remember Drupalcon the pre-note which was pretty epic if you ever have time go on YouTube and search for Drupalcon Prague there was a whole opera before the keynote and because we have some awesome musicians and singers in the community and for me though actually Drupalcon Prague is a bit special 2013 Drupalcon Prague because that's where I met my wife the second time and since then we have been together at many Drupalcons and yeah we live together now in the US. So a bit about me before we start my name is Michael or people in the community call me Schnitzel that's pretty much the name that is more common. I'm a longtime contributor to Drupal as you see and I've been here quite some time since Drupalcon Prague and earlier before. I'm a little bit an open source maximalist as you will hear today and yeah I'm founder and CTO of Amazio hosting company. So today I want to talk about open source and specifically a little bit in a different context than you usually probably think about open source and the first thing I want to do is actually dissect this. So we have open source we use it all the together but for me there's two actual words in there so there's open and there's source open source. So let's look at the open. I asked a couple of people what does open of open source mean for you and people told me like well it's verifiable I can check I can make sure that the things that people say are actually happening and that generates trust because I can trust in the code nobody can change the code just randomly and I can do this so that means also the people that say what they're doing they're accountable against that code and so all in all this creates safety I feel safe in an open source environment because I can verify I can check the code. Now this actually looked like what open isn't well of course it's closed. So I asked people what does it mean if it would be called closed source and people told me like oh it's unclear there's a lot of uncertainty in a closed source environment up to fear because I don't know what's actually going to happen with that code and of course a lot of concerns. So if you put them together I'm asking you what do you think people rather have? Do they rather have safety, accountability, trust and variability or do they rather have fear, uncertainty, unclear and concerns? Now I guess it's pretty obvious what people want more. People want the left side more. People want the openness. So I feel open is good for people. Now let's look actually what are people. What are they? Well people are our friends. They are communities where we live but most important people are also companies. We spend a lot of time in these companies. So if open is good for people open is also good for companies. Now let's look at the other side of it. So we have open we know that what this is now. Let's look at the source part. So what is source? Now source can be a lot of different things. Of course source can actually be code but it can also be information. It can be processes. It can be structure. So if we look at all these three things, informances, processes structures, well all of that exists in companies. So if you look at open source and open means good and companies mean source, open companies means good companies. And so that's what I want to talk about today. I want to talk about how our company tries to use as many things from the open source world that we all like, that we all love inside a company. And this might sound strange but I'll give you exact things that we're doing, that we're trying to see if this actually works. So the first thing we have is a handbook. Now many companies have handbooks that you find things. What we try to do, and there's other companies that try to do this as well, specifically I want to give a shout out to GitLab which does this very very well. So like theirs our handbook is public for anyone. You can go today to Handbook Amazio and you will find our handbook that we use internally for telling people how we work. It's also writable by everybody. And I not only mean Amazio people, you could literally send us a pull request to our handbook. And it defines everything. Now we're not there yet and we're slowly getting there but the idea is that you have a handbook that defines everything that happens within the company. Every process, every structure, everything. And so for example what can you find in there today? You can find our post-mortem process. It clearly defines how we write a post-mortem, there's a boilerplate, things like that. You can also find the health and well-being budget from all our employees. So we give everybody a health budget. They can decide and depending on which country or currency use it's on there. It's publicly for everybody to see. And you can also find things like up-leveling. Like this is the page of the security engineer and it clearly defines how do you become a security engineer within Amazio. Like what is required? And that's interesting for people outside the company that join us but it's also interesting for people that are within the company that want to become that. So there's a clear role or a clear structure how to become that. Like we do in open source. Is there anything we can do against the flickering? So no. All right. Next one is change management. Companies have a lot of change and a lot of things. So for us, change management is all about every change needs to be trackable. So everybody needs to know when something happened. Also every change needs to be reproducible. Meaning you don't only know when something changed and what changed, you also want to know why it changed. And the next thing is it also needs to be communicated. You cannot just change something and don't tell anybody. So what we do, well, first of all, we have the handbook. The handbook is in a Git repository. So any change on the handbook can be seen by everybody at the same time when you actually merge it in and change it. But we also have like a Slack channel that is team changes and in there anybody writes in there something that changed in the company. People coming, leaving, people moving up, processes changing. So anybody can just write in there and saying, hey, this changed and people can follow up as questions or things like that. And this allows, if you leave for a week or two for a vacation, you can come back and you can just read through it. You can just see what has changed since I was there the last time. And that really helps people understand just what is going on. Because there's a lot, as our company is 24-7, like we literally have people online any time of the day, there's a lot of changes, there's a lot of stuff going on. And you want to make sure, like in a Git repository with an open source community, that you can see what actually has changed since I was there the last time. Because I can tell you, things can change in 24 hours really fast. The next thing we do, we have so-called work streams. Now, what does this mean? For us, work streams, we separate the team, our whole team into separate work streams. And each of them needs to be clearly defined. So it needs to be a clear purpose for each work stream. They need to be independent, meaning each work stream has a specific part of the company that they can decide themselves that they are responsible for. And also, each work stream has a clear leadership. So each work stream has a lead that is responsible for that work stream with their team inside. So as a hosting company, we right now have 10 work streams. So there's a BizOps team, which does all kind of finance things. There's a client services team, which handles the clients, making sure that the clients are happy. We have a TAM team or a technical account management team, which handles all kind of technical things with the customers. We have a support team. We have an internal IT team. As we have an open source project, we have a lagoon team. We have a platform team that runs all the platform, sales, security, marketing. So, and everybody is assigned to one of these work streams. And like I said before, every of these work streams need to be defined. Meaning, there is on our handbook, there is a definition of each work stream with a clear responsibility list. So that work stream is responsible in this case, owns all first level support. That's what they own. That's what they're responsible for. It also says like what they provide and how escalations are going, stuff like that. But also, and actually almost more important, there's also the non-responsibilities on there. Because it's easy to define the responsibilities. But it's actually harder to define what a work stream or a group of people are not responsible for. And so we also write them down. So for example, it says clearly no 24-7 on call. Because there's another team that is responsible for that clearly. And so employees of that work stream or of that team, they can clearly read through this and they can understand, okay, what am I responsible for? What am I as a team responsible for? And so you can also show this. So we do this for every single work stream for every single team. And in the end, it's going to end up like this. So these are all the work streams and the dependencies on each other. Because let's say the finance team has a dependency on the client services team to make sure if there are questions about invoices to be answered or things like that. So we define all of them, they're structured. And you also see dependencies to the outside. So the white, the black squares with the white background, these are external companies, external team members, because we of course, not only work with us, but we also we've worked with a lot of other people. So it also defines how others are interacting with us as a company. And then of course in the middle, you have all amazing IEA work streams that define how we do things there. So we basically have these work streams and everybody is assigned. Now, beside of that, we also have so called circles. Now circles are things that are cross work stream. Because sometimes you need to do things across different work streams. These circles can be started by anyone. So anyone in the company can come up with an idea for a circle. And each circle needs a clear goal. That's super important, because you cannot just start something and nobody knows what it is. So you want to have a clear goal that defines what this circle is actually about. And so we have three types of circles. We have delegated circles, which means from every work stream, somebody needs to be in there. We have, for example, a product circle. If we want to release or change a product that we offer, this changes a lot of things in every single work stream. So in this product circle, every work stream has to send somebody to this circle to decide about changes in all of the company. There's a couple of special circles as well. There's like a board and the management. They're technically also circles. And then the end, there is an initiative circle and the initiative circles are the ones where anybody can come up and saying, I have an idea, or I want to do something. And then anybody can join like there's no requirement to join and stuff like that. So these are our current initiative circles. And they are documented. Each of them has a goal or has a short description and see things from like, we want to improve our handbook to we want to figure out a go to market strategy. And we define all our SKUs, we have the DEY, CDN competitor analyzers, and we're looking at future payment systems as well. So these are all things that people came up with and said, Hey, I'm interested in doing this. They can meet, they have a select channel, people can talk about this, they have a goal. And they're just talking about this and maybe out of this comes actually a change, or they have an idea, and they want to change something within the company. Now for that, we need some kind of decision making process. Now, how do you change something to ensure that everybody is happy with it? Now, the easiest, of course, that people say is like, Oh, we'll just get consensus. The problem is with consensus and consensus means that everybody agrees, like everybody has to 100% agree with that change. Now, have you ever had a decision where 100% of the people decide agreed? Not even by yourself sometimes, like you don't even agree with yourself. So that's not possible. But we still want to find a way to make changes in a way that people can raise concerns that they can say, I'm okay with this. And that's where consent comes in. So consent means it's something that people are okay with. Doesn't mean they 100% agree, but they are okay with. And we do this, we track this with consent. So consent is something where I can say, I have concerns, but I'm okay with moving forward, while an objection is something where you say, hey, I object, we cannot go forward. And the question in the end, we ask, if we propose a change, it's not the question, do you agree? Because like I said, that would be consensus. Instead, we ask, is this good enough for now, and is it safe enough to try? That's the question. So is it something that you feel as an employee or as a lead or as a team member, is it something that you feel it's safe to try? And the really important thing is trying there. Because we don't know if tomorrow something changed. We don't know if a year changes. But is it right now, do you feel it is safe and good to try? We don't know if it's safe to try this all out. Now we try to do this process in all types of decisions. Some of them take really long. So we had, we launched a new product, a completely new product that we didn't have before, Laguna as a service. It impacted every single work stream, it impacted the marketing, the sales, the platform, the market. And this took really long. So we went from the different circles, the product circle first agreed, and we felt, no, we actually want every single employee to also say, this is good enough for now, safe to try. And so this means you will actually have like Google spreadsheet where you track, for example, objections. So we presented this to the team. And then, for example, the product circle, you can see they brought up an objection and said, I have a question, I have an objection. So they said, like, the third one said, hey, we are very stretched on the support team. How can we make sure that this does not overload the support team? And then the team discussed about this. We came up with an idea, we presented it again, and then they resolved it. The last one actually was one of our employees that brought up last minute an objection. And interestingly, we actually changed the name of the product last minute because we realized it didn't make completely sense. So that was like at the very end, we presented it to every employee and we said, every employee, does anybody have an objection or is this good enough for now, safe enough to try? And he stood up and said, no, sorry, I have an objection. So we talked about this. And in the end, the decision or the product we did at the end was actually better. Like everybody agreed that this was a really good objection and people never thought about this. And so, yeah, this can take nine months, it can go multiple day, discussions, meetings, and stuff like that. But of course, it can also go pretty fast. Like within the work streams, the teams use the same process as well. So this is an example of the platform work stream. Basti, he's the platform lead. It's a bit of context, like we use phone duty and page duty has a new system. Like we just want to change a tool to use something else. And all he did, he wrote the Slack message. This is the Slack channel of the work stream of the platform because it only affects the platform work stream. They decide. So he writes a Slack message, defines what it is. And at the bottom, you see a short like if you say, check, that's good enough for now. The hand up is, okay, I have some concerns. And the red dot means I have objections. And people go in and you can actually see a hand up there. So somebody said, hey, I have some concerns. It was discussed in a thread shortly. And then the person that raised the concern said, okay, that was enough information. I'm now good. And so it's released. So everybody of that team goes in it and says, check, check, check. And when this is the case, it is decided. And then the work stream goes and writes it in the team changes and says, hey, the work stream platform work stream decided to do that change. And this is what it is. We don't have to ask the other ones because it doesn't affect them directly. But we want to tell them that we have a new tool now or the platform team uses a new tool. And this takes like 24 hours. Like I said, we're a 24-hour team. So usually decisions take minimum 24 hours. But that's just a simple decision. But if anybody asks in the future, why did we cite this? Like why did why, why do we suddenly use page duty instead of phone duty? You can go back. You can link to that. You can see all the concerns. And you can be almost like you were there at the decision. So that really, really helps in deciding. Now, it's a bit of a process. I'm not saying that we're perfect there. But it's really something that takes a lot of that helps a lot in deciding coming up with decisions. So the last thing I want to talk about is making mistakes. Now, none of this we just done in one day. Like this is a process. And I would say our 3D printers still sometimes printing the wrong thing. So it's really something that takes a lot of time. And it's quite a process. But overall, I really wonder, like we have so many good things in open source, so many things that happen in communities that work really, really well. Why not try to use them also within our companies? And you don't have to implement all of them. But maybe think about what do you really like about one specific thing in an open source community. And maybe you can implement them with a team. And you can start small. You can start with a couple of people. Like it doesn't have to change everything at once. And who knows, maybe in the future we're going to have different things. So before we go into Q&A, people that have seen me presenting, they have seen that slide before, I really like that one. So Henry Ford said, when everything seems to be going against you, remember that the airplane takes off against the wind. Not with it. So some resistance sometimes is actually a good thing. Because it gets you thinking. So if you go back to the last thing we said before, when that person, when that employee brought up the objection last minute, it felt like, okay, why do you, really? And then we went through it, we talked about it, and out of it came something much better, that we are way more proud of what was there before. So yes, resistance in the beginning might feel hard. It might feel like something that is, okay, do I really have to work with this now? Or do I really have to do this? But I believe, like the airplane, you need a little resistance to actually take off. So.