Culture workshops

 Boris (0:04):

If I give a feedback training and people ask why do I need this and I tell them, "Well, imagine the next time you're doing a code review." And then their eyes go up and they’re like, "Oh, I get it." Because a code review is feedback. And you're giving feedback on a part of the soul of someone else. So this is a soft skill training for tech people that usually get very deep, very fast. And this is why I think you need tech people getting them. This is why I think it's no use hiring a non-DevOps company to give soft skill trainings because you need to be aware of how tech people think.

Lauri (0:41):

Hello, and welcome to DevOps Sauna podcast. The saying goes that DevOps is 70% culture and 30% technology. But why is it that DevOps is so strongly connected with CI/CD pipelines, shift-left security, infrastructure as code? Where is the culture? Our people both in our DevOps teams and POPs, people operations, have productized some of their important lessons learned into a customer workshop portfolio so that businesses can develop their so-called soft skills and hard skills side by side. We invited Boris Schulz, one of our team leads in Germany, and Nina Maria Figueiredo, a people and culture manager out of her office in Copenhagen. It was awesome to get deeper in the culture part of the DevOps and software development with Boris and Nina. Let's get going with them.

Lauri (1:37):

I'm happy to have you here in the DevOps Sauna podcast, Boris and Nina. Welcome to join!

Boris (1:44):

Hi, it's good to be here. I think this is the first English podcast I've been going in a while. It's good to see you guys. For those who don't know me, I am one of the German team leads for Eficode, currently leading the south German team. And I've had a couple of podcasts about cultural workshops or cultural topics with my German speaking colleagues. And I'm looking forward to sharing my ideas and thoughts with Nina and Lauri.

Lauri (2:10):

And welcome, Nina.

Nina (2:11):

Thank you for invitation, Boris and Lauri, happy to be here. Basically, I'm a people coach and manager in Eficode. I work mainly with the Danish and Norwegian market, but also I help in the soft skills training. I'm a trainer myself and I'm also driving this mentoring program that we have in the company. So I think we're going to have a lot of topics to discuss today.

Lauri (2:35):

Absolutely. Boris, you said this is your first English podcast. But if I'm not mistaken, you actually made an appearance with Esther Daniel and Nina about a year ago. Do I remember that right?

Boris (2:48):

No, this is totally correct. It's the first podcast in a while. I fondly remember the one with Esther Daniel and Nina.

Lauri (2:55):

Yes, exactly. And I'm looking forward to have you back. And the background for this podcast was I saw Boris making a little, let's say internal advertising for our sales teams and consulting teams regarding the culture workshops. And the culture workshops raised my curiosity not only because it's so often we hear that DevOps is not a tool, DevOps is a culture. And some people go as far as saying that DevOps is a management science. And I thought that wow, culture workshops is something that we absolutely have to talk in the DevOps Sauna podcast. So why don't I give you the floor, Boris, to talk a little more about where the culture workshops, how they come to exist, what's the core of it, and then we'll just get going with it.

Boris (3:45):

So the core is basically that we keep saying DevOps is about 70% culture or mindset, and only 30% tech. If you go to a company as a consultant, you're going to see that they are very, very eager to get your tech skills, they want you to build the CICD pipelines, they want you to help out coding and whatever, but there is a certain reluctance to actually address the mindset problems they have. And I hope we're going to go into some details or discussion on why that is. To address this, I have been condensing some of the work I've been doing as a permanent employee into custom workshops for customers, then I've been talking to Eficode colleagues and we've been productizing that. So now we have a quite good portfolio and that is what I've been talking about in Slack, which caught your attention.

Lauri (4:37):

When I think about the workshops that Nina has been running and the trainings, how different things are they when we talk about employee training or soft skills versus culture workshops for organizations who want to adopt DevOps?

Boris (4:54):

I would say there is no big difference. The main reason being that we are a DevOps company and our customers want to be DevOps. So it would be kind of weird if there was a big difference. <laughs> I also strongly believe in eating your own dog food or drinking your own champagne, depending on what you prefer. I think the same way that we're using our own technologies to build (Eficode) ROOT and the same technologies we're advertising for customers to use. We're also promising customers that the stuff we do in-house is going to help them. So I think Nina and I are pretty much just addressing the same issue from two different sides.

