Debate: Workers' Safety in the DevOps Factory with Ester Daniel Ytterbrink, Nina Maria Figueiredo and Boris Schulz

Lauri (00:09):

Hello and welcome to DevOps Sauna. My name is Lauri, and I am the chief marketing officer of Eficode.

Lauri (00:17):

When dealing with DevOps it's close to impossible to avoid coming across the history that goes back to factories producing goods. Back in time, factories were not exactly the safest places in the world and sometimes people had to work for the fear of getting injured to their paycheck. Luckily, this is not the case for IT workers, at least in the physical sense. But a lot is to be said about improving the IT workers wellbeing overall.

Lauri (00:45):

In our grand debate series we invited Ester Daniel Ytterbrink, Nina Maria Figueiredo, and Boris Schultz to talk about protecting worker safety in the DevOps factory. It's an intriguing conversation varying between gamification and psychological safety but also shares insights how middle management can make a safer workplace for their software development and operations teams.

Lauri (01:25):

How are you today?

Ester Daniel (01:29):

I'm excited about this meeting.

Boris (01:33):

It's nice and sunny outside. It's a nice day, so I'm fine.

Lauri (01:37):

That's the easiest way to let people down in Finland which is typically known as the only country in the world with four months of November.

Boris (01:45):

I would have to disagree there. I grew up on the Lake Constance in the south of Germany. One year we had six months of fog. So four months of November actually sounds pretty cool to me.

Lauri (01:58):

It happens that in Finland, I won't bother you with the Finnish word, but there is a concept that you will plow your way through November by exercising minimum 25 minutes every day. So that gives you vigor for the darkest period of the year which is actually not that bad idea considering how much energy you can get from exercising. Even though while you are exercising you are losing energy, but then it will pay you back with interest.

Lauri (02:33):

Welcome to all of you. So we have Ester Daniel, we have Nina, and we have Boris. Glad to have you all three here. And thank you Ester Daniel for taking your time to prepare an interesting topic for us. The headline says, "Worker Safety in the DevOps factory."

Ester Daniel (02:54):

Okay. Worker Safety in the DevOps Factory. I want to talk to you about worker safety. This is the words of Paul O'Neill as he in 1987 took over as CEO for the American aluminum company Alcoa. He saw the fight for a safe workplace as a way to create habits of excellence throughout the entire organization, and he succeeded. The IT industry has taken a lot of its processes from the production industry. The Toyota model, Lean, and Theory of Constraints, all come from factories. But have we understood that we also have to think about safety?

Ester Daniel (03:44):

It is rare that a server falls down and breaks someone's arm, but we have other problems. A brain can also break. Burnout can cause as severe damage to a software engineer as a heavy machine can do to a factory worker. So how do we protect the workers of the IT industry? Does it help that it's a DevOps factory?

Ester Daniel (04:08):

The DORA DevOps report shows that just as the Alcoa success was founded in worker safety, the same things that drive productivity also drive work life balance and reduces risk of burnout. Continuous delivery and all it requires as well as a clear process of change are proven to be protective factors.

Ester Daniel (04:33):

So how do we support companies in supporting the health of their developers? What factors do we find essential in the environment? What support do we need to give to individuals in the organization? Where does psychological safety come into the picture? Are there people that should stay out of the IT industry for their own safety, for the safety of others? And what are the side benefits of having a safe working environment in the software industry?

Nina (05:05):

Thank you, Ester Daniel, for this great introduction. Basically when I listen to your introduction a lot of things comes to my mind. Working in people operations in Eficode, I can totally see that one word comes very strongly to my mind. It's about wellbeing of our people.

Nina (05:24):

So if we are thinking about the DevOps factory and how people can thrive in this industry, how we can make sure that we create great work experiences, practices, ways of working that align with what we believe and where we want to go.

Boris (05:48):

I don't think I would use the word safety, but I choose it for similar reasons before where I used to work for Ops teams and they al got cynical and depressed, and I needed to figure out a way to get them over this. So I think my relation to this topic is more a very practical one.

Ester Daniel (06:08):

