Tomasz Manugiewicz: CTO View on DevOps Transformation

This talk presents a CTO's perspective on DevOps transformation, highlighting the importance of a collaborative mindset and the integration of development and operations. The speaker shares insights from their experience in both the banking and telecom sectors, discussing the evolution from traditional software development processes to modern DevOps practices. They emphasize the significance of tools like CI/CD pipelines, infrastructure as code, and containerization technologies such as Docker. The speaker outlines the challenges of breaking down silos between teams and the necessity for change management strategies, including the 'unfreeze-change-freeze' model. Ultimately, they advocate for fostering a culture of trust and collaboration to enable successful DevOps implementation across organizations.

[Music] welcome back folks it's time for our final talk before we take our lunch break so hang in there if the hunger is setting and you know I always say if you get a little bit hungry it just kind of clicks your brain in it engages you even more and you want to be engaged with this because next up we've got Thomas here to talk to us

and give us a CTO view on devops Thomas floor is all yours hello everyone very good morning or good afternoon despite um the the time zones that we we are in today we have like 40 minutes around to talk about the the Bob transformation and I would like to show with you the the point of view of CTO or other SE level Executives as um I spend

a lot of time working with them uh on a daily daily basis I'm the general manager of Grant parade technological Hub um technological software software House of the the bigger group called evoke right now uh so I will tell you about my experience from this company and also from previous banking Industries and Telecom industries that I was working in so devops if we would have the inaction

I would ask you about what do you think devops is right but this is the big mystery we talk about devops we talk about tools we talk about devops culture all the things are um you know a little bit of fuzzy worlds especially culture so right now let's focus about you know defining what does it really mean for us as engineers you know I was Java engineer

back then like 20 years ago so I was no devops at that time but um remember um having discussions about software development um efficiency people may say some of the people may say this is the mindset and that's May sounds fuzzy for you but the mindset is actually what we really think about working with others how we approach working with others while producing the software the other

people will say this is the tool chain so every tool we use that's devops I mean from the model engineering work but this is a half true so this is a mindset and a chain when we compare um those two together we have full develops approach so let's focus at the beginning about talking about technology uh reminding myself when I was in the Java engineer that was

some development that I was doing I was then building jar file using Maven or rather uh I think I was using mostly Maven at that time um and I pass this jar file to operations guys to deploy to production and maintain all the software okay that makes sense so uh on one hand we have development and on the other hand we have a uh operations so talking

about development it's all about designing the software so all the architecture it's about programming then what we've designed it's about having Version Control to work collaboratively together right Gator SVN or other um other tools and then it's all about you deploying logging and then creating the logging mechanisms and so on this is about all also about the provisioning of the software and the infrastructure and then there

was operations people who were just getting the jar file or even getting deployed jar file and they were monitoring checking the logging mechanism that we implemented on the develop development side and patching so they were more like know having operational work okay so it's development operations and the whole movement that Patrick De boa starts when he start talking about devops is building the relationship between development guys

and operations guys and there is a great area how to do it right because there is a great area of deployment to the staging environment deployment to uat testing and by man to prepro prod hidden prod hidden prepro we know it right we would love to create such stages of the of the environments so this is the hidden area that sometimes development is um taking care of

and sometimes operations guys and they takes care of take care of this hidden than this gray area we also have some mechanis Modern me modern Technologies and mod approaches like infrastructure as a code we also have Docker containers orchestrations configuration management cicd pipelines logging again some automation logging mechanism monit in them the apps so this is again gray area between development of operations and depending in which

company we work we may want to do it as a developers or as operations now and that's the great area that we can start from when it comes to the devops common goal right so the devops common goal is to have developers still developing the software operations guys still focusing on um operating the software but then having those two working together and um upskilling themselves in order

to address the endtoend process that's obviously the ideal state is not that easy obviously but that's our ideal State uh we know that you know I guess that you saw this infinity loop of devops uh processes right it's all about all about modern uh tools right now on different stages so some of us use some of the tools during our work right Jenkins I think Jenkins everyone

use Jenkins G gitlab and so on H but also we have something like puppet Chef so some of us use puppet Chef Docker right so to uh for this container approach and that's the challenge how to distinguish which role we'll use which tools and uh how to work together and there is a mystery or transformation so how the SE level guys CTO sees the transformation they would

