Coffee Shop Devops: Tips for avoiding burnout

5 rules for avoiding burnout

Subscribe now

Get the highlights in your inbox every week.

I have goals that might seem familiar to you: improve my overall working conditions, set boundaries for myself, and arrive at some sort of balance between a reasonable stream of work vs. getting things done in a resource-constrained space. If these goals are true for you, keep reading. If not, is the company you work for hiring? "My friend" is looking.

Just kidding—I love my job and the reason why is that I work with a lot of excellent humans. They make work fun. They also can, unknowingly and with good intentions, contribute to an impressive, sometimes almost overwhelming, amount of work for me. I am not good at setting boundaries. I want to help everyone who needs help, and if someone is asking, I'm the first one raising my hand. However, I recognize that this desire to want to do everything all at once is not practical. So I return to the fundamentals of everything I know from my profession.

As I am a practitioner of the cliché "practice what you preach," I recently wrote a list of rules for myself. I am sharing it today as a way to encourage you to try it out, or, far better, to formulate your own. Help yourself avoid that desperate state in which you lose interest in something you love.

1. It is OK to say no, but define the rules before I am asked.

Recently, I was asked to fly to India to help some new teams at Red Hat learn a bit more about how to approach the ideas underpinning Agile effectively. Impulsive me wanted to respond, "Yes, I will absolutely travel to India to meet people and share what I know." However, reasonable me followed up with, "OK, so you are going to fly to India. That's almost a two-day trip, you will only be there for around a day, and then you have to fly back for two days. You have a class that week, are teaching the following week, and somewhere in between all of that you are supposed to organize a yard sale. Oh, and in case you didn't know, you need a visa."

In this case, logic and reason won out over emotion and a desire to help. I needed to have a plan in place for training distributed team members, one that includes other parts of APAC. I needed a higher-level goal to achieve while I was there, and a little more information about whom I could help while I was in those offices.

I wound up saying no, but how did I arrive at this decision? I asked myself these questions:

Is it no? Or not right now?

Is it no? Or not the way you asked me to do it?

Is it no? Or can we do a little bit now and increment into the rest of the request?

Is it no? Or do we need a better-defined goal before I can commit?

If it is a yes, how do I know I can commit to the work?

2. All work must be visible before I commit to something new.

I use a combination of Trello and a cork board in my office to track work. Trello is for work that can be shared, and the board in my office displays the work that I alone can do. I look at both each morning and assess the priority of the items I have to complete. The boards indicate the volume of work that I am currently aware of that belongs to me, or my team.

Also, the board will show me our most common failing as an industry—overcommitment to work, or even worse, having someone else overcommit you.

My levels of procrastination increase, which are directly measured by the increase in number of "cute cat video" searches in my browser history.

Exercise decreases. I start failing to go to the gym.

I become more socially withdrawn as the responsibilities pile up. Simple tasks like feeding my cats or deciding what to eat for dinner frustrate me.

Repeat all above steps.

It's a vicious cycle to break. The only way I know how to break it is to reset everything around me completely and set serious time-related boundaries.

3. Set time allocation goals for specific categories of work.

Twenty percent of my time is dedicated to responding to email—no more, no less. If I don't get to it all in one day, I have to live with that. This helps me set the amount of time I will allocate to each response. If I need significantly more time to respond to an email, then it should be handled with a follow-up call or face-to-face meeting with that individual. After that meeting, a recap email should suffice to touch on high-level points. I have a queue of approximately 200 unread emails in my work inbox. That does not count the ones that exist in filtered mailing lists that I also ought to be reading. The amount of effort I would need to expend to keep up would come at the expense of other categories of work.

Tip: I got myself a walking desk. Yes, it was expensive, but it was worth every penny. I now walk while responding to email. This means I walk approximately 1.5 hours a day, five days a week. I still want to go to the gym, but at least I feel like I am doing something.

Fifteen percent of my time is dedicated to the mentoring coworkers, including my own team. Helping others achieve their professional goals and feel good about what they are doing is a personal passion of mine.

Ten percent of my time is dedicated to professional goals, such as writing this column, helping organize a DevOpsDays for the Raleigh area, speaking at conferences, and also attending classes. These things are critical to my overall well-being because they are typically the things I want to do, rather than have to do. These are the things that make me happy, but are often the things that are immediately dropped to handle the next category.

Fifty-five percent of my time is dedicated to the Agile teams I support. This is the day-to-day running of teams—ensuring that work is done in a sustainable way, making people smile, generally helping get stuff done. This work is constantly changing, so estimating the time I need to dedicate to these efforts is hard. Therefore, these percents are my general guidelines for what I should be spending my time on when work is a steady stream. When it is becomes a fire hose, resorting to priority is also a critical tactic for success.