I think it actually has to do with safety, like physical safety. I have multiple friends that have had such severe burnout that they had to consider a career change. One friend who went from hobby novelist to not being to write their own CV from how the situation was at the workplace. So I would say that it actually risk for bodily damage because the brain is part of our body when we don't take care of ourselves and each other.

Ester Daniel (06:50):

And the continuous delivery part as being protective. That contains a lot of things that has to do with code maintainability, automatic testing, all of those stuff that we sometimes compromise with because we think it's okay for the product. I mean the product is good enough. People still buy it, but we forget that the code and the pipeline for releasing code, the deployment, all of those things around it, it's also the working environment for the developers.

Ester Daniel (07:29):

So it's like saying, "It's okay to have a messy kitchen for the chefs as long as no one get food poisoning, but that the chefs burn themselves because there's no way to move around the stove tops, that's okay."

Lauri (07:46):

I remember I happened to take a tour in a mine, and the tour guide said that about 50 to 70 years ago when new miners started their career, 100 meters beneath the ground level, they were advised to start smoking. The logic was that when you smoke then you will also exhale all of the dust from your lungs, and it will keep you healthier.

Lauri (08:16):

Which brings me to the question, Ester Daniel, that you posed in your opening is, "Are there people that should stay out of the IT industry for their own safety?" I would like to flip it around and ask, "Compared to the other industries, is there something inherent in the IT industry where safety plays a bigger role?"

Lauri (08:38):

Because I believe that the psychological safety and the mental wellbeing and that sort of aspects are present in every industry and IT industry per say is no exception.

Boris (08:56):

I would say that there is something inherent, not in IT but in all industries that do not deliver physical goods, and that is at the end of the day you cannot see what you did. You cannot see what you contributed to whatever cause.

Boris (09:11):

I think this reflects that in the fact that pretty much all of my friends have a very physical hobby besides their IT work. They do carpentry. They do sewing. They do whatever. I mean even I started sewing now. What I hear from all of them is that they need something where they can see the result.

Boris (09:33):

And another thing is, and that's probably something that reflects my background coming from Ops. In the better days when you had Ops and Developers, Ops did the on call. So they were involved a lot more because they got the calls at night. At the same time, they were normally the ones least able to influence the actual product. And I think that's a very inhumane way of working where you bear the brunt of the responsibility and have the least influence.

Ester Daniel (10:02):

And that is also like one factor for burnout, right? That you don't feel that you have influence over your work. I listened to another podcast. We can reference it down below if it's okay. That I think Nina perhaps also heard where they talked about risks for burnout and where there was a teacher who actually started off hours teaching for kids with extra needs in an organization. She was totally overworked but the thing that saved her from burnout was doing more work so that she felt that she had the power to change things and that kept her sane.

Ester Daniel (10:45):

So, yeah, I think this with having power over your work. But I also think about the feedback cycles. So if you can't really touch what you're doing. If you have a steady deploy cycle so that you actually get your stuff out in production or even the test driven development thing, it's almost like a game. So if you implement a test and then you write your code to make it pass, you get another green checkbox in your list, then you can actually track your progress in a way.

Ester Daniel (11:19):

There's some research who said that if you are a manager, so that's also a group that can't really touch the work they're doing, you should play Tetris or something else like 20 minutes a day. Because then you would get the endorphins from seeing progress and having success when the feedback from your work wasn't enough.

Ester Daniel (11:43):

So I think DevOps part can also be that it builds for feedback, and we need feedback.

Nina (11:52):

And how to make sure that we are collecting this feedback? Because I think feedback is a very important word for us if we think about feedback loops and building psychological safety for software development teams, but I also think that for having this culture of wellbeing in taking even more care of our people in this knowledge based industry, it's important to continuously collect feedback.

Nina (12:18):

So if I think about the organizational level, I think it's important that are continuously doing surveys for our employees, wellbeing surveys but also satisfaction surveys as well. If we think about managers and how they could work with people, especially during this COVID-19 situation, it's super important in my point-of-view that managers super close to their people, having more one-on-ones as well like besides the formal talks. Because a lot of can happen between talks, right? So it's important to be continuously talking to people.

Nina (12:57):