like to move from State a to State B sounds easy right so they have state a development and operations guys working in the silos and building barrier between them and the end state is to have everyone working together developers operations and some some devops uh some people say devops Engineers I would love to say that those are the engineers who enable practices those those yellow ones on

at top but between a stage in our company and transitioning to the B stage there is a um intermedial inter intermediate step which is natural so we start to break a silos and then once the silos is broken or it's is removed we find people who are willing to jump in and help so those yellows boxes the RS in the yellows boxes to combine those two groups

together um there's idea in the change management that those are three steps that um that um are named unfreeze change and freeze so this is the card Lev model of the um software not software but of the change that at the beginning you have the organization Works which works in a certain way you need to unfreeze it uh so sort of prepare an organization to change then

you need to implement a change and then once the change is implemented so new ways of working are established the devops practices and devops approaches established then say okay this is how we would like to go further so at the in the first stage you create a climate for change so CEOs CTO um they create a climate for change showing that they are willing to invest money

invest um budget in upskilling people in training people and CTO shows us also that they expect us to work together not in the silos so the expectations are said at the beginning the inspiration if we have INSP inspirational leaders on the CTO position uh they Inspire us to change so they unfreeze us right then in the middle we have those volunteers or the change agents or the

you know Pioneers who are willing to step up learn new things and share it across the uh the organization in teams so they enable the organization they change the organ ization and then the freeze part which is sustain the change so CTO expects that after this changing part is the middle part then we will establish the concrete devops processes concrete ways of working that will help us

working together obviously it's not that happening just like this overnight uh we I guess know this uh know this um diagram that it's very hard to go from the very beginning like just coding having coding and building people um in the separate departments up until you know fully develops operational environment the first step could be I'm not saying that it's always is but could be the Agile

development so agile provides you the possibility to work together to more in a more collaborative way to build a trust between you guys and uh code and build the software together then we have continuous integration which is uh which lasts up up until the tests integration right then continues delivery so we are delivering to the to to the point when someone needs to say yes I approve

it going to production or no I don't approve it that's usually the step that the change is is happening very quickly and then there you need to convince people convince your CTO convince your Chief product officers that you are the ones who can tell that this software can go to production it's not an easy thing we will discuss in a minute how to uh build trust with

with Executives to in order to get this um autonomy but if you do it then the next step is continuous deployment right so can continuously deploy to production without um manual approval process and then fully devops um automation environments all right so we talked about little bit about devops right what does it mean how we can approach that what are the expectations from sea level so let's

focus on sea level view now how they perceive the word the question is if you really want know because that's different story how word we are operating as Engineers very specialized deep knowledge our narrow Focus but de deep knowledge allows us to develop good software and good products on the other hand General generalist General leaders um and the sea level guys they need to have the zoom

out view very Broad View very looking far away to the Future like five years ahead of ahead of now to define the strategy and so on so they need to have this broad picture but they are just humans right so they don't have the full capacity to be full specialized and also have the the broad picture by the way this this graphic comes from pedman Milani I

like this guy I recommend you following uh this this this guy on LinkedIn he is very creative in in producing such such visualization all right so this is our world right as we discussed we program we have the Version Control so we collaborate on the on the code level we deploy our code we have cicd pipelines that to to the deploy it uh automatically we have containers

we orchestrate everything we have configuration management provisioning logging uring and so on and so forth right it's in under every single word here is a huge specialized knowledge that you guys have we let's call it devops to simplify that right devops practices devops tools but this is just a small piece of because when we have devops we also have agile agile ways of working this talk is

not to have the agile uh discussion but but I can tell you that agile ways of working very much helps in establishing devops so that's the another box right and thus address agile and devops address the thing uh the question with whom I would like to work so this is like a collaboration aspect with whom I would like to develop my code with whom I would like

to uh collaborate on the backlog right with whom I would like to work to produce the software then there structure structure in place on that that seeing level guys needs to think think of because obviously the answer with whom I would like to collaborate that's on the team basis but especially in the large organization there needs to be a structure uh of the roles and departments uh

the modern approach is to have flat organization fairly flat organization right but if you have huge Enterprise it's difficult to have flat organization so right now uh it's the point when the structure comes in so how to engineering people working together how to making product people working together how to have the bridge between them how to put the finance inside how to uh collaborate with HR and