Lauri (5:32):

And I'm asking Nina for confirming so we have an alignment on this one.

Nina (5:35):

Yes. And actually I think they contribute to each other because if we are able to build internally the skills, we are able also to offer these cultural workshops for our customers. And we have the expertise as well in working in tech teams. So we are very well equipped to help the customers also in this domain, on team collaboration, on feedback, on communication, on psychological safety, there are a lot of topics that we have experimented inside that we are able to help outside.

Lauri (6:06):

Yeah, and often times, when I listen to you saying that, it's so oftentimes strikes me that after all those things that are listed have quite a little to do with software development. And they have everything to do with a professional in any discipline to really want to become a better person and better at doing whatever they are doing, whether that is finance or marketing or whatever that discipline is. But all the things that you listed there, Nina, they just as well apply to any role out there.

Boris (6:36):

Yes, but I would say that this specifically and especially applies to software development. The complexity of software development has grown so much over the last couple of decades, especially in contrast to other fields of expertise that I would say it's actually impossible to build something on your own these days. Yesterday, I've seen the video announcement of a guy who built his own Zelda like game, and it looks awesome. He spent several years on that. So there are people who are able to do that and probably someone like Elon Musk is able to build his own car all alone in his workshop. But I would say 99.999999% of us are unable to build software on our own and software development these days is, in my opinion, more about collaboration than about actually coding.

Lauri (7:29):

So when you are a tech company, how does it then look like for a tech company undergoing this culture training or culture workshops series? So can you talk us, Boris, through the first few steps on this is how companies do it?

Boris (7:47):

Well, there is no strict path because every company has different problems that they need to solve. So yesterday, I had talked to one potential customer and we agreed that they are going to take one month time to actually figure out what they need help with. There's absolutely no need in telling them you need to do this and this, if they've already solved this part of the communication. My suggestion is always that feedback is one of the first things you should address. Good quality feedback is probably the basic for most of your communication issues and whenever I'm permanently employed in a company, as a team lead, manager, whatever, that's the first thing I try to do.

Lauri (8:29):

And how does that line up with, let's say internal culture workshops, Nina, feedback? I think you mentioned that in your list, didn't you?

Nina (8:36):

Yes, I actually mentioned and Boris is the trainer for the feedback that we have, feedback course that we have. But the feedback course is also part of our mentoring program. So we can provide more tools for mentors to give feedback to the mentees. But I would say that besides the feedback, I also find really important to build the culture around psychological safety. Because if you're able to communicate openly, you're not afraid of sharing your input, providing ideas and challenge your colleagues, you have the right culture to build anything. So I'd say the psychological safety and feedback comes hand in hand and you do need those as a basis to build the rest of the elements that the team needs. 

Nina (9:22):

And we have been talking a lot about psychological safety. So next week I will actually give a training for the team leads and I have my head around this topic quite a lot. And we can also see in the literature, how, since the 90s. And actually this is something from the book, The Fearless Organization from Emmy Edmondson where it has been increasing a lot. So you see that there is an increase about this discussion in different medias since the 90s. You see a peak now of this topic, so it became quite important. And there is also research from Google showing that this is the basic elements of teams and then you have the other element that comes after that as well. So actually, the name of this research was Project Aristotle. So there is a lot of good content around that. And I think those topics, they come well together. And I think, as Boris was saying, it really depends on the customer and the needs of the specific team. So there is no right step to start with, you have to understand where the team is, where they are in their journey and then you come up with the right solution, right?

Boris (10:33):

Psychological safety is super important. And I don't think there's a single workshop where I don't mention that. The interesting part is that people don't know why. And my own theory is that we're all knowledge workers. The environment we've been raised in is that we tend to think of hierarchy as the more qualified person is on top, but that's not true anymore. A knowledge worker is defined as you know more than your boss on a specific topic. It does not mean your boss is worse than you, or has less qualification, he has different qualifications. And in this environment, what is most important is that the people that have the specific knowledge, they are able to freely exchange ideas and thoughts. And the more the whole industry actually has turned into a knowledgeable working teams, the more this psychological safety has become important.