But also at the team level, I think this idea of shared responsibility, that is pretty much a value in DevOps, could also be something that we bring the wellbeing in the scene where the team has a shared responsibility of their teammates wellbeing. Where if somebody is overworking and you can see the workload is super high, you can actually share the responsibility with the work. So that's a little bit my input if we think about the different ways of handling wellbeing in a company.

Boris (13:33):

I would like to disagree on one point and that is the surveys.

Nina (13:37):

Okay.

Boris (13:37):

There's research showing that if you do too many surveys, you actually help to cement a certain state of mind. So basically if you ask people, "How are you currently feeling about your job?"

Boris (13:48):

And if they say, "Three out of five ones," it's fine. But if they repeatedly do this, then they will just keep giving the same answer out of habit. You're basically preventing any improvement by just asking them too often.

Boris (14:04):

So surveys are important, but I think they should be used very wisely.

Nina (14:08):

I agree with your point of using very wisely, Boris.

Lauri (14:14):

Last week I was having a discussion with somebody from GitLab who as we know has established an all remote culture. They don't have offices. Everybody works, not from home, but they all work remotely. And what intrigued me in that conversation is they had codified something that used to be implicit in organizations, which is like water cooler conversations, for instance. That if you take a normal workplace then you have this tacit knowledge and the way of socializing with each individual by a random chance of stumbling up on somebody else and then you have a conversation. You learn a new colleague, and you learn new interest.

Lauri (14:55):

Instead when you are working in an all remote organization, it is not accidental that you stumble upon new people. You have to make it deliberate, and one example was that they have sessions where people come online and then for instance the online platform will randomly select random individuals to have conversation with each other. So they take a system and they apply a system to introduce the kind of randomness that you would need to have the desired outcome.

Lauri (15:32):

Maybe in this case it's not the randomness that we want, but it's more like how to accelerate the establishment of a desired behavior and desired culture using tools so that you get the desired effect? I think that's a long-winded way of asking my question.

Nina (15:49):

Yeah. I might sidetrack us now, but the thing that hit me when you talked about structuring the things we need to keep an organization is that we can then also protect our time and our flow. So it could actually be more beneficial than sitting in the same space because in the same space we will have those small conversation but not always at the water cooler. Sometimes it's just someone coming in disturbing you when you're really deep down in your work. But having it structured you could do your 30 minutes of focus, and then you have a planned session where you deliberately talk to others.

Nina (16:41):

But we also touched on it before this recording when some of us came a bit early because it's good to be prepared especially if you're not used to the tool, and then we started chatting. And I have another friend who has made it a habit to come early to all meetings and start playing his guitar.

Lauri (17:03):

Wow.

Nina (17:03):

So people start to show up early to hear him play. I think that in a remote setting we will need to be more clever about how we do things and do it deliberately. Perhaps there we can use the DevOps mindset like automate things, see what we want to achieve and then make sure that it takes the least human effort to actually get there, so it doesn't depend on us faulty bags of flesh.

Boris (17:38):

I'm a bit hesitant or hesitant, yeah, that's what you'd say, in appreciating any effort to automate human behavior, but I know what you mean. I think there is at least one part of the IT industry or the online growth that we can look for and that's the gaming world. I used to do a lot of online gaming before being a purely remote worker, and I used to have friends that were sitting eight hours away and still we would meet once per week for a couple of hours. And I know that you can have a really good personal relationship to someone that you've never actually seen. And I think this is probably one direction we can look at in a remote IT company, how those people do it.

Nina (18:26):

I actually just had a thought, and I would like to ask your input on that. Can gaming be a way of building psychological safety?

Boris (18:35):

Yeah.

Nina (18:36):

Yes. And how?

Boris (18:40):

Ester looks like she's about to say something.

Ester Daniel (18:42):

Yeah, what I've seen from research there are two things that build psychological safety from what you've seen systematically. And it is equal speaking time and people being good at reading emotions in others, if I'm not confusing the studies now. But I think that's two things, and that is one reason why ensemble programming, where you're a group of people. It was previously called mob programming. Because then you take turns talking on a timer, basically, and you have frequent retrospectives so that you practice watching people and then hearing about their emotions. Watching people. Hearing about their emotions. So that's like the only structured way that I think I know builds psychological safety.

Ester Daniel (19:49):