so so that's the structure with whom on the overall company level and then the strategy that they need to think of so how to achieve the goals how to achieve their goals in the five years time for example uh to move the company to the next level to earn more money right because we are focused on technology but our aim as Engineers is to produce software to

bring the revenue to the company so that's the challenge we may may not be thinking about the revenue of the company every day but sea level guys they think about that and the last one the last bit is organizational behavior so what we are doing and how we are developing um the software so the behavior right I see that uh something is is is broken with the

slides I thought that um it will it will be fixed automatically but let me uh maybe switch to uh sharing the screen if that's possible because right now I have my slides uploaded to streamyard and for your experience would be better not to have it let me check if I can present from my share screen share screen okay I have this one do you see my screen

right now the thing is that if you answer I don't see the okay I see right now perfect slides show from the beginning now I don't see you but that's fine uh so let's find the slide where we were in right so devops let's put it that way from the current slide you right now should be able to see it I see that you you see it

okay one more thing that pilot needs to work okay all right so this is a little bit of Animation that's that's why it didn't work previously so we have this devops aspect the devops is a very small piece the other piece is agile collaboration as we mentioned about a and devops then we build on top of that the structure then the strategy and organization Behavior beautiful looks

looks really nice so this is the whole big picture that uh CTO and C Level guys need to take take take care of and think of and and and address so you see that if they have the broad scope of accountabilities and the broader view they are not able to then um to then Focus very narrowly of devops uh practices so we have this organization right and

that's the beautiful animation that I was working during the whole night I hope that you see that um yeah so when we have transition we need to transition the whole company transform the whole company the the whole structure through the through the change so now how to do it actually there are two I call it uh bus mindset bus and Technology bus so we need to change

the technology and tools and then we need to change the ways of working we work together we we have to work together and also our mindset how we think about the way ways of working another cool animation so those two aspects mindset and Technology by the way Thomas sorry I just want to say uh I think it's frozen on slide 20 it's frozen because yeah yes oh

you didn't see my beautiful shiny animation I know as soon as you said I was like what animation I'm missing out on the good stuff all right so let me stop sharing and maybe then try another slides because when I have the slides in uploaded yeah it's difficult for me to entire window okay looks like whoa now we should there we go all right I'll let you

get back to let me check if is now there's animation do you see it yes perfect right yep yes so I need to come back and show you the previous animations so the big organization and now this big organization is going through transition right I'm very proud of it and this transition goes with a mindset and Technology bus right so as I mentioned we need to have

proper technology to use but we also need to have the proper mindset how to work together so those four aspects organizational behavior strategy structure and collaboration are those aspects that uh CTO need to think of obviously CTO is focused on technology but C Level CTO is a c Lev role so C Level role needs to think broader as well to help C CEO or driving the forward

so as you can tell there are four aspects that I mentioned organizational behavior so how we behave how we approach other others in terms of working together strategy what's our strategy for the next three years where we would like to be the structure how we would like to shape the teams and the Departments and the collaboration how we will collaborate together in using devops practices and tools

so those those four so organizational behavior is more sort of the input to this mindset by bus right we have S such a mindset how to work together we are for example that we are open for the people who are not uh brave enough that they are afraid of learning that that can be one example of our Behavior right or we are open to people who like

to learn teach us right that we appreciate their time and we allow them to teach us technologies then the strategy structure and collaboration collaboration is more like our CPU um of our brains right it's with the connected with the technology but also connected with the mindset how we um would like to use this technology and the strategy is also connected with the mindset where we would like

to be the so so we think about that and which technology we use and the structure is more more about about mindset so um when I talk about this mindset bus and Technology bus it reminds me the two pillars that um we uh build trust on when I mentioned at the beginning of my talk how to build trust your Executives in order to allow you to deploy

to the production without approvals for example that's this aspect you have the cognitive aspect of trust and the emotional aspect of trust I'll be not talking deeply about that because that's separate talk that I have um it is on YouTube so you can you can check if you if you are interested but definitely what I can tell is that cognitive aspect of trust is that the aspect

that we deliver so we have the knowledge we have the experience we have our intelligence right and we thanks to that we deliver stuff so we deliver stuff to our CTO here or she sees that we build a software she or he asked about something that we delivered that's cognitive aspect of trust and there is another aspect emotional so they need to feel that they trust us

