 Hello, Open Source Summit, and this is Federico Luchfredi joining you from Red Hat's Westford office. The stock is designed to last 40 minutes, and I think we have 30. So sit down, strap in, and fasten your seat belt. Here we go. A quick word about me. I had the privilege of spending my entire career in free and open source software, Product Management Director for Saifat Red Hat at present. Previously, you went to server at PM, and if you go back the decade, the systems management Tsare Tsusa. Of course, none of these awesome organizations suffer from any of the issues we're about to discuss. Oh, shameless plug. I have a book on AWS system administration out by the types of O'Reilly. That's why all those clouds there in the picture. And here are a few things that I worked on, collection of different products. That's enough about me. I usually speak about hardware hacking, and the obligatory disclaimer is it will mostly like break some hardware playing with it, and it will come out of your pocket. In this case, the hardware is the organization. People may be involved. Caveat, Ampter, let the buyer beware, proceed with caution and all that. Jokes aside, don't break people. The spirit of a management talk is to take what you like and leave the rest. I don't expect everything we will discuss today to make sense for your org. Woe is you if it does, it would be a scary place to work at. You probably need 10 companies to manifest all the dysfunction we're about to discuss. Our subject today is decision making in the corporate organization. Decision making in the modern corporation is riddled with paradox. The outwardly declared objective of the organization, which is making something, has to contend with all two human realities, ranging from the Peter principle to having too many cooks in the kitchen to the individual's perfectionism in decision or straight-up cowardice. Decisions that are the lifeblood of your project can be deferred, avoided, eroded, derailed in perfectly legitimate and even well-meaning ways. This can spell death or what you were tasked to build. As success depends on implementation as much and more as it does on a good idea. So decisions, I don't know about you, but I don't feel a sense of relief when the organization sends down decisions. And I'm a manager. Should we really be asking for decisions? Decisions are necessary because of how wonderfully unconstrained software is. Until some key decisions are made, you could be building voting via blockchain or a self-driving car with the same team. Well, almost. Unless you're building a category special, a team making a car knows it will have four wheels. And that it will be a roughly a certain number of feet long or meters if you're in Canada. Apparently, someone built a Formula One racer with six wheels in the 70s. But even if you buy the apex of automotive innovation today, a Tesla, Elon Musk will still ship you four wheels. Manufacturers have lots of other hardware, of other hard problems to keep them busy, mind you, like union strikes, supply chains, inventories, shipping delays, flooded mines, trade wars, even train derailments. This is a train derailment in Montana a few years back. 3737 fuselages went straight into the Clark Fort River in transit between Kansas and Washington State where they were due for final assembly. And you thought your problems were big. But the rigidity brings constraints a manufacturer's team can build upon. They do not need to wait for you, or your boss, or your boss's boss, to decide how many wheels do you want to go to market with. At Morpheus taught us, the matrix allows us to make anything real. As long as it is codified by electric sinew knots. There are no constraints. Well, except perhaps time and budget. As Jeff Bezos has famously pointed out, constraints drive innovation. One of the only ways to get out of a tight box is to invent your way out. Constraints are therefore wonderful. They clarify, cut through, and get to the essence of your problem domain. Let's free our minds about decisions. You're not that important. You can get things wrong and still be okay. Things will still be okay. As long as you do not stall the organization and your team is set up to recover quickly. A single contributor can stall a few colleagues by not taking a decision. I can block about 200 people by overthinking and stalling. My boss, more than 300, his boss in turn can block maybe several thousand if he picks the right thing to waffle about. And his boss could conceivably block all 15,000 of us. That's no good. Here is a model to make the technically minded among you comfortable. Early in my career, I worked in the same office as Miguel de Casa for some years, though not on the same team. He was working on Mono. I was working on Sucellinox Enterprise Server and the systems management tool chain to update all of those products. One thing that struck me about Miguel was the speed with which he would take technical decisions, often on the spot in a couple of minutes. And he would defend that speed, allowing dissent, but not what he called stopping force, which would cause delays. Now, I'm sure Miguel would argue that he has five nines in his decision success rate, but to me, his speed was striking, not his accuracy. That got me thinking about the odds. I was not in that team, but my impression was that he was right a lot. So perhaps not always. That got me thinking probabilistically. And I decided that for certain types of decisions, you could be right 70% of the time, and as long as you were fast, you would be a good manager. 90% would make you great, while 50% would make you a coin toss manager. That is one that could be replaced by flipping a coin with your organization better off in the trade. Bezos again has a heuristic to offer here. Having recently said that most decisions should probably be made with somewhere around 70% of the information you wish you had, meaning waiting to have the full picture would make you late. Now, I don't think you should be wrong one time out of four, to be clear. But the thought is liberating. At 75%, you could be wrong once every four decisions and still be a better manager than one making you wait a week for decisions that are 80% accurate. At 90%, you're off one out of 10. Allow yourself to be corrected by others. It is okay, really. I don't think I'm wrong every 10th time I make a choice, but even if I were, my concern would be first to discover if my teams are getting decisions out of me fast enough. Not if I need to move to 95% success rate. Besides, engineers will keep you honest if you're a product manager. If your success rate is too low, you will know. But if you're too slow, they may just let you be. So you need to police speed yourself and let them wake you up if you're getting sloppy. Still with me? One more detail is needed here. There are different classes of decisions, strategic decisions for one. Choosing architecturally between Kubernetes, Swarm, and MISOs three years ago would qualify. If your strategist picked the wrong container orchestrator, now you are busy re-implementing and migrating your customers. Inventing your own cloud infrastructure while everyone else flocks to OpenStack is another such example. These are hefty decisions and make all the difference between building a product for three years or gaining experience for three years that you can now use to rebuild your product with the winning technology. The opportunity cost is huge. It could sink a company. Some decisions are worth pondering for weeks, even months, if you really need to talk to a large number of folks. Now, I don't know you, but momentous decisions of that magnitude are one or maybe two a year for me. The rest are things like, should we monitor this cluster with CollectD or Prometheus? Or should we install with Puppet or Ansible? It is not as dramatic a cost to change implementation tooling as is to replace an architecture when the underlying factors or technology fashion changes. And these, in turn, are huge decisions compared to what you are deciding every week as a middle manager. So you have almost no excuse for not being blistering fast on questions that are almost tantamount to what parking spot shall we use today. In planning terms, you need to move it and let your team catch you if you fall on a fast one. While you don't let them down on the strategic, well thought items, they will rescue you on the day to day. Now, let's go to the patterns or rather to the anti-patterns. Now that we have laid the groundwork for how things are working or failing to work. The first and most destructive anti-pattern of corporate decisions is not taking them. Perhaps the most damaging of all is postponing strategic decisions. So let's start there. This is straight from Seth Godin's blog. Your first mistake was getting on the A53 bus, the one that goes cross-down instead of to where you are going. Mistakes like this happen all the time. The big mistake, though, the one that will cost you is staying on that bus. I know it wasn't easy to get on the bus. I know you got a seat. I know it's getting dark outside. But you are on the wrong bus. And staying on the wrong bus won't make it the right bus. If you really want to get where you set out to go, you're going to have to get off the wrong bus. It does not matter why you got on the bus. It does not matter how much the ticket was. The only way you can fix this is by getting off the bus. I can tell you there is no solution I know of for the wrong bus problem. If you're a VP or a general manager or their boss, the CEO, you can try and depending on you and the organization you have, you may be able to make a strategic change. But if you're lower in the organization like the rest of us here, we can only contribute to an organization that wants strategic input, not force an organization to think strategically. You may have to get off the bus if strategy changes matter to you because you are never touching that steering. This bus always travels along the same path. In other words, someone else is making the strategy. But there are good news here too. You can get people to steer for tactical reasons. We discussed having no constraints as a problem at the tactical level. You can force decisions from the leadership on budgets and schedules using the cone of uncertainty model. This concept was made famous by Steve McConnell, the author of Code Complete. You can get this poster from his company Constructs, which delivers excellent training, by the way. The idea of the cone is to track the remaining variability in the project. This is the right way to convey to senior executives that we need to make up our minds as to what is we are actually building. How many wheels does the car have, as it were? Because we need to know what is outside of the project as much or more than what's in it, especially at the start. The core decisions about business model, target market, feature MVP, are gating the detailed planning and schedule. See how the curve changes and becomes linear. And you can hide very professionally behind this chart until they give you the decision you need. It forces a decision, but it does so politely, implying no decision equals no schedule and no product. But without you ripping your hair in front of them and being less than dignified manager. Now, let me share a personal battle story. Years ago, so probably okay to tell, but let me put it this way. I was working for a Linux distribution and we unplugged the partner and let's just say that their name starts with I and ends with BM. Now, unplugging the partner would be bad enough, but what happened was way worse. We unplugged all their customers. Here's what happened. Of course, I own holiday because that's when things happen. I think I was in Florida. My phone is programmed to sound off for a predefined set of emergency, red alert, email, subject lines. And it goes off repeatedly. I read the messages and my jaw drops. So after I explained to my wife that I'm no longer on holiday for the rest of the day, I did three things. First, I sent an email to my boss, his boss, the VP of product, and his boss's boss, the GM of everything. I put lots of detail in because I'm a detail-oriented kind of person, but the message is, I'm a DEF CON one, you do not need to be. Then I tracked down the four people I needed to solve this mess. My right-hand manager in Prague, fortunately, Europe was still on and awake, the lead manager in Utah, and his manager, who also happened to be in the US. I would like to tell you we met in 15 minutes, but we did not have iPhones and Google Calendar. It was the age of group-wise and Blackberries. It took a little longer to organize. But nonetheless, maybe an hour later, we were all on the phone. These are people who know me well. We worked together for years, and they are visibly nervous. We're bouncing up date requests for a sizable chunk of the user base of a partner delivering 25% of the company's revenue. This is scary. The first thing I say to them is, I assume full responsibility for this incident, do not worry about explanations. Let's just fix it. It was just like lifting a huge weight off their shoulders. You could almost hear them breathe easier. With that out of their heads, they all focused on solving the problem. Nobody's getting blamed for the past. Now, the job is to make sure we're not all blamed for the future, meaning the next few hours. What was previously not thought possible was implemented in follow the sun mode, and the issue was resolved in 24 hours. By 36 hours, support was confirming resolution with fortunately few customers who had realized they could not access their updates. I get a couple of jokes from the GM and everything is back to normal. What happened here? And why did they do this? Now, the first thing here is fear. These are people I worked with for a long time. They can handle some stress, but the situation called for more than handling, far more than that. It called for resolving a problem we previously thought could not be solved. I needed amazing performance on instant schedule. I did not want them distracted and removing fear allowed them to laser focus on the problem only. This is the easy one. There is more going on here. Usually I ask the audience to guess, but in this case, I will just tell you the answer. The answer is that they are my team. Okay, they are my team. I'm going to protect them anyway. So I might as well tell them now so that they can relax. Yes. We accomplished under extreme time pressure and stress something that months before we thought we could not do. Focus helped us do that because folks were on the problem. The politics of the rest of the organization were off the table. So I announced that this buck stops with me. I enable people to focus exclusively on what needs doing next, not on CYA for what has already happened. Now, one word of caution here. Removing worry from the group can be a powerful management technique, but danger will Robinson. Your team will definitely appreciate your behavior, but here is a problem. Multiple problems actually, but let's focus on the bigger one. As your sphere of influence in the organization grows, someone is bound not to like you. It's nothing specific. It's just simple math. Even if you're the nicest person, one out of 500 colleagues will not like you. Who knows why? The meme here is funny, but it is not about people being evil. It's just a law of large numbers. If you have enough influence that you have the son of a snake people dash statistical phenomena to contend with, you cannot leave yourself that open. They may even sabotage you to make your recovery effort fail in the worst case. While in the best scenario, they will just advertise your original failure to the four winds. Thank you. As a marketing manager put it to me over dinner, assuming responsibility like I chose to do in my story does not scale. At the very least, you need to make sure you're taking the heat does not invite trolls to the party and make the problem actually worse. Now fear is an extreme case, but there is really risk aversion everywhere at work. It may be cultural. Oops, sorry, something there with the slides. It may be cultural in a permission driven society. It may for be some form of politely deferring to you out of respect. It does not have to be full on fear, but the mechanism is the same. If people are not sharing their thinking enough, they may not have been asked or trained to speak up. But also, and more likely, they simply do not realize that they are in a safe space to share their ideas. Remove the risk, tell them it is your decision and hint, hint responsibility, but you want to hear everyone's ideas before taking it. You may think of risk aversion as the managing down version of the cone of uncertainty, which is the managing up approach to make people speak up. Now the opposite scenario is too many cooks in the kitchen, zero fear, anyone chimes in on everything. Open discussion is fine, but pointless chatter is really not. At some point you are not adding anything and the cost of communication is way, way far from small as Brook's law teaches us. You want to cut back a little, but you do not want to shut down communication completely, which will be the outcome if you outright tell people not to say anything stupid ever. Now tuning the balance of risk aversion is a powerful mechanism for increasing or reducing communication. I know this developer that five or six years ago during a planning sprint in front of Mark Shutterworth went and chipped in a somewhat crazy idea just to be cute. At least he thought it was a crazy and funny idea. That was his point, I laughed. Mark pretended not to understand this was a joke, made it a core part of his keynote plan for the next OpenStack summit to be delivered in two months, three months. That engineer stopped joking in the wrong meetings, I can assure you. He had to implement and present a demo and he did a darn good job of it too, but I think he also learned something else there. Now, here is why too much communication is just too much. This is from a book from Matt Nicholson when computing got personal. It's like getting 400,000 people to agree what they want to have for lunch. I mean, it's just not going to happen. It's going to be the lowest common denominator. It's going to be hot dogs and beans. So what are you going to do? IBM had created this process and it absolutely made sure that quality would be preserved throughout the process. That you actually were doing what you set out to do and what you thought the customer wanted. At one point, somebody looked at the process to see what it was doing and what was the overhead built into it and found that it would take at least nine months to ship an empty box, Sidener 1996. What I really love about this quote is that someone went out, studied it and put a number on the overhead. I absolutely love the quantifying approach. It is so IBM, nine months to ship an empty box. Now, IBM is not the only company tripping on its own red tape. And here, the focus is on communication overhead. Get 400,000 people to agree. That appears to be too much communication. IBM also gave us Brook's law on the cost of communications two decades before this study was made. Adding people to a late project makes it later. Ultimately, only you can decide how much is right for your product, your team and your audience. But this is your starting point. There is such a thing as too much communication. Now, what about the next anti-pattern? What if the problem is that they cannot be bothered to care? You would think that they would just say yes and send you on your way. But instead of the justifiable fear we faced earlier, here we have cowardice or laziness. Unjustified fear. What happens if someone stamps your project with a yes? They feel somewhat responsible. They aren't really. The people who think this way are 599th in line for the blame. They're so risk averse, nobody will pass them with any responsibility. But these are process focused people. And you need something from them, usually bringing nothing in exchange. The classic example of this is needing something from the IT department. Did you get the PayPal bull approving your request? Oh, you missed the 2021 planning deadline back in 2018. See you next year. Good luck moving at the internet or even DMV speed with these internal functions. What can you do? Now there are three things that you can do. The first one is show respect, not as impolite and proper, which you should be anyway. Here's a story. It's respect for the person's time. One of the Linux Foundation board members and me are selling this product concept to a C level investment board within the company. We addressed the general managers, the CMO and a few others. Next is the head of support. This was a very mysterious stakeholder to us because her role did not really have anything to do with creating a product at this company. None of the other six products created that year required support approval at this level. It was done by her staff, at least two levels down in her organization. Here we had her ear only because of this new C level board organization. So we're perplexed. We do not know her. I do not know the motions that this corporate role expects from us. We could just show up and give her the facts we prepared for the previous executive, but that made no sense to me. So I call my mentor and the head of product. I explain my predictive comment. I need this approval. I am not sure what this executive cares about. I don't know her. I do not know what KPIs, a four removed executive on the support line tracks. I'm basically blind. I don't want to have a meeting to get slapped around and then do it right the second or third time. And after I discover what is that that this executive expects from me. So my mentor gives me a number of items he thinks she will care about. Will we create more incidents than the existing version? Will we need to hire more people in support? Stuff like that. So I schedule a meeting to go over material created for this person specifically. I make it relevant to her concerns. I made the meeting about what she needs from me, not about the approval I need from her. Also that's obviously why I'm there. She asked me something I did not expect. Will hardware returns be going through her team and what about warranties? Great question. I worked that all out last month. Avnet takes all the Dell hardware and preloads it with our software, handles shipping and returns. We never touch any hardware. We do not have any inventory on the books. We just pay a bill once a quarter. She was impressed. At least I think so. But in any event, she gives us her nod and we go on to seek the next executive approval. This is very much of a community manager type of skill. Respecting being polite and considerate of others should be natural to everyone. But respect for other people's time, as in don't show me 40 slides you made for someone else, is much, much a error in the corporate environment. But a community manager can understand what someone he or she does not necessarily agree with is thinking and start from there instead of showing up with your problem, see what happens. That is what this approach is. Community managers understand this instinctively because they live in a world where communication is a many, too many phenomenon by default, where most middle management think that communication is one, too many by default. Now, at the opposite end of the spectrum is making it ridiculous not to agree with you. Mind you, you're not ridiculing a person. That would not be nice. Now you're doing something completely different. You're making it harder to embrace a set of ideas with sandbagging power contrary to your proposal. You make it ridiculous for folks to take that position before they declare themselves. Here is a good example. This is from an old notebook of mine. I got this slide from Nat Friedman when he was working on getting early funding for SUSE Studio internally at SUSE. He had this slide that collected all objections you always hear about innovation. From the objections that the company historians like me would have, knowing all past failures, I can effortlessly pull up an example at will. To the hilarious juxtaposition of it has been done before and it has never been done before. Very nice. Now, let's say you're in an operational role and have some approval power, maybe accounting or even the CFO. Do you want to be labeled an innovator or someone who does not understand innovation? This slide is disarming to anyone who does not really care, call them innocent bystander, if you will, and may wind up sandbagging you with generic objections. It defends the defenders of the status quo and works wonderfully in large meetings. You can neutralize multiple naysayers in one shot. The third option is opening a can of whoop ass. Discourage on so many levels and we will see why later. So hold on to your horses. The key here is that people who are sandbagging you essentially do not care and have nothing at stake. Losing your temper in some variant changes the equation. You are on the offensive and now they need to spend effort to defend. In negotiation terms, it changes their baton. This is the best alternative to a negotiated agreement negotiators use as their bottom line. If the negotiation is going nowhere, you get the baton without the counterparts agreement, meaning it does not require anybody to agree for you to achieve that level of success or failure. In the case where your interlocutor does not care, you're asking them to invest effort while they could just do nothing. Their baton is sadly better than what you are offering. The result is that they are sincerely uninterested. If you fail, give up on your project or simply walk away, they have less work to do. The can of whoop ass radically changes this math. Now they need to put in work to defend from your attack. It is suddenly better to just agree to your boring to them uninteresting request and move on. Pure corporate dysfunction on tap but you see this all the time, especially with service centers or cost centers as traditionally they were called. The vice president of the cost center is not measured on how well it's serving the rest of the organization. In most companies anyway, he or she is measured on how much money they're saving. So if you do not ask IT to do something, if you do not ask finance to do something, the KPIs for the VP owning that part of the organization looks better. Side but true. More on this later. There is a better way to approach this situation than opening a can of whoop ass. We will call this the Oppenheimer and Feynman approach. Richard Feynman was a Nobel Prize winner in physics, of course, and among his many achievements, one of the youngest PhDs on staff at Los Alamos during the Manhattan Project. One day, project chief Robert Oppenheimer sends them for a safety inspection to Oak Ridge in Tennessee where fissile uranium is being separated from the common isotope. Fissile material is being handled by staff who have not been briefed by the military on nuclear chain reaction risks. And Oppenheimer feels that there will be an accident. Feynman objects to the idea. Dr. Oppenheimer, you're telling me that the military bigwigs at Oak Ridge are going to listen to me. Little Richard? Yes, they will, says Oppenheimer. And he explained he is to use the following words. Los Alamos will not assume responsibility for the safety of the Oak Ridge plant if these concerns are not addressed. Feynman flies over, has other adventures along the way, including the other passengers on the plane wondering how this youngster got a seat during wartime. And sure enough, the plant managers do what he says. And for the record, he does indeed find problems. What is going on here is assumed ownership. The person sandbagging your project presumes it will stay your problem even as they wash their hands of doing their part. They are lazy and very much wrong. And you can make this very clear without ruffling your feathers. The modern version of Feynman's line is, my team cannot deliver a corporate level OKR without your support. A corporate objective tracked by the board will be missed and it will be on you. Mic drop, have a nice day. You will not carry the ownership for them if they did not deliver their part, whereas you will if they do. Blame versus potential credit. On the receiving end of this strategy, you may honestly not have the resources to deliver all your known and unknown commitments, in which case, you surface the conflict and let the higher ups decide what they want more. But you do not sandbag. Now let's go back to the can of who pass and resolve that one. This is what I would call going zero dark 30 on someone. If you have not seen the movie, it's worth watching. In the scene I'm referring to, Maya, a CIA analyst who has been trying to capture the terrorist Bin Laden for 10 years, tells a higher up that if she does not get the resources she needs to complete the mission from this guy, he will be the first chief of station summoned in front of Congress for subverting the effort to capture or kill Osama Bin Laden. Now, first of all, look at her face. That is reason number zero, not to do it. It is hard on you. It is your blood pressure shooting up, not the other person. This guy on the backside doing nothing. He is perfectly unfazed. It is also hard on your reputation. You're expected to keep your cool. If you really must do it, you want to make sure your direct boss, your VP and your GM have your back and that you have weapons release authority. If they do not care enough about the problem to back you, neither should you. You can be the bad cop if the need arises, as long as it's not very often, but you should not be the organization's lone gunman and it is their job to provide top cover. Finally, you should always be hard on the problem, not the people, even when you open the can of whoop ass. Do not attack the person, attack the problem and demand that others do their part to solve it. There is perhaps a situation where you feel you can legitimate take this path. And that is dealing with someone who puts their selfish interest above the team or the companies. You have to think this through, however. A consummate player like that will not be taken by a simple assault. More important for you is to wonder if you are working for the right company, if so many things are upsetting to you. If I'm upset twice the same year, I drop whatever I'm doing and sit half an hour in a conference room with a nice view outside, opposite side of this building, actually. Considering why I should not call my headhunter, it is a good routine to check the limits of your own tolerance. Maybe, if doesn't make sense, it doesn't make sense. Otherwise, chill. Now, you may choose not to go medieval on a toxic element, but there is something else you need to internalize. Folks who do not let you discuss important decisions by throwing a lot of noise and chaff in the way to delay need to be removed from the decision path, from the critical path. They will not go away on their own. You or someone will need to do something about them, preferably sooner than later. The anti-pattern has a name, but this is a PG-13 version of the stock, so we'll leave the name out. Corporate sabotage is such an effective strategy that the Office of Strategic Services, the CIA's predecessor, circulated the manual on bureaucratic sabotage in the 40s, providing it to sympathetic industry staff in the Third Reich. This is a very interesting read. Anyone in your organization who operates with any of the techniques described in this book should be put on notice if you care about the health of your organization. That's PG-13 enough for you. This is a self-sustaining, team-generated variant of the individual SOB anti-pattern. And it comes in multiple org chart versions. The traditional one is technologists debating a point forever. This is easy to unlock. If your team respects users as those we're trying to serve, you can bring in customer data points to aim the ship in the general direction and unlock the discussion. Say, this part is in scope, this part doesn't matter. And then let it proceed naturally, again, back to the experts. Variant two, I will take revenge of the German bureaucrat for $50, Alex. This is one of my favorites. The name is just crazy. The moniker comes from this German chief of police in one of Jack Reacher's novels. When he gets upset with his boss, he stops taking any decision whatsoever and sends every single question, no matter how small, to his boss. A denial of service attack by bureaucratic means. Germans incidentally have some of the best words to describe out-of-control paperwork. Papier Krieg, the paper war, is a term old enough that Vernon von Braun's boss already used it in the 1940s. So what do we do about the return of the German bureaucrats and revenge of the German bureaucrat anti-pattern? Well, here you need to be aware of what is going on first and refuse to take over decisions that aren't yours. If necessary, point out the other team or a person possesses the expertise on the topic, why are they asking you? Can they clarify what help is that they are seeking? Ultimately, in a worst case situation, you could just ignore the request, but it is better to make really sure these are not well-intentioned requests for help at first as folks with insufficient agency may simply feel too differential towards you. They may think that you want this decision or they may think too highly of you. Make clear to them, you think they are the domain experts and they need to lead their part of the project while you will be happy to help as needed in your area of expertise only. Now, the second variant comes from the opposite angle. Instead of someone pushing tasks upstairs, it is the managers from upstairs putting their noses in decisions they should not be taking. And this actually is an official name for the pattern from a management anti-pattern book published 30 years ago. As a manager, this is easier to diffuse. As you can point out to the other managers that really, the best decision here will be taken by those actually doing the work as they understand it best. Throw in a micromanager for bonus points. Nobody wants to be one, even if they are. An individual contributor can have a harder time diffusing this. So just ask a sensible manager already in the jamboree to disband the unneeded group of interlopers for you. Now you have the tactics and the countermeasures. Part two, rules for rebels is the next step. You need forward thinking in addition to crisis response. That is the next part of this training, something that I've promised to deliver already last year as an article to opensource.com and as a second training here at the summit. But I never seem to have the time to make this presentation because somehow grooming rebels is not a priority. But I'll get around to it. I don't know about the presentation, hopefully OSS 2022. But in the meantime, you'll be able to read the written version of this fall on opensource.com. So yes, this talk ends in a cliffhanger. You have the fun part with all the stories. The follow-up is how I look at all this every day and that yet remain allegedly sane. You can read that when it comes out this fall. And that is it for today. Now you have the catalog of how the decision-making can be broken and repaired, at least for a simple contributor or middle manager. Back to your personal circus, hopefully with some new skills to navigate corporate dysfunction in your tool chest. I hope I have given you at least one or two useful thoughts. It took a lot of time to build this out. Remember that speakers are Pavlovian devices. If you like this talk, please submit feedback. Let us know that you did. Will help me make the second part happen. Submit comments as well. You can reach me as posted here. And you will get the slides and the write-up as well. So thank you so much and enjoy the rest of the conference.