But there is a really good book that is called Reality's Broken that I think is pre-dated the concept of psychological safety, but it lists all the ways that gaming is good that we need more of in real life.

Lauri (20:05):

Something that I remember from management literature actually, is the concept called procedural justice. And procedural justice is to evaluate the process by which the decision was made in order to evaluate the justice of the actual decision. So people evaluate how fair that decision was based on how fair the process was by which the decision was made. And when we think of psychological safety in a group, then it would be easy for me to believe that if you take a group of people who together make decisions, they will not only access as to what those decision were for the fact but they will also constantly monitor, "What's the process by which we are making these decisions?" And there's so much in the human behavior which is inexplicable but intuitively as we work together we get to get a sense of whether the process of that decision was justified and then that will then contribute to our safety there.

Lauri (21:16):

I feel that if I contribute to this team and I propose something and then we discuss about it and we make a decision, I feel that my input is evaluated on a fair principle just like everybody else's contribution.

Boris (21:34):

So I cannot quote studies, but I've done this one company where I actually had a weekly gaming session. And one thing I found is that there's different kinds of games obviously, but some of them are tailored for a group experience. And let's say if you have an online role playing game, you typically have those roles that need to be there in order to do some content, and that means the part that Ester mentioned where you get equal time of speaking might not be explicitly there, but the game dictates that every person has to give an equal part to succeed. And I think that's one way where this can help.

Boris (22:15):

The other thing that if it's a game tailored for a group experience, then it's a group experience. That's the whole purpose of the game, and there's not many things that strengthen team spirit, whatever you call it, more than a group experience.

Nina (22:32):

The connection that I can make here with playing games and psychological safety is that you are in a setup with a team where you can actually fail, you can actually act in different ways, and it's okay to do like that. People will not judge you. You are playing a game, right? And I think once you play and you learn by those things, you can actually bring it back to your daily life, your interactions will have some influence by that experience that you tried all together. So it's about trying out things together and failing. You fail in a game. You lose, right? But also you innovate. You find new ways of playing things, right? And you win as well.

Ester Daniel (23:16):

Yeah. And if you look at collaborative games, often choose a set of players and abilities so that you can achieve something together. You don't have all the people of the same kind. So you have the one who can take a lot of damage. And then you have the glass cannon who can deal a lot of damage but need to be protected. And then you have the dealer and all those different roles. And everybody then has to be used for it to succeed.

Ester Daniel (23:54):

And what you've seen in studies of group performance is that if you don't have psychological safety, you can have a really diverse team but you won't get any benefits from it. Because if you can't be who you are at work it doesn't matter if you have a healer and a glass cannon and a buff thing because you can't show yourself as one. So when they try to study benefits from a diverse team they won't get any predictable results if they don't also measure psychological safety.

Ester Daniel (24:32):

I'm calling it the Little Mermaid symptom that you have to sacrifice who you are to get access to the world you dream of and then you can't win the prince because you've lost your identity. So yeah. I think that's a part of the gaming that you can learn from, to use the entire party.

Lauri (24:51):

So how could organizations identify the symptoms that they and then what's the right way to start addressing them? That would be my one question. The second question would be that when you think of, I can think of many people who have by way of their work, they have seen many, many organizations and they have experience. They don't have an N equals to one experience. They probably have been part of 10 different organizations, and they have accumulated a wealth of knowledge and information. So how could that knowledge be harnessed and then made available for more organizations so that they could benefit from that?

Boris (25:38):

I'm one of those persons that have worked for many companies. I think I've worked for 10 and now at Eficode I'm kind of like working for even more as part of my consulting but 10 real companies. And one thing I've seen that, and this is also reflected in literature, it has to start at the top. You don't need to start measuring anything until you have a management, an upper management that really believes in what they want to see it on there. It has to start on the top, and I think that's the most important thing, and then everything else is going to follow.

Nina (26:14):

I agree.

Boris (26:14):

That was too easy. Come on.

Nina (26:24):

But I don't know. Yes, I think it starts from the top but for sure we have this agency, right? Which means that we have our drive as well as people. We can change things. So I believe also if we then find things that we can change, we can be actors in that change too and contribute to the whole change together, right? So I don't think necessarily we will need to wait for all the solutions come from top to down, but also we identify something that can be changed like how we can leverage this discussion in the organization and that speaks up and people engage and start changing things together. That's a little bit my belief. Yeah.

