How do I get better at saying no to new project requests when I have too much work on my plate, without sacrificing my relationships with my team?
Having the autonomy to choose what you work on is a wonderful privilege. But it can be a curse. When there is no one to tell you what to work on, there’s also no one to tell you what not to work on this. Because of this, many researchers find themselves working on far too many projects at once.
If you ask a group of researchers the biggest point of feedback from their most recent review cycle, chances are at least one of them (if not all of them) have this underlined in their growth plan: “Work on saying no.”
But saying no can be really, really challenging. First off, it requires some amount of confrontation. Just saying the word ‘no’ out loud can be uncomfortable. And what’s worse, saying no can put your position of trusted adviser to your team at risk. You’re supposed to be a team player! Saying ‘yes’ is the fastest way to building more trust, right?
No. (See, I just did it!) Taking on too much work will degrade trust in the long run. It’s far better to do a few projects well than it is to do a lot of projects poorly. Many stakeholders won’t recognize this in the moment. They’ll truly believe that what they want right now, in this moment is for you to take on this new request, darn the consequences! But with a little perspective, they’ll realize that the thing they want right now isn’t as important as other value you could be delivering for them.
So what do you do when you have to say ‘no’ but you aren’t sure how? Try the Four D’s:
The first tactic in my book is simply to ask, “How soon do we need this.” To be fair, a lot of stakeholders will respond with “ASAP”, no matter how urgent the request actually is. So I get more pointed. “How soon will a decision be made that this data could impact?” or, even more of a mouthful, “What is the latest point at which this data could be delivered and still influence the decision?” In the vast majority of cases, this work isn’t needed right now. And you can easily delay the request by weeks. But you’ll never know unless you ask. Once you know the timeline, add these future studies to the top of your backlog and return to them once you finish your current work load. Who knows? You may be surprised to find these ‘urgent’ requests simply disappear once a little time passes.
As a general rule, I try to have no more than one big project and two smaller projects running at any given time. What ‘big’ and ‘small’ means depends on the person but over time I’ve worked out a rough intuition for what works for me. When a new request comes in, I check my current work-load to see if I have room for that size of project. If not, I try to think of a minimum viable version of that project that could help my team move forward. For instance, maybe I can decrease scope by running the study in only one region. Or, in extremely urgent cases, use employees at the company instead of outside participants. Depending on the importance of the decision being made, and how much we know already on the topic, there are a number of trade-offs that can be made with project scope.
Are you the only person who can run this study? If no, ask for help. That’s it. This is an incredibly useful option that frequently goes un-used by researchers who think they have to do everything on their own. There may be others at your company who can do this work faster and equally as effectively as you. Better yet, someone may already be working on a similar study. It’s better for you, your team, and your company if you can combine efforts with that researcher to kill two birds with one stone.
Make a Deal
Have a project that absolutely can’t be delayed, down-scoped, or delegated? It’s time to get down and dirty and make a deal. Lay out the options for your stakeholder, just like you would in any other negotiation. I always keep a backlog handy that describes what projects I am working on, their relative scope, and the value they will bring to the table. Whenever I get a new request, I compare it against the other work I could be doing. I involve my stakeholders early and often in this process to show them the “cost” (even if it’s just opportunity cost) of the work they are asking for. Then I ask them if the project they are asking for is more or less valuable than the other work I could be doing. Not only does this help push back on low-value requests, it also helps my teammates develop an intuition for how much their requests costs, and creates an appreciation for how much other work/value I am currently delivering. It’s a win, win, win!
If you’ve ever struggled with prioritization before, you might notice two d-phrases conspicuously missing from this list.
Just do it – Suck it up. Take on the extra project. Work a few late nights and weekends. It’s just this one project, right? And the next one. Oh, and the one after that. And, look, I’ll be honest with you. I “just do it” all the time. I’m doing it right now, in fact. But it sucks. And you don’t do your best work that way. And it’s the quickest way to burn yourself into the ground. So don’t just do it.
The other missing d-word?
Drop the ball – This happens when you take on too many tasks and end up missing a deadline or failing to deliver altogether. It’s what happens when you overcommit and under communicate what’s going on to your stakeholders. And it’s a lot worse than just saying a big, fat, outright “no.”
So the next time you start to just do it, or risk dropping the ball, stop and ask yourself, is there a better way? How could I delay, down-scope, delegate, or make a deal to ensure I’m doing the best possible and sustainable work? Have any other clever ways of saying no? Let me know @tiny_data_tech or tell me in the comments below.
Shout out to Betsy Anderson who worked with me on an earlier version of the Four D’s.
Genevieve Conley Gambill is a strategic adviser and UX researcher with ten years of experience in entertainment and technology. Her blog, tiny-data.tech, is dedicated to doing good with data and making tech a better place for all.