The heart, brains and bloodstream of an organization

Paweł (00:05): The beauty is in simplicity. So, I don't want to make this approach complicated. Do what you want with this, and this is the mind map. This is the connection point for you. And that's it!

Marc (00:21): This season, Andy and Marc are back with a fantastic group of guests.

Andy (00:26): I bet that depths remain classified, and Marc keeps his head in the clouds. With our combined experience in the industry, we can go from the bare metal to the boardroom.

Marc (00:35): In DevOps Sauna season three, we'll explore Platform Engineering, and the people and cultures that make it happen.

Andy (00:42): Enjoy your time in the DevOps Sauna.

Marc (00:53): Okay, we're back. And once again, it's Marc Dillon here with my cohort Andy Allred.

Andy (00:59): Hello, again. Great to be here.

Marc (01:01): I'm super excited this week to have Paweł Piwosz on our podcast. Paweł, I've seen some of the work that you've done, some of your other talks. And I've seen some submissions you've done for our DEVOPS Conference, which is coming up in March of 2023. And I just feel the passion from your work. And then when we spoke here, in the kind of pregame before the podcast, you know, I could feel that you're a storyteller, and that you have a lot to give us. But can you tell us a little bit about how did you get into DevOps, what's your approach?

Paweł (01:36): Sure. Hello, everyone, and thank you for this invitation. I'm really happy to be here with you. So yeah, I’ve got more than 20 years of experience in IT field. So I saw many things, which I don't want to see again. And in some way, I try to encourage others to not only do not make mistakes, but to make mistakes, in fact, because this is the best way of learning, right? So this is what I've done many times. And if one day, you will have an event about mistakes, I can fill the whole event with my stories. So 20 years in IT, started as a sysop and then path was like next to me, like natural way. So first of all DevOps appeared, we start to think about some change in the approach. So I started to look on DevOps, then on agile, then on value stream management and mapping. Right now I'm focusing on CI/CD in the whole scope of this and everything is interconnected. So yes, I still have like, more ops than dev experience. I'm not a developer, I can write a script, not application. Yeah, that's the path. And I think that DevOps is emerging more and more as not only a framework or connection, it's even more than that.

Marc (03:01): So you actually got into DevOps before agile?

Paweł (03:05): Yes. I’m sa big enemy of saying that I am DevOps engineer, I'm big enemy of DevOps engineer at all, because DevOps for me is not the position, the role, the person, but I started from it. And it was that learning path, the agile came to me a little bit lighter, then learning agile, I discovered, let's say, Lean, which is the foundation of DevOps really, and foundation of all agile methodologies, in fact. And I closed this picture from another way, like, almost everything in my life, so. But this gives me also the, I would like to say unique perspective on the things because when you approach things from the behind, it's definitely harder to go through this, all these wires around. So the path is not just the golden blocks. Before you need to really, really know what you do and think about what you do.

Andy (04:07): I loved what you said about making mistakes and everything. And I found a quote recently that I just love that says, “Only a fool learns from his own mistakes. A wise person learns from others’ mistakes.” And I think it's really important that we kind of share that, hey, I've seen this fail spectacularly. And this is why I do it a different way now, instead of I did this once, and it was fantastic. So I'm kind of curious what types of problems and what types of troubles were you seeing in difficulties that led you to looking into DevOps?

Paweł (04:40): One of my biggest, let's say, failures in the early days of my career was to delete the whole data files for the end of day procedure in bank. It was quite interesting what was done after that, and this was my, maybe not first, but first very conscious approach to automate things. Because here we have the process, which can be done in the wrong way very easily, because generally it was done like on 3am in the morning. So, well, we were not that, you know, sharp at the time, and we do it regularly. So, why to do it manually? So, what we can do in order to make this more robust, more stable, more efficient? In that time I approached this topic and created the scripting for it, and was like a simple script. But anyway, it was something what makes people like, relieved for this process. It was simple, it was easy. And no mistake like that happened again. And you know, in that area, I have to disagree a little bit that you cannot learn on your own mistakes. Because, you know, we have this saying that, like, fail fast, fix fast. But I would say a little bit differently, fail fast, fix fast, learn fast. So it's not the problem if you make a mistake, it's a problem when you make this mistake again. So it means that you didn't learn anything from it. But yes, it's the learning process also for others, this is very important. And if someone else did this mistake, why to not learn from it, this is the best way for yourself.