Ester Daniel (27:08):

I also think that we need to be deliberate. We can't leave stuff like this to chance or well wishing or well intentions. It has to be deliberate. We have to look at what research says because we have the research. We have to start measuring the right things. And if in the society we have all those biases. We have all those social structures. In the IT industry we have the glass roof that stops people who are not male. We have the bamboo roof that stops people who are Asian from reaching higher positions. And if we don't deliberately try to change this, they will stay. So we have to have a way to make sure that we do the right thing. Otherwise we can assume that we will do the wrong thing.

Lauri (28:14):

Something in our marketing team, and I should say it's not representative of the IT organization but it is a representative of the organization who is hard to see the outcomes of the work because it's so intangible. The outcome is so intangible. Something that I feel we've been struggling a lot is to be able to piecemeal our work into small enough chunks so that we can feel that we are getting things done. And I don't think there's anything in that practice that is specific to marketing. I have never been a full-time software developer, but I have been an Ops 20 years ago maintaining Linux and Unix systems and all of that.

Lauri (29:01):

The basic question is how do you when you look at your board and you think what's going on in the board, how do you get the feeling in the beginning of the week that everything is possible? Like, "I don't carry a baggage from the previous week to this week. I can start over. I am a master of my work. I can decide what the world would look like." And then when you come to the end of the week, just accepting that the week is a cycle, then you feel that, "Wow. I got done what I planned for. And the work I planned, it's there. I saw it moving from left to right, and it's now there, and I can go to my weekend, and I can enjoy my well-deserved break."

Lauri (29:49):

And more often than not, if it has happened that there is a work on the board which is not done, it is because of the lack of scoping for the work. It's that we have agreed that we will do this, but we haven't either piecemealed it small enough so that we properly understand and plan how much can be accomplished in a week. And then when you come to a Friday you realize that I was planning on doing it but never got down to it or some other type of excuse.

Lauri (30:22):

So actually it is the case that well planned is halfway done.

Boris (30:28):

You said something that I really liked and that is roughly remembering you said, you're the master of your work. And I think that's the big thing that I wanted to say, actually prepared for ahead of this podcast. The most important thing to is to take responsibility of your own life. That's the only way to get safety, and that's the only way to actually change anything, by not waiting for others to do it but doing what you can do and accepting that your life is your own responsibility. It might meaning having to change a job or changing a team, but you have to take the responsibility.

Ester Daniel (31:05):

At my first job I had one of those paper folders where I put three columns. To do, in progress, and done. And posted my post-its on it, put it on my desk, and then when I left work because we didn't have designated desks, I put it together and put it in my backpack because I have ADHD and even though I didn't know it by then that taught me not to take for granted that I will ever get anything done if I don't piece it very specifically and make lists. And not only lists of everything I have to do but also as the getting things done method states, the first actionable thing to do to get that done.

Ester Daniel (31:53):

So I had to put fishing hooks out everywhere to make sure that I actually had something to stick to when I started pulling in the project. And I'm starting to think that projects also have ADHD. So if you want something done in a project, you will have to be very clear with what is supposed to be done? What is the smallest thing I can start with to get it started? If I need something to make that happen the first step is not that step, it's the step to get the things that I need. And try to slice things as small as possible. And then you also get the reward of moving stickers and you get the early feedback.

Ester Daniel (32:38):

Because if I know that I need this number to be able to get in touch with a person that I might first think is the person that will start it all, and the number is hard to get by, then I will figure that out earlier if I know that getting the number is the first thing to do, not to call the person.

Boris (32:58):

I like that approach a lot. I haven't looked into a GTD for a long time myself, but I used to be familiar with it. But I think what you mean is you have to start with small things and combining that with what Nina says, "We should not wait for the upper management to just start ourselves," I think that's both true but there's only so much you can do in any large or medium sized organization. And Nina in HR might be in a position where she has a lot of reach, but I found in quite a few companies that I can change my own team, maybe even my own department, and then there's kind of a block. And I think if we really want to get worker safety company-wide it has to be at least be sanctioned from the top that things need to change.

Boris (33:44):