For example, I will always prioritize the needs of my teams over writing email. When team needs increase, I am not going to continue to spend hours of my work week responding to email—nor am I going to work 90-hour work weeks to catch up. However, I likely will have to spend an entire Friday in the future answering all of my email and getting my inbox to zero.

4. In the end, when you do need to say no, do it gracefully.

There is a difference between unacceptable no vs. an acceptable compromise.

Scenario: Your manager has indicated that Important Project #925.16 v.7 has a critical upcoming deadline. To meet this deadline, all staff must work the weekend. You are absolutely not going to come into work on your day off. So, how do you say no?

Unacceptable no: Just don't show up. Sure, avoiding confrontation at all costs sounds like a great idea. Although your manager may forgive you eventually, your team members will Never Forget. I promise you. I still remember that time when a coworker didn't show on a weekend when we were all supposed to be on site testing the roll-out of a new version of Windows to all of the 1000+ desktops in the company. I will Never Forget.

Acceptable compromise: Talk to your manager before the weekend and see whether you can negotiate a deal. Something to the tune of, "I understand that we have to work over the weekend to meet our deadline. Can we discuss other ways that I can modify my schedule so it has less of an impact on my family/hobbies/etc.?" If you approach this conversation in a sane and civil manner, my expectations would be that you are treated sanely and with civility. The answer that they can give you is either Yes or No. It's that simple. If it is yes, great. If it is no, it might be time to reassess your working conditions and start thinking about what you want to do next.

5. Revisit and revise the rules regularly.

These rules are about building healthy and sustainable habits. They're not about my sense of self-worth, but about my well-being, and so they can't be carved in stone. I need to revisit and revise them regularly, and know that this process is a feature and not a failure.

Finally, time to build good habits is the most important factor that will determine whether or not this strategy will work for me. If something isn't working, I will modify my behavior to see what will work. I won't accept an unhealthy habit as "just the way things are," but instead will plan to make a change and try something new. I can't determine at the moment whether I will be successful, so instead of trying to guess how I will do, I will follow these words of wisdom:

"Always with you, what cannot be done. Hear you nothing that I say? You must unlearn what you have learned."
"All right, I'll give it a try."
"No. Try not. Do. Or do not. There is no try." Yoda and Luke Skywalker, The Empire Strikes Back

Topics

About the author

Jen Krieger - Jen Krieger is Chief Agile Architect at Red Hat. Most of her 20+ year career has been in software development representing many roles throughout the waterfall and agile lifecycles.
At Red Hat, she led a department-wide DevOps movement focusing on CI/CD best practices. Most recently, she worked with with the Project Atomic & OpenShift teams.
Now Jen is guiding teams across the company into agility in a way that respects and supports Red Hat's commitment to Open Source.

6 Comments

I absolutely love this article, thanks for sharing! Quick question - when you reach your percentage of time for items besides e-mail, do you simply stop that activity as well, knowing that it will still be there later?

Very good suggestions. As of a month ago, I started the end of my full-time career, and am now starting to work only two days/week in the office in the center of Tokyo. I'm worried about stuffing the excess time with so many projects that will not achieve the balance you mentioned. Your suggestions of activities/percentages are helpful . Also, the quote, "Stop starting and start finishing" really struck me as one of the secrets. It is such a great feeling when something is achieved and finished. Unfortunately that feeling can be so powerful that the tendency to overcommit as you mentioned intensifies.

The quote is one of my favorites... and probably one of my most repeated mantras here at Red Hat. :D Observing all of the lovely people around me - we all need to live that a bit more... both in our work lives and personal lives. :)

Hey liko - Typically when I reach my percentage of time for the day, I move on to other activities. Take that with a grain of salt though - this week and last week have been consumed with team support activities, so I am behind on everything else. I blocked some time off for myself on Friday and Thursday afternoon to play a bit of catchup on the other items I have languishing in my backlog that need attention. Having the visibility that they are there is a good reminder for me to keep context.

One of my biggest weakness has always been saying yes when I'm asked for help.
I rarely say no, and as such, it seems the more I help, the more I'm asked for help.
The requests continue merely because I'm willing and I see this as a great thing.
Unfortunately, as you've stated, this also presents the seemingly unavoidable problem
of over commitment. When I over commit and spread myself too thin, those that I've already
committed to help, now feel my absence and that's not very helpful at all. I've
learned that sometimes the most helpful thing I can do is to quite simply say, "No".
But finding the balance where I can maximize my effectiveness is always present?
Thank you very much for your well written and methodical approach to this conundrum.

"If something isn't working, I will modify my behavior to see what will work. I won't accept an unhealthy habit as 'just the way things are,' but instead will plan to make a change and try something new."
A very nice personal statement to live by!

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.