 All right. Welcome to another session of the Virtual Open Source Summit. My name is Federico Lucifradi and I'll be your guide for the next few minutes. Let me see. Let's get started. So this is meant to be an introduction to managing certain types of problems in a corporation. Now, a little bit of background to justify why am I saying these things and hopefully give you a little bit of confidence that I know what I'm talking about. I worked on a few of these products and I was the maintainer of MAN for about five years between 2004 and 2010. As you can see, I had pretty much the privilege of being in open source my entire career. Currently, I'm the product management director for Sefert Red Hat. Previously, I was the Ubuntu server PM at Canonical and if you turn back the decade, I was the system management star at SUSA. Of course, none of these awesome organizations suffer from any of the issues that we're about to discuss. Oh, shameless plug. I have a book out AWS System Administration by O'Reilly. And that's why you see the clouds next to my picture. So you can see that besides the Linux distribution stuff, I have a big background in systems management. And usually, I talk about hardware or hardware hacks and they come with a disclaimer. The obligatory disclaimer is that we'll most likely break some hardware playing with it and it will come out of your pocket. But in this case, the hardware is your org and people may be involved. caveat, enter, let the buyer beware, proceed with caution and all that. Jokes aside, don't break people. The spirit of the management stock as opposed to a technical talk is to take what you like and leave the rest. I don't expect everything 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 dysfunctions we're about to discuss here. So 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 the old human realities ranging from the Peter principle to having too many cooks in the kitchen to the individual's perfectionism and decision or even straight up cowardice. Decisions that are lifeblood of your project can be deferred, avoided, eroded or derailed in perfectly legitimate and even well meaning ways. But this can spell death for what you were tasked to build as success depends on implementation as much if not more than on having a good idea. So you cannot execute decisions. You cannot execute if decisions are not prompt, mostly correct and accepted by the team. And that's why we're here. So, okay, 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? So 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, obviously there are limitations almost with the same team. Unless you're building a category special, a team making a car knows it will have four wheels. And it will be roughly a certain number of feet long. Well, meters if you're in Canada. And apparently someone built a Formula one racer with six wheels in the 70s. But even if you buy the apex of automotive innovation today at Tesla, Elon Musk will still ship you four wheels. Manufacturers have lots of other hard problems to keep them busy, mind you, like union strikes, supply chains, inventories, shipping delays and all that. Flooded mines, trade wars, even train derailment. This is a train derailment in Montana a few years back with 3737 fuselages went straight into the Clark Ford River. And you thought our problems were big. But this rigidity of manufacturing brings constraints and manufacturers 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. As Morpheus taught us the matrix allows us to make anything real, as long as it is codified by electric signals. No constraints. Well, except perhaps time and budget, but they're minor compared to the rest of the real world. As Jeff basis as famously pointed out constraints drive innovation. One of the only ways to get out of a tight box is to invent your way out. They clarify cut through and get to the essence of your problem domain. So let's free your mind about decisions. They are not that important. You can get things wrong and 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 decisions. I can block about 160 people by overthinking installing my boss more than 300. His boss in turn can block maybe 500 if he picks the right thing to waffle about. And his boss could conceivably block all 15,000 of us. That's no good. That's much more important than whether the decision was correct or not. So 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 Caza for some years. They're not on the same team. And Miguel was working on mono. I was working on suicide products for Linux products. One thing that struck me about Miguel was the speed with which he could take technical decisions often on the spot in a couple of minutes. And he would defend that speed allowing the scent, but not what he called stopping force, which would cause delays. Now I'm sure Miguel would argue that he has five nines and his decision success rate. But to me, his speed was striking, not his accuracy. And that got me thinking about the odds of what was going on. 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 could 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 the organization better off in the trade. ASUS 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 will make you late by definition. Now I don't think you should be wrong one time out of four. 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's okay really. I don't think I'm wrong every 10th time I make a choice, but even if I wear 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 your success rate is too low, you will know. But if you're too slow, they will, 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, well, five years ago would qualify. If your strategist picked the wrong container orchestrator. Now you are busy re implementing and migrating your customers. Whereas if you pick the right one, you had a two year head start. Inventing your own cloud infrastructure while everyone else was flocking to open stack is another major example in recent times. 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 then use to rebuild your product with the winning technology. The opportunity cost is huge. It could sink a company if it's a startup. Some decisions are worth pondering for weeks, even months, if you're really to take to talk to a large number of folks. Now I don't know about you but momentous decisions of that magnitude or maybe one or two a year for me. The rest are things like monitor this cluster would collect the or Prometheus or installed by a public or Ansible. It is not as dramatic a cost to change implementation tooling as it 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. So you have almost no excuse for not being blistering fast and questions that are almost that amount to what parking spot should I be using today. In planning terms, you need to move it and let your team catch you if you fail on a phone if you fall on a fast one. While you don't let your team down on the strategic and you think through those well, they will rescue you if you screw up on the day to day. Let them help you. Think through the right stuff, move fast on the rest and everything is good. Well, if you have a well oiled team, everything is good. Now that we have hopefully freed your mind to take decisions. Let's look at what happens adding group dynamics and what anti patterns emerge, which is the core of this talk. 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 set Godin's blog. Let me read it to you. Your first mistake was getting on the a 53 bus, the one that goes cross town instead of to where you're going. Mistake like this happened all the time. The big mistake though, the one that will cost you is staying on the wrong bus. You have to get on the bus. I know you got a seat. I know it's getting dark outside, but you're on the wrong bus and staying on the wrong bus won't make it the right bus. If you really want to get to where you set out to go, you are going to have to get off the wrong bus. It doesn't matter what you got on the bus. It doesn't matter how much the ticket was you only way you can fix this is by getting off the bus. I can tell you there is no solution I know 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 your organization, 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 org that wants strategic input, not force an organization to think strategically. We have to get off the bus, if strategy matters that much to you, because you're never touching that steering this bus always travels along the same path. But there are good news to in this pattern, use that affect you directly. 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 convene to senior executives that we need to make up our minds as to what is we're actually building. How many wheels does the car have as it were, because we need to know what it is outside of the project as much or more than what's in it, especially at the start. The core decisions about business models strategic 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 what you need. The course is a decision, but that's so politely implying no decision equals no schedule, but without you ripping your hair out in front of them, which would not be proper. Let me share a personal battle story eons ago so probably okay to tell but let's put it this way. I was working for a Linux distribution and we unplug the partner and let's just say their name starts with I and ends with BM. Unplugging the partner would have been bad enough, but what happened was way worse. We unplugged all their customers. Here is what happened. Of course, I'm on holiday. I think I'm in Florida. My phone is programmed to sound off for a predefined set of emergency red alert email subject subject lines and it goes off repeatedly. I read the messages and my jaw drops. 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 GPM of everything. I put lots of detail in because I'm a detail oriented kind of person but the message is, I'm a desk on one you do not need to be. Then I tracked down the four people I need to solve this mess my right hand manager in Prague, fortunately Europe was still on and awake. The lead engineer in Utah, and his manager, also in the US. I'd like to tell you that we met in 15 minutes, but we did not have iPhones and Google Canada. It was the age of group wise and blackberries. It took a little bit longer. So maybe an hour later, we're all on the phone. These are people who know me very well. We work together for years and they're visibly nervous shaken. Almost. We are bouncing update requests for a sizable chunk of the user base of a partner delivering 25% of our revenue. 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 like lifting a huge weight of their shoulders could almost hear them breathing easier. With that out of their heads, they all focused on solving the problem. Nobody is 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 and follow the sun mode and the issue was resolved in 24 hours. By 36 hours support was confirming resolution with the fortunately few customers who had managed to realize they could not access their updates. I get a couple of jokes from the GM and everything is back to normal. Now what happened here? Why did I do this? The first thing 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 it. 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. Removing fear allowed them to laser focus on the problem. Now this is the easy one. There is more going on here. If we were live, I would let you guess, but we're not. So I'll tell you the answer. Here it is. They are my team. I'm going to protect them anyway. So I might as well tell them now so they can relax. 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. As I announced that this buck stops with me, I enabled people to focus exclusively on what needs doing next and not CIA for what had already happened. They focused on not getting blamed for what was coming, not focusing on getting blamed for what had already happened. Now one word of caution. Removing worry from the group can be a powerful technique, but danger will Robinson. Your team will appreciate your behavior, but there is a problem, multiple problems actually, but let's focus on just one for starters. As your sphere of influence in organization 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 mean here is funny, but it is not about being evil. It's just law of large numbers. If you have enough influence that you have these son of a snake people dash statistical phenomena to contend with, you cannot leave yourself that open. You can even sabotage you to make your recovery effort fail in the worst case. While in the best case, they will just advertise your original failure to the forewind. 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 seat doesn't invite trolls to the party and make the problem actually worse. But there is risk aversion everywhere at work. It may be cultural in a permission driven society, it may 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 more likely they simply do not realize they're in a safe space to share their ideas. Remove risk, tell them it is your decision and hint and hint your responsibility. But despite it being your decision, you want to hear everybody's idea before taking it. You may think of risk aversion is the managing down version of the cone of uncertainty, which is the managing approach to make people speak up. Now for another anti pattern, the opposite scenario. Too many cooks in the kitchen, zero fear, everyone chimes in on everything. Open discussion is fine, but pointless chatter is not at some point you are not adding anything and the cost of communication is way, way far from small. As Brooks law teaches us. So you want to cut back a little, but you do not want to shut down communication completely, which will be the outcome if you are tried to tell people not to say anything stupid ever. So 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 shuttle were went and shipped in somewhat crazy idea just to be cute. At least he thought it was crazy and funny. That was his point. I at least I last Mark pretended not to understand this was a joke. He was part of his keynote plan for the next open stack summit to be delivered in three months. That engineer stopped joking in the wrong meetings I can assure you, he had to implement and present the demo as he did, and he did a darn good job of it too. But I think he learned something else here. Oops, there is the site. Here is why too much communication is too much. This is from a recent book from Matt Nicholson when computing got personal. It's like getting 400,000 people to agree on what they want to have for lunch. I mean, it's just not going to happen. It's going to be lowest common denominator. It's going to be hot dogs and beans. So why 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. The customer wanted at one point somebody looked at the process to see what it's doing and what's the overhead built into it found that it would take at least nine months to ship an empty box. I absolutely love love the quantifying approach it so IBM. So they measure 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 not communication overhead. Here the focus is on communication overhead. Get 400,000 people to agree that appears to be too much communication. IBM also gave us Brooks law on the cost of communication, 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. Yes, but here are some starting points. What about the next time pattern. What is the problem is that they cannot be bothered to care. I think that they would just say yes and send you on your way but instead the justifiable fear we faced earlier, but instead of the justifiable fear that we faced earlier. Here we have cowardice or laziness. 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 599 in line for responsibility and the blame. There 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 department. Did you get get a PayPal bowl approving your request. Oh, you missed the 2020 planning deadline back in 2018. See you next year. Good luck moving at the internet. I mean DMV speed with these functions. But there are some things you can do. The first is respect, not as impolite and proper, which you should be anyway. Here is a story. One of the Linux Foundation board members and me are selling this product concept to a C level investment board within the company. We address general manager CMO a few others. Next is the head of support. This is a very mysterious stakeholder to us, because her role did not really have anything to do with creating a product. The first six products created that year required support approval at this high level. It was done by her staff to levels down here we had her own year only because of this new sea level approval board. So we're perplexed, we did not know her I do not know the motions that this corporate role expects from us. We could show up and give her the facts we prepared for the previous executive. So I call my mentor the head of product. I explained to my predicament. I need this approval. I'm not sure what she will care about. I don't know her. I don't know what KPI is a for removed executive on the support line tracks and basically blind. I don't want to have a meeting to get slapped around and then do the right thing. The second or third do over. So my mentor gives me a number of items. He thinks she will care about will we create more incidents than the existing version where we need to hire more people support stuff like that. So I schedule a meeting to go over materials created for this person specifically for this role 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 or what about warranties. Great question. I worked that all out last month. I'm not takes all the del hardware and loads it with our software and shipping blah, blah, blah, blah, blah. We do not have inventory in the books. Marvelous. We just get the bill on the quarter. She was impressed. I think but in any event, she gives us her note her not and we go on to seek the next approval. This is very much of a community manager type of skill respect in being polite and considerate of others should be natural to everyone respect for other people's time. As in don't show me the next 40 slides. You made for someone else is rare, but the community manager can understand what someone he or she does not necessarily agree with his thinking and starts from there. That's why what this approach is community managers understand this instinctively because they live in a world where communication is a many too many reality by default, whereas most middle management thinks one too many by one too many by default, or one to one. 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. No, you're doing something completely different. You're might making it harder to embrace a set of ideas with sandbagging power contrary to your proposal. You make it ridiculous for folks to take on that position before they declare themselves. And here is a good example. This is from an old notebook. I got the slide from that freedman when he was working on getting early funding for sister studio. 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 just a position of it has been done before and it has never been done before. Very nice. Now, let's say you are in an operational role and have something of an approval power, maybe accounting or even the CFO, you want to be labeled an innovator or someone who does not understand innovation. And this slide is disarming to anyone who does not really care and wants to send back you with generic objections. It defanks the defenders of the status quo and works wonderfully in large meetings. You can neutralize multiple naysayers with one shot. Now I'm going to cover one more pattern, and then we're going to cut this because we're running out of time. Now, the third option is opening a can of who passed discouraged on so many levels, and we'll see why later. So hold on your horses. The key here is that people who are sending bagging you essentially do not care and have nothing at stake. Losing your temper and some variants changes the equation. You are on the offensive and now they need to spend efforts to defend a negotiation terms that changes their batman. This is the best alternative to a negotiated agreement. The negotiators use as their bottom line. If the negotiation is going nowhere, you get the batman meaning it is what does not require agreement for you to achieve. In the case where your interlocutor that just does not care, you're asking them to invest effort while they could just do nothing. Their batman is certainly better than what you're 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 who pass 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. term and move on. So pure corporate dysfunction on tap. Here's what you can do. It's a better way to approach this situation than opening a can of who pass will call this the open Heimer and Feynman approach, which are fine one was a Nobel Prize winner in physics, of course, and this among his many achievements, one of the youngest PhD in staff at Los Alamos. One day, Project Chief Robert Oppenheimer sends them for a safety inspection to Oak Ridge. Where a fissile uranium is being separated from the common isotope. Fissile material is being handled by the staff who have not been briefed on nuclear chain reaction risks and open Heimer fears and accident. Feynman objects, Dr. Oppenheimer, you're telling me that the military big wigs over at Oak Ridge are going to listen to me little Richard. Yes, they will says Oppenheimer and he explains he's to use the following words. Los Alamos will not assume responsibility for the safety of Oak Ridge plant. If these concerns are not addressed. Feynman flies over has other adventures along the way, including other passengers wondering how is it that such a youngster got a seat on their airplane during wartime. 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 projects presume it will stay your problem, even as they wash their hands of doing their part. And you can make this very clear without ruffling your feathers. The modern version of finance line is my team cannot deliver a corporate level okay are without your support a corporate objective tracked by the board will be missed and it will be on you. Mike drop have a nice day. You will not carry the ownership for them if you do not deliver if they do not deliver their part. Whereas you will carry the ownership for them if they do blame versus potential credit. On the receiving end of the 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 between the two possibilities. Now we are out of time. And there are a few more patterns here, which we don't have the time to cover, but the slides are going to be up on the website. And I'm happy to take questions on slack. If you want, there is also a full recording of the presentation on the, that is going to go up my rehearsal. So to speak at the Boston Linux and Unix user group, and you can find them on their YouTube channel so you can learn what a longer version of the talk would look like. And I think we'll, we'll stop here.