So the minimum is people that take responsibility, people that start small, and a management that at least allows them to, "Okay. Let's see where this goes to." Not a blocking attitude.

Ester Daniel (33:56):

Yeah. Because I think the knowledge comes from below. Right, from the floor? It's like in the Toyota factories where you can pull the line to stop everything because you have an idea for an experiment. And I think it's the developers who know how the code should look to be able to be a good workplace. I don't think. Okay, some management can write code. They might know. But I still think that that initiative has to come from the bottom, but it has to be allowed from the top.

Lauri (34:31):

Can I dig a bit deeper on this management aspect? In sales, when you sell something you need to get a mandate from the top and then you need to get endorsement from the bottom. So the basic idea was that if you are selling a software then you need to sell the business case to management that we have a problem that we need to go solve that problem. So that's how you get the mandate and you get the budget. And then you have to go to the people who actually are users of that software or whatever software they would select to solve that problem. And when you make those users your advocates, then they will speak on your behalf for the management. And the management says, "Okay. Here we seem to have a solution that our customers like and the likeliness for our problem to go away with money is higher."

Lauri (35:20):

So if you apply that mandate versus endorsement to the worker safety in the DevOps factory say, "What is that mandate?" So if you are a team lead, if you a manager, head of R&D, whatever sort of roughly speaking middle management. You have somebody above you, you are reporting to and you are accountable for. And then there are people who you manage one way or another. So you have an influence to what an how it should be done in rough terms.

Lauri (35:58):

So what is that mandate that that person in that middle management needs from the top so as to go and do their work to make that DevOps factory safe for the workers?

Ester Daniel (36:09):

I think it is money and probably a lot of money. Yeah.

Nina (36:17):

Really?

Ester Daniel (36:17):

Because one thing with the DevOps factory is, at least what I've seen, is that the chefs are quite used to burns. If you look at the DevOps report, the difference between the high performers and the middle and the low performers is so big that I think that a lot of people, and this is from the companies who answer the DevOps report survey. So there's probably a lot of people who don't even know that it exists. And we don't know the distribution of them.

Ester Daniel (36:47):

So a lot of people in the software industry can't even imagine a safe factory. It's so far beyond what they ever seen that it's not only that they're not allowed to do it properly and they're stuck in their old ways, so they can't imagine what opportunities they have, they lack the skills to do it.

Ester Daniel (37:10):

So you will probably need some support in some way. Hire a senior developer and let them decide how to do it. Put in consultants who can fix it. Courses. Boot camps. Anything. But if you take an ordinary software shop and try to get them to excellence from in the DORA report, I think it's doable, but yeah. I've heard from teams calling tested and development a unicorn because they heard of it, but they couldn't imagine it being true, and they've never seen one.

Boris (37:56):

So I'm really happy that you mentioned money because normally that's me, and I don't really want to be the one to point this out. But yes, one way or another I think it's money because you need to work in a different way and working on psychological safety, working on safety in general means diverting from the path everyone knows and has accepted and it's going to take some time to show results.

Boris (38:23):

Like if you do some talks to your team or however you spend time with your team and invest time into their wellbeing and the overall forming of a team that you want to work in yourself, this takes time.

Ester Daniel (38:37):

And it is an investment.

Boris (38:38):

It's an investment, and the only way to justify it is by showing either by pointing at research or by other departments, "Look. We make more money." Because in the end that's probably the only thing the upper management cares about and maybe that's even a good thing.

Lauri (38:54):

Yeah, Ester Daniel, you mentioned earlier in your opening speech, you mentioned Paul O'Neill from Alcoa. I am looking at the book, The Unicorn Project, now and as you said, it needs money and it needs a lot of money. Money is actually, it's a simple way of solving the problem just as long as you can justify the need. And if you look at Alcoa and I'm verbatim reading it here. "His board of directors initially thought he was crazy, but in the 15 years of his tenure as CEO, net income increased on $200 million to $1.5 billion. And Alcoa's market cap went from $3 billion to $27 billion."

Lauri (39:40):

So it begs a question, how much of that growth is attributed or can be attributed to the influence in the worker safety? And then consequently, if this is also true for the DevOps factory, then what kind of payback is expected in exchange of that investment? Like if you need money and you spend that money, then what do you get for that money?