Andy (06:30): If you don't learn from your own mistakes, that's really, really foolish. And I've made quite a number myself. So nothing wrong with that. It's what makes you smart. 

Paweł (06:41): Yes, this is the best way of learning.

Andy (6:44): Exactly. And then the key thing is that that is a fantastic way to learn. But it's very inefficient if everybody learns the same thing by failing first. So let's talk about it and kind of learn from others at the same time.

Paweł (07:00): Yes, exactly. That's why during the DevOps Academy, which I lead, I prepared a couple of tasks, let's say, where the troubleshooting is in scope. And how to troubleshoot things, you need to have something broken. So I have couple of, for example, for Linux, I have couple of machines, which are broken by me deliberately. And people need to fix them. So they need to troubleshoot them. So even if they do kind of mistake later, they have at least some muscle memory, hopefully, to fix the things. And also, before they hit enter with some commands, they may be think, “Oh, this may lead to something like that. So maybe I shouldn’t run this command.” So yeah, that's a simplification of the whole process. But definitely yes. And honestly, the mistakes are, first of all, the great learning process for others. And also, great learning opportunity for the troubleshooting skills, because troubleshooting in working system is not troubleshooting at all. So how to teach it, let's say this way.

Marc (08:10): You reminded me of a conversation once. I knew a couple of guitar builders that would build guitars by hand. And one of them would kind of go where the wood took him. And the other one was a German guy asnd he knew exactly what he wanted. And they were having a discussion about these kinds of techniques. And the conversation between them went like, “The level of craftsmanship is how well you cover your mistakes,” was from the German perspective. And then from the American perspective, it's like, you know, the woods tell you which direction to go. So it's like your mistakes actually lead you into a certain direction or not. I think there's a lot with what Paweł is, and Andy are describing here.

Paweł (08:53): Yes. And that is always the sweet spot in between, right? <laughs>

Marc (08:57): Yes, indeed, I've saw on your website that you have a really interesting mind map. And I have to tell you, this is something that we've actually kind of been looking at inside of Eficode when we start to assess company's capabilities. And you know, we have lots of products, lots of DevOps kind of companies can come in and look at what you're doing and help you kind of understand your capabilities. But I was absolutely, just I think it was beautifully done. Can you tell us a little bit about how did this happen and where are you going with it? How are you going to use it? What are you doing?