Lauri (11:26):

Yeah, one aspect is that there is no culture workshop where psychological safety is mentioned, so that's one aspect. But the one aspect is, is there a separate workshop for psychological safety? And if there is, how would a course like that look like?

Nina (11:44):

Should I reply that one or do you want to go for it?

Boris (11:48):

I'll take it. Well, Nina is giving the course next week, so there is a course for that and anything that she can teach us, Eficodians, is something we can teach our customers. But I think it's a very, very big topic. And I've been trying to put it into workshops myself, and I always end up with at least three different days spread over one month and I'm looking forward to seeing how Nina does it in one day.

Nina (12:14):

Yes, and there are different steps, different practices that we can do. And leaders have an important role for that as well. And leaders across the different levels of the organization. So you can see different levels of psychological safety in the different teams. It's not that will be the same for every team. So some teams might have like psychological safety, some of them will not have. So it really depends, but it's something that all leaders should do it in all the different levels. And all the teams can do themselves. As team members you can also be a role model for psychological safety, as long as you're open, you kind of admit mistakes in front of others, you share your failures. So you celebrate failure. And there are a lot of different things that you can do. Boris.

Boris (13:02):

Yes. And the thing is it's different for every team constellation. There is of course, a certain mindset we have or a certain picture in mind that probably makes most people happy. But I've had two teams that had a very, very big level of psychological safety. And if you came in from the outside, you would have been appalled at how much swearing we had and people that came in every morning and said, "Yo, what's up, bitches." <laughs> This was a very, very interesting psychological safety because one of the key concepts of one team was, we're making fun of everyone not because we don't like you, but because that's part of our nature so please don't feel offended. 

Boris (13:43)

And everyone in the team knew that if you're being made fun of, it's not personal, it's just the way we are-and everyone accepted this. And the interesting part was then when people came in from the outside, suddenly with one more person entering the room, you had new rules applying. And the whole concept of psychological safety had to be twisted to incorporate the new person. So there were no more jokes on the outside or there was a completely different language because suddenly the people had changed and you needed to act differently. And this is also true for companies. There is no one size fits all, you need to figure out what fits your company and what you need to do to make your company a safe place and that's the part where I have no recipe for success for 'one day (training)'. Yeah.

Lauri (14:31):

I remember a few times, I've been looking into DevOps assessments, and I think there are a few ways of doing DevOps assessments. One is you send a person to the customer and they basically do a deep qualitative interviews and basically long form conversations with individuals in the organization and then they form an opinion on the basis of those conversations. The other way of doing assessment is more quantitative where you make statements and then you measure to which degree people agree with or disagree with those statements.  And then you assume that when your sample size is big enough, then it's a reflective of what the DevOps readiness or DevOps maturity, or whatever you want to call it. I wonder how well these assessment tools capture the cultural aspect, as opposed to more hard skills, like continuous deployment or test automation or things like that. 

Boris (15:32):

They capture them quite well if you have experienced consultants doing them. For instance, I've been doing them with my senior co-consultants a few times, and you can just ask questions about how people behave every day and then there are certain questions like, "What happens if you fail?" "How are you treated?" The interviews of my last customer said, "Oh, it's fine. It's very open, we're always happy. And if we have a failure, we treat it as a learning experience." And basically, they gave us the full list of things that we wanted to hear. And then we said, "Okay, so when was the last time you failed?" And the answer was, "Failure? We're not allowed to fail." <ironic laughs> And that's something that's more easy to capture in an open interview than in an assessment where you say on a scale of one to five, etc. I think the current questionnaire involves about 80-plus questions, maybe one-third of them is about culture. And if you've been working for a few companies, then you can recognize the signs of a bad culture pretty fast.

Lauri (16:40):

