Hello everybody, my name is Tomasz Manugiewicz and today I would like to spend this 30 minutes with you talking about CTO view on DevOps transformation. Starting with the word DevOps, I would love to ask you, what do you think about this word? What does it mean for you? Usually it means two things. The first thing that people say is that DevOps is a mindset. What that really is. We'll dig into it in a second. But on the other hand, some engineers say that DevOps is a tool chain. We have a lot of tools that we would like to use in our project, and that's DevOps. So that's also right. DevOps is actually the mindset and the tool chain. So the way we think about tools and others and our technology and the tools we are using. Speaking of technology, simplifying the process a little bit, we have development activities going on. Those activities produce some jar file, for example, and we put this jar file deploy on the server and ask operations guys to maintain the observed. That's the software development in a very big nutshell, right? However, when we dig into the details on the development side, there are a lot of plenty activities like architecture. We need to design the software, we need to plan the architecture, then we need to program, produce a code. We need to make sure that our code is merged to the one project. So we need version control systems. We then deploy to various environments and we implement logging mechanisms, right? So that's the development piece of work that we do. On the other hand, there is operations piece of work. So monitoring our software, how it behaves, how it performs, and so on, observing the logs that we implemented and patching our software with the new versions and fixes. All right. But in the middle there is magic thing, deployment, deployment to staging environment. We can have the UAT environment, so user acceptance tests, we can have a pre prod environment, prod environment, hidden product environment, even, or hidden pre prod environment. Obviously in various organizations we do it differently, but that's how it looks in general. And now this middle section, nowadays we replace by infrastructure as a code approach, by containers, implementing Docker or other containers, by orchestration mechanisms, by configuration management, CI CD pipeline logging, monitoring and so on and so forth. And this part could potentially belong to our development world and development team, or could belong to operations team. And it differs from the company to company. And that's where the DevOps core of DevOps, DevOps heart is. I would say so. DevOps for me is a development plus operations, development people, programmers and operations people coming together in order to have efficient software, sometimes developers needs to do, and they would like to do something from operations side of things. Sometimes operations guys would like to do something from developers. And those two activities combined together is a DevOps for me. So that's why we are talking here about mindset, because it's a set of our mind, how we will approach our collaboration together using those tools. Obviously, everyone is talking about this kind of this picture. Everyone is talking about those tools. We use puppet, we use chef Docker, you've already mentioned everyone is jenkins, right? And build pipelines and so on and so forth. So that's not a tough thing. We can learn about it, we have skills to use it. We are curious about how it works as well. So that's very interesting for us. What's difficult is who will be using which tool, what are the standards, how will communicate together and collaborate together. And that's where this transformation word comes into play. Because let's imagine the old monolithic architecture of our system and old monolithic structure of our company, right? In order to transform it to microservices. This is not just only about transforming our technology stack, it's about transforming away ways of working, it's about transforming our cooperation, communication and so on. So that's why we talk about transformation. Either it's DevOps transformation, or agile transformation, or any other kind of transformation is about changing the way we work. We used to work, so that's why it's so important to know and so difficult to implement. So how to implement that? We have state a, for example, the monolithic architecture and the system corresponding with our monolithic organizational structure. And we have state b, beautiful, shiny microservice architecture, orchestrated on the cloud, everything is automated and so on. So that's two space. On the other hand, we have people who wanted to work in a state a. Some of them would like to also work in a state b. But there are some people who don't like change, and that's totally okay. Pretty much every one of us have some difficulties in changing our habits. So that's why we have the state a transformation to state B. And this is not just easy, just like saying, hey, from tomorrow we'll do everything in another way. We need to do it step by step. We need to transform it. So in the middle stage, we need CTO have something that we were using before. So on the left hand side, you can imagine the silos, for example, like green and red rectangle, corresponds with the two departments working in the silos. And in ideal state in the B state, we would like to have those people working together, development and operations. So in the middle, we need to break the silos a little bit, building trust and having this third component, which is this activities in the middle that we had this orchestration, deployment activities, container activities and so on, as a shared responsibility between those two departments. Now, when those people from department Green and department Red will establish trust, the shared responsibility is possible. So there will be no blaming game, or we would like to eliminate the blaming game. We would like CTO have one group responsible for the whole software. And that's actually three steps that Kurt Levin described is unfreeze the organization, change the organization and freeze. Unfreezing means that saying, hey, we would like to change the ways of working. We don't want to have silos anymore. We would like to unfreeze it and prepare you to explore the new ways of working. Then in the stage number two, we change the ways of working and then freeze again saying, hey, this is new ways of working. You see the benefits, you can experiment with that. And that's our strategy moving forward. So those three steps, this is the Kurt Levin model, as I mentioned. So unfreeze, change and freeze. This is typical behavior of our transformation. So when we unfreeze, we create climate for change. We learn how to implement the change. We teach other people, teach our leaders, we show them that the change is, first things first, important. The second thing is very critical for our business. And there will be benefits for the organization and personal benefits as well for the people engaged in this stage. Then we enable the organization. So we provide all the tools that we would like to have, all the knowledge, as I said, all the trainings. We have a lot of one on one discussions with people, showing them the benefits, explaining them the need for the change. And that's the most critical process, this enabling organization in the middle, because if you will do it right, people will be ready for this change. And then freezing, meaning sustaining change. So once we learned new ways of working, once we learned how to together operate in, for example, Jenkins, or how to use nagios and other tools, we would like to keep it. We don't want people to come back CTO, the other tool to the old ways of working and old tools, saying, hey, this nagios is not so good. I would like to use the previous tool I was using, or saying, no, I don't want to be involved in this build pipeline creation, because I'm just operation guy. We don't want that. We want people, developers and operations working together. So that change needs to be sustainable and we need to provide environments to keep people satisfied and keep people engaged to have this change. So that's, this freezing part here is just an example, but I guess that you already are familiar with that, that we have obviously some activities. I'm not calling those phases because we are not in an environment of waterfall anymore. Maybe in some commands we do, but I would like to call it activities. There is a coding activity, there is a building activity, that we build software, there's an integration part, there's a testing part. We release and software with the corresponding changes and then deploying to production and operating. So this is about first step is CTO have continuous integration, then continuous delivery, continuous deployment. And DevOps is one step further. So having everything and everyone working alongside together. So that's DevOps. All right. And our talk today is about clevel view or CTO view on DevOps transformations, how to implement the change and how to drive the change in the organization, how to transform this organization. The question is, do you really want to know what's the city of view of DevOps transformation? I guess you know, you want to know. First things first. You need to understand that there will be broader context for you. And sometimes it will be difficult to have this context because we, as a specialist, as engineers, we are very narrow in the focus. We have deep knowledge. That's our advantage. That's how we earn for living. We have very deep knowledge, technical knowledge, but our focus and view is limited. And generalists have a zoom out and have a broader view. They don't have any more. So deep knowledge, that's why they hire you guys. But they have the broader view on the context of the business, of the environment, of the structure of the organization. So that's the visualization. I would like to show it to you, by the way, I would like CTO recommend to follow this guy. He's very great designer and provides designs such like this. So I like CTo be inspired by this guy. All right. Talking about our activity, daily activities, programming version, controlling deployment and so on and so forth. What we've already discussed, that's huge part of our life, that's huge part of our knowledge and our experience. And at the same time we call it DevOps. Right as I greet. But this is just part of the organization. This is not a core of the organization. Obviously, it might be a core, but this is very small part of what's going on in our organization. So we have DevOps activities, we have agile activities that I'm not here to talk about agile, but I also specialized in agile ways of working, and it goes hand to hand with DevOps. So we have DevOps and agile practices, and that's about collaboration, about tools as well. Agile is also about tools sometimes, but in general, it's how we collaborate together, developers, operations guys and product guys in the agile environment. Right? So that's collaboration. And then in the whole organization we have structure, as I said. So CTO guys need to think with other CE level people about the structure of the company, how we will be working together. So that's the structure. With whom, how and with whom, what will be the structure of our teams, what will be the structure of our departments, how CTO break the silos and so on and so forth. Then there is a strategy. This is more about how actually the strategy is with whom, how collaborate, but how to deliver software. How about our technology? We'll be using Java or net. Are we going to go CTO, the microservices oriented architecture and so on. So the strategy, technological strategy for ctos and the business strategy for executives, for CEO, how to earn money for the whole company, for the whole business, to provide you jobs, right? So that's the strategy piece. And then there is the last but not least organizational behavior piece. So what we will be doing here in the meaning maybe not even about the product, but how to behave in our organization, what are the norms, what are the standards, what is our culture in this environment, what is our language that we speak, for example, that's a lot of different activities. So that's in general broad picture of the whole organization. So you can see that your technology part even is key in the organization, is just part of it. And the organization is going through change. So we need to transform this organization from state a to state b, if you remember. So all the people, all the topics, all the aspects that we have already talked about need to be transformed, need to change and have this way ahead of the organization. Actually, I see the two ways or two buses, if I call it that way, the mindset bus and the technology bus. We already talked a little bit about the mindset of technology, right? So we need to change the technology and we need CTO change our ways of thinking and ways of working. So that's how our organization is going through the transformation. We need to transform technology. At the same time, we need to transform our mindset, ways of thinking about ourselves. So looking again about the structure, we can see the interactions that's up there. There's interaction between mindset bus and technology bus. I guess that some of you already recognize this pattern and this analogy to our computer architecture. So if we think about organizational behavior, this is an input to our mindset. So how we will be behaving, what do we accept or what don't we accept? If operations guys will be blaming developers and developers will be blaming operations, are we okay to accept that? Or we will say, no, this is not our norm, we don't accept this rule. We accept no blaming culture, for example. So that's the input to mindset bus. But when it comes to strategy, actually, when I was thinking about that, there are actually inputs, CTO, our mindset bus and the technology bus, because it's about which technology we will use and how to use it. But also, this is about how to approach this technology and what are our ways of working together alongside with this technology. If we have, for example, microservices oriented architecture, how our teams will be speaking together, or even more. And that's the next bit, the structure. So this is the analogy for me to the memory, the organizational memory, how we'll structure our teams in order to make sure that the knowledge will be stored in our organization and the experience that we have in building. For example, microservices will be stored in the teams, rather than just pulling people to projects and dispatching them after the project. So that's about structure. And at the end of the day, cpu is our collaboration. So we have our cpu here, right? Every single one of us. But in the organization, there is collective cpu. That's why organizations are getting bigger and bigger, because they need, sometimes we call it brain power. They need the brain power to think through solutions, to design the products. So we need to collaborate together. More precisely, our brains need to collaborate together to produce the outcome. So that's how it works and how it looks. And then there is a trust that needs to be established. And the technology bus, for me, it's cognitive aspect of trust. So we need CTO know that this person will deliver the solution, that he or she has the knowledge, he or she has the experience, and will prove that is able to deliver the software, and then will trust this person. And also CTO will trust this person and vice versa. If CTO have to have some knowledge, people needs to trust him or her, that she or he will deliver the idea that the strategy, technological strategy. And there is another aspect of trust, emotional aspect of trust. And this is about more about the mindset, how we approach other people, collaboration with other people. Do we trust them? If we are open with them, if we are honest with them, we don't hide ourselves or keep a secrets. We are ready to cooperate. That's emotional aspect of trust. So those two buses, for me, is also about building a trust, cognitive aspect of trust and emotional aspect of trust. I don't have time today to talk more about building trust, but as an engineers, trust for me was a little bit fuzzy word. So I dig into the details and created a special talk about trust. If you are interested, I think there are some talks out there online you can reach out to and listen. There's one effect connected with trust, the iceberg of the ignorance. This effect tells us that ceos or clevel guys know just a little bit about the troubles in the organization. They measure that this is just about 4%. They know about just 4% of the problems. Why is that? Because of the erosion of trust. That 100% of problems are known for people in the teams. Right. You know, guys, what's going well, what's not going well. And sometimes you share with your manager, if you have better trust with him or her, you share more. If not, you hide some problems. Right. Sometimes we are afraid of talking about problems. So that's the challenge, and it's going on. Right. So, to remove those barriers, we need to build a trust to bubble up the problems, not to be blamed by our CTO. We don't want to be blamed. Right. But to solve that problems. Okay. So now, looking from the CTO perspective, what are their needs and what are the biases? They have some needs, and sometimes the conversation with CTO can be tough. I know, and clevel guys, but this is because they have some needs, personal needs, as all of us, and they have some biases as well. So today, I would like to tell you something about that for you to understand more. Clevel executives. It is about needs. Based on the Marshall Rosenberg research and biases, notation is about this organization that I put the link here. You can check. There are more than 100 biases over there that people are biased. And I chose the most suitable one for sea level guys. So I divided into four sections as we talked about organizational behavior, strategy, structure, the collaboration. When it comes to behaviors, sea level guys have a need of presence, of your presence. They need to see the people that are engaged, that are ready to support ctos, and they are ready to build the trust with CTO, even though there are sometimes tough conversation. CTO need to build trust with you, and you need to build trust with CTO, so they need your support. That's basically it sometimes it's challenging. And why it's challenging because there are some biases that CTO guys can be led by. The first one is choice supporting bias, seeing previous choices as a good. Let's imagine the situation when you have new CTO coming into your organization, and she was seeing good options and good solutions in the previous company. So she will be probably bringing these ideas to the table and seeing, hey, it was good because previously I did that, it worked. But right now there is a different organization or different structure or different business environment. So that is one bias, the other one is a conservatism bias. As simple as it sounds, prefers PI or evidence over the new information. So basically, sea level guys, they are searching for evidence in the data. So if they have the evidence that something worked, they prefer doing that way, rather than seeing new solutions, new architectures and so on. Obviously, ctos are more open to new architecture and new technological stuff. But in general, clevel guys, they may be conservative in that type. Confirmation bias, seeking information to keep our internal judgment. So if you would like to implement microservices or go to AWS, we seek only about that. Everyone is going to aws and so amazing. But we may forget about difficulties in the structure piece. They are achievers, most likely sea level guys. They are achievers, meaning they would like to achieve something. They would like to discover. This is strategy in a structure. So they would like to achieve something. They would like to discover something. So they would like to build a strategy to achieve and discover new horizons. Right? And they would like to also know that we know where we are heading to them as a CTO. So they YC level guys produce strategy piece and roadmap and so on. But I would like to also understand that you know where you are heading to. And there are also three. By assisted I found impact overestimating of things because of its potential impact. If we see potential impact that they may have on the revenue, for example, we overestimate the implementation of microservices, of getting rid of our servers and moving to AWS. Ostrich does. The funny name ostrich by us is ignoring dangerous information, obviously. So focusing just on solutions that worked and with a happy path. Obviously there's not that way that all ctos will be forgetting about ignoring that dangerous information. But that's the bias that can be dragged into and overconfidence. That's very frequent bias. Being too confident about our abilities, too confident about moving to AWS in a year or so. In the structure piece, they seek consistency, stability, and clarity. So they would like to have consistent structure in the organization, stable structure in the organization, and clear structure in the organization. That's why when you have new executives coming in, they would like to make this organization as efficient as possible for them. And the biases that they can have at this stage. Clustering, isolation, seeing patterns where there are no patterns. I had one advice from my colleague. We had totally two different departments, but just one word in the name was the same. I don't remember even the word, but let's put it strategic projects. And one department, let's use that name. One department was totally technical strategic projects development, and the other was strategic projects project management. And this person saw just strategic projects and say, hey, we need to merge those two teams, right? Because it's just strategic projects. So be aware of this vividness. Focus on the most easily recognizable data. So, again, looking at the data, but focusing, you need to understand that ctos have a lot of distractions and a lot of information they need to have in their heads. So they seek for clarity. And if they recognize the data patterns, they will go under this one, even though the data might be not correct, framing, being influenced by the situation, is how the situation is presented. That's the aspect of elevator pitch, right? That we remember some examples in Silicon Valley of the elevator pitches that were not so, that the businesses were not so profitable, but the elevator pitches were so great. So that's why we need to avoid this bias. And the last one, collaboration, group empowerment, inspiration and situation and contribution and belonging. So when CTO asks you to come to the office, because they have the workshop for you, they seek inspiration from you, they seek stimulation that you will ask questions to CTO, you will collaborate, contribute, you will be empowered group to inspire CTO, because CTO is not just one person sitting somewhere and judging. He or she would like to speak with you, and that's also about belonging. He or she would like to belong to the group, because sometimes he or she is perceived as a person somewhere else in the board, and he or she may feel alone. So he or she would like to belong to the group on the workshop, for example. That's why people ask about coming to the office. And the biases at this stage, mirror imaging, assuming others will act the same as we would like to or as we would act. This is more in the group, right? False consensus, overestimation of consensus within the group. If we don't have a trust and we are afraid of conflict. Sometimes not so frequent, but sometimes the discussions that should have happened will not be happening because of the lack of trust and fear group thinking. Choosing the option that majority of the group prefers, even though it's not the best option. That sometimes that can happen even in the executive team itself when more like say, hey, we have six executives and five of them are into one solution. But just CTO is seeing different point of view. But it's difficult. CTO challenge those five people and hello effect agreeing and disagreeing with someone because of his or her personality. If we are inspired by someone, we can also be biased. All right, so at the end, in a couple of minutes I would like to give you a pro tips how to show up in front of the sea level guys in front of the CTO. Be docker but not this docker. Be a container that have a lot of information inside of you and can ship those information to your CTO. Also organization can be this container and the transformation is very slow because this container moves very slow. So you need to be bond, James Bond. Basically you need to be the person go to person for special tasks. If your CTO trusts you and say, hey, this, I don't know. Mike. Mike will deal with that definitely. You will win trust in the CTO and you will win in the organization. Build trust within the crew and the skipper. So build trust between your team and CTO. Not having a blame game, we have bad CTO and so on. Even though team have this narration. Build trust with them, try to bring them together. Know your coordinates so create a map roadmap for your team. Measure where you are. Inspect and adapt. If you can improve something and have alternative road meaning. Have alternative solutions. If this solution will not happen, keep a full steam, have the energy be energized and motivated to help your CTO because CTO seeks for people who will help him or her moving this organization. Don't wait in the port, just be brave and be vocal. Ask for meetings with your CTO and propose your solutions and drive a tagboat. Not sure if you know what the tagboat is that those small boats that moves those bigger containers, bigger ships in the port. Small tugboats can move huge ship. With this tagboat you can stabilize the ship. You can normalize the tech stack. Help your CTO be involved in the technology in a typical technology discussion as well. But also know your limitations of your technology and don't just focus on AWS because this is AWS. Know your limitations and speak with your CTO about hey, this is good solution but you need to watch out for this and this and that and look behind the horizon. This is the most important point for our technology people, engineers. We need to look behind the horizon of the business side. We are not just here to code, we are just here to grow the organization. So be the captain in your team. Drive the group towards new destination. This is something that CTO and CW guys seeks in engineers. Not just coding, but thinking about the whole business and thinking about other ships. So other companies, if they can do what they do and how they achieve results in the organization at the end. I would like to leave you with this quotation. The wind and the waves are always on the same side of the ables navigator. So be brave and thank you very much. It was a pleasure to speaking with you today. Cheers.