Paweł (09:35): Thank you for your kind words about that. So it came to by accident, let's say, as greatest inventions in this world, right? So I already positioned my mind map our greatest invention, okay. It came to me like couple of years ago when I used to work with one customer when we had to design approach to many things. One was, of course the architecture, but also from the DevOps perspective, to establish the pipelines, establish the process, establish the CI/CD vision for the team. And I was thinking how to start with that, because you know, the discussion is good. But for many of us, visualization of the discussion is a way how we can remember and connect the dots. Colleague of mine, the architect, was using the mind maps. And I thought, “Hey, this is the way.” So I spent some time to just pinpoint the most important elements which I want to discuss, then we discussed those elements. And after the discussion, I spent my time of course, as well, to connect the dots between the elements in this mind map. In other words, it was very easy to see that, for example, this way of doing things is completely not negotiable in another element. For example, the branching strategy is not compatible with the deployment form strategy. Of course, we can do it, but it will be definitely harder. Or we have this limitation in the security area, which this allows us to use specific tool for example. Based on this, I started to think how to grow this approach, because it helped me a lot in discussions about CI/CD, how to design, how to understand the CI/CD. And I thought, “You know what, there is a problem. And this is not only the problem in DevOps area, but in agile area at all.” So for example, if we talk about scrum, we position scrum very often for the team. But it's not the team who sells the product. It's the organization. And many times, very often, this organization is a big one, and have multiple teams. And they need to scale somehow the scrum. So we have SAFe, we have another approaches. This is the one element of the puzzle, which was interesting for me. And the second element of the puzzle was also from the technical perspective. So we allow the teams to select the tooling, they select the approaches, etc. So in fact, we created or we allowed to create small kingdoms in our organization. It means that we didn't have or we do not have the control of the toolset, sometimes licensing, etc. If we can end with having free themes with free tools from different vendors, or license at free times, doing the same thing. And that was the second element of the puzzle, which I joined. And on the end, I came to think how to expand this idea. And the mind map was there. So I started to work on this mind map with very, very specific idea in mind. This approach, I call this framework, but this is maybe too big word for this. This approach is not creating any roles, any specific processes or anything like that, this is just the guide, where you think about the CI/CD, the process of CI/CD, who is responsible for what, what is done why, here, there, why, when, etc. So this is something what can be used, like from now, by everyone. So I wanted to create something very lightweight, something what I thought is already done, but looks like it's not necessarily there, because I had a lot of discussions about that yes, we fought about something like that, but we didn't know how to start. So I just spread this sparkle of my bright intellect in this way.

Marc (13:47): I really like the fact that you kind of just put down like you said, it's not about specific processes, definitely not about specific tools. But it has this kind of immutable quality to it. It's like everybody needs to understand or at least talk about these things. And I think that's where the value really comes.

Paweł (14:06): Yes, I agree. Also, the nice thing about this mind map itself is that you can start in wherever you want. So there is no starting or ending point, you can start the discussion in any area you want, and go through any areas you really want. And it will work for small teams, and it will work for a bigger organization. So that's, I think the beauty of it. That was my goal really to do something that is scalable by design.

Marc (14:39): Am I the only person that here anyway, that always looks at a mind map and starts on the same area?

Paweł (14:47): Well, I think it depends on the mind map, right?

Marc (14:50): No, it doesn't. All clock start with 12. And usually, my maps don't have something at 12 so it's at one o'clock. And when I picked this up, I was like, “Okay, branching strategy is first.”

Paweł (15:04): Logically it is first <laughs> because this is where the CI/CD starts! And generally, I started this idea from it. It always depends on what is the issue you want to answer. And why you start to using some specific approach. Because if you will have heavily in your mind that, for example, the security and tooling and this is your area of interest right now, you probably will navigate with your eyes do the proper branch. But if you start something generic, I think there is still some work for me to make this generic view a little bit better than it is right now. But you can do it as well. So this is also something what I don't want to force. If you want to go just around the clock, please go. If you want to go counterclockwise, go! In my mind, always about DevOps and before about sysop, I have one sentence in my mind, “The beauty is in simplicity.” So I don't want to make this approach complicated. Do what you want with this, this is the mind map. This is the connection point for you. And that's it.

Marc (16:19): I used to have kind of a starting point when I would start to look at a software organization, if I took a new job there, or if I was interviewing or being interviewed or something, I always used to think about, you know, like, is there a smoke test and work backwards. And then is there any level of product management and work forwards or, you know, start on the right and go left and then start on the left and go right. How do you approach like, if you were looking at a company, how they do their work, what kind of approach, of course you're going to ask questions and things but like, what's your go-to?

Paweł (16:55): This is very important topic, because here we have Conway's Law, right? And it is very important to understand the logic inside the company, the organization, and how the communication looks like because this is presented later in the designed architecture, design software and created software, really, and this is the first place where it's nice, let's say to learn how it works. So what are the communication channels? How people are communicating with each other? How it works, really. So I would start there on the beginning, talking. So maybe we should have another dev*ops, which will be devtalkops, but this is something what I prefer, in this case, talk with people and honestly, look behind the lines. It's very important what they say. But it is also very important what they do not say. With experience, of course with years in specific areas, with years in IT, you have better gut feelings about things, I would say. But what I learned that, you know, this approach can be quite beneficial.

