Dr.Burnout and the Dev

I have just started listening to a new series of TED Talks called Sincerly X,. It is fantastic! The series are presented anonymously and cover topics and ideas that would not be appropriate for the standard TED talk. It is really amazing and I highly recommend it if you have not listened to it yet.

The second episode is titled “Dr. Burnout” is about a Doctor who let a patient go home when her better judgment would have told her to pressure him to stay in the hospital. The speaker (we’ll call her Dr.X) talks about how that particular day she just couldn’t muster up the energy to…well…care. The patient went home and later returned to the hospital and died of preventable complications. This patient under Dr.X’s care might not have died if she had cared enough to push back on the patient’s desire to go home.

She calls it “Doctor Burnout.” Dr.X talks about the expectations of Doctors to always be there, always being accommodating and always able to fix the problems they face. This leads to many Doctors neglecting their own needs and personal care. Eventually, they tend to just stop valuing people like they should. This causes them to be less engaged and can lead to poor decisions that may kill people. In Dr.X’s case…it did.

Listening to this I couldn’t help compare to our work as IT professionals. Just yesterday I was talking to one of my leaders and he said, “My work life went up, and my personal life goes down.” My operations and development teams work long hours to perform their daily responsibilities. What’s worse, is that many of the projects get dropped or implemented poorly. We have many, many examples of this problem in the DevOps handbook and many of the talks from organizations all around the DevOps community.

And much like Dr. X, burnout results in apathy, just like with Dr.X. I remember walking into my organization as a new hire ready to take on the world, that did not last long.

“Just curious, shouldn’t we spend more time testing?”, “Think we could get a server for this?” “No, no funding” “Think we could try a Node server?” “No, not in scope?” “Not my job..ok” “That’s not the official change window?…yep I’ll be there at 2am”… After some point most of us stop hitting our head against the wall and starts saying, “It’s not my problem.”

This apathy, in a siloed organization, only feeds the “wall of confusion” that sits between Dev, Ops, IT, and the business. “Look, I have a million things to do today I can’t worry if Ops can’t support the last build, it’s their problem, not mine,  it’s all in the documentation.” This kind of attitude, I believe, is probably not from a lack of empathy or laziness, it’s from bad metrics put on IT professionals creating IT burnout.

What do I mean by metrics? Let’s go back to Dr.X. In her talk she talks about the metrics of how she was valued. The, paraphrased, list was like this: always available, always accommodating to patients needs, and always able to fix their patients problems. These metrics are how Dr. X measured herself and how her patients measured her. If she doesn’t measure up, then she isn’t doing what she is paid to do.

We could probably just replace “Dr” with “Dev” and we would have the metrics expected from most IT professionals and departments. Every IT individual is expected to “keep the lights on” no matter what. But the “no matter what” comes at a price and often a big part of that price is burnout.

But what do we do? It’s not like we have people working 80hrs a week for fun! I know we all want what is best for our people, but you’re right sometimes you have to get what you have to get done…done.

The answer…this is no prescribed answer. Your issues in your organization are a likely combination of technical debt, culture, and industry pressures. How you address these issues will be specific to your problems.

But there are some things you can do to start. If you haven’t read the Phoenix Project & The DevOps Handbook I recommend reading these books for a start. The next thing to do, get visibility into what is going on in your org.

When I say visibility I mean not what you think is going on, but rather what do your workers say is going on. A successful method you can use is Value Stream Maps, Alexa Alley from Hearst has an awesome talk on this topic from DOES 2016. In addition, Kanban Boards have an amazing ability to bring clairvoyance into what day to day demands your people deal with. Dominica DeGrandis from LeanKit has a really good on what she calls “time theft”. I will have a future blog post on visibility, stay tuned.

Burnout hits all of us, and for many of us, it feels like a way of life. The way to fix burnout is no simple problem, but it is an important problem, and we have examples all in of the work we do as well as many case studies (See the The DevOps Handbook). The burnout your people face has very real consequences and depending on your indrustry, those consequences may be the same as Dr. X’s. But there are a way’s out of it, but it is not easy and takes time, consistency, and work.

I believe not only that burnout can be reduced, but that reducing it will be rewarded in ways that cannot be imagined now. Imagine what a work force that is not apathetic can do! I wonder on how much innovation we are losing out on because our people are too burnt out to try? I wonder how much more effective we can become? I wonder if I’ll ever have to stop wondering…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s