it's more fuzzy but it's connected with that if people are open and honest your brain subconsciously can feel that this person is trustful and the other is not trustful so so so so well so do those two pillar of trust um cognitive is about technology we use technology data our knowledge emotional is about our mindset so if we have the mindset of being open to everyone our

CTO will see that and say hey this guy is very open and would like to collaborate with everyone perfect I trust him right there is another drawback if you are just open and the emotional aspect of trust addressed but you don't deliver the results because you don't have the knowledge for example that's also difficult to build a build a relationship and trust and talking about trust that's

the that's the aspect of the iceberg of the ignorance you may have heard about it that um Executives see the only four percentage couple of percentage of the problems why is that because of the lack of trust right you as Engineers you see all of the problems then you share some of them with your leaders right if you trust more to to your team leader you may

share everything but if you TR try trust less uh that you don't share everything and then goes on and goes goes on people may have difficulties in Sharing all the problems so Executives just see small amount and actually they would like to see the whole broad of scale of problems so if you are brave enough to show Executives CTO for example the whole scope of the challenges

problems that's fine and that's that's really appreciated the only thing that I advise you is to share not only the problems but your proposition how to solve it because CTO has a lot of problem in in their heads so if you are brave enough to share and then to provide proposed Solutions uh you will be trustful CTO needs and biases okay so right now is a section

to talk about a little bit what they need why they are CTO they are CTO to solve problems right so they have some needs and they have biases those needs and biases are based on those two Theory the needs notations is based on Marshall Rosenberg research and the B biases notation is based on uh this company um the I encourage you to go to this this website

and check there's like more than 150 biases that every human being is sometimes is trapped into I chose um the the best ones that I observe in in working with se- level Executives in those four areas as you remember so the organizational behavior what they need they need presence of people they need support from people and they need Trust of people so they are human beings right

if that's for example the question why why is C Level guys ask people to come to the office however you uh come to the office and spend the whole day on calls right so what's the point and I get it that there are pro and CA of being in the office and uh personally I prefer the hybrid mode so some days in the office some days out

of the office at home but definitely they need the presence of people because because they're human beings they would like to speak with people right to listen to them to hear your their problems and being all the time online it's not it's more difficult not it's not it is possible but more difficult they need your support so if only you are brave to support them to call

them and say hey I see this challenge uh I would approach this um this way do you want me to help you that's something that uh she or he will be uh satisfied and Trust again he or she needs trust uh between you and this uh this person to rely on you that you will deliver and you will be a trustworthy person um now the biases that

they they may have is the the three of them the first one is Choice supporting bias so they see previous choices as a good for example you have new CEO coming into your company and say hey everyone in the office because I saw it in my previous company it worked so right now I see the previous Choice as a good so I will choose this approach in

the new company right so that's the bias that that that people may may want to have the conservatism preferring P evidence over the new information sort of connected with with that so uh most like the CTO CEOs they are very successful in the business so they knew how to do things they know how to do things um better and they knew from the past what to do

H now they make some decisions but if they don't get a feedback from you that this may this maybe this solution is not fit for this organization fit for purpose they may trap into this bias and confirmation bias seeking information to keep our inter initial judgment so our uh brain subconsciously because biases usually work subconsciously our brain SC The Reality Checking the information that that uh um

supports our judgment the other part is strategy so why what's the need for the CTO guy when he or she thinks about strategy they would like to achieve they are cdos to to go um go one uh mile f further to be above and beyond and all the you know the the the slogans that we know but they would like to achieve things right they would like

to develop their career develop their companies uh introduce new technologies so they are Achievers let's put it that way usually um they would like to discover new things there are people those are the people who would like to discover things from the perspective of Technology obviously but also from the organizational perspective and they are the people that they know would like to know where we are heading

to so um they have the strategy defined by CEOs or together with the CEO and they on the journey to this to achieve those goals they would like to see where we are right now so that's the whole thing with the metrics measurements kpis and so on this is to satisfy their need to to control the situation where where the organization is going through and the biases

again three of them on this strategy uh level uh impact bias overestimating of things because of its potential impact so if they they would like to achieve so if they would like to achieve something for example I don't know uh go to the cloud with AWS they may overestimate the this movement because they see the potential impact of being in the cloud technological wise professional wise uh