Andy (18:12): I like when you were talking about the different team and everything and small kingdoms. And then we usually talk about silos, but you use small kingdoms, and I thought that’s sometimes even more appropriate. And then when Marc asked about, what do you look at first on mind map, I also went straight to branching strategy, because it's kind of the number one clock position. And then just thinking that every single team is like, well, this is a way to do branching. It's the only thing that makes sense. And then you brought it back also with Conway's Law of, you know, what you have, you know, the way your organization is structured is how your product comes out. And then just thinking how many of these companies who I have worked with that their branching strategy is completely different in every team, and every single one of their products delivered and looks nice. And none of them seem to work well with the other ones. It's like they came from different companies. Just the way you were talking about this and bring it up. He kind of my mind focused on exactly this, that because the teams don't talk with each other and don't talk around a common framework like this, they end up fragmented on seemingly trivial things that turns out to be that the products just don't feel like they came from the same place. It almost feels like it should be obvious, but somehow, it's not. So how do we make it more obvious or reveal it?

Paweł (19:36): That's right. And even very often that when you look on AWS console, and especially when you want to delete resources, it should be like very common thing. But you need to confirm for many resources, you need to confirm that you delete the resource. In one type of resources, you need to write “Delete me.” In another you need to write “Confirm.” In another, you need to put the name of the resource. So even that simple thing, and this is also visible here, one team will use Git flow approach, second will use trunk-based development and everything looks all right, as long as you start a look on the whole picture, but also like I call it like instant zoom in, zoom out, right? So here, there, you'll start to see these inconsistencies inside, this may not lead to problems, maybe. But the point is that if you have a process or two processes between two teams, which should cooperate very closely, because their alignments, their components are very tightly connected, and one has completely different process than another, in case of any issue, there maybe, really, really serious problem. A good example can be with rollback strategies, right? We have two types of rollback strategy. Rollback back and rollback forward. What can go wrong with two components, which are very tightly connected, where one component will be rollbacked back and second forward? So it may work, yes, why not? But I'm not very convinced this is a good idea. So the point is to look on, I think, at least point is to look from the issue perspective. And from the issue perspective on let's say product level, where our being as a company is in risk, how quickly and how well we can recover from it. Having this picture, gives us this perspective on the whole components there. I'm not sure if the approach with Chaos Monkey will help here because Chaos Monkey works a little bit differently. We probably have to have kind Chaos CD Monkey or something like that, which we'll do think more deeper than then just, you know, turn on/off some services. And this is kind of another word here I think. In my perspective, how team is organized is very important, of course. And we can have the self-establishing teams, self-organized teams, etc. It's perfectly fine. But at the end of the day, it's not the team who sell the product in the market. It's not the product itself, the product is something bigger, and contains not only IT, contains business, contains marketing, contains many, many other elements, which are also important and we cannot forget it in our simple work in the trenches.

Marc (22:49): Hi, it's Marc again, if you'd like to hear more, Paweł will be speaking at The DEVOPS conference in March 2023. This is an online interactive event where thousands of people gather every year. I'll leave a sign-up link for you in the show notes. Also, if you'd like to see Paweł’s website, it's cicd.run. There you'll find his DevOps model and a bunch of other cool stuff. Now back to the show.

Marc (23:18): I'm going to connect the dots by reading your words back to you, because this is one of the most brilliant things I've seen in a while. If DevOps is the heart of your organization, then value stream management should be the brain and CI/CD the bloodstream.

