Host Intro (Gene Kim)

This is the industry discussion on burnout and technology. The purpose of this panel is to share what we've learned this week about burnout and engagement. Here are the questions, and I'll just list them out and we'll see where it goes.

Is this important to you and why? What do we need to do about it as a community? We have an opportunity to shape next year's programming, so what can we do to make a dent? What have you heard about that is needed from leadership? In the hypothetical, what does leadership need from us?

That is about as far as I've thought this through. Maybe we start about, is this important? John, come on. This is actually your idea.

John Willis

I always say that I didn't choose burnout, burnout chose me. In the DevOps community in Los Angeles, I think it was 2014, a young gentleman who I'd gotten to know at SCALE, the largest local Linux conference, committed suicide. It was clearly burnout, and it affected me in such a deep way. I called Gene and asked if I could write a blog post on IT Revolution, because what happened just took me down as a human. Gene said absolutely.

I put it up there, and if you didn't think there was a problem, what we saw in the comments was thousands of comments within a weekend. Gene and I went on suicide watch for a young man. We had to coax him and tell him who we were. Then I started getting emails, and I realized this is a really dangerous thing in our community that we're just not talking a lot about.

There were similar cases in the information-security community. Josh Corman was also very passionate about that. That's how I got to Christina Maslach. Josh Corman sent me to the Maslach Burnout Inventory, the MBI, which she created. They had done an industry-specific MBI with about 400 people in the ITSC community, and he shared the results with me. I started tracking down who Christina Maslach was and what this was. To summarize, it was as bad as police officers and ER.

I've always wanted to do that in our industry. I think it was the first time a report showed in IT, and in ITSC, that our industry is stressful too. People may think the programmer in the corner must be happy, while a police officer or ER worker must be stressed. I thought it would be awesome to do an MBI in our industry, so we could compare ourselves with doctors or fighter pilots and see where we are.

Courtney Kissler

I think it's extremely important. One aha for me in the last six to twelve months is that in our industry we focus on resilience, but often we talk about the resilience of the systems and services we provide. Really, we need to be talking about the resilience of our organization, our teams, and our people.

I started in startups, and it used to be a badge of honor to pull an all-nighter, stay up and deploy code, get back up, and go right back to work the next day. Somehow our industry has not lost that. People still talk like, if you're not sitting at your desk for twelve hours a day, you must not be committed. It's so opposite.

As a leader in a big organization, I find myself exposed to that old way of thinking and figuring out how I can show up differently, engage differently, lead by example, and influence our peer groups so they see that you actually get more resilience when you practice things like mental health days. I was reading GQ on the flight down, and it talked about the courage it takes to say you need a mental health day and how hard that is. So yes, I think it's extremely important, and I'm glad we're talking about it more.

Scott Prugh

This is incredibly important to me. When we did CultureIQ and started measuring NPS and employee NPS, the first CultureIQ results came back with thousands of comments. There were a ton of comments around work-life balance, with a lot of people saying it was not sustainable. That hit me: this is what I'm doing to people.

It became incredibly important to start looking at that, understanding it, and making it visible. In the presentation with Brian, part of what he cares about is seeing what work is happening on teams, both product development and operations: change requests, service requests, pages at night, work, and disruptions.

As an organization, we had no idea. You hear about it, but we didn't surface it and make it visible. The product-management teams definitely didn't understand it either. Once we started to make those things visible, we understood we had to fix it because this was something we were doing to people. That has been the focus for the last eighteen months or so: getting a handle on it and continuing to improve it with our folks.

Jeff Gallimore

It's important to me too. John mentioned the blog post he wrote a few years ago, Karojisatsu, and the comments and emails it generated. I was one of the people who read that blog post and sent John an email afterward.

My perspective on what John had written, as a leader with a team of people and a company of employees, was that I feel a great amount of responsibility and accountability for their careers and their happiness, both personally and professionally. One thing I appreciate about this DevOps community is the sharing and learning that happens, teaching me things I needed to know about that were important to my clients and employees, but also the caring that goes along with it. It's the most human community in the technology space that I think I've ever been part of.

