 Cool. Okay. Hello, everybody. Welcome. I hope this is me, who you're looking for, and I hope you're going to have some time. A really good one. In reality, it feels a little bit anti-climax after two days of amazing speakers, mind-blowing keynotes, plenty of learning, to actually take you on another ride when you've been going up and up on this huge roller coaster, and you kind of expect this, and I'm just a little bit worried that you're going to get that. But let's see how it goes. I want to continue on the topic of failing leadership, ownership, blaming games. So let me start with this. In 2007, I finished university. I was a software engineer, and I had the dream to change the world one line of code at a time. So I decided to move to London and become a Ruby on Rails developer. Ages ago, this is how this stack of books looked like, and there was a really good joke about how Ruby on Rails was a really cool technology. So I moved to a company that was doing some really cool stuff, and I was a junior developer there. You should have seen me on the first day at work. The spring and the step. You get by underground to the place called London Bridge. You see Tower Bridge. It's just mind-blowing. It's just great. The funny part was, I didn't have a clue what I was doing, but London is a great place. It's a place full of opportunities, and whatever you want to do in London, there will be a way to figure it out and to actually do it. And the worst thing you can do in London is, as a developer, there's just way too many projects to do that you can handle. So what I thought was, why don't I not only not know what I do in this startup, but also help another one? So I started working on another project in my free time. It was like this kind of a concept of a side hustle, money was flowing in. And the interesting part happens is I was very, very, very, very inexperienced, and I didn't really know what I was doing. But what I did was, I worked 9 to 5, probably in the hours there will be 7 to 7 on my first project. I was in the office. I was working. I was coding. And 5 to 5, I would just basically pick up my laptop and start working on the other one. And somehow, this information about the way I was working got passed to my CEO at that time. So as you can imagine, the next day in London, it never looks like this. This is just a lie. It always rains over there, so enjoy the weather. I got invited for a chat with my CEO. And I'm a nice guy. Don't get me wrong. But I've never been shouted dead loud at me in my life. Like no one has ever did to me what this guy did. And Felix was a very awesome, very honest, very transparent kind of a guy. He would always share with us the good stuff and the bad stuff. When I got invited to his room, I didn't know what it was about. But that was one of the biggest runs I've ever seen. And if you've seen a rant on the internet, you can just play press pause. When you were in the room with him, there was no pause button. It just went on. The whole building knew we were, it wasn't a conversation. It was like far away from having a conversation. Everybody thought I would just get fired on the spot. The interesting thing was that my CEO in a nice and very polite way explained to me what was at stake. He kind of told me that the startup that we were working on, he put all of his money into it. And most of the employees put their savings into it. They remortgaged their houses to make it happen. Each of them quit their well-paid jobs to do and live their dream of building what we were building. And he just couldn't grasp how I could finish eight hours of work and then do something else. He just couldn't. And he just went mad. It was awesome. Everybody thought that I would just get fired without even leaving the building. Lucky for me, I didn't. I don't know how and to that day we are friends with Felix and he doesn't know either. I think in the passionate moment that he was describing to me what was really going on, he just forgot to say at the end, you're fired. Okay. But I kind of realized, and in retrospect, it's kind of quite easy to recognize that. At that day, I probably didn't say much, but I kind of realized that there was plenty of lessons to be learned from this moment of my total ignorance and the lack of understanding what was going on around me. Yes, I was a junior developer. Yes, this was probably my first real job. Yes, I wanted the dream to happen, but there was plenty of lessons learned. And what I did was I decided that from that moment I will never work for people who doesn't shout like that, which means I want to work for people who have passion. And this passion can be represented in a different way. In his way, it was like this. In other people's ways, there are different ways, but I want the passionate part. I don't work with people or for people who don't have that part. I realized that I don't want to work for people who doesn't have the purpose. There was lots of conversations here about the purpose before. When I go now for a job interviewer, when I speak with anybody who wants to build something or who wants to join our company, and I ask him, hey, you're offering me a job. Why you do what you do? And if they don't have a great answer about why they do what they do, not what they do, not how they do it. If they don't have the answer, I'm out. I don't want to work for companies that doesn't have a why. They don't have a purpose. The way I do it with recruiters, if you want a piece of advice, I say, do you know TED conference? Who knows TED conference? It's great. It's like the best speakers in the world speak over there. And I'm saying to them, look, if you want to hire me, I want to work for an organization which will allow me to speak at TED conference. What it means for me is, first there is Bill Gates and he says, hey guys, I cured malaria. And the presenter says, and now here is Paweł Kaminski, saying that. Whatever is that, I want to work for that company that gets me on this stage. If you cannot do that, I'm not interested. Our lives are way too short and way too important to work for companies that don't do that. And the interesting thing I've learned in this moment of madness is that we all failed to communicate and we've got this illusion that, oh, I've told you that. I thought you understand what I meant when I said it's serious. Like, I've learned that the communication plays a huge part, no matter how many lines of Ruby and Rails code I can write. So those were the lessons from my first failure in real-world. There was one more. I decided to stay in that world, which means I never really worked for any company bigger than X. I don't want to do huge agile implementations. I don't want to do digital transformations for hundreds of thousands of people. I love what I do and I'm really enjoying this start-up journey. And I've been doing this for 10 years now, yeah, failing and succeeding from time to time, but really, really having fun. I was trying to change the world. I was trying to build the Internet for Kids, which was the only secure place where they could actually go and don't feel threatened by predators and don't feel threatened by the content they were supposed to read. I went to beg or pitch the investors for $10 million with a nice face, decent story, zero MVP, zero users, just like a nice vague idea what it should be. That didn't work that well. I got now plenty of bruises of what to do right and what to do wrong. And I worked for the companies that didn't have the money at all. And then the only thing that drove us was passion sleeping back under the desk and actually eating plenty of kebabs, which is just not recommended version of what you should be doing with your life. But it's still a great journey. So four years ago, I kind of had this conversation about a new venture and about new possibility where we wanted to create, share our experiences and what we do with people who are non-technical founders, and they've got this big dream, big gut feeling of, I want to do this, I want to build my own company. So we thought, okay, why don't we who went through all of those pains try to help you out? And we did. We started Ucreate, which the initial purpose was we want to help founders who are non-technical, who doesn't have a clue about agile software development, product, lean, validation, all of those keywords that just means nothing to them. But they just get this gut feeling that there is something that they have to do in their lives and in the lives of other people who are around to make a difference. So we got our first customer. It was a company that was trying to change the way we buy and sell properties in UK. If you know how it works in UK, it's like you kind of say you want to buy a house and then for three months you've got zero information and your lawyer does some magic in the background and after three months you get, ta-da, you have a house, or sorry, you don't have a house, which is just a relatively poor user experience of the whole process. So the founder wanted to change that. He wanted to bring the transparency to the whole process. And we actually built the whole system of doing this with a beautifully looking mobile app to deliver this new experience to the users. We released on 5th of October, which was my birthday. I was very proud and very happy about this. And as you can imagine, it didn't went well, but I've learned another lesson. There is no amount of bugs or issues that you cannot sort out with unlimited amount of pizza and a free day for the team that you're working on. Just try. Just give them pizza and let them go. We were okay the next day and we kind of started working. The founder was very happy. We were starting to get the customers. We were putting multiple million pounds property transactions for the platform. It was going quite cool. A few weeks later, in just a little bit of context, Ucreate has got a development part in Chandigarh. So I, at that moment, PM, CTO, coffee maker, fruit buyer, anything you have to do in the startup world, kind of a person, was getting up at 5 o'clock in the morning, working myself with coffee straight to my veins because drinking it was way too slow. Started working with India team. And because I was a big fan of Agile Kanban, you name it, we were kind of deploying every single day at 5.30 in the morning to pre-production environment. And then during the whole day, we were just coding and working together kind of remotely. They in Chandigarh, I was here. And you know those days when your kind of alarm clock rings just before it's supposed to really start. So the first message was from my CEO and it was like, hey Pavel, you know, the production database is kind of a gone. So then you kind of lie down in your bed and you consider, do I really need this? I don't need that. What should I do? Should I go back to bed? But I realized that over the years of experience, I had now a great opportunity to do certain things right. But my first idea in my head was, I don't know how many fans of Game of Thrones, I really like that quote, just cutting off heads doesn't really make people work well together, but that was my first thought. So we moved on from that. I had a quick chat with my India team. They explained me what happened. And the funny thing, like this is just how interesting we were ages ago, do you know like Word documents? They've got like pages. So there was a sequel query, an update, where the first part of an update sequel query was on page one, but the where clause was on the second page. And the developer copied the first part for getting about the where clause. Yeah, that's kind of embarrassing, but moving on. So yeah, that was happened. So all of the relationships in the database were gone. We didn't delete it. That would be better. But yeah, we had just wrong IDs. You get the gist of it. Like it all went wrong. The guy who run this, he was kind of already packing. He was ready for it. Like I think that most of my team at that point understood that I don't remember if I have seen them before that or not, like in person, but they thought like, there is a CTO in London. He's just gonna destroy this whole thing. You are fired, you are fired, everybody is fired. This is how they used to be working with their leaders being carrot and stick kind of an approach. Let's have a go. So the guy was like honestly packing. I think he was updating his LinkedIn profile saying, I'm available for hire. So what we did, I had a quick conversation with them. We realized what happened. Then I called my CEO, Matt, who is the founder of the business. And I said, look, we have to call the other CEO. So now you can imagine it's 5.45 before six o'clock. And we called the startup founder that we are working for. And we are just like, hey, Simon, this is great. But yeah, great to wake you up, but you don't really have a business at this moment. By nine o'clock UK time, you might have it. But today it's tricky. So I think he was still half asleep. So the conversation went okay, if you can say it like that. And we went back to work. Actually, it was quite surprising because it turns out that we had the backups. We recreated everything. It was okay. And by nine o'clock, like nothing happened. But of course, everything happened. And we had another great opportunity to learn from this failure of what happened. The crucial question, which I was asking myself and at that moment I couldn't really articulate it well, was who is to blame? So the obvious answer was, wow, the guy who put the query in. And as a good agile team, what we did, we retrospect. And I put a little bit of fire under the team to make them speak because when you call an India team, it's usually this or nobody says anything. It's great when you don't want anything back, but it's just terrible when you're really trying to learn and trying to adjust. So the team blamed everybody. It was a beautiful kind of example of how the blame game operates. Like no one was safe, but of course everybody focused on the developer because he was the obvious choice to be fired first. So what else we found? We found multiple reasons and multiple people really responsible for SAP. We learned that our developers have got ego and sometimes they do things straight away on production, which was a nice surprise. We learned that our poor documentation using Word documents is really, really poor. We realized that we've got poor requirements. We didn't talk to each other. We didn't have the concept of chaos monkey or any kind of a real disaster recovery processes. Look, we were a startup of base rather than months or years. We were having bigger problems than that. And we were still running an operation which we probably put to shame a lot of modern agile teams. But it was cool. And we were relatively sloppy in the way of our approach. So what did we do? Well, we realized and we were very, very honest about saying that this is a blame game. Even though the culture of the company was saying, hey, we don't blame individuals. We don't want that to run the company in such a way. We want to do it different. We improved certain parts of the process. We automate certain things. We kind of made a few improvements there. Each person who was kind of a felt a little bit of responsible for all of the other things that went wrong took a bit of the ownership. And the ownership parts started to grow within the team. We kind of said it's a Facebook quote, no problem is someone else's problem. It has been here before and we really try to do it that there's just no one person to blame. And we realized that we want leaders in our sense on almost every single level of the organization because the leaders takes the ownership of the problems and everything around them. But the coolest thing was, we promoted the guy who removed the database. We made him the head of DevOps for amazing reason. From that moment, he was the most diligent developer I've ever seen in my life. He just didn't want to be in this position to keep updating his LinkedIn and packing every single day. So he becomes our temporary head of DevOps. So you can imagine his situation. He comes in with a great ego as a senior developer. He removes the database. We call his CTO and say, hey, I did that. Then he comes back, we retrospect. Everybody blames him and he ends the day as a head of DevOps at our company. That could be a really cool day if you can survive that. And he did. And he kind of did a lot of processes improvements for us. He did a lot of things and he just made sure that this situation never happens again. And he was actually the best person to do it. He cared a lot. But there was still one question. And that question was still in my mind. Even though we behaved properly and our India team realized that we're just not going to fire them, we understand that the errors happens, we understand how the improvement works. There was still the question, who was to blame and what we should do about this? Because the fact that we fixed the issues were just fine. And then we were lucky that the database, we had the backups and so on, and we could recover it. That was just more of a lack than the real challenge. And there can only be one. And funny enough, that was me. For every single thing that happened on that day, there was only one person responsible. And that's the leader of the whole team. However you work and whatever organization you work, if you self-manage yourself, there is a leader who is responsible for absolutely everything. In your world, you own everything. It was all on me. Even though I was not copying the code from Google Doc and putting it on the live PostgreSQL console. It was all on me. So we learned a lot. So leaders must own everything in the world. There is no one else to blame. Don't pass the blame to someone else, especially when you're in the leadership position. And in reality, what you're trying to do, you're trying to make everybody be a leader. What that means is you don't blame everybody, but kind of everybody blames themselves. It's a strange feeling, but it kind of works. Simplify. I cannot tell you how bad there was that we had multiple pages of Google Doc documentation representing our deployment process. Just automate it and just don't care about it. Simplify every single thing that you can, because when things goes wrong and they always do, the only way your team members and yourself will be able to recover is when the reasons of what you're doing and how you're doing are relatively simple. If you've got a complex plan that you have to execute when everything goes wrong, well, good luck. And we took a certain approach that we kind of assumed how the developers worked. When I called them first time after this happens, they were all kind of a shaky. So we kind of say, look, you breathe. You ask someone to bring you a cup of green tea. And then you behave like an engineer. No matter what happens, no matter how many production database are just going totally wrong and how much on fire we are, you do those three things. And the last one is behave like an engineer. You've got the data. You know how to prioritize and execute. You are a smart person. We trust you. There is no one else who should be shouting at you. You behave like an engineer and it will be just fine. That's what we've learned from this situation. How many of you have seen Wolf of Wall Street? So I really believe that we don't really learn that much when the organizations are in a great shape. When your CEO gives your motivation, pep talk once every three months that everything is cool, you don't really learn much about the organization besides the fact that you kind of have got creative accountants who are giving you the right numbers to share with your team. What I strongly believe is that... Do you know this guy, Simon Sinek? So, like, I don't want to say that you should read just one book after this conference, but if you haven't read the book, Starts With Why, that's the only book you should read after this conference. It will change your life and it will change you how you approach your work and your colleagues. So what I'm trying to say is that the companies which are having correct why or correct purpose will always behave properly. And you should always Starts With Why. Don't worry about what you do. Don't worry about how you do Always Starts With Why because it's going to lead you at those moments of crisis that are always happening. You create at this moment have got a really nice why. We work with non-technical founders and we want to help them change the world, and the other one is we want to build the products that people love to use. We don't want to build another CRM. We don't want to build another app doing exactly the same. If the app or the solution that we're building is not loved by the people, we don't want it. That's our why. Well, but that why gets tested a lot, especially when you run out of money. So we are an agency and you've got a typical problem of having more projects versus more people and you constantly have to feed the beast and we grown very, very nicely and we are very happy about it, but from time to time, we are just tight. Let's just be clear about it. And there was one of those moments. Lucky enough, we got another project. And I was looking for this meme with cricket. It's not a sport, but is that too much? Okay, I couldn't find it. I don't know why, but I couldn't find it. So the project was about golf. My CEO loves golf. He plays golf. The PM that volunteered to run this project used to play semi-professionally and still plays twice a week. The founder will go first and golf changed their life. The investors will go first. If you can imagine how their meeting looked like. It's like five of them were sitting in one room and they were like, oh, this is the greatest app ever. This is like Netflix for golf. No, no, no, it's like Uber for golf. No, no, no, it's Amazon for golf. Everything was there. The confirmation bias was just mind-blowingly beautiful. So what do we do? We run our typical validation process. We ask multiple users what they think about the app. Do they love it? We run thousands of Facebook ads to really see if the message validates with any users. We run experiments, safe to fail. We run surveys, usability sessions. We even organize a golf tournament to find out from the real users what they think. Well, it came back disappointing. So there were a few ideas around it. There were certain people that we could do, but the users definitely did not love the idea or did not love the concept or did not love what we wanted to do with them. Well, so you can imagine now the meeting when the PM who loved to play golf he kind of pitched first to our CEO saying, you know what, this money that you think is coming? It's not. If you want to stick to our values and our principles of building the products that people love to use, don't do that. Then if you think my CEO was surprised, you should have seen the founder. He was like, look, I can write you a check now. Like, I want to work with you guys. And we're like, no, not really. Computers is no. We don't really want to work with you. And it's not because you are a bad person. He was actually a nice guy. It's just the idea was not fitting into the criteria of what we could do. And we told him multiple options of how he could pivot, how he could do this online. And I think we saved the world another golf app, probably 250,000 pounds being spent on development, X amount of QA time, and we just moved on. But what really happened is, one, we recognized the confirmation bias. So what we do now, we don't allow the same people to be in the room making the decision about the same thing. If we see that, we just invite a random person who doesn't have a clue about golf. That's a great way. We realized that while the gossip's about this project not being great for us because of our values and because of our why, the whole company is watching. This is the moment when everybody stops and looks from their computer to see what you're going to do. Those are the moments that matter for the company's success and how people feel. If we accepted this project purely for the money, all of the beautiful worlds we've got on the world would just not matter. All of the things we say we are passionate would just not matter. Sometimes you just have to stick to your values and what you really believe in. And what happened now is a consequence all of the people in the organization, when they are in trouble, they go back to those values. What they do, our developers now, will call a founder of a business somewhere in London and say, you know what? This feature that we are building, users are not going to love it. We are not doing it. The founders get furious, but we love it. So that's how you translate your own values into the leaders in your organization so they can use them to their advantage and to do really what you believe in to do. The last thing I want to talk with you is like you don't, as an organization, as a team, you don't have to wait for a production database to go bust or you run out of money to really learn from the failures or from the things that are relatively challenging for you. The one interesting thing which is hugely challenging and hugely failure-driven is one line of code. Every single one line of code, let's see if that works. Works kind of like that. I've just changed one line. That's it. The rest of the bridge went away. The one line of code, if you really think about it, is the representation of the future failure. You know that in six months' time you could write it better. You know that in six months' time it's going to become your technical debt. You know that in six months' time someone will look at it and say, how could you write that? Oh, it was me. Oh, sorry. And in six months' time you will know that you really like to start from scratch, which means your one line of code today is kind of the smallest failure you're already building for the future of your company. There's this famous statement of, the best solutions are built without the software. That's kind of it because of that. So what we thought about is, why don't we use this opportunity of a failure of every single one line of code to do something about it? So we kind of created our own version of the code review, which we call Review E. So what we do, we review every single line of code. Okay? Everyone reviews. Our senior and junior developers, CTOs, everybody who's got the technical knowledge reviews. So the seniors will review juniors, junior will review juniors, juniors will review seniors. Developers love to reject my code and say, CTO, this was rubbish. You can do better, which is fair. We review the code, not the person, which means we teach people how to give feedback. So it's so much easier to say, hey, that's a really bad code or we can improve this code together versus you're a bad person, why did you do that? We learn how to give concise and simple feedback because we don't allow people to write 20 pages document how to explain how to fix it. It has to be concise and simple so that someone can do something about it. And that usually triggers another conversation that developers are having. So we start talking about code much more. We learn to say thanks. When you get your code rejected, you say thanks. It's a funny feeling, but that's what we do because actually that's a great opportunity for all of our developers to learn something from someone else or start a decent conversation about what they do. We explain why, because it's not enough to press a button to reject it. You have to explain why you're rejecting it so every single person starts to think, not only change this to that, they have to be clear about why we are rejecting it. And what happens now is when one line of code that you create is rejected, everything stops. There's no more deploys, there's no more user stories, no one codes. We fix this one line of code first and we do it now. Why we do one line of code? That's a very famous thing. If you are reviewing 10 lines of code, you will find 10 issues. If you are reviewing 500, it's roughly okay. If you are reviewing pull request with 5,000 lines, it's always good. It's always good. Just move on. So that's why we review per line of code. So we have a lot of code that we do to help our developers. As you can see, I'm not even saying that our developers, those guys have become leaders of what they can and do own. So the first thing is, this is CTO rejecting all of the code that this particular person did on their day. There's no problem. There's no fight. 5, 10, 15, 15 minutes left. Awesome. Everything is fine. When you're recording any date, everybody's code. She didn't have a great day or I was in a bad mood. But in reality, she was not angry or sad and she got the feedback how she could improve. Those are a few examples of what is going on now. We now have themes in Poland and in India. That's how they communicate. The messages that India usually surprise me, I really like you notice this thing. It's appreciated and many things. When was the last time your developers said this to another developer? Or when was the last time your developers said, good job, Sandy. No matter what the code is, as you can see, she changed three lines into one. Good job, Sandy. And sometimes it helps us catch stuff that we just don't like. Like commenting out the test-driven development test so that it can just pass. It just, every single commit is there to be reviewed and we can catch all of those things and we can teach the correct behavior. And the funny thing is, everybody sees everything, which means there is no hiding. All of the correct feedback about the positive stuff that we do and all of the bad things we do, it's all public. Nobody is afraid to get there. There is just no other way. And we code on one branch, multiple deploys per day, developers are not allowed to keep any code on the local machine when the day is done. They commit multiple times a day to trunk and we automatically deploy it kind of a close to production. So what they did for us, it creates this concept of no blame and what we call now the extreme ownership. So we don't blame people. We always look at how we can improve the system of work when something wrong happens and we usually blame ourselves for what is happening. That's how we know that the leaders own what they do. That's very, very important for us. We learned that as much as I like talking to you and I hope there is some thinking going on, change the behavior to change the thinking. When we released the first version of it and I said, this is how it's gonna work, everybody said this is just not gonna work. We're not gonna be reviewing every single line of code. This is gonna slow us down. This is gonna kill the company. We are not doing it. This is my screenshot from morning from 10.18 to 11.08. So between those 15 minutes, we had nine improvements done to our code as I was kind of preparing for this presentation. It happens all of the time, 24 hours a day. As soon as the developers comes in, the first thing they do is review code. It's like dramatically change how they think about it. And to be honest, I received 200 to 300 emails per day with all of the improvements that we do. And there's probably more because on every single commit, you've got the right to kind of make multiple comments. So there could be more. But that means that every single day we improve our code 200 or 300 times. We run multiple projects and so on, but that's still a lot. I don't know how many improvements to your code you do. We never do big rewrites. Our review is causing the fact that we constantly keep removing the technical depth as we go. I don't have to review anymore, which is quite nice. The team now protects the tool. When we work with external company, the first thing they do is like, we don't want feature branches. We don't code like you want to code us. You come to us and we do trunk-based development with the review tool. They protect it. So if you think that some of those advice or some of those thoughts about using failure to your advantage within the organization was not good enough. One thing, I know that you have plenty of ideas from this conference and that's awesome. Just be really, really careful about Monday. So your context matters. Remember if you go back to your office and on Monday you say, Paweł told us to do this? Don't. Or we should implement Spotify model? Don't. Spotify did not implement the Spotify model. They just started doing things that worked in their context and it ended up being Spotify model. It might not work in your context. Be very, very aware. But of course your boss is gonna say, I paid for the conference. What do we do? Well, I'm really, really hard to say but it starts with you. If you're a leader, everything is yours. You are blamed or you should take the blame for everything that happens within your organization. And I mean up and down and maybe on the holocracy views left and right. Whatever your ability to see, you should not allow, you're basically speaking blame for absolutely everything that happens in your organization. That's how we see it at this moment. So if your CEO does not explain you the new project well, it's your fault. It's not his. You should go back to him and say, you know what, I might be stupid today but I need more explanation why this is happening. If you don't believe and you don't understand why we are supposed to do this initiative, you will never be able to pitch this to your team. If they don't believe, well you can shut the door straight away. What else you can do? The moment you start taking blame for things that you should be taking the blame as the leader, other people will do the same. Extreme ownership is contagious. As you've seen, there was a comment there when someone just sent a commit and straight away he wrote, I know this is better, I'm fixing it straight away, don't even reject my commit, I will fix it. People starts to take ownership the moment they see you take the ownership. It's contagious. Lead with why. Don't worry about what and how, people will figure it out. You don't have to micromanage great people that you just hired. Just give them the purpose that they have to understand why you want to do what you want them to do. And to a certain extent you have to believe. If you work for the organization that you don't believe where you are going, first ask the people above you to say, I just don't get it, can you tell me? Because in most of the cases there will be a reason why they are doing what they are doing. Most of the CEOs don't want to destroy their companies. There will be a reason why they think this is the right choice. If you don't understand it, it's your fault, not theirs. You should go up and ask the question. Check your ego. Look, when I said it was my fault in the situation when we removed the production database and when I spoke with the founder and I said, it's on me and he was like, oh, but you've got the team in India. No, no, no, it's on me. I made the mistake and this is the plan how we are gonna fix it. Wow, your ego get hurts. I was a nice CTO working on great projects. I could blame everybody there. It hurts you, but you learn, you adjust, you become a better leader for them and everybody around you learns. Keep it simple, stupid, all right? I think it's a kiss. Like the more complex the plan, the more 500 steps of your manual deployment process, the more chances of things going bad and your leaders should communicate simply. What we do, we ask our founders to call India team and pitch them their idea in a tweet. Now it's easier because they've got 280 characters versus in the past they had 140. They have to be able to explain to an India development team what they want to achieve and what's their why in 140 characters. Keep it simple. And every time you want to blame someone, first blame yourself and after that together look at the system of work, what you can do to remove this thing from happening again and what you can do to improve. I don't know how you feel about this. I was listening to this morning presentation and the presentations yesterday. I truly believe that there is certain burden of leadership that only certain people should have. Even though we are trying to build a company that operates with multiple leaders in multiple positions and everybody should take the ownership. I truly believe that certain things should stay within the ownership of the CEO however you want to call it. I don't think so that your developers should be firing other developers no matter how nice you are to each other. I don't think so that a group of people should own ability to press a button and nuke another country. If you're running a US submarine and you say, okay let's vote on this. That's just passing the leadership burden on everybody else who might not have either the information or the ability to do it. There are certain things. I think they should stay with certain leaders but it's still up to discussion and I'm happy to be proven wrong. I would love to see how it works somewhere else. And don't be that guy. That's the CEO of Volkswagen when they went wild with their diesel problem. Hundreds of thousands of cars. Kind of a took back. What he did, he blamed 11 engineers in a random factory in Germany for this. That's not a leader. Don't do that. Don't be him. I don't know what he does now. He probably have a great job. Every single time something goes wrong with your organization try to tell yourself, good, you're still breathing. You're still going on. There is something we can do about it. Every single time there is a bigger or smaller failure that's an opportunity for you. And I want to bring the kind of one of the inspiration for the stock that helped me really realize what we were doing for a relatively long time. There is this Navy SEAL officer. If you watch the Ted presentation he talks about war in Iraq and his Navy SEAL officer who run one of the biggest military operation over there and his principles of leadership and especially extreme ownership are part of the discussion we had today. And I really like him. He's got a great podcast. He talks about cool stuff. And when we are discussing about the bias point of view he potentially has got nothing to do with agile. He's a military commander but it's an interesting to have a different point of view compared to always listening to the same kind of a... I'm not saying bias but kind of at the same point of view. So learn from multiple angles and pick the things that really work for your organization. Funny enough, it starts with why, just read that. It really changed everything. And the guy, Jack Wickling, he also writes the book for kids how to change wimpy kids into warrior kids. It's quite cool. My six-year-old daughter started doing pull-ups after reading the book. She just loved it. She's now eating lots of broccoli because apparently it feeds her engine, whatever that means. Just if you did not enjoy this talk or there's something wrong, I'm the only person to blame just so we're clear. There's no one else if something went not bad, not great. I'm happy to have a conversation about this. Thank you very much. It was a pleasure to see you. We've got one minute, I don't know. Okay, we've got three minutes. Any questions or anything? Pleasure. Thank you very much. Oh, sorry. Please take the mic for me. Sorry. The tool you are using, review. Yeah. Is that built by your tea company or something else? Yeah, so I don't think so. I'm allowed to have the public conversations about our own tools, but it's going live kind of today-ish, so I'm happy to have the conversation after I don't want to be doing pictures here. Thank you very much.