How to Avoid Drowning In Grunt Work Daily And Balance It With Growth Work

By Poornima Vijayashanker

I hate grunt work.

You know the work that you have to get done but it’s rote, so you’re not learning anything new or advancing yourself. Doing it feels like a waste of your time and energy.

You wish you could sweep it under a run or pawn it off on someone else, but it needs to get done and you’re the one assigned to do it!

How do you handle it and avoid having it become the only work you do?

Well one reader recently wrote in and asked me this question, Dali wrote:

Hi Poornima,

I noticed that you take the time to respond to questions from your readers. I’d like to share a problem I’ve been experiencing for the past 6 months, and hope you can shed some light into how I can handle it.

9 months ago, one of our senior developers quit. As a result, my manager re-assigned a bulk of the work to another developer and me.

At first, I didn’t mind getting assigned additional work, because it gave me a chance to learn a new part of the code base, and to interact directly with the designer on our team.

I noticed after the first 3 months, my manager stopped assigning new work and has just been focused on fixing bugs.

I don’t mind fixing bugs and understand they are a necessary part of my job. About a month in, the other developer and I noticed that many of the bugs were coming from the APIs that had been created for our web app to send data to our mobile app.

Since we weren’t getting assigned new features, we thought it would be prudent to revisit the APIs. We noticed that much of the code hadn’t been tested.

We don’t do test driven development and decided this would be a good time to learn a best practice and create a test suite.

We knew that creating a full test suite would take too much time, and if we got pulled into another project we’d be stuck. Hence we decided to just focus on the APIs and figured we could do it one API at a time.

We approached our manager and shared our plan. Our manager was really resistant to our idea, said there wasn’t enough time or resources to get this done, and told us to get back to fixing bugs.

That was 6 months ago.

I’ve been fixing bugs ever since, and I don’t know how much longer I can just keep fixing bugs.

I’ve asked if new projects will be coming in, and have asked about carving out time to create the test suite. My manager told the other developer and me that we need to improve the quality of the code and that means fixing bugs. However, what my manager doesn’t get is that we aren’t improving code quality. We’re just adding more bugs!

I feel like my days are filled with grunt work, it’s really demotivating.

The other developer told me that they’re tired, and it feels like they’re drowning in grunt work. They’ve started talking to recruiters at other companies because they’re fed up. They’ve been here for 3 years, so it makes sense, but I started less than a year ago. I don’t want it to look bad on my resume, and I’m hoping I can turn things around, just not sure how.

What would you recommend I do?

Thanks for taking the time to respond!

-Dali

Balancing different types of work.

I’d be lying if I said there were jobs out there that had no grunt work. Every job has some amount of it. There can also be periods where there is more of it than other times. There are ways to deal with it, and I explore a number of them in this post.

And grunt work can be great for building up new skills and knowledge. For example, Dali mentioned how fixing bugs, in the beginning was good because it taught Dali about new parts of the code base.

Other times, it can be the work that needs to get done to keep the business functioning, like responding to customer support issues to keep customers happy, and sitting through sales calls to attract new customers.

But to stay motivated, and continue to grow in your job, you’ve got to balance out the grunt work with work that helps you learn new skills. This could be taking a course, working on a side project, attending a conference to meet new people and learn best practices from them, or speaking, writing, or teaching to deepen your own understanding of a particular subject.

Carving out time for growth work.

To balance grunt work with work that I like to call growth work, you can do a few things:

• Defer the grunt work for some time. If it’s not time critical, then it’s OK to put the grunt work aside for a few hours, days, or even weeks. When you come back refreshed, it doesn’t feel as bad, and you might even get it done faster if you’ve learned of a way to automate it, which leads me to the next point.
• Automate the grunt work. If there’s a tool you can invest in that costs less than your time to do the task, then buy it! I’m a big fan of buying versus building it myself if I know it’s going to take me too long to build it, and it’s not in my wheelhouse.
• Figure out what is causing the grunt work and fix it! It was great that Dali took the time to notice that the majority of the bugs were coming from the APIs between the web app and mobile app, then recommending they put in a test suite to avoid additional bugs.

Continuing to do the grunt work will lead to burnout, and leaves us feeling like we’re not learning anything new and just being pigeon-holed. These are two of the leading causes of employee turnover, which we see here since Dali’s teammate is talking to recruiters and exploring other companies.

Getting buy-in for growth work.

It’s great to hear Dali and Dali’s teammate came up with a plan to put a test suite in over time rather than all at once and then approached their manager about it.

It’s easy to jump to conclusions and think that their manager doesn’t care about their careers. The manager might also have felt ganged up on by Dali and Dali’s teammate.

Without a deeper understanding of where the manager is coming from, it’s not a good idea to assign intent. So I’d recommend giving their manager the benefit of the doubt by taking the time to have one to two additional conversations. In the first conversation, Dali should ask the manager the following questions:

• Do they understand they impact this project will have? Often when people don’t understand the impact, they are quick to say no. This should also include the cost of inaction, in this case, more bugs! It also helps to tie it to a company or team goal. For example, if quality is important or cutting down customer support issues, it helps to align the project with those goals.
• Why are they opposed to this project? Is it because of time, resources, or are they having trouble getting buy-in from others like their bosses or other stakeholders?
• Are they concerned about how risky this project is? Perhaps the manager feels like working on this project will be all-consuming, even though Dali said it won’t be, and will derail other critical issues later on. Or they think it will contribute even more bugs to the code base.
• Have they done similar projects and faced major issues? Maybe the manager has gone through a similar project, and it didn’t end well. Might have even made them look bad… So instead of taking the time to explain that to Dali and Dali’s teammate their manager just dismissed it.

Hopefully, in asking these questions Dali and Dali’s teammate will get a better understanding of their manager’s decision, the objections to it, and be able to address them.

Dali and Dali’s teammate, also need to be candid, and explain that they understand grunt work is part of any job, but continuing to do just bug fixes is demotivating. One way for them to stay motivated and turn the grunt work into growth work would be to create this test suite over time. It will give them an opportunity to learn something new, and get the grunt work done.

If their manager is still resistant to their proposal, then there’s no harm in exploring other opportunities. They may not be in a culture that empowers them to grow.

Finally, I know Dali is concerned about leaving a position in less than a year, but what will be worse is if Dali stops learning altogether. It’s not only de-motivating, but it can lead us to question ourselves and our abilities.

Have you been in a situation similar? Help Dali out by recommending what you did. Please leave a comment to let us know!