As a developer, something that always frustrated me was the fact that my managers didn’t seem to realize the disruption they caused. I would be working on a ticket, and someone would switch me to something else on short notice.
Here we go again. Stash my work. Create new branch. Understand what has to be done. Do it all over again once this one is done. Get asked why the ticket I had to drop isn’t finished yet. Well, because you gave me a different task, that’s why!
So when I started managing people, I’d tell them to let me know if there was any problem, and to raise their concerns early if something wasn’t going to be finished on time.
Time after time, I would be disappointed to hear that someone was delayed on a critical task because they were assigned a second task and dropped the first one.
Why didn’t you tell me?
Oh, I thought you knew!
Ah. The mythical mind reading manager. If you never lead a team, you probably assume information always gets to your manager first, including information about how you will proceed if given an ambiguous instruction like “hey, please fix this ticket” without any other specifications on when it is due, what the priority is, and if you should drop your tasks or not to attend to it.
You may think they know that when they tell you that, you will drop everything and do it.
Unfortunately, very often, they don’t. This is especially true of newbie managers. Maybe because they assume there is enough trust that you would simply push back if you had a problem. Maybe because a PM or other member of the team sent you a ticket and told you to work on it without your manager being made aware. Maybe because they think you will work on it as soon as possible and nothing bad will happen.
They should know better. We should know better. But sometimes, we don’t.
I could write a blog for managers (and I might) about being specific when it comes to assigning work and what our expectations are… but I decided to write it for engineers because nobody ever tells us what we can do to make up for mistakes our managers make, or how to push them to improve, or even how we as developers can be better at asking the right questions to help us be more productive and less overwhelmed all the time.
So. The next time you get a ticket assigned that would interfere with your work in progress, go ahead and ask
“Should I stop working on #this and get started on #newThing right away, or should I finish #this first?”
or
“If I drop #this, we may not make it to #that deadline, since I have to context switch 3x to work on #newThing and it takes some effort, is that okay with you?” …
…or any other question that helps you figure out the best path forward.
It may feel weird, but communicating your constraints is a good thing. Your manager may not have realized the problem that a new task would cause. Thanks to you, they may find a problem they had missed before around workflows, or they will learn how to plan better.
They may tell you that YES, you need to drop your task. Or they may reconsider and reprioritize. But at least you will know, and they wont be able to ask you “why isn’t this other task done” 1 hour after they told you to context switch 😉
They may even learn a thing or two about remote communications. As you do this, you may want to bring it up on a 1:1, and explain how you managed to stop context switching, or why context switching is problematic if it happens too often. I would expect any engineering manager to know this, but if they have forgotten how bad it can get… at least this will remind them to be careful when they assign work.
On your end, by asking this questions you will know for sure when your task is urgent enough to drop everything and when it is only urgent because someone higher up the chain wants it ASAP. This is important, because it lets you make better decisions, too.
Being the person who knows how to dig up important signal even in casual communications is a skill that will be incredibly useful as you progress in your career. You will understand how work flows from X to Y a lot better, and you will learn how to ask better, more insightful questions that help your team make better choices and be more productive.
Let me know if you have had this problem, and how you approached it. I’d love to hear from you.
This post is part of my series for remote software developers. You can check it out and subscribe here https://rowasc.com/engineers-working-remotely/
Top comments (0)