Ester Daniel (40:07):

I think it accelerates its survival. That in the long run software companies who doesn't do this won't survive, and all companies are software companies today.

Boris (40:19):

Mm-hmm (affirmative). Yes, survival is a good point. I don't have the numbers, but one of my colleagues showed the time needed to deliver a feature before and after his successful, they were DevOps information for a customer and that's a number you can put down and put a cost to it. And even I was impressed as to how much money that company saved. But yes, I don't have the numbers but you can get the numbers and someone probably should.

Ester Daniel (40:48):

I think they are included in the DevOps report. I mean it's at least actually included in grouping the companies on their performance. So it is a factor.

Lauri (41:01):

Yeah, that is.

Ester Daniel (41:02):

And it correlates with how well they do DevOps. And then also with how well people are faring at that company. So if you would use the Alcoa method, you could drive even further excellence by also looking at how people fare.

Lauri (41:22):

I think accelerate usually is the deployment frequency lead time, change failure rate was on the list, but I don't think they ended up selecting it. And then there was meantime to recover. At least three of those four were on the list. Maybe something more as well.

Boris (41:40):

But I think the point to survive as a company should not be underestimated. Software projects have now gotten so big that if you don't take care of how you work, and if you don't take care of the knowledge of your workers, you're likely going to end up in a lock where nothing ever gets moved.

Boris (41:58):

And I've seen this actually a few times myself where you have a software basis that was just so big and there were so many processes that it was actually literally impossible to change a simple feature under six months.

Lauri (42:13):

It just occurred to me that there was some of the literature who said that for psychological safety, there was a line of thinking, but for psychological safety you need absence of fear. Like if you don't have absence of fear then you cannot have psychological safety. But survival is not a positive word. It have an element of fear in it. So any time management is making a case for DevOps on the basis of survival, then there's immediately this element of fear in that company existence level, not in the DevOps level. If you can see where I'm coming with this.

Lauri (42:58):

So I would ask for something more safe way to put it than survival.

Ester Daniel (43:07):

But I think when it comes to psychological safety, it's interpersonal risk that is the more specific thing. So it's not lack of fear in general, but it's lack of being hurt in a personal relationship because of what you do. So it's fear of social punishment in a sense.

Ester Daniel (43:28):

And I think that, okay fear, if you face it as a challenge it can actually group people closer together, I mean the external enemy. And sometimes we perform as best when we know that we have to join forces to be able to achieve anything at all.

Boris (43:56):

I think if you want another word you can choose business continuity which is probably the more business term. But it's just the same, and there's two different kinds of fear. One is the fear for the people on top that have to take big decisions that they're losing and other thing is the fear of the person working in the company that they're not treated as human beings. So that's two different kinds of fear.

Boris (44:24):

And personally I don't care if one fear does a greater good by solving a bigger fear. That's fine for me.

Lauri (44:33):

Yeah. So many parallels that comes to my mind from fictional literature. Let it Harry Potter or it be Star Wars or maybe Lord of the Rings or anything like that. I can draw many parallels to any of those.

Lauri (44:52):

We have had a good 45 minute conversation, so I just wanted to ensure that we spend the time and we give a chance for Ester Daniel, not wrap it up but make an entering report and then we make a round for Nina and Boris and then we will basically wrap up.

Ester Daniel (45:14):

I think it's something you can do when watching a movie if you want to think about psychological safety is all the ways the plot would have been ruined if people would dare to speak up. A lot of the intrigue in a movie is built around people being psychologically unsafe and having that as an exercise could destroy a good Friday evening, but it could also bring some insight into how rare the world sometimes is.

Ester Daniel (45:50):

Nina talked about gaming and how collaboration and feedback and rewards and I think it was about celebrating failure as well as building your health.

Ester Daniel (46:08):

Boris, you talked about taking responsibility over your own worker safety. Knowing that you have to put your helmet on and that you should leave if you see that the leadership doesn't do anything about the creaky beams. To put your own life over next month's paycheck.

Lauri (46:31):