As a leader, the picture I had in my head when I read John's post was: imagine getting the news that it was one of your employees or somebody on your team who did that. It horrified me to think about that. That was when burnout, that B word, stopped becoming just a word.

John Willis

A week later, another gentleman from that same company committed suicide. I got to know Christina Maslach. One of the things I talked with her about was a hypothesis: if you read Carlo Flores's tweet stream, it was clearly crying about efficacy.

We do a disservice if we think burnout is a badge of honor. Let's obliterate that. Even worse, there is a difference between clinical burnout and just being exhausted. The hidden things are important. In the MBI there are three dimensions: exhaustion, cynicism, and efficacy. Exhaustion is easier because you can see it. The one you never see is efficacy: do I matter?

I might work for Courtney, have a great idea, and she says, John, not right now. Then a week later the same thing happens. I know she's busy, I don't understand the big picture, but I start to get the sense: do I matter? I start caving in. I have a feeling that in our industry, efficacy might be the really nasty hidden one.

We can see that we're overworked, the death marches, and as good leadership we should cull those. But the roles we play today and the things we touch have incredible impact on lots of people's lives. Imagine a 25-year-old out of university turning knobs. Somebody turns the wrong knob and loses $420 million in three or four hours; they're out of business in 24 hours. A lot of our people may feel that if they make a mistake, someone can't check into Disneyland. That is part of the pressure.

Host Prompt (Gene Kim)

I'm going to give you a magic wand. What would you want to do, if you could wave a magic wand, that we could do for the programming to address this issue? We've got Dr. Maslach, who was willing to come back. John and I have been brainstorming about bringing in chief people officers, people trying to redefine HR and performance management. The idea box is open.

John Willis

I think we ought to follow through on the MBI. We've been talking about it. Let's roll up our sleeves and get it done. Gene has the biggest microphone in our industry. Let's do an industry MBI and see what the data says. Then we can start from there because now we've got proof that this has to be changed.

Courtney Kissler

I like the idea of industry experts and chief people officers. The other piece that's important is finding technology and business leaders who are making this happen in their organizations. Once you make it visible and decide what you're going to do about it, I would love to hear success stories or things that have been tried to make it better.

It comes down to what the organization values. If you can get that story out there and people can see that burnout is not a badge of honor and how addressing it builds resilience in the company and helps people be successful, that would be powerful.

Scott Prugh

Something interesting I'd like to see is a tie to burnout and working safely in complex systems. One issue is obviously overworking people. The other is putting people into systems that are incredibly dangerous, where if they make a mistake and blow up some environment, executives and customers come down on that person. That is incredibly stressful and terrible for the individual because it's not their fault that they made a mistake. The system was not designed in a way that could prevent that from happening.

That's another key area: working with my people and architects to make systems safe so people can't make those mistakes, or so the blast area is relatively small. Leaders across the organization need to understand that failure is not a people problem. It's a robustness problem in the system, and it is also about resilience in the organization to deal with it. It's hard to change that culture because it's easy to pick up the phone and say, fire someone because they made a mistake. That's the wrong reaction.

Host Prompt (Gene Kim)

Part of CSG is a bill-printing operation. There are norms in the plants about safety. Can you tell us what that sounds like?

Scott Prugh

At the printing facility, all the systems are designed so you can't get your hand caught in them. The plant manager's biggest worries are that a roll of paper weighing tons could roll off and kill someone. They are very focused on physical systems being safe so people can't get hurt, and there are protections in place.

In IT systems, since you can't see the system itself, and Richard Cook has a great pictorial of above the line and below the line, the complexity that people manage creates unsafe and dangerous environments. Surfacing that and continuing to make it better is incredibly important.

Host Prompt (Gene Kim)

How do we tackle that problem with programming? I don't have easy answers because it isn't easy. If it were easy, it would already be solved. Did you learn anything this week that is relevant to making a dent in this problem?

Jeff Gallimore

One thing I relearned was the MBI, the Maslach Burnout Inventory, and the construct behind it. I now have a vocabulary to talk about burnout in a way I didn't have before.

