DevOps Topeaks

#33 - Soft Skills

• Omer & Meir • Season 1 • Episode 33

Share episode

Send us a text

This week we talked about soft skills, based on our conversation from last week (Ep #32) it was important for us to cover a topic that's often ignored - communicating ideas, reviews and so on.

Links 

  • https://mistral.ai/

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

Oh my ready. Oh my ready. And action. Slowly. Soft clean. There is something. Why are you doing this thing so soft today? Because I mean friends and in friends everything is very delicate. I thought it's because of the topic of the episode but okay that's that's also pretty special. That's even better. Okay so today's topic is on the other revealed is DevOps. Soft. Soft DevOps is how you can take DevOps and softly press into him. With that. That's the topic. Yes so today it's going to be DevOps soft skills and we have no idea which episode it is. So I think it's 33 because last week I started writing the episode numbers so it's easier to follow last week was 32 so it's going to be 33. At least someone is following. Okay so are you ready for us today's topic common? Yes. For the first question of today's topic. Yeah I am very exciting. Yeah okay. What is the first thing that comes up to your mind when I say DevOps soft skills? The biggest missing part in every engineer I've ever worked with in the industry specifically DevOps. Now maybe I'm not maybe first sure I'm making a huge generalization here but DevOps engineers they don't tend to be I mean it's me right I'm speaking about myself so it's not like taking a group from making a generalization but they sometimes have this vibe of maybe a little bit condescending or a little bit less on the communicative side. I'm trying to put it very softly okay I'm trying to kind of walk on eggshells and not make any harsh statement. Not the best communicators in the world. Let's put it at that and soft skills is the entire area of not the hard skill. It's not typing on a keyboard and knowing the best commands and knowing how to work with Kubernetes or knowing how to you know run phenops in the cloud. It's about communicating things, explaining topics and on the flip side of that is learning how to learn and understanding that you don't know everything in the world. Probably you don't know most of it and you can learn from others. You can take feedback, criticism that's also a soft point or corner that we have. That's the essence of it. Okay, interesting. All right, make sense. Everything you said makes sense. I'm sure there are a lot of things that we're going to cover in this episode. So as I usually like to do, I asked JPT about it and he wrote down a few bullets that we're going to go through some of them. Well, it's like a very very short list so we can go through. All of them is going to be very quick. Before you start, before you start, what do you think, what does it say about us as humanity that in order to cover soft skills, which is literally the one part of our job that has to do with humans, we go to JPT and ask the bot, ask the robot, how can you help us with that? To be completely honest, it means that we are lazy and we just want to get easy answers without thinking up front, without putting anything. That's a good answer. It's not the end of humanity in your eyes. It's just the laziness of humanity. That's good. I don't mind being lazy. Okay, so I'll give just the big bullet points and then we'll dive each in each one. So the first one is communicating with developers. Second one is communicating with team leaders and then communicating with stakeholders and then other soft skills. So now let's start. So let's divide this. Maybe we can divide this episode to these four chapters. Yep. Okay. Both sections and then dive in each one. So the first one, I'm not going to leave with chat really real. They just want to read the bold stuff. Okay. So communicating with developers, speak their language. What do you have to say about that? Wow, that's actually a perfect thing that JPT came with. Speak their language. It's a lot to unpack. But to me, when you say speak the language is, again, I'm trying to put things in a soft way. For some reason, I only have harsh words. Maybe that's how I speak English. To speak someone else's language, obviously we speak the same language, be that our own native language or English. But we need to kind of use the same terminology. What I mean by that is that if you're constantly working with AWS Cloud and you know the terms, you know what I am is, you know what SSM is, you know what an easy, well, easy to rather simple, but SSM is a good example for that. Someone asked me yesterday, what do I do? I need to SSH into an instance. So I was busy, right? So I just responded SSM. Fig like expecting for him to understand exactly what I wanted. I was lucky. This point is a friend is a senior engineer. He know exactly what it was. But it happened to me with juniors in the past. I just read SSM. I would think SSM means stop sending messages, but whatever you say. I now can't unlearn what you just said, but yes, exactly. So that was part of what I wanted to happen. I wanted him to stop sending messages. I wanted to keep focusing on my work. And on the other hand, that's by the way a perfect bad example for how not to communicate stuff. I didn't answer anything, not high, not by, not this is what you do. I just SSM, SSM, like a robot, go figure it out. I then figured, I immediately understood what I'd done and had them. Like I left my work. I explained what I was doing. And he actually asked me, can you, can you help me understand more thoroughly that I can do it alone next time? That's a senior engineer. Most of them wouldn't do that. But I explained, I thought, you go to IM, you add the role that the instance needs, then you make sure that the instance profile has it, yada, yada, yada, yada, and then you can log into the instance without it having to be connected to the internet, and you don't need the SSH key. Bad example from which you can learn on how not to communicate things and what's to be expected. Now you talked about the language. So a language would be don't tell them SSM, tell them there's a system in AWS. If that's something niche, there's a system in AWS that helps you does kind of like an SSH connection only that it can do one, two, three. For example, in this case, you don't need to be connected to the internet, you don't need the key, and so on and so forth. What is it? Okay. I'll just elaborate on what you said. So when it comes to the language, I'd also say that if I know the developers, I'll talk in, let's say, web developers talking about TypeScript, and let's say we are discussing about Docker. Now, I know they're not proficient with Docker, but when they see up get update and up get install, so then they can get confused. So I'm explaining them. It's to them as if it's like NPM install. So every time I try to explain something, I love to give an example from their world. So speaking of their language to me, it's like speaking in their world. Like if it's a Python engineer, I talked with the Quailments TXT, Node engineer, you know, package JSON, you know, or whatever. So this is how I like to explain stuff. And when the result team comes with their MATLAB stuff, so what I love to do, I tell them like, okay, so in Python, we have requirements TXT, that's our packages. How is it in MATLAB? And then they also, they have more empathy to what I'm about to say because I'm explaining it through what they already know. So they're more engaged, you know, so I like to make them more engaged by using their actual programming language or language terms in, you know, their professional language terms. So this is how I see it speak their language. Okay, I want to take you on an adventure for a second because what you said is so important. First of all, it's just, this is important for everything. For every type of teaching or delivering content, you want to wrap the, the thing you're talking about, not in, it's, it has two parts. One, put it in language that the other side understands. Another part is putting it in a story, in an analogy, in something that kind of packages the thing. So it's easier to digest. I don't know what movie was it, maybe do it whereas my car or euro trip, I don't want, I have a scene in my mind that they're riding in a school bus, it's like four people. And one of them is trying to learn for a test. He needs to take a test in the university, and the other dude is trying to teach him, and he asked him, how would you teach him, and he only knows, I don't know, basketball or baseball or something like that, and the teacher, supposedly the friend teacher, they asked him, how would you teach him history in five hours? And he says something like, I can teach a monkey about history in 10 hours is if you tell me what his hobby is. That's something around that narrative. And, and that's exactly, and that's why I kind of recall that because it's taking something the other side knows, in a language they know, in a topic they know, and then they can relate. So it's exactly what you said. That's it. Very random. So I love it. I love this analogy with movies, you know, I always like compelling to movies. So I'd say we'd cover these big hair language. Ready for the next bullet? Yep, we are still communicating with developers, all right? So in communicating with developers, we got the code reviews. Tachis, I don't want to expand what Chagititi said about it, let's just see if we can talk about it. So communicating with developers, code reviews, do you have anything to say about it? You can take it to any direction only, you know, we're not really specific to what he said. So yeah, I think this goes in two ways. I'll take it to what's comfortable for me. I always think that DevOps engineers and I'm air quoting here shouldn't be a job. There's ops and they're developers and these should the entire meaning of DevOps is these two groups. Let's call it are coming together into either one unit or at least working together very nicely. And the way to do that is for each of them to speak the other side air quotes language, right? So developers should understand cloud Docker infrastructure stuff like that. And I think that ops engineers need to at least to some degree understand the code of the developers. It doesn't mean be a developer, although that would be great, contributing code to each other side would be amazing. But at least contributing something. And what I want to say about that is that pull requests and code reviews should work both ways. So if I'm a developer and I need some kind of an infrastructure that's relatively easy to add. For example, I have a Terraform repo for the entire company and I'm missing one port that's opening a security group. Not saying that's a good example or anything is just something that's simple enough to go and change in Terraform and then having the ops engineer review my code, right? I want to be to that to work exactly the same as the other side. So if there's something that you need to handle within the application, maybe the port is wrong with something like that or the Docker fight within their repo, or even code. Maybe they have an outdated dependency for you as an ops engineer to be able to open a pull request and have them review the pull request. Maybe even contribute something to the literally the logic of the application, but having both both sorry work both ways. Each side can contribute to the other and each side can review the other ones code. And that kind of creates a same level communication because you both review each other's code. You both kind of each one has its own expertise and you help each other and you can work together rather than someone is just writing code like a monkey. And there's, I just tell you, you do that, you do this, you improve your Docker fight, you open that port, et cetera. That would make sense. Yeah. Yeah. I totally agree. Yeah. If I can even relate it to speak the language, I'd say it's important for the code reviews to be clear to the other side as you sort of mentioned, like it's got to be perfectly clear. Like if I added something in the infrastructure, so the developers need to know about it in my pull request over the other way around if they install the new dependency and I need to go through the pipeline of vulnerability checks or scans or whatever. So it has to be clear that it's going to go through it. Okay. I don't like this example of code reviews by the way. This bullets, I would skip it. I don't think it's related to soft skills. I think it's more related to automating pull request, automating stuff. But, you know, I object it. However, I must say it's a good example about that because sometimes we feel that within pull requests, maybe because you're writing comments within GitHub and actually speaking face to face to someone, it's kind of an automated process and then you can just write simple stuff, but that's also part of communication. And that's human, although it's based on a platform and it's done in a specific manner or a structure, it's still communicating with another side that has feelings and thoughts and that's you're basically reviewing someone else's work. I have some sense to say about it, what you've just said. Okay, so now that I relate, it's completely to soft skills. So make sure your code reviews are constructed and not criticism. Okay, because nobody likes to get criticized. So it almost tells me, like, let's say we ended this episode. The normal tells me, listen, I didn't like the way you talked in this episode. It wasn't good. You should improve yourself. You should, your English should get better. I'd be like, what's wrong with OML. But if OML told me, listen, I learned, okay, now OML is going to do inception to me. Okay, if OML told me, listen, I just discovered a new website that makes your talk very, very good and I also learned from that. Do you want me to share the link? You'll improve your English and it will upgrade our podcast by many levels. Okay, it will take us to the sky and I'll be like, wow, I want to learn about it. You know, you want to think of the outcome, but also think about the way the other person would think when you do a code review to him or her or whatever. OML, you want to answer that? To be honest, that was, that was perfect. That's literally the essence. I have nothing to add on top of that. I'll just say, regardless of that point that I've said in the past episode, and I'm going to say it again, I think the number one skill, I'm obviously when I hire new people and when I interview them, though number one skill, I take a look at if the communication between us and the ability of the other side to communicate what they feel, what they need, what they want both in writing and in face-to-face conversations. I also think it's not only related to developers, like the code reviews and the criticism and the constructive. Anyone use anyone to anyone, even between DevOps engineers, between team leaders, between stakeholders, like anyone. Yeah, a proper review, not criticism review. Okay, so moving on to the next section, communicating with team leaders, like each section has two bullets. So it's nice, it's very short. Okay, so the first bullet is metrics. As you like it, the metrics we like in the bullet of communicating with team leaders. Yes, yes, so it's not matrix, like the moving or matrix. Yeah, yeah, matrix. Metrics, I get it. Yeah, so for key point indicators and whatever, so metrics, what do you say about metrics and communicating with team leaders? It's hard for me to connect the two, but I do have a lot to say about communicating with team leaders. And for once, I want to take the side of the team leader and speak about that. I think one of the most important aspects of managing a team or a group or any size of a team of people living it. That's one is communicating thing, which is what we said earlier. However, when the direction of the conversation starts from someone who's by definition, leading someone or leading something, like a component or a segment within the company. And he has kind of his on top of you in some way, right? He's a leader. He has maybe you can think air quotes that his words mean more or maybe he makes the decision or or she or she of course, yeah, I'm sorry. But it shouldn't be like that. I think communication is number one. And the idea of having a leader is just helping his, it's funny to say sub-ordinates, but it's helping his team do the work. And helping his team do the work is by giving them freedom is by listening to them. And it's by helping communicating stuff that are coming probably from above. It's not making the decisions for them. It's giving them a framework for them to work easily and comfortably. And that's what I think is important to understand about leaders that sometimes many, many times actually is kind of taking a wrong turn. And then leaders, especially ones that don't have a lot of experience, see themselves as decision makers and kind of giving commands to their sub-ordinates telling them, okay, that's your task. This is what you should do. That's ABC. Go ahead, run, do it. And I don't think that's the way to go. That's what I have to say about leaders. I think it's an important point, at least for me. And how do you bind it to metrics and KPIs? How do you bind it together? If you can. So I think KPIs can be a topic of its own, right? Because you want to have an indicator, a metric by which you kind of review people, right? How do you know if someone is doing their job well? What's the KPIs for that? You need to measure something. It's hard. I don't have an answer. I think you can go to the dry numbers and speak about how many tickets were closed or how many hours did they work. I think we can both understand that this doesn't mean anything, right? We can all close tickets. We can all just scan the card or say we work like 12 hours a day. It doesn't mean anything. And KPIs are hard. I don't know. Do you have an idea on how to measure correctly someone's efficiency, someone's productivity? Okay, so I want to take it to measure someone. I take it to maybe if I take communicating with team leaders and metrics, I'd say I need to provide team leaders with a way to know what I'm doing, which is maybe measurable. So let's say if I tell them I can provision developers, environments. I don't know. They can tell me, okay, how much time does it take? So that's a matrix. That's a method, right? So it takes me up to one hour to set up a developer environment or it takes me three hours to welcome a new engineer and to let them know about the DevOps in the company and how it works. So I wouldn't take it like measuring people or measuring tasks. I would take it to a place like because we're talking about soft skills. So I'd say we should be proactive with providing metrics to team leaders of how they can measure maybe our work or the developer's work or I don't know if it's also in your organization, but you usually, okay, just usually, DevOps engineers are GIA experts because we also do the integrations, you know? So we know how to use all the plug-in integrations. Usually we get the admin access to GIA in conflict. I am the complete opposite middle. Oh, yeah, five, five, five, five. I am the number one year a hater in my company. To a point I once wrote it as a joke on Slack and I was told to immediately remove that because it's not productive and it's not helping anyone. Which I understood and I did, but it's not about task management. It's specifically GRI. I just, there are some tools and you have the other name in your mind. I just cannot work with them. They're not good for me and the word that comes to mine is friction. There's so much friction when trying to do stuff. You can blame it on who's managing GRI and how they are used to do things, but for me the friction of just opening a ticket and explaining what I want to do and assigning it and putting it in the right screen and understanding what it goes. And then the number of times just a ticket which I just applied kind of vanished into thin air and I could no longer found it and I had to use someone else's help. Just blows my mind. So that's why I don't like it. So I can't believe I'm going to say it. Okay, I'm not going to look you in the eyes when I do it. I'm just covering my eyes. I enjoy using the GRI and I enjoy creating tickets. I'll explain why. Okay. You're certainly one of a kind. As we said with, as we said about communicating with images and soft skills and whatever and metrics. So usually when somebody someone asks me, I think when we talk specifically about that, but someone asks me, listen, can you do this and that's for me? So if it's a show task, I just do it, you know, or help me with something. But if I know it's a long task and when I say long visually, I mean, I need to create a branch out of it. Okay, so I need to check out from the repository branch and do something about it or if it's something that I'm tracking about it. So I enjoy creating GRI tickets because it's part of my documentation. So then I create a ticket. I branch out from the developer's repository, team leaders repository or whatever. I track down everything that I did when it comes to the tasks and it's not under the table. So usually I laugh about it with team leaders and stuff. Listen, like everything in GRI is like, it's like it's legit and it's your pain taxes about it and it's documented and everything that we only communicate in Slack, which is a very short task and, you know, not a big hassle, it's like under the table. Okay, so GRI helps me makes like, I take float stuff. Okay, so everything floats. So nothing is under the table. Everything is visible to anyone who wants, by the way, my GRI project or GRI dashboard is available to all the companies. So anyone can create tickets in my board and I can reject it. They get emails and stuff. So I enjoy not talking only about GRI. I'm just talking about the fact that you can create something and add all, if you saw my GRI tickets, you would get crazy because you will see like 50 comments, like every ticket that I work on, I document everything, mostly my mistakes because I learn from them. So I like to add everything. Okay, that didn't work. That didn't work like every time. Okay, so this is how I would go with team leaders and metrics. Okay, I want to say two things. First of all, I want to say that's, yeah, it's a perfect workflow because what you're doing is, I think the word is transparency. You're showing the world what you're doing. There's an easy place to follow. There's a log of what's going on and I have no problem with that. I actually think task management is amazing. You do need to take large tasks and break them down into smaller and smaller chunks. Something that's digestible and easy to work with is to follow. My problem is with the interface. I mean, GRI is an interface. If I had another interface, I'd use that. And I think me, specifically, my brain works a little bit different and I like kind of a stream of events. I like to see a stream kind of like you're seeing a log stream coming out of an application. I like to have a stream of thoughts. And for that, I use Slack. So I usually open a channel. It can be a channel with myself or just the developer or two that I'm working with. And I write everything there. This works. This doesn't work. This is now a success. Whenever I have like a minor success, I would literally record a video, a demo video. In quick time, I'll just capture the screen and I'll give a three, four minutes of this feature is doing that. Now I'll show what it's doing. Put that in the channel, move on, move on, move on. Yes, we have tickets. Yes, we do try to follow them like everyone else. Honestly, the developers are doing it much better than I am, but we do follow that. However, I like the stream of conscious thoughts there. And then we don't need, I mean, I try to not be part of so many status meetings. What's going on with this, the group manager wants to know, the team leader wants to know the project manager wants to know, you don't need to, you don't need to guess. You have my stream of thought right there in the Slack channel. You can see the demos, you can see what works, what doesn't work. Where we're at, I try to not miss a day without writing something there. So that's my way of communicating. One star in a caveat, I work remotely 100%. There's no other means of communication. I'm not in the office. I don't get to hang out with my friends on the ones every few months. That's my way, my way to communicate. That's it. Okay. I think we covered metrics like communicating the cumulative metrics enough. Thank you for sharing. I think we do the same thing. I'm in real. I do it with Slack, you know, same thing. I think. So we covered metrics, sort of strategic vision. Okay. So communicating with team leaders, strategic vision. Do you have anything to say about that? I do, but we are talking about soft skills. It's hard. I think it's helpful both of us to remember. The topic is soft skills, because we usually run away to, I think technical skills and stuff. So I'm going to run away here, but not in the, in the technical aspect of it. I want to say that a strategic strategic vision breaking my tip here. Without going into depth of what it means or how to do things, I think something else is important for me. Strategic vision is something that is important for everyone in the organization to be familiar with and know about. And by that, I mean, is that we work daily kind of in a rat race. We either write code or build stuff or move tickets around the right of stream of thoughts. But what's the end goal? Where are we going? Where is the ship? Who's navigating the ship and where is it going? Normally who's running or who's navigating the ship would be the CEO or the CTO. And where we're going is something very, very important. Maybe that's a kind of something you need to play in your head now, but ask yourself whether you in your company, you know exactly where you're going? Where the ship is heading? Do you know what the product does? Who's it? I mean, not to the bits and bytes, but generally, where are you going? Who's what's the field? Where are you? I mean, what's, what's not the end goal? Because there's no end goal. But what fit are you taking over? What's the vision? What's the product vision? What's the team vision? That's something I find lacking many, many times. And I think that we're talking about soft skills. So maybe I'm a kind of approaching CEO's now, or leaders, company leaders, try to make sure that everyone knows what the goals are. Where is the ship going? Where are we navigating? What are we trying to take over? And if you can add something to it, like numbers or this is our, you know how sometimes even in the YouTube videos, they'll show you kind of a timeline. This is the schedule. We started here. We're going there. This is where we're at at the moment, kind of like with slides. We're right here. This is the map. This is where we start. This is where we're going. This is where we're at. I think it's very important for every engineer, because even though that there are monkey writing codes, air quotes, of course, I'm not making fun of anyone, they want to know where they're going. So I think that's very important. And sometimes it's kind of misunderstood. Okay. So you took it to a very, very, very high level. Yeah. I'll try to take it to the day-to-day soft skill thing. Like, I told them to be good with what you said. Okay. So all employees, as you said, not only RMB, all employees should know where the organization is going, strategic wise. I'll try to take it to strategic vision for day-to-day tasks. So yeah, when, when a team leader approaches to me and says, we need to do this and that, maybe create development environments for developers, maybe creating another easy tool, maybe. Usually what I tell them, listen, don't tell me about the service or the thing that you want to use. Please let me know. What do you want to achieve? So I'm trying to understand, you know, the end goal, you know, the strategy, I'd say, of what you're trying to achieve. And then let's think about the solution. Because you think it's a different level. But we're talking about the exact same thing. I couldn't agree more with what you said. People want to see the big picture. Exactly. Yeah. So it's important to ask for also to ask for the big picture. Sometimes they can tell you listen. We need to use EC2 to do this and that. And suddenly, you can say, listen, don't you easy, easy to, easy to do, you need to use at the same or any others. I'm just shooting my AWS services, but you get the idea that don't lock on a service, don't lock on a thing. First, try to understand the idea with no limits. So the way I like to think about it, if we're talking about strategic vision is first, no constraints. Okay, please let me know what you want to achieve. If you're going to tell me, I need 1000 machines. I'd say, okay, do you need a million or 1000? Like, let's talk about no constraints. After talking about the constraints, you know, realizing, okay, is it money? Is it time? Is it people? Is it like, you know, human resources? Or what do you need? Okay. Let's narrow it down to specifically what you need when it comes to the task that was given to you. So when I say strategic vision, I'm inclined to talk about, you know, the big picture. This is how I see the strategic given you ask for the big picture. This is how I would summarize. Okay. Again, move on to the subject. So yeah, I totally agree. I just want to say that it's basically the same thing. People want to know what's, what are we talking about? Because it's important for people to give their input, even if you're not going to use it for everyone, where all each one has its own expertise. If you're working together on a project, I want to know where we're going. It's exactly what I said about team leaders before. People want to know what they're doing. They're just not monkey, which they're out, their output is code or some kind of an executable. It's someone who is part of a team and he needs to know where we're heading. Yeah, let's move on. Okay. I'm just waiting for a topic where we will fight because I like it when we fight. Okay. So moving on to communicating with stakeholders, all right. First of all, the second bullet of it is a bit transparent. I think well, we talked about being transparent so we can skip a bullet from there. Okay. I like the skill and stuff. So the only bullet that I see in stakeholders is business jargon. You know, again, I mean, friends. So I like to do this. Okay, business jargon. Okay. Yeah, go. What do you have to say about communicating with stakeholders and business just gone with comes to develop soft skills? Okay. I would go back to the point that I made earlier. I think the conscious stream of thought that I use, and it doesn't matter where, of course, do it wherever you want. This is something that works for me. It's something for everyone. So if we're talking about having the stakeholder within the group channel note, wherever this is going on, I would try to, I want to say, I keep on saying dumb bit down, but that would sound condescending. I'm not dumbing it down first because I'm smart. I'm dumbing it down as in taking it. It's humanizing, humanizing the text from a very technical perspective to something that anyone can understand. For example, a sales engineer. So if I just made a demo for something that is installed within Kubernetes, it's a very technical product. It's hard to understand. But if there is a feature that was good enough, and it's a significant enough point that I took the time and kind of recorded a demo, maybe I'll add four or five more lines that are written in simple enough language for someone even on sales to understand. That's what I have to say about that. Just making sure it's communicated to everyone and understandable to everyone. It's funny how we both, I think, got it like it in a different way, or maybe you also got it in the same way that I did. So when I see business job gone, I'm thinking about business-wise, you're just going to come to the business. So when I talk to sales and I tell them, oh, I, for example, they'll get me better. And if I talk to QA and I say a bug, they'll get me better. So I think it also relates to the language that we talked earlier, like make sure that I'm not sure why it's in stakeholders. Again, it feels to me more like to a language thing that make sure you communicate in the language of the person that is listening. So if I say to a salesperson, okay, it's in my CICD, they'll be like, what? I need to tell them it's automated. Okay, so you need to make sure you're using the right job on right language. When it, right? It's automated. When it comes to the right, it's a computer running it, you know, electricity on internet. Yeah. Yeah. Yeah. Okay. Yeah. I'm moving on to the next section. Yeah, I like this section. Moving on to the next one, I think we'll like it. It has three bullets. Okay, so it's the model useful soft skill. Now we have three bullets. And because I don't want to make, I don't want to make this chapter like two hours. So let's talk them. I don't know, maybe together. Okay, like I'll shoot the, I'll shoot all three and we can discuss them. Okay, so empathy, problem solving and flexibility. Okay, so these are the other soft skills. Okay, flexibility, problem solving and flexibility. Do you have anything to say about them when it comes to DevOps soft skills? Yeah, let me kind of take that list. Let's eliminate the problem solving, which is the tech level. Let's move on to the garbage, you know? Yeah, let me talk about this list. Yeah, let me try and speak, we're talking about soft skills. Let's talk about empathy and what was it? The third one that I liked. Empathy, problem solving and flexibility. Flexibility, right. So this is how I see things. The biggest problem I told when we started the episode, I said that would probably be the biggest downside or the biggest problem or I don't remember the exact wording, but that was the problem. And I think the essence of it is actually empathy. That's the center. And being empathic to someone else, I'm not getting into psychology here, but there's someone else on the other side. We talked about it when we talked about code reviews. It's someone else's work. Someone had worked in vested time and effort and energy into producing something. Don't go telling them that's shit. Even if that's what you think. Communicate thing, you said in a constructive way. So be empathic to that. It's someone else's. Not long. I mean, we don't have a lot of time till AI takes over everything and then you can just say whatever you want. You can be as nasty as you want with your prompts. Until then, as long as you work with humans, you need to be empathic to them. And it's not just being empathic so they'll be happy. This is how communication works. It goes both ways. If you'll be empathic and nice to others, there'll be nice to you. You'll enjoy your work. So you can think of it in an egoistic kind of a prison. It's it's you. It's for you. The empathic so others will be empathic to you and flexibility. I think is the aspect of being flexible enough in your mind to understand how to approach how to approach different people. You need to know them. So we're not all communication experts. Surely I'm not. But at least try to understand who's who likes your nasty jokes and who prefers to you for you to keep it a little bit down and talk, you know, be that be more direct or someone else's who avoids conflicts try to be as gentle and as flexible as you can. You're not just with I said a lot of a snowflake last time. You're not a special snowflake and everyone should just accept you the way you are. Try to communicate in a way and be flexible enough to communicate in a way that everyone likes. And that will just compound and you'll enjoy the fruit of that. Okay sounds good. I like it. I do want to add that when you said empathy and you talked about AI and how we can talk to you that AI the way we want like anyway that we want. So just so you know when I talk to J.PT every time and yes, oh man, every time I write down something like hey, yeah, can you help me with blah, blah, blah, please? Can you do this this and that, please? I have no idea why I like miss your J.PT for you. I'm not. Hey, I'm Mr. J.PT. It's just nice to communicate that way because it also responds. Yesterday, I told slightly, you know, by accident. I told some silly ask like did you need anything? And I say and I said nothing, you are amazing. And she answered, it's nice to be appreciated. So even those programmatic and even though someone probably wrote it down, you know, upfront, it's nice, you know, so it's nice to be appreciated. Also, AI fulfills to be appreciated this way. It will communicate better in the future. Now, I want to tie down to bind the empathy, problem solving and flexibility, maybe to a very short story of example. Okay. So the developer comes to me, tells me listen, I worked on something and I don't understand why my application doesn't run. Now, let's go behind the story. Let's say the application is run because the developer executed something like NPM install NPMCI or like installed only the production packages, but forgot to install the development packages. Now, there is something that I know, but the developer doesn't know this. Okay. The developer comes to me and says, listen, it doesn't work. Can you help me? So first, I'll be empathic about it, right? I'll be like, okay, what's wrong? Do you want to do a zoom about it? Do you want me to come over to your, you know, if I'm not remote, you don't need to come over to your place and see the issue, hang on. I don't have time right now. You can get a ticket and I'll look after it, you know, today. What's the urgency of it? Okay. So that's like being impacted where I'm actually, I actually listen to what you said and I want to help. Okay. So like providing or giving the feeling that I really want to help, I just don't have time right now. Or if I do, let's do it. Okay. Let's solve it right now. When it comes to problem solving, even if I think that I know the solution, you know, before even the developer talked, I let him say what he thinks, because maybe he'll also cover he or she will cover something that I didn't think about. So make sure you listen to the whole problem, you know, before you offer a solution. So problem solving also, I don't only see it as just solving, you know, it's a problem, solve it. No, let the other side. Sometimes it just want to complain about it. And now it's psychologists, you say, some just want to say, listen, I did this and that and this and if you interrupt them in the middle, you're like, let them bring out their steam, shoot out. Sometimes it's even nice to interrupt them, you know, read the room. Okay. So you can interrupt them in the middle and say, listen, I have a solution for you. You know, it really depends on your crowd. Okay. And the flexibility, which I think is like one of the most important things when you listen to someone's problems, sometimes you think that the solution is a. And the developer thinks it's b. Now, if you think the solution is a, then you are really binded and locked to it. And it's very hard for you to change your mindset to solution b. Okay. Sometimes solution a is way better than solution b. Okay, like your solution might be way better than the developer's solution. But always take the sweet spot, well, the effort of explaining the developer of how to do it in solution a, maybe it will take me a week to explain to the developer how to implement solution a, you know, my solution. And maybe it will take me 10 minutes to understand what he did or what she did and to stop it in their way. So try to be flexible in your mind. Well, when the developer comes to your place and tell you, listen, I need help with something, make sure you understand the big picture, you know, the strategic vision, the big picture of what it just said and be flexible about their solution. Because it might be better because it will take you less time to help them. If it comes to security or something that is very, you know, dramatic, of course, put your word into it, explain why it's important to do it the other way. But don't make a scene about everything. Okay, be nice, be empathic, be more, you know, it's a service. I like to call us as, you know, when I, we work in products, you and I, I always, when I talk about products, I say we were like DevOps as a service. So we are a human service. You know, this is how I see it. Like DevOps is a human service. This is how it would summarize all this DevOps soft skills. Think of us as a service. Okay, anything you want to add about that on it before we move to the call them? I just think you should consider your alternative career as a group coach. That's the one thing I have to agree with everything. A group coach. Okay. A group coach. Very specific. Yeah. Not a team. Not a division. A group. Now I'm joking. I'm joking. That was perfect. Every tip was golden. Thank you. Thank you. I'm flattered, you know, I'm blushing right now, but yeah, I will listen up. You did just listening, not viewing, but I'm blushing, I think. Okay. So, do you want to put some summary or do you want to move to the corner? Let me try and summarize everything we said in, in two sentences. You know what? Let me say something about that. I've seen, we had in our company a lecture by someone who speaks about communication and learning better. I don't want to don't remember what the framework was, but he said something at the end. He said, we just had an hour and a half lecture here. I talked about many, many things. If you wrote them down great, even if you did, try to forget, scratch everything I just said. Take one thing. What is it going to be? Any asked like eight different people, and then you had to think of something. One thing, scratch everything and take one thing from this. And I remember taking, I remember what it was. It's not relevant for what we're talking about right now, but I remember this one thing and I keep it, I, for some reason, my mind keeps bringing it up. So, I try to do the same. So, if I take one thing, communicating is a big thing. I'll take the empathy part. Try to be empathic to the other side, because that is somewhat of a challenge. We're all, we're all going through stuff, right? You may have a bad day. You may have not slept enough at night. Something's going on. Maybe you're a little bit sick. Maybe your kid is having something. Try to be empathic. That's my takeaway from this talk. That's it. Okay. There are, I don't know, bad days on other good days and better days. There are no bad days, just so you know. I told you, I would take even though, even though, even though it's not fair to take the last bullet of the whole talk as your bullet, like, so I'll take the flexibility, even though I don't think it's fair, because usually it's smarter to take something that we talked about maybe 30 minutes ago, but I'll take the flexibility, because I really like being flexible and to, I like understanding people, like to understand, okay, but why did you think about the solution? How did you come up with it? Do you have any past experience with what you just said? You said something. You said something that's a center of it. You said, read the room, which I really liked. Read the room. You're sitting in a room, maybe with 10 people, maybe with one, maybe with two, read the room and understand the dynamics between them and then try, it's exactly comes down to flexibility, but you need to be flexible enough in your mind and fast enough and sharp enough to understand. So, yeah, read the room is the essence. And to join you with the room thing that you've just said, I also want to add one more thing. I don't even think it's related to DevOps soft skills, but as a human skills, when it comes to read the room and clear the system, if you really want to give a constructive review to someone, make it, make sure you do it one-on-one. If you're sitting down with two developers, you and two developers and you're letting one know what he did wrong, it will never pass the firewall of the developer of defending himself or herself. I'm not bad. I know what I'm doing and blah, blah, blah, but if you do it one-on-one, so I would never, well, I can't say I would never, but I always try to give a review when it comes to one-on-one and then they also feel comfortable and say, oh, you're right, I could have done it the other way, you know, so it's also important to do it in the right room, okay? I agree. Okay, I know, are you ready for the corner? Yes, I've been waiting all along the past 46 minutes and 25 seconds to talk about the corner. So, you'll have, okay, so today, I'm going to be in the corner alone because I was in a vacation this week. So, you're all alone in the corner, okay? So, moving on to the corner of the week, go, go, go, go, go! Oh man, any opinions, knowledge, tool or something that you have to say that came across your mind in the past week? Yes, I don't know if you've heard of AI. It's something new. I recently, you know, had, chagitat is the most famous one. There are many LLMs, which stands for large language models. Most of them you need to use as a service. Some of them are open source. Famously recently meta. I think said they were open sourcing their LLM, which is called LAMA or LAMA2 or whatever. That's going to be open source. And the fact that it's open source means two things. First of all, you can consume it if it's deployed somewhere in the cloud. But if it's slim enough and lean enough, you can run it locally. So there is one which allegedly is supposed to be even better than LAMA or LAMA2. It's called Mistral. I just found about it last week. It comes with a nice deployment that you can just deploy on containers locally on your machine. If you have a fast enough machine, for example MacM1 should do not too bad with it, you can deploy an LLM model in your machine and run with it. And things you can do with that is just approach that thing as you would through any kind of service, through CHGPT, notion, I don't know what tool you use for that. I'm building something for me to use within my ID. I use Neovin. You can do it with any other ID. And then being able to approach an LLM that sits locally. So first of all, it doesn't cost you anything because it's free. You run it. But the flip side of that is that it's very, very quick and you can train it if you want. So I'm working into integrating that. But I think it's super cool one to have and to be able to deploy locally. The other scary part of that is that if everyone can now run their own model in their own computer, bad things are going to happen because we're not all saints. But that's for another conversation. That's it. Okay, I like it. I like it. So you'll definitely have to share of how you write down Mistral. How do you spell it? It's exactly RAL. Yes, I'll put a link below. But yeah, exactly RAL AI. Okay, so thank you for sharing and we're done. Anything else to add? Yes, I keep forgetting. I bring it up every couple of episodes. If you need us, there's a Facebook page. You won't find a lot there. But it is where you can find us. Obviously, you can communicate with us directly the links and emails or telegram links are all in the description. So if you want to ask questions, go ahead. That's it. I'll try to remember to tell you to tell that in the next episode in the beginning. Last time I told you, listen, I'm like, yeah, when we started with the beginning. And yeah, it's also forgot about it. So next time, I hope I'll email to do it in the beginning. Okay, so thank you for listening. Thank you for all you in. Thank you, Omele. Thank you. See you next time. See you next week. Bye. Bye bye.