 Hi, I'm here today to talk to you about enabling descent, which might seem like a very strange thing to want to encourage. Unfortunately, we can't be together in person, but 2020 is coming to an end in a few months. And here's to wishing everybody a healthy 2021. Before we start, I wanted to give a shout out to Pixabay. All of the images in my presentation are from Pixabay. Pixabay has a great open license called the Pixabay license, which makes them safe to use without asking for permission or giving credit to the artist, even for commercial purposes. So I wanted to emphasize and remind everyone that we should encourage being free and open while still being respectful of licenses and rights. So if you're going to be using images and presentations, it's always good to first make sure you've got the appropriate license on those. My name is Sim Zaks. That's Sim, like the card in your cell phone. I'm based in Israel, where I've been living for the past 18 years. I've been working at Red Hat for the past six years as a DevOps CI architect, working in the Quality Engineering Department. And I have about a little more than 20 years of experience in the industry. I currently write a blog called Every Person Strategy, which is a strategy for regular people. It's not only for high ups and executives. Everybody can use their strategy. And this talk is based on one of those ideas in how to be strategic. My current role is leading initiatives across the QE department for multiple products. And we're trying to standardize on things and get people walking in the same direction. So let's get started. Why would we want to encourage dissent? So about a year and a half ago, I was asked to lead an initiative to, among all of the Red Hat QE teams to standardize the CI workflow. And now CI workflow in QE, basically using all of the CI tooling in order to automate the testing process. Until then, we had each team worked on their own. They had to figure out how they were doing things. And there was little to no communication between the different teams. So we had a number of different teams who were doing very, very similar things in very, very different ways. So among our objectives was to develop the QE CI workflow. And we had a continuous productization effort going on in Red Hat where we wanted to go from upstream through productization QE and out to the customers in a standard flow. So we wanted to connect QE to that. So we needed to actually be working in a similar manner in order to do it. And most importantly, we wanted our teams to be able to work together and form a vibrant community around the work that they were all doing. We had about 50 teams participating. One representative per team. It's a global group. We have people of China, India, Europe, Israel, America. And so we invited a subset of them over to Israel. We can meet face to face, discuss what we wanted to do and build a framework for our collaboration. Our first decision was to use the open decision-making framework for all decisions that we were going to make. We understand that each team is unique. They have their own processes, their own requirements and their own challenges. We required full partners. We wanted every single team to be partnered with us and to grant them ownership of the process and enable buy-in. So we started off the process by declaring it was open. We care about what you have to say. We need your requirements. We want you to be able to influence the direction that we're going in. And we very quickly found out that just because we declared something open, doesn't make it so. Now, before we discuss how to encourage dissent, what is open decision-making and why do we do it? So a long time ago in a galaxy far, far away, decisions were hierarchical. There was a single leader who would decide what is the direction and how do we want to do things and tell everybody this is our method and then everybody down the road had to do it. There are rumors that floating around that this methodology is still around, but hopefully in this time of enlightenment, more and more teams are moving towards open decision-making. The assumption was that the more senior a leader, the wider view he had, the better he was able to see the big picture. People with less experience know their small little task and don't really see the big picture and therefore they should remain quiet. However, at some point in time, people realize the business leaders are looking at the environment and the decision-making ecosystem pretty much and decided that, found out that the emperor had no clothing. It's impossible for one person, no matter what his experience, to fully grasp the entire picture, especially in a global environment with multiple cultures and a lot of different regulations and challenges. There's a lot of difference between theory and practice. We also have the grump workers, us regular engineers, who are faced with specific challenges that senior leaders are blissfully unaware of. At the same time, diversity started becoming an important aspect in business. At first, leaders thought that they were doing minorities a favor by bringing them in and making the business more open to them, but they very, very quickly realized that every person who has a different background or who comes from a different culture or who has different life experiences actually is bringing in a new perspective to the process so they can understand stuff that other people on the team are not understanding. And so when you put together this diverse group of people, then you're getting a completely different perspective because everybody is going to be able to share. Now, to harness this great new advantage that you're bringing in with all of these teams, because you've got the diverse teams, you've got the people doing the actual work, you have the business leaders who have a greater vision of the big picture and have the actual experience. We need to include all of those people in the decision process. So as I said, we declared our process to be open. Now, there's a lot of challenges involved in a standardization project. They often fail because people don't keep all of these different ideas and what needs to happen in mind. We explained what our goals were and why we wanted to do them. We told everyone their opinions were important and we needed them to influence. We needed to hear from them in order to make the best decisions. And we had a few loud passionate engineers who made sure their voices were heard, but the majority of participants remained quiet. And so we went through a process of understanding why people weren't talking and what we had to do in order to get them to talk. We had numerous personal conversations with the people who are participating, asking them about what they thought of the different things we were doing. We had discussions in internal company forums and asked people for their experience in order to understand from a wider group of people what was going on here. And it turns out there are numerous reasons why people are not giving the feedback, why people are not disagreeing and telling the leaders what the problem is in order to make the better decisions. So let's talk about a few of them and then we'll discuss how to mitigate this. So first of all, we have culture. This is a global project, as I mentioned, people from all over the world. Some of them are from authoritative cultures where people are highly discouraged from disagreeing, from expressing individualism. If you say I have a different idea than the group, you're frowned upon, you're looked down upon and that is not considered a positive thing to do. We also have patriarchal cultures. We've got standard introverts, right? Who never liked talking in groups. Shy people, uncomfortable in a public setting, are not going to necessarily shout out what the problem is here. People like to avoid confrontation. In open debate, there's often bullies who shout down other people's input. So in this global project dealing with all of these different elements, we have to understand where they come from, what their culture is and how to get them to open up in order to gain the benefit that we need. Second of all, nobody likes being wrong, especially if their suggestion is going to cause a debate. Oftentimes ideas are brought up, discussed and then there's a determination this won't work for everybody, right? The person who suggested it maybe had a narrow view, maybe had a different idea, but when you look at 50 teams across the department, you say, well, that's a great idea for your specific team, but if we want everybody to be able to do this, that isn't gonna work. And then people might feel embarrassed about that. Debates can use harsh language, as I said. People might be insulted by what somebody else is gonna say. So people would rather keep quiet than risk putting up an idea that's going to be shot down. As an example of this, right? Of people wanting to remain quiet rather than to look bad, right? I've been in an interview process recently, interviewing people. And one of the questions that I always ask is can you give me an example of a time that you screwed up? And there's a lot of things I wanna gain from this question, you know, how they work, how they deal with things that had a problem, who they communicate with, transparency, right? There's a lot of great answers that come in and most of the people just like, look at me blankly and like, no, I'm not really, I don't know, maybe a small thing, maybe I did this, it took me two minutes to fix it. And then I say, you know what? Let me give you an example. And I tell them a time that I totally screwed up. I said in my last position, right? I was in charge of IT for a small company, about 100 people. And we developed an internal application for all the company to use. And one day, somebody turns on the application, completely 100% internally developed. Somebody turns on the application and it says there's a virus. And I look at it and I say, you know, there's probably, you know, a problem here. It's probably a false positive. I know this application does not have a virus. I clicked on the button, I let the virus in and it went through the entire company very, very quickly. It took me 27 straight hours of work with two other system administrators to get back all of the computers into a normal state and to completely get rid of that virus. As soon as I give people that example, they're like, oh yeah, you know, I did something once it took me two hours to fix, right? They can't be as bad as what I did and therefore they're willing to open up. So, you know, giving different ideas, telling people it's okay to mess up, also gives them the ability to now say, I don't look so badly because you screwed up as well. So this is also very similar in meetings. Third, it often takes time for a new idea to sink in. Some people grasp ideas very quickly. They understand all the ramifications. They know what's going on. They see the big picture, they hear an idea. They, you know, all of a sudden their brain goes in a thousand different directions of exactly what's going to happen with this. However, most people need time to process and understand exactly what the suggestion is and what ramifications it has. They want time to research. They want time to look and see what happened with similar ideas. What happened when we tried other things that were different than what we're doing today? Somebody might have something in the back of his mind, right? Something is bothering me, but I don't know what. I can't put my finger on it. So what he wants to do is discuss it with the rest of the team, right? He wants to talk about with the other people before agreeing on something because whatever he agrees on is going to impact everyone. So he wants to make sure that everybody's on the same page. People are not prepared to stand up and explain when they first hear the idea, but after discussions with their colleagues, they can stand up and they can explain exactly what the problem is here. They might want to research or even just sleep on it so that they have some time for it to sink in. As an example of this, when I was a junior programmer, I was given a task once to scrape data from a popular web service. We wanted to use the data and offer it to the company's customers as statistics for something. And after working on it for a full week, this is a number of years ago before everybody understood how the web works. We found out that it was against their term of use. Not only that, they were actively preventing people from scraping data and there was even a lawsuit that was recently publicized against the company that was scraping this company's data. So we had to stop doing that. Now in the end, the company contacted via the web service directly and we ended up getting data from an API from them, which was much, much simpler. And this just goes to show us that research and thought first, right? Without just jumping in and saying, this sounds like a great idea, let's go and do it, that will save time, money, and effort. Fourth, people don't like to look like troublemakers. People are concerned for their careers, right? People don't want anybody to see them as a problem, as somebody who doesn't go with the flow, who always is throwing up obstacles. This may be based on past experience where either they've had obstacles in their careers because of things that they've said. It may just be based on survival instinct where you say, you know what, he's the alpha, I'm going to make sure to stay in line and not dissent too much. If people don't feel psychologically safe, they're not going to speak up, especially true if there have been repercussions in the past. Now, if you've led a process and you've either had repercussions or you've had a closed process, it's very hard to change your reputation. You have to work especially hard if you want to suddenly start using a more open model and work with people. And finally, people will only speak if it really makes a difference. There's a lot of processes that people declare to be open that have lip service. But after they go through the whole process and people give their feedback, the leader ends up making the same decision that he originally proposed. In other words, he asked everybody to come in, help and discuss and all of that. And then he's like, okay, now we're going to do what I wanted to, but we were open, dissenting, giving negative feedback, giving, you know, engaging. Takes a lot of effort and emotional engagement. People must be convinced that this is not for naught, that they're actually going to be able to influence and make the process better. During conversations that I had with people as part of this process, I was told that they had never been part of a truly open process. They didn't really believe that it would make a difference if they helped or not because I already knew what I was doing and I had already decided on the directions. It took a lot of convincing and showing proof of major impact by the participants where I said, this is what we started out with and look at where we went to, right? This is 180 degrees from what we originally had discussed. Now, an important thing to remember is who cares, first of all, if they remain silent. All of these people who are not speaking up, what happens if you make the decisions without them? What happens if you allow them to remain silent? So some teams do the nod and ignore, right? Yes, yes, yes, that's a great idea. And then they go and do what they think is best, they keep their original processes. They justify this by saying that the standardized process did not take their requirements into account. The fact that they didn't participate and didn't include their requirements is not relevant to them or to their managers. Other people mumble and grumble the walkway, this guy doesn't know what he's doing, we're going in the wrong direction, nothing is working. They might go to senior leaders to raise objections. They're gonna ask the leaders to come out and say, this isn't a good process, this is the wrong direction, the people are the wrong people, this happens all the time. So by understanding why they aren't speaking, you can mitigate this and you can bring them in and bring them on board in order to make sure that their requirements are included and that they own the process. And that will prevent all of this negativity that we're talking about. So now we understand some of the problems and what is behind them. And we also understand the ramifications of ignoring those problems. So the main question that we have to deal with is what can we do about it? So we came up with this methodology to adopt dissent. We have to get rid of the great silence and get people to tell you that you don't know what you're talking about and that you're missing things and that there are much better ways of doing this. So the five different methods of adopt are ask for ideas before presenting a proposal. Decisions shouldn't be finalized in a meeting. Open personal conversations. People can be called on during a meeting and thank people for dissenting opinions. So let's go into each one of these and see what that means. So when we wanna ask for ideas before presenting a proposal, when you walk into a room with a proposal and ask people what they think, the impression is that this is already a done deal. You might be able to slightly influence. You might be able to change a word here or there move the direction, but the main work is done, right? So what can you do instead of that? Instead, you can walk in and present goals. Say, this is what we want to accomplish and ask people for ideas. This does two things. First of all, it removes dissent from the picture, right? Instead of asking people what they think about this proposal, right? Ask them how to solve a problem. This is positive feedback, not negative feedback. It also empowers participants. It tells them that it's obvious that you care about their feedback and opinions because you didn't go ahead and write the proposal first before asking them. You're asking them before you wrote the proposal. So when you ask for feedback on your work, they can pretty much give you a plus one or a minus one, but when you ask for ideas you're saying, I need your help. So how does this work from a practical perspective? You start with a blank whiteboard and ask a question, right? Currently, we have no standard for triggering our jobs, but we need to participate in continuous productization. So we need an automated process for this all to work, right? How are you doing it? What is your team doing right now? Let's figure it out and we find out that we've got like a ton of different methods. So we have one team using the message bus for disconnected triggering so that one system can send a message to another system and then the other system can listen for messages and get it and it's a decoupled system for auto triggering when the build is available. Wow, this is such a great idea. Does this work for everyone? No, why doesn't it work for everybody? Why won't that work for your team? Well, my team gets multiple builds per day. If I trigger every time I get a message, I will be constantly running and there's no reason for it. If I just trigger once a day, that's good. So I would like to put my trigger on a schedule. Okay, so now we understand already that different teams have different requirements because their realistic workflows are different. Instead of just having a single methodology for doing this, you can have multiple methodologies. Now, instead of having 50 for 50 teams, maybe you'll have end up with two or three or even four and say that if this is your workflow, this is the proper way of doing it. And if that's the workflow, then that's the proper way of doing it. And therefore you include both of their team's requirements and you say, we can work with both of you. Now, the third team was doing something completely different, but one of those two methodologies works for them. So we're going to ask them to see if that will fit into what they're doing. Decisions shouldn't be finalized in a meeting, right? So we've all been to meetings and ideas proposed, discussed, modified, and then there's a decision to do it. But after some time, we realized that there's missing a very important aspect, very similar to the example I gave about the web scraping. Maybe it's not the best idea, but it sounded good at the moment. So what should we do? We should use the meeting to present an idea and answer initial questions and then get initial feedback, right? If possible, send out the idea beforehand so that people can be ready. Sometimes you want to have it as a surprise and a great idea and have the whole show, but very often it makes a lot more sense to send that out in advance. People can review and come in already at least a little bit prepared, still not fully prepared. So when you do have this discussion, right? The first meeting should be a discussion and not a, this is what we want to do, let's vote yes or no. The best discussions is an idea is valid, right? Everybody who brings up an idea, that idea is a valid idea. If it's not a perfect idea because no ideas are actually perfect, there are challenges. We don't want to throw out the ideas. Sometimes we can take this idea and that idea and blend them together and one idea will fill out and answer the challenges and other ideas. So we want to list out the challenges of the ideas and enable people to work on figuring out how that will work for them, right? You always want to send them down and other modifications in order to make things production ready. So after this full discussion happens and you have a number of different ideas that you want to work on, send out a summary to all of the people and ask them for comments. This gives them the time to research and discuss. You need to have a deadline on that so that it's reviewed in a timely fashion. And after everybody sends in their feedback, you review it, now there's time for a new meeting to present the proposal, right? Now you've taken their ideas and you've meshed them all together and you've written out a proposal of how we can actually do this. By this time, most people have the time to review and discuss it and research and they understand the full ramifications. After that meeting, when you have the final feedback on the proposal, send out another survey. And then when you get in those results, then you make the final decisions. Remember, decisions are not a democracy. You want to bring in all of the opinions and understand and allow them to influence and take advice from them, but then the leader has to make the final decision as to how to actually do this. Now, the length of this whole process that we talked about, it's a long, painful process. It depends on the type of decision you need to make. The more important decision, the longer time you wanna work offline in order to get that working. You wanna open personal conversations. If you notice someone not speaking during the meeting or looks like something's bothering him, talk to him personally afterwards. Introverts and people from non-individualistic cultures are generally very happy to speak in a one-on-one. You may need to gently coax out important information and explain how important it is to you that you need their honest feedback. However, this might be a little bit longer, but it's very worthwhile as very often you're going to find out things that we're missing, but they didn't wanna speak up in public. So don't get upset because you just had a meeting and just talked about all of these things and this guy was sitting there and did not give you any feedback. Try to understand their perspective. Public discussion may be the best and most efficient method for you to talk to multiple people and together all of the ideas might even be the most efficient way for everybody as a group so that people hear each other and understand why their ideas have challenges and how to mitigate them together. However, a one-on-one conversation will definitely elicit more information from individuals. Another benefit of a one-on-one conversation is persons feel that they're very important, right? If the leader goes to them and says, I need your help, what do you think about this? As an example, I called a female co-worker in China after a meeting that she was silented and I said to her, listen, I know that this proposal causes problems with your workflow. How did I know? Because with that team, we always had problems with all proposals in their workflow. I said, I need to understand why. I need to understand what your workflow is and how it works and why this will not work with it. In that personal conversation, we learned about very specific challenges that that team was dealing with and because of that, we made changes to the proposal. Afterwards, few months later, she told me that no one had ever insisted on hearing her feedback and she felt like it really made a difference to her. People can be called on during the meeting. You have to know your audience. You don't wanna embarrass people but try to call on people specifically, right? This will help bring out feedback that you're interested in. Sometimes people don't know that they can speak or they don't wanna interrupt or it's not the right time or they're not really sure. In a small meeting, you can go one by one in the people who haven't spoken, right? So you throw out an idea, you ask for feedback. You have this whole discussion. When that discussion is over, you're like, okay, on our meeting here, we have 10 people, four of them have already spoken. What do you think? What do you think, right? In a larger meeting, you randomly pick on a few people, two or three people, try not to pick on the same people every time but just look for the people who haven't spoken and say, how about you, how about you? This has been a stimulating discussion but we haven't heard from a number of people yet. Oliver, how does this fit into your workflow? Alexandra, do you see any obstacles here? So this will give you a couple of things. First of all, it lets them know that their input is valuable and requested and what that might do is it might encourage them to speak up in the future. If they think that they're needed, they may volunteer the information the next time. It also encourages participants to pay attention during the meeting. There's thousands of distractions out there, either with your telephone or things you're thinking about or an email that just popped up. If people think that you're gonna call on them and ask them what they think about something, they're actually going to pay attention during the meeting and help out. And finally, thank people for dissenting opinions. A simple statement such as, that's such an interesting perspective. I hadn't thought of it. Thank you for sharing. How can we overcome that challenge? These sort of messages tells everyone that they have a real ability to influence. Anything you can say that will convince participants that this is not lip service is going to help you bring out their information so that you can use it and harness all of the power that they're bringing in. Even, or maybe even especially, if dissenting ideas are not accepted, right? Not every idea has to be accepted. Every idea has to be valued, but it doesn't have to be accepted. There are tons and tons of ideas out there that are the wrong ideas that do not work for everybody and did not take a lot of things into account. However, when you give an idea that is not accepted, thank them. That was a great idea. You know, we obviously have challenges. Keep on thinking. Let's continue to collaborate on this. Show your appreciation, right? By doing this, instead of deriding the people who come up with ideas that are not accepted, that will go a long way in showing that it is a safe psychological environment and people will feel comfortable saying, I don't think that's a good idea. You're missing a lot. You're not taking everything into account. All you have to do is say to them, thank you for telling me that I missed something. So by following these methodologies, you're gonna do a number of different things. You're going to empower your group and enable them to fully explore the entire picture and understand what they're doing in order to achieve your and their objectives, right? Don't forget, these are all of your objectives. When they are part of the decision, they own the decisions. That's their decision. And now when they go back to another group, they're going to defend those decisions and they're going to explain why that's the best way of doing it. Even if it's going to cause them a lot more work. When an idea is not accepted, you don't want to say no. You want to explain why that idea wasn't accepted, right? And give the entire ideas, right? It could be that there's another initiative going on and because of that, that you need to collaborate and work together, then we have to use a certain tool. We have to use a certain methodology even if it is more difficult for most of the teams in our group, it's better for the entire organization. When people understand that, they're willing to take a step back and say, okay, that makes a lot of sense. If you just say no, because that's the way that I've decided we're doing it, people are like, yeah, that, whatever. Don't be afraid to add exceptions and multiple processes, right? You don't have to have a single way of doing things. In fact, if you have a single way of doing things, it's most likely will not be appropriate for every team. In one case, we started out with 50 different methodologies. Every single team that was working with us had implemented something to do the exact same thing in their own way. We knocked that down to five accepted methodologies. They were based entirely on team requirements, right? Does this work for you? Does this work for you? Why not? What can we do? How do we get this all to work? And when people are convinced that you're trying to get them all in the same, to actually work with them instead of forcing them to change, don't ever try to put every shaped peg in the same square hole. Doesn't work. Best of all, by being inclusive, you generate passion. And people who are passionate are the best workers. Teams will love what they're doing. They're gonna put in all of their efforts. They're going to put in extra hours. They're going to work on this in order to make sure that it's good. And best of all, you're coming up with the best solution. So, in summation, and I can't express this enough, use the adopt-descent methodologies. Ask for ideas before presenting a proposal. Decisions shouldn't be finalized in a meeting. Open personal conversations. People can be called on during a meeting and thank people for dissenting opinions. Thank you very much. That's what I have to say about enabling dissent. If you have any questions, I will be here to answer them.