stability wise right but they can overestimated it and may not think of they will be thinking about costs because there is a CFO Chief Financial Officer who will ask about cost right but they may be impacted by this impact bias um the other impa the other bias is ostrich ignoring dangerous information some of them not many of them because CTO are very engineering oriented so they have

kpis they have knowledge to not ignore the dangerous information but sometimes it can be that they can ignore some information that you try to put in front of them but they they they ignore it for example like monthly releases or uh bigger releases that makes troubles but they are focused on something else and they may not uh hear you so you need to be more vocal about

that and overconfidence being too confident about our abilities that's you know that's that's the the bias that uh everyone I think in the engineering can trap into because we are usually confident about about our uh work okay when it comes to the structure what do we have in terms of the structure the need that CTO have is consistency have the stability and have Clarity they put in

place the structure of the company so the Departments um even like a guilds or or or working groups because they would like to have consistency if there is one structure in the um I don't know data domain let's put it that way similar structure may be implemented in other domains like in engineering domains because they would like to see this consistency that they see the picture of

the organization and it makes sense for them it provides them the feeling of that company stable because it has stable structure and Clarity they are clear who to ask where they have the problems they just look on the orc chart so that's the need be behind you know building the structures and uh biases clustering isolation seeing patterns where there are not patterns for example good example is

a central team uh we had a central team uh in in the Telecom organization I was working in and uh a specific name of this team I think I don't remember the the the the proper name but I was a let's put it central uh implementation steam right and then in other departments there was a team uh which was uh accountable for totally different thing doing totally

different thing but the name was implementation team and what CEO C CTO more about SE level guys did they said oh this is implementation team and we have Central implementation team okay so let's join them that's the Trap that they can fall into the the other one vividness focus on the most easily recognized data so that's the thing that when you present your data you need to

present your data in a proper way because our brain is just seeking for the the best the easiest way to uh to take the information so if you have the data proper data is not not only the the success criteria success criteria is to focus how to show them uh the true in the in the way that they can absorb it uh and framing being influenced by

how the situation is presented again that's that's a similar thing when someone pres prepares you know PowerPoint slide deck the whole structure in play and the whole idea of of new new solution it needs to be concrete it needs to be to the point they have very small amount of time for you and they they are tend to be framed by you know influenced by this how

we present the situation all right and the last one collaboration bit our devops agile practices right so what they need they need to empower the group and they need to be empowered by the group so they need to feel the day rely on the group that knows devops knows agile and will be uh will be working alongside they seek Inspirations and stimulations right what's the modern uh

engineering ways of working tell me about that and last but not least and actually very first contribution and belonging so they would like to belong even though they are on the top I can tell you they know the top they are very lonely because everyone expects something from them but they don't usually have people to you know to just speak with to have the relationship just you

know like regular one because there's a so intense environment that there's no time to do that so when they think and that's the difficult thing but when when your CTO thinks that she or he belongs to the team even though doesn't work in this team but people know him people sometimes are in the office to just say hey hello just inform what are you know what are

the important points important topics in the team that's the that's the fulfilling their need of belonging and contributing to the team and four last four um biases mirror Imaging assuming others will act in the same way as we would that's challenging when you have you know team meeting and the CTO comes on the meeting she or he can assume that you will be thinking the same as

as as him or her but actually it doesn't really work like this because you remember you are very narrow and focused with a deep knowledge and they are they have the broader scope so you need to challenge them if they think that you will Echo what they say False Consensus overestimation of um consensus with a group that's not usually that that trap that I observed but some

for some execs I observed that they would like to have they would like to belong so much to the teams that they consensus so that's consensus not not not the best sometimes is not the best agree agree with the with the broader group group thinking choosing the option that majority of of the group prefers so again looking on the majority because you can have people who are

not in the majority but they are right they are they have better ideas that don't the majority and Hollow effect agreeing and dis dis dising with someone because of the personality so you have this shiny beautiful presentation and and speakable person who presents the idea and this hollow effect around this person will May drag CTO to make some decisions but actually the true could be the better

decision could be in a different different um space all right so I have some Pro tips in the end I think we have still some like five six six minutes so very quick Pro tips for uh for you when you are interacting with CTO you know already about devops you know already about how CTO thinks CEO thinks C Level executive thingss so the protips this is a