So you said earlier that some of those customers, they give themselves like one month to figure out what they should be doing. So I take it as one way to do that is assessment, like figuring out what should be done. What are the other ways besides the assessment that get to the bottom of things and what needs addressing?

Boris (17:00):

The assessment is the easy way, but if you need cultural changes, the assessment is going to come out saying that your management needs to change, and they might not like that. So the better way for the company is for the management to say, "Okay, we're going Agile in whatever way and we recognize that our way of managing teams is no longer applicable. So we would like to get help from the outside." And what this means: how can we be Agile team leads? And if the customer comes in like this, then the biggest obstacle has been taken. And then you can focus on so what are the problems you can see? 

Boris (17:39):

What is the point where you're thinking you need help most of? And then probably the first step is still going to be a one day workshop, talking about how they think the management is currently working, how they think they should be working, and you know, just getting the status quo and then coming up with some suggestions. But if they already say, "Yes, we know we have to change, please help." This is the way-more-favorable scenario.

Lauri (18:01): It Lauri again. Businesses often resort to assessments to benchmark them against competition and industry, learn best practices, and gain insights from experienced consultants and coaches. One of the easiest way to get going right away is self-assessment. You can fill the questionnaire in a matter of minutes, invite your colleagues along and get a good coverage of the DevOps maturity in your company. We made one of these called DevOps Self-Assessment that works exactly as I described. Plus, at the end of that assessment, we offer you analysis of the results, we identify areas of strengths, but also where you can improve-all free of charge. Naturally, self assessment doesn't replace qualitative deep interviews. I am leaving links to the show notes to both the Self-Assessment as well as assessment services. Have a look. Now let's get back to our show!

Nina (19:02):

I have a question for Boris. So, Boris, when you are working with customers in cultural workshops, where do you usually notice that the course that you're giving is having an impact on the customer, how do you notice the change?

Boris (19:23):

Well, that's a bit hard. So when you do tech consulting, then you're usually employed for an extended period of time, maybe 12 weeks. And you can see the changes on the code side. When you do a single workshop you have to figure out at the end of the workshop if someone had an insight. And my way to figure this out is to cheat and just ask. <laughs> You've been to one of my workshops or two. So you know that at the end I ask, "What is your core insight?" And I don't want to know what you learned today, like what you learned about psychology, what did you learn today about tools. But where did your mind go click, "Ah, I got it." And this turns out to be a question that most people can come up with an answer if I give them five or ten minutes time. And it's really interesting to see what people take away. And over time, I found that in all parts of my workshops, they have someone that says yes, this is where my mind went, "Oh, wow." So it's different for everyone. And I'm using this both as feedback to adjust my course material. And to know that I'm actually having an impact.

Lauri (20:37):

I remember not too long ago, we were having a discussion with a small group regarding employee NPS, so ENPS. In the rate of 0 to 10, how likely you are recommend your company for somebody. And NPS has its own problems. Let's face it. So the question was, is there a better way of, on the whole, measuring what ENPS tries to measure for employees? And one of the studies were pointing out that if you really want to go to the bottom of employee satisfaction at work on the whole, you should be asking for their happiness. Because even though happiness can be viewed as a low level virtue, that there are like many more higher level virtues, like meaningfulness and the fulfilment and things like that, than happiness, then it's still a very good proxy for employees, that something is right when the happiness goes up. 

Lauri (21:40):

So I was just I just wanted to throw it out there for discussion whether measuring happiness could act like 'happiness in the software development team', or 'happiness in the scrum team' could actually be a good proxy for succeeding in the culture stage. And there's just one more observation there is measuring in behaviour is typically more effective than measuring intention. So instead of asking, how likely are you to do something in the future, you could ask how many times you have done something in the past? And because I'm not the practitioner, I'm not a specialist in DevOps, I wouldn't be able to come up with a question like, what's the right question to ask about the past behaviour. And that's why you are here. So we can have a discussion about that.

Boris (22:23):