I relate this to culture. Culture used to be fuzzy and amorphous, something you couldn't put your finger on but knew when you saw it. Through this community I learned about the Westrum cultural topology. I now have a taxonomy and construct for talking about culture, describing different kinds of cultures and their characteristics. Because I can describe it, I can measure and assess things about it. Because I can measure and assess things, I can change it, because I know the actions I'm taking are having an effect.

The MBI is doing the same thing for burnout. Instead of just saying, I feel burned out, now I have vocabulary to ask: what about the situation is making you feel burned out? Is it overwork? Is it cynicism? Is it self-efficacy? Tell me. Then we can start tackling those things and coming up with actions to move the needle and get that person out of that situation.

John Willis

For $15 you can run the MBI yourself. At QCon a couple years ago, I was asked to give answers, and I said I am not certified to give answers. I researched what was out there. I took the MBI myself when I was at Docker, and I exaggerated a little to show how it worked. But on efficacy, I had no idea I was fire-engine red, in the highest percentile. It was beyond the fabricated effect.

It helped me understand that at Docker I was remote and frustrated because decisions were being made without me. I had ten startups behind me and wondered why they weren't asking me. Then I realized: because I don't live in San Francisco. The next question was whether I wanted to live in San Francisco. No. Taking that test helped me every time I got frustrated about something happening at the whiteboard and then coming out later.

If $15 is a barrier, DM me. We could also create a scalable MBI for the DevOps Enterprise Summit community and have real data.

Gene Kim

When we wrote The Phoenix Project, there was the Brent character. Brent is a caricature, but we've all been Brents. Writing the confession for the router error was astonishing because I realized there was a dimension of Brent I either didn't acknowledge or didn't understand. The stress and physiological response when you're in that mode, especially sustained, made me realize that's probably what we do to Brents. Lots of organizations have Brents.

Courtney Kissler

I agree. I also think there is a false expectation that Brent is going to raise his hand and say, I have too much workload. Brent is never going to raise his hand and say that. So how do we see it? Jay Paul and I have talked about weak signals. Someone told me that when he went through a dark period, you will not be able to see it in someone else; you know it yourself.

As a leader, rather than trying to identify it, how do I create the environment where it never happens? Make sure people feel valued. Make sure people are part of decision-making. A big challenge for us is empowering teams to actually have decision rights. That level of engagement is something I can control. Maybe I can't control an assessment process that sees it coming, but I can do things differently to help individuals and teams feel like they can be successful.

Jeff Gallimore

Everything Courtney said, plus: it is important to empower teams and give them autonomy, and you have to help them get there. Sometimes it takes a leader to step in and say, this is not right and this needs to change. It lets that person off the hook from feeling responsible to work themselves out of that situation.

Recently I was meeting with one of our teams. The team lead was supporting a production release window on a Friday night. We finished our work and waited for other teams until after midnight. I was up with him on Slack, and he let me know he had gotten in at the normal time that morning, 9:00 a.m. I had a WTF moment: he was working a fifteen- or sixteen-hour day. It was not right.

Gene Kim

At lunch, someone gave me an alternate ending to the confession story about the engineering leader who left. The different ending was loud: this is not right, I quit, here is my resignation letter, and it goes to everyone because this norm is not right. It painted what it should look like. It was provocative.

Courtney Kissler

I have definitely been in the scenario where you're put on the spot to say who made the mistake and who is going to be exited from the organization. I have genuinely said back, me. If you're going to show someone the door, show me the door, because I'm the leader accountable for this environment. That's what I would like to see leaders do.

John Willis

When I wrote that blog article, I got 200 or 300 emails and testimonials. People, industry leaders, people I didn't know, people I thought didn't like me, would start with, John, please don't tell anybody, let me tell you about my situation. I wondered why they sent it to me. I realized I'd been vulnerable. I had made myself vulnerable to people.

The greatest gift you can give as leaders is to be vulnerable. Steven Spear had a quote: we can talk about empowering the masses, but that's impossible when the leader acts like an arrogant jerk. Leaders need to model not knowing. Imagine the CEO or CIO saying, hey, everybody, I don't know how to do this. That doesn't happen often, but it has to go both ways. Even in one-on-ones, people may come with stories if there is vulnerability.

Jeff Gallimore