I think more than anything else, what we have referred is the DORA report and Accelerate book. There is a very good reason why we continue to come back to those sources because the sample size is so big and the work is so well done. So I personally would advise even though I am not a DevOps practitioner, I'm a marketing leader, but I have referred to the dollar reports. I actually have them all printed out here for my own entertainment starting from 2013, and I have Accelerate book that I keep going back. So if I were to give any peer advice to anybody else in the position similar to me, I would tell them to start by reading Accelerate Book, maybe other similar research in the same region. There's a DevOps handbook. There's Unicorn Project, Phoenix Project. They all sort of go around the same bowl of porridge.

Ester Daniel (47:30):

Yeah, and they have their root in the Theory of Constraints.

Lauri (47:34):

Yeah.

Ester Daniel (47:35):

So reading The Goal and the books coming after that is if you want to go back to the factory factory, that is a good way to do it. And I also want to say something about science in itself and the scientific thinking. It also celebrates failing. When you failed in experiments, it's first then you know something. Success doesn't ever prove anything. It's only failure that proves something. We should listen to research we have. It's not about opinions. It's doing DevOps right saves our brains. And we can also do all those tiny experiments in our life because the feedback will make us happy. And if we don't know how to do things, that it says in the DevOps report we should do, get help because it will be a good investment.

Lauri (48:42):

Doing DevOps right saves your brains. I think of that. That was what you said, fantastic summary. Boris.

Boris (48:51):

I think because we surely could do another podcast on the scientific way to measure success and happiness and cultural changes, and I would really like to do this. But even before just at this Ester, I wanted to point out at the end of this podcast that measuring, looking back, and actually taking a look if what you did had any success, is probably the most or one of the most important parts. Because what I've seen a few times, companies moving somewhere, implementing things, and then moving on to the next things, implementing new things, but not looking back. And some of those things that were implemented actually increased the amount of fear instead of reducing it on a team level.

Boris (49:37):

Yeah, looking back is probably one of the biggest things to do.

Ester Daniel (49:40):

Retrospectives.

Boris (49:43):

Retrospectives, yeah.

Ester Daniel (49:44):

And making them properly as well. It's also a skill to do a good retrospective. So if you don't get any results from your retrospective, it could be that you're doing them wrong.

Boris (49:57):

And I think this whole movie example is just awesome. I never heard of that before, but I think that's something, if you take away one thing from this podcast it's this movie example. All the companies I know have some sort of drama. So there's ample opportunity to actually put that analogy into place, and I think about the drama that we had last week, how would it have been different if people had found the strength to raise their voice?

Ester Daniel (50:24):

And also that psychological safety is not an individual trait. It's a trait of a situation. So you can't be a person that is more or less psychological safe. You can be in a setting that is psychological safe. So if you feel that knot in your tummy that stops you from saying things because you will be ostracized and not having any food around the fire that night, then it's not about you, it's about the context. And if someone comes to you with that fear that is like the biggest gift you can get. So that kind of feedback is, "Thank you," is the first thing to say and then realize what it takes to do something like that because they actually, our lucid brains is putting our life on stake.

Lauri (51:17):

Mm-hmm (affirmative). Nina. Final words from you.

Nina (51:20):

I think we have very fruitful discussions today, and I'm very happy to hear your point-of-view about psychological safety, gaming, organizational structures, and driving things together. Yes, I actually don't know what to say, so you can cut this part.

Ester Daniel (51:50):

Oh, Nina. You're awesome. Do you know that?

Nina (51:51):

Thank you. You are also awesome.

Lauri (51:56):

All right. Well, thank you a lot for the conversation. It was very enlightening, and you gave us a lot to think. I believe this is one of these podcasts where you listen to it once, and then you go and think about it for three years. Something like that.

Nina (52:11):

Wow.

Lauri (52:13):

Thanks a lot.

Lauri (52:14):

What a fabulous discussion. My discipline does not lie with software development, but I was able to relate to so much of what was said. Our participants referred to a lot of literature during the discussion. Be sure to check out the show notes for the references.

Lauri (52:34):

To wrap it up I want to repeat the brilliant advice from Ester Daniel. "Do DevOps right and save your brain." I should say that is our responsibility not only towards ourselves but also towards each other.

Lauri (52:50):

That's all for this time. Stay safe, and talk about the IT workers safety.