I think happiness is a very good metric because everyone achieves happiness a different way. I found out that the main thing I need to be happy in a company is freedom. So me currently being in a position where I'm helping the German team to grow and productizing stuff and where I have a lot of freedom. Because we're doing things that have not been done for Germany. They've been done for Finland, but they need to be adjusted for Germany, they've been done for Denmark, but they need to be adjusted. And the people doing this, they get the freedom to do what they think is best. And this is what makes me most happy. But we have others in the team that are most happy if they can grow professionally. If they have someone that looks over their code and says, “Look, this is not how we write TerraForm in 2022, this is what we did four years ago, please do it this way.” And everyone achieves happiness a different way. So I think asking for team happiness is probably able to cover a lot more aspects.

Lauri (23:22):

What do you think, Nina?

Nina (23:23):

I agree. Yeah, the ENPS is related to if people are to recommend the company, right as a place to work, but I think is also very much related with the happiness because if people are happy, they're going to recommend the company. So I do agree with your point of view. Yeah. And I also think that the Agile way of thinking highlights a lot the team aspect. And I do think that the team, even though might be that we're not going to be able to make people 100% happy we should try to get the team happiness in place, right?

Lauri (23:56):

Yeah, maybe one way to make it very, very simple: after the culture workshop, I'm thinking out loud, and could be that I'm just completely uneducated, uneducated on this subject. So forgive me of my ignorance. But I was thinking, imagine you do the workshop. Imagine you wait six months, and then you ask a simple question. In the six months, what has been the most important change that you have seen in your behaviour, in your team, in your workplace that has increased your happiness at work? And then you take that out and look what kind of responses you're getting. And then try to conclude if those things that people mentioned are related to the training or related to the changes in the culture and so on and so forth.

Boris (24:37):

I think that's an awesome question on a very theoretical level. I think for practical purposes, half a year is too much in the attention span of someone that's used to deliver something useful once per sprint, or maybe several times per sprint but where all the planning is done in two-week partitions. Six months is like 12 sprint's basically and that's a lot more than most people I know have the attention span for at work. I know I don't have it.

Nina (25:06):

So I would like to share a little bit some of my experiences with this trainings that we do in Eficode. So we have been experimenting with that for a while, we already have some concrete things to share, as Boris is saying, we are able to provide those trainings for customers as well. One of my learnings is that doesn't really matter, actually it matters a lot. We have technical people talking about very human stuff and usually it starts about the technical problem. But at the end, you end up perhaps in a communication topic, or that people don't have the psychological safety that they need to talk about problems, or they have this impostor syndrome. So it's everything kind of in the middle of the technical stuff. So I gave the empathy training in the mentoring program. When I did that, for the first time Boris and I had a shock about that. But I felt this kind of I don't know how to describe the feeling I had afterwards, it was like, wow, that was very deep, and the guys were all technical. And for me, it was so interesting to see that they are taking something to work with the mentees or with their teams that are going actually to be able to help them to be better at what they do. Go ahead, Boris.

Boris (26:26):

If you go into this kind of training with tech people, it gets deep, very fast. And the reason is, obviously, we pour a part of our soul into our work. So if I give a feedback training, and people ask me, “Why do I need this?” And I tell them, “Well, imagine the next time you're doing a code review.” And then their eyes go up and they’re like, “Oh, I get it,” because a code review is feedback. And you're giving feedback on a part of the soul of someone else. So these this is a soft skill trainings for tech people, they usually get very deep, very fast. And this is why I think you need tech people giving them, this is why I think it's no use hiring a non DevOps company to give soft skill trainings, because you need to be aware of how tech people think.

Lauri (27:12):

That is very much compatible from a different industry where we think that when we do something called sales enablement, and sales enablement means that you develop the selling skills, but you also develop the solution skills of whatever product is it that your company is selling, there is an agreement or general agreement about the fact that when you are training 'selling skills' for salespeople, the drills and the exercises should be related to your own products, and not to some hypothetical products, because when those two things go hand in hand, they reinforce each other. And then they create the kind of there's a bigger economies of scaling the benefits when you get to have the drills and exercises, not only about how to do stuff, but also concerning your own products. And that sounds very much like what what you're saying.

Boris (28:03):