Amy Edmondson's work is the actual demonstration to establish norms because you're modeling desired behaviors. If you know the Google re:Work studies, psychological safety was the most important factor for high-performing teams at Google. Amy Edmondson has done a lot of research on that. Actions leaders or individuals can take include framing problems not in terms of success or fail criteria, but as learning problems; admitting your own fallibility, that you can make mistakes and don't know everything; and demonstrating curiosity and asking questions. Anybody can do that, but because it's new, different, and against the grain, it takes courage.

Gene Kim

One thing we brainstormed and tried to get to this time was bringing in Dr. Christina Maslach; Prasad Setty, who was at the helm of Google's Project Aristotle; the chief people officer of Kronos; and Nicole Forsgren to bring the State of DevOps work to bear. Kronos made being one of the best places to work a top goal, brought in the SAS Institute, benchmarked employees and customers, and found the biggest problem with retention and engagement was bad managers. Their strategic goal became that every worker deserves a good manager. Over five years they moved to a mechanism where the primary measure for first- and second-line managers is based on their reports, created a Management Engagement Index, and found statistically significant relationships between MEI and retention and engagement.

Courtney Kissler

My only add would be, if possible, find a leader or manager who was part of that transformation and could share what it was like to be influenced to change how they were showing up with their team. It's great to hear about programs and industry information, but putting it into practice is the hard part. If we could find someone who went through that journey and would share, that could be powerful.

John Willis

I told Christina when she got here that this is a unique community because we have been very open to people coming in from outside the industry. If you listen to Sidney Dekker, John Allspaw, Christina Maslach, Scott on resilience and complex systems, commonality keeps showing up. It must be true because it keeps showing up. Almost every one of them has something embedded around psychological safety.

If we stop blaming people and look at systems, there is no person actor. The person is just an actor in a system. That starts lowering or raising the efficacy scale or cynicism scale. My ask is that I've been throwing ideas at Gene: let's bring this person in. You all need to start. If you read something and it sounds like Dekker or Christina, ask whether we can get that person here.

Gene Kim

How cool is it that we can bring the best experts into this community: Dr. Steven Spear, Sidney Dekker, Richard Cook, Christina Maslach? If you have a magic wand to bring someone in, get it to us or to John. Sometimes it takes a while to earn the right to ask, but if we come up with the right list, I think we can get them.

Let's wrap up. We said: is it important? Yes. What can we do about it as a community? Great discussion. We have an opportunity to shape next year's programming and got good ideas. Jeff, do you want to put your question out there in terms of what we need from leadership or what leadership needs from us?

Jeff Gallimore

I mentioned my perspective as a leader. I participated in open spaces at DevOpsDays around burnout, hearing people share their stories who were experiencing burnout and realizing that as a leader there are people in my organization experiencing that too, and I don't know about it. What do they need from me as a leader? What do we need from our leaders to do or do differently that we haven't been doing? I want to hear that.

Courtney Kissler

At one point in my career, an executive leader literally said to me, I walk the floor where your team works after 5:00 p.m. and nobody is there. I stand at the elevator banks in the morning and nobody shows up until 9:30 or 10:00 a.m. That must be the reason we're not delivering against expectations.

I thought, how can we manage this with facts and data? I tried to explain that the work we do doesn't always require physically sitting at a desk, and that many people were doing work at night and on weekends because that was the situation. I worked with an engineering leader on my team and extracted all the code commits happening outside normal business hours. I used that with the business partner to have a fact-based conversation about what was really happening. Sometimes it's hard to have the conversation with someone whose mindset is in a certain space. I was struggling with what I could use to dispel the myth. It helped.

John Willis

When I got to Chef, Chris Brown, who wrote Amazon EC2, and Jesse Robbins, called Master Disaster at Amazon, were part of an incredible set of people. At 9:00 there was no one in the office. At 5:05 there was no one in the office. From 2009 to 2015, if you pay attention to what they did for our industry, that was basically a 9:00-to-5:00 shop. It was more productive than most companies I've seen in almost forty years. They would not have been as productive had they been working twenty-four hours a day.

Close

Gene asks whether there is another session, learns it is break time, jokes that the panel is stealing coffee and soda, and thanks the panel.