Over the years I’ve had some conversations with people in my teams about them feeling bored with their tasks.
In my early days as a manager my natural reaction was something along the lines of “that’s why it’s called a job, not the fun-hobby-zone”, sometimes just in my head, sometimes spoken out loud.
Fun fact: this does not help.
First, as a manager you should always be happy when one of the people you are responsible for approaches you. They are the few that speak their minds, while many others don’t and will potentially vote with their feet and quit the company.
Ever heard someone say in a job interview “I left my previous company in order to learn new things/become more experienced/felt stuck and wanted to progress”? Yeah, that’s boredom their former managers ignored.
That’s why I’m always glad when people approach me with any of their problems and I always take them seriously.
Second, empathy.
Let’s be honest, we’ve all been there. Everybody has had to work on things they found boring. It’s a real thing. The subsequent content is based on what I found useful for myself first.
When someone tells me they feel bored I reply in 2 ways:
1 – Intrinsic View – Set yourself a challenge
- It’s in your head
No task is boring per se. “Boring” is just your own interpretation of a task that should best be called “repetitive“.
Look at it this way: It probably wasn’t boring to you when you did it for the 1st time. - Automate it
If it’s a repetitive task that you understand well, how could you automate it?
For instance, if you have to copy data from one place to the other, then how about writing a script?
Many great inventions were driven by boredom or laziness.
Check out “jobs-to-be-done” for example. Everything that feels annoying to a large enough number of people is a hidden business opportunity that’s waiting to be picked up. - Vary
I’ve programmed a ton of pretty common functionalities in my days like login forms, registration forms, deployment scripts etc. How about trying something new while you do it, leveraging your experience?
Maybe try to validate the data with a different and more elegant approach, avoid conditions and favor stateless functions? Get to 100% code coverage this time, try data driven or mutation testing? Try a different set of libraries or framework? Increase security, e.g. using a Captcha, honey pots, or try to hack yourself with a fuzzy logic attack script?
#TimTowtdi (There is more than one way to do it) - Abstract it & teach it
Everyone who is an expert in anything was at a crucial point in their career: “OK, I understand it now. I could move on to the next thing – or I could dive deeper into it, abstract it, teach it to others”. See also the “Feynman Technique“.
Repetition is a core element of becoming an expert. - Improve it
If you’re really familiar with a task because you’ve done it a bunch of times, then you could think about how its execution can be improved so everyone benefits from it.
Your experience is a chance to make a difference. - Delegate it
Last but not least: repetitive tasks are good candidates for things you can delegate to more Junior staffers. This implies that you have to explain the task to that person, see “Abstract it & teach it”.
2 – Mix it up
Common sense tells us that having the same people do the same things for as long as possible should yield efficient results. We can assume that they have become true experts by now.
In my experience this has proven to be a fallacy in many cases:
- If people do the same things over and over again they do not necessarily get to the point of “Vary” and “Improve it”. I’ve seen teams being stuck with tools and practices like ant scripts and Subversion while the world has moved on to Ansible, Docker and git.
This is partly the reason why people go from bored to fearful about their careers when they feel that they might not be up-to-date with the job market’s demands and then, eventually, quit. - Even worse, work might be so “optimized” that it’s very hard to change anything later on. And there will always be the need for change some time.
A process designed for maximum efficiency is a common antipode of agility. - Assuming a “steady-state universe” is dangerous because there will always be fluctuation in your teams to some degree, be it attrition, parental leaves, promotions, sabbaticals, retirement – you name it.
You should have a plan for how to retain knowledge when people leave and how to onboard new people.
That’s why I recommend mixing up teams every once in a while so people get to know other tasks as well – and to ensure back-pressure against a “steady-state universe” attitude.
From a business perspective, if you do it to early then the invest of time for onboarding might not have paid off yet. If you do it too late then people might leave or work might have become “rusty”, see above. Find the sweet spot.
From a people management perspective, some people are bored faster that others. Get to know everyone well enough to know their personality and ambitions so you can identify when it’s time to shake assignments up.
Agree?
Leave your comment, like and share.