So one thing I do in a conflict resolution workshop is I go into the mindset of how Ops, Dev and security people think, I mean, we're doing DevOps, so at least you're bringing together Dev and Ops, and companies that have this thinking that they form a team and agile team, and everyone's in there. And it just starts to work from the start. But the reality is that you're bringing together people that have a very, very different way of thinking, a very different way of being judged by others, developers are being judged by how fast they can deliver cool features, an Ops guy is judged by is your system stable, and an Ops guy usually gets attention only when it breaks. <laughs>

Boris (28:45):

So for an Ops guy, it might be a very, very good idea to just never get attention. But this is not how the world is working for developers. And then you adding security people on top of that and they have a completely different mindset. And then the company expects all those mindsets to go together and form a super human being and this doesn't work. So you need to be able to explain to the people in Agile teams and DevOps teams, what those mindsets if you put them together what the belief systems, what the values mean, and how you can combine them without insulting the other side. Or maybe just seeing that, yes, this guy used to be in Ops, he is working differently. Or I'm the Ops guy and the guy that I've been making fun of for the last 10 years because he was just caring about features, there's a reason for that. He's not a bad person. He just has different values. He had different goals to achieve. And now we have to adjust.

Lauri (29:37):

Yeah, the divergent goals is a super interesting topic. Because you mentioned about that I'd like you to talk a little more about the diverging goals. It's again, it's different when we talk about divergent goals between sales and marketing and diverging goals between the engineering teams.

Boris (29:53):

Well, divergent goals are everywhere, been in many companies where the sales guys were the bad guys because they had the goal to sell as much as possible. And if no one was linking those goals to the actually technically achievable goals of people writing the software, we had on one side, people selling things that were not ready or maybe just selling too much. And then the software was unable to scale or wasn't able to deliver. So this is the classical approach. But on a more practical level, I would say, imagine that you're building a house, then the mindset, or the goals you have to build this house are very different for DevOps and Sec (security). 

Boris (30:30):

They care about different parts, they care about different delivery dates, and more importantly, they used to care about different things. And they just weren't throwing it over the virtual fans to the other teams to take care of it. And now they're having to take care of all of this. For instance, for development, usually in the past, the project was over once something went live, and they could go on, they could party or whatever. But if you've been working in Ops, then stability was one of your main goals. And if you went to go to a party, you probably had your laptop with you to work. And these things have to go together. 

Boris (31:04):

And you need to explain to the Ops guys: No, that the Dev guys, they're going home on Friday evening, and they're partying, that's not because they don't care, they have different goals. And the Dev guys have to learn: Yes! If you're taking responsibility for your product, it means that once every six or eight weeks, you'll get to get a laptop, and you're on-call and stuff like that. And actually on call is one of the hottest topics for cross functional teams and I've had many long discussions on that with customers that just said, “No, our Dev team is never ever going to do it.” <multiple laughs> And I think it's the basic part about sharing the responsibility for your product means that yes, I don't stop caring for the product at 5pm when I go home. I take the responsibility for as long as the product is running. And that's a new goal. That's a new responsibility.

Lauri (31:55):

So are there some silver bullet questions that open the eyes of your audience to realize that there's sort of the importance of the on-call? Or is it the different reasons every time?

Boris (32:07):

There is no silver bullet, because it mainly depends on how stuck people are in their mindset, you might have people working for 40 years in one company, and they're used to a certain way of working, and they're unlikely to change. Especially if you come to corporate companies like big finance institutions, they have people that are so stuck in their old mindset. And they know that they have the right to do this, they're unlikely to voluntarily give up whatever they're doing. In smaller companies, the silver bullet would be to say, “Okay, you want your stuff to be delivered faster, are you willing to take responsibility?” And the responsibility includes a lot of steps, including the live performance, the security and what not. And I found that especially, let's not say startup scene, but in the smaller companies that I've been working for in Berlin, the developers are very, very much willing to take the responsibility, if it means they also get the ability.

Lauri (33:09):

Yeah, super. I think we are starting to come towards the end of the conversation. I think there were two other things I was hoping to intrigue you with, in preparation for our conversation. I think, Boris, we discussed about the definition of brother-in-law. And I think you had some ideas there that we'd like to talk a little bit, and then I'll save my last question. But let's talk about that first.

Boris (33:34):

Yeah, that's an interesting one, the brother-in-your-law <sic> is currently visiting, and he's quite young, and he came up this morning, I think, and said, “Hey, I'm studying computer science. And later in my job, I'm just going to be sitting on my desk working alone, right? We're nerds, we don't have to talk to others.” And I just laughed at him. And I explained to him that the most important part is knowing how to communicate, cooperate and collaborate. And he was a bit shocked and this kind of went in line with what one of my customers was saying, I think, this morning or yesterday. I'm doing a big transformation plan for them. And they said, “The tech guys, they have their cool new toys, and they're going to do CI/CD, and they're going to get new frameworks. But we have those management guys, and they're very unsure what is going to change for them. Can we talk about that?” So I'm going to have a talk with them with their management team about what does it mean to be an agile leader. Because it's not about having cool new toys, it's about having responsibilities, having to change your mind, and they're going to do culture or mindset workshops.

Lauri (34:48):

Right. So that's a message to all of the brother-in-laws out there. Software development is not a lonely job: it's a team work. Well, I only have one question remaining: what would you like to tell someone who is in the beginning of their DevOps journey? What would you like to tell to someone who is at the beginning of their DevOps journey, given everything that we have discussed? So maybe we start with Boris and then Nina, and then we round up?

Boris (35:17):

Well, it's kind of what I told my brother in law, right? It's about communication. And the reason is that we can say no man is an island. And that's always been true. But in the last couple of years, maybe 10-20 years, the world has been getting smaller. Here in Finland, I think, Nina is in Denmark, and we're sitting here in a virtual conference, and our mindset is rather similar, I dare to say. But now imagine you have someone sitting here from the other side of the ocean, or someone from the other side of the continent. So they have a different cultural background, and they might have a different religious background on top. And then things get a lot different. Because you're exposed to so many more kinds of people these days in a typical tech team than 20 years ago that you need to be able to communicate, you need to be able to show respect, and you need to be able to, well, and that's the hard part, express your feelings. You need to be able to say what you just said, was hurting, because otherwise no one's going to know. And on top of that, I have something very technical and that is just know your basics, get a good foundation to build on, a good technical foundation.

Lauri (36:27):

Thank you, Nina, what would you like to tell someone who is in the beginning of the DevOps journey?

Nina (36:32):

I think for me, it's pretty much about not neglecting the human side of the technical problems. Because as we like to work with our customers, we have a big toolbox, where we pick the right tools to provide them the best solutions, the more human side of that also has tools that we can offer and that we can use. So sometimes we need to put some Docker and Kubernetes git, but sometimes we also need to improve the collaboration, the communication, how we talk to each other, how we organize our work, and so on. If we have goals and are aligned on goals, there are so many other things that we can also use there.

Boris (37:11):

This is a really good point, the tools we have for the human side, they're very important. And they're also a lot harder to use than the technical tools. Everyone can sit down and learn Docker in a week. But for the human side, I've seen people actually start to cry in workshops. Not only once, I've seen that happen for people ranging anywhere from 26 to 46 (years of age), I would say. And that's because in order to communicate well with others, you need to first communicate well with yourself. And in some way those tools, they're not only projecting outwards, they're also projecting inwards. And that makes them hard. And that's why we need to practice them.

Lauri (37:49):

Great, excellent conversation. I thank you, Boris, Nina, for all of this. And the topic was culture workshops. But I think we ranged far beyond culture workshops subjects and I personally think that's a good thing. So I thank you for joining very much.

Thank you for listening. If you want to continue the conversation with Boris and Nina, you can find their social media profiles in the show notes. If you haven't already, please subscribe to our podcast and give us a rating on your platform. It means the world to us. Also check our other episodes for interesting and exciting talks. Before I sign off, I say take care of yourselves and remember that everyone achieves happiness in a different way.