Docker right but this is not a Docker that we understand from the software engineering this is the uh imagine this Docker is the company and this Docker when it turn turns it turns very slowly right so the huge company also turns very slowly so bond be there and be bond to um even start moving this huge ship right need to be Bond speaking with your C sure

he needs do see you that you have the valid point right but you may have the valid point but if you are not Bal not brave enough to speak with them to speak out loud during the the bigger meetings uh they will not recognize so James Bond is the is is something that you can remember B Bond James Bond um and do the mission build trust with

the crew and the skipper right so we talked about a little bit about trust if you have a trust and CTO trusts you you then can um influence the direction of this ship and I can tell you that usually this is not formal role in very informal but usually in organization CTO has one engineer that can trust 100% And if there is anything that he has or

she has in the mind go just straight to this engineer without any you know aile processor going around everything just because he or she needs immediate action and if you are in the position to be this one person for your CTO again informal role right now you you you are be you will be in the best the best position uh now your coordinates of the of the

curse so create a map of the curse understand we talk about the road maps right it also may be fuzzy word for some of us but understand where we are handing to in half year one year two years because then if you understand you can have a meaningful conversation with your CTO measure inspect and adapt especially measure because we may be afraid of setting up kpis measuring

our software measuring our work that's totally different you know topic but not be afraid they expect the measure they need measures so if you will be the one measuring and answering the questions good for you and have an alternative road so have a different um Plan B let's put that way different plan in your in your mind keep the full steam so not to be you know

uh not to drag into this un motivation aspect in front of the change you may be tired and you'll be unmotivated but if those CTO and CEOs they need desperately seek for people who are motivated so if you are motivated it'll be uh good for you don't wait in the port so don't wait that someone else will solve something and don't just complain but be active be

active be brave and be vocal and that's how you can build relationships and influence the ship so you may saw this is a huge ship but this huge ship is moved through the small tag boats so if you will be the one impacting your personal um space and be vocal about that you will be able to uh to help you will be able to stabilize the ship

you will be able to for example normalize the text stack that you use and be vocal again about that in front of that ctOS so that's the one and know your ship limitations right it's very popular uh picture of the Rena Rena ship um know your limitations not over complicate things in engineering not come up with the new new new technologies if we don't use don't need

it or complicate that so that's that's the thing look behind the Horizon so look this three years five years ahead what they see and beig Captain driving Drive group towards the new destination so be the one be brave enough to drive it now the ship constructions and uh if you have the knowledge about the technology and know the ship constructions CTO will um trust you again evidence-based

conversation is the best so having the meaningful CTL and in the end I think still two minutes why bother because the wind and the waves are always on the side of the Navigator I would like to thank you very much with this quotation remember that in your organization you have the waves you have the wind headwind for example but if you are able Navigator the ablest Navigator

right you can take the advantage of that you can help the organization you can build your career H with that so thank you very much and like two minutes for questions or even one minute to questions right obviously if uh we don't have time you can reach out uh on to me on LinkedIn and I can I'm happy to answer the questions all right guys you heard

Thomas there if you've got any questions put them in the chat now click the Q&A Tab and drop them in there stop Shing them yep thank you really cool uh conversation there Thomas I've had a few kind of thoughts off that one I think the the interesting thing that I got that it felt like what you're kind of saying is uh when it comes to CTO I

think a lot of people think you know these SE level exacts they want full control of what they are overseeing but it kind of I think the the message you're kind of trying to give there is that really what they want is someone they can trust in to empower to kind of Drive the ship oh sorry it's challenging to to hear the question I think something going

on with the internet connection I hope that you you you were able to hear me fine yeah I can hear you fine can you fine or still laggy one second let me try is that any better still okay we're back yes we're back okay fantastic see you fantastic can you hear me one second one second uh so let's try leaving okay did that change anything still still

can't hear still sounds robotic okay all right uh no problem no problem all right we'll we'll end it there then uh okay all right it looks like questions will not work today because of the internet connection at least I hope that you heard everything that I was what I was saying and again I encourage you to contact me on the LinkedIn if you have any questions I'm

happy to answer them uh as long as I have some time but definitely we will come back to you all all right so thank you very much it was pleasure to to to have the session for you I hope that the next sessions will be uh will be great and that conference time will be good for you so thank you and have a nice day