Paweł (23:33): Yeah, I'm quite proud of this. <laughs> And this came from one of the customers that DevOps is, let's say, heart of the organization and CI/CD is the backbone. But backbone, even if it's flexible, like CI/CD should be, is not proper, in my mind, this is the construction, only the construction of the things. And CI/CD is the alignment which delivers, like a bloodstream. And this bloodstream is controlled by heart, which is DevOps in this case. This is one of the most important parts of DevOps, I think. And this need to be controlled by something. And this something is, of course, brain. Brain is saying to heart, “Pump more, pump less, etc.” And the same has happened here, but the brain needs to understand what to do, and how to understand it. And I think at this point of my career, that the value stream is the best tool to understand that because value stream is giving you the holistic view of the process, where you have problems, where you have bottlenecks, where you have waste, and also from the proper perspective, where should you look first, because it's not the big deal to just fix the easiest bottleneck, but it may create even bigger bottlenecks somewhere else. So you need to be very smart on how you approach to this. And without understanding the whole scope, you will not understand where to start. And this value stream, when we map the value stream, I think the majority of it is covered by CI/CD, if we think about CI/CD from the start of the code to deliver to production, this is the pipeline. And of course, it's not one to one description, but still big part of this map is covered somehow by CI/CD, so the connection is there. So even if the blood is not going directly inside deeply in your mind, or in your brain, it still controls that.

Marc (25:44): Yeah, and the thing that's interesting to me is when we do a value stream map of, let's say, a cycle. So what you talked about, Paweł, the code cycle, and we show that it's kind of a garbage in garbage out situation, then we go to the head of the chain, and we look at the portfolio management. And we look at the product management. And we look at how the service desk tickets are processed; we look at how sales information and CRM is working as the front end of that value stream. But you also said an interesting word in the quote that I read here, which is you talk about value stream management. So would you like to tell us any stories about the activities or the actions in managing an existing value stream?

Paweł (26:34): That's always a kind of tricky thing, because, you know, the main reason why this kind of exercise is not working well for many companies, is because not the proper people are inside the process. So the problem is that in order to properly work with value stream, the same is with DevOps and with agile, really, it needs to go through the whole organization, from head to feet, everyone needs to be involved in the same way. So those people in the team, their management, and also the C-level, this is very important here. Why? Because C-level has the opportunity, I'm not saying that they are using this, but they have the opportunity to somehow disturb the flow very easily, saying for example, yes, I understand you have a scrum and sprint etc. But this is my task, which is the most important in the world. And everything is gone. So this is here, a very important. And what is the power of the value stream mapping in this management is that map is showing this graphically. And also, with numbers. And this works. Because from the high management perspective, they look on the numbers. And those numbers can justify things easily or, hopefully easily if you do the mapping properly. But the mapping here is only part of the process. Because it's easy to map the existing process. It's easy to say, okay, this is my future state and what and then is the whole process of pushing this forward. And this make the things really interesting, because this is the place where you can fail easily, I would say.

Andy (28:36): Yeah. And you know, we've been talking a lot about the value stream mapping and looking at everything and especially, I really like this framework. I'm just looking this again, and I really enjoy it. And I just thinking that there's a lot of stuff in here is that really just makes common sense. But then I've been doing this for decades, Marc's been doing this for decades, you've been doing this for decades. So it makes sense to us. We were talking earlier about all the mistakes we've made. So we've learned from those, and we figured out that hey, branching strategy, rollback strategy, deployment strategy, of course linked together, it's obvious, but it's not obvious for everyone. So I think having a framework like this is really interesting and good, not only to share with everybody else, hey, here's like a checklist of things you want to think about and a visualization of how they kind of linked together but also as a checklist for us as well, that then I remember, oh, that's right, this kind of rollback strategy. I remember the time when, so now we want to make sure we avoid this.

Paweł (29:43): Yes, that's true. This is kind of a reminder for us even. So why we write notes, when we do things, why we write procedures for us in different kinds of tools? Why we have READMEs in GitHub repositories? We know that stuff, we can even figure it out if we don't know that but why to reinvent the wheel? Someone did it before. So why to not use this knowledge and not waste our own power time, whatever to do it again? I think that even 10 years or even more, after I did my last end of day procedure in bank, I still remember 80% of it. And probably I can do it from my head right now. But I will never do it without the procedure. It's very easy to just forgot about something about one argument or whatever. When we talk about different frameworks, different methodologies etc, very often we say this is a set of best practices or good ways of doing things. And I think that this is the best way of thinking about that kind of mind maps. This is the helping hand for you. It's not the law, it’s just the helping hand. So to ensure that you can discuss everything what you want to discuss, and nothing will just elude you.

Andy (31:09): Working as a consultant, pretty much every single time the answer always is, it depends. And the tricky part is, it depends on what? How do you know what does it depend on? So I really like this framework, which maps out value streaming, and environments and measurements and KPIs and branching strategy and monitoring and security. And it's a checklist to go through everything. But it really gives a good visualization of when I'm thinking, what's a good tool selection? What's a good decision to make for X, Y, and Z? The answer is, it depends. It depends on what and here we have a list of things to look at.

Paweł (31:52): Yeah, that's true. And you know, the thing is that we should look and I know how it will sound, we should look on our kids, what our kids do. They ask, why, why, why, why? And with some why in the chain, you start to feel uncomfortable. And this is the point, this is the root. This is the place where everything starts, why you need to do in this specific way. So really, this, we have different approaches to why, three why, five why, eight why, whatever number you want about anyway going with this why that deep that you'll feel that, yes, finally, you touched this problem. Because when you just answer, that means that you know why you did this. So what happens that it came to this why. I think that this is quite also important to take this approach.

Andy (32:55): And I've also kind of learned that there is no such thing as best practices, there's just good practice is given a certain set of constraints. And then knowing what constraints there are which affecting this decision, helps you understand that. And you get to that by asking why.

Paweł (33:15): Yes, exactly. So the example here can be very simple. When you start analyzing some solution, you can easily say what the crazy stupid things you've done here? But it will lead you to the black hole really. If you understand why, it was done this way, because there was a good reason for it. This is the answer. This is the place where you can start to craft evolution or change in this place. I believe this is also a very important element to understand that this questions, everything is coming to the question why? What is the historical reason for this specific solution? And then everything is clear that it’s not just stupid idea, it’s the best idea from this specific set of requirements.

Andy (34:06): The junior consultant goes in and says, “This is stupid, what kind of idiot came up with that?” And the client says, “That would be me, thank you.” The senior developer goes in and says, “This is not what I would have expected. Help me understand why this was a good choice.”

Paweł (34:29): Exactly. 25 years[ago], I tend to laugh at 25 years...I came to IT not to talk with people! But today IT especially in the area of DevOps consultancy and agile this kind of sphere is people business. And we need to learn this, like soft skill or human skill, or whatever we call it, in order to understand each other a little bit better because yes, we get rid of silos. Did we? And we need to build competency, which is more vast than just our area of expertise. And this human touch is very, very needed here.

Andy (35:19): Yeah, given my background on submarines, we had all kinds of technical stuff. And sometimes silos means a little bit different thing. <laughs> But that's another discussion. But there's all kinds of amazing tech that I worked with in the military, and doing electronic warfare and stuff, there was so incredible, unbelievable stuff that I got to play with. But one thing I learned was, every single thing we were doing on the tech side was to help a human fulfil a mission. And so even though I’m really the tech guy and the IT guy, and I'm the one who's going to be in the server room till three o'clock in the morning, because that's my hobby and I think it's fun. But the interacting with people and understanding how the people work is where all the value comes in. That's the point of the whole thing.

Paweł (36:08): Yeah, that's true. It's quite tough to develop all of those skills, because there are so different. And even in the technical area, that when we were in silo, it was simple. We had one operating system, we have one application, maybe one database, we have help of DBA guys who manage this database inside. Simple thing, right? And even then, 25 years ago, I've heard that in order to stay around with the system, you need two years of experience. Today, something unbelievable. No one will spend two years on the technology to, especially in DevOps area, because the technology is changing so fast. We need to have different approaches. And maybe good enough approach is good enough. Also this people aspect. And sometimes I heard from my colleagues, if we work together, I work, you, Paweł, you will talk. So I'm for talking and someone is for work. But still, this is very important alignment, building this relationship, building the trust, building the understanding between the parties, build the agreement, let's say that we work towards the common goal. And this common goal is to make our lives happier, that's the key. Sounds easy.

Marc (37:29): What better way to do that than to bring people together across the entire organization to look at the value stream of how they actually, you know, understand the opportunity, develop it and turn it into an offering. So I think, you know, I've never thought of value stream mapping and just such a human kind of way before, but it's really, it's about every single human interaction, more than the processes and the tools that are there.

Paweł (37:56): Yes. And when you have that proper culture in the organization, when let's say, junior developer is not afraid to say to his own CTO, that, hey, I have a better idea here, or I have different ideas, let's say this way, this can lead to not only to better solution, technical solution, but also to better connection inside organization. This is really what we want to achieve. Of course, it's not my company, someone else own it. But how deep I feel responsible for this company is also important for the quality of my work, quality of my life, quality of the life of my colleagues. So, there are many layers on this.

Marc (38:44): This has been really fantastic, Paweł, I can't wait to see you speaking again. But I've got two more questions for you. These are personal questions and something we've been asking everybody that comes on the podcast. The first one is, remember back when you were a child, the first thing that you wanted to be when you grow up? What's the earliest memory you have?

Paweł (39:04): I think it was the pilot. And very quickly after that, it was like astronaut. Because I came to the let's say, astronomy very quickly in my life. I think I was six or something like that when I read or I just look on my first astronomic kind of book. And yeah, I think it was a thing. Then the second because of my eyes, etc. The second was to be astronomer, but I'm the IT guy.

Marc (39:31): Read shifts and blue shifts. Yeah. Cool. All right. Second question. Was there a point in your life where you either realized crystallized that you're on the right path or you realized, oh, I need to change the road that I'm on?

Paweł (39:46): Yeah, it's happened a few years back. It was quite tough period of time in my life. I believe this was also the trampoline for me to be where I am right now. So it was like more, maybe not a-ha moment, but oh, sh- moment that the direction where I go is maybe not perfect for me so I can use the thing what I want to do, but not necessarily go into that direction directly. And that's why I started to bring more agile approach, this human approach into DevOps. Yeah, it was, I think that everyone has this kind of moment in his life. So there is a situation which brings some better understanding of yourself.

Marc (40:38): Excellent. Once again, Paweł, we could do this all day, I could easily talk to you all day. But thank you so much for being on the podcast.

Paweł (40:47): Thank you very much. [unintelligible] a good politician. So I cannot speak quickly, I need to talk for two hours.

Marc (40:55): Okay, and thank you once again, for the support, Andy.

Andy (40:59): Thank you, this has been really fun.

Paweł (41:01): Thank you very much. It was really great to be here.

Marc (41:08): Before we go, let's give our guest an opportunity to introduce themselves and tell you a little bit about who we are.

Paweł (41:15): Hello, everyone. My name is Paweł Piwosz, and I tend to think about myself as a DevOps kind of coach. So I try to join multiple areas in the DevOps work, human touch, technical stuff, processes as well. And I created a framework, let's say boldly about it about the CI/CD or how to design, how to approach to CI/CD. And I believe this may be useful for you to look at and to use in your work. I got a lot of experience in IT. But right now, I work as a consultant and also lead the DevOps Academy where we shape new types of engineers, hopefully with the big success.

Marc (42:01): My name is Marc Dillon. I'm a lead consultant in the transformation business at Eficode.

Andy (42:05): My name is Andy Allred, and I'm doing platform engineering at Eficode.

Marc (42:09): Thank you for listening. If you enjoyed what you heard, please like and subscribe, it means the world to us. Also check out our other interesting talks and tune in for our next episode. Take care of yourself and remember what really matters is everything we do with machines is to help humans.