I’m a people pleaser, a helper, and a fixer. I always have been! When I was little, my dolls used to get upset with me when I played with one of them more than the others, so I made up a rotation schedule to ensure that I played with all of them equally. When my favorite teddy bear had to get a “bath” in the washing machine, I made my mom open the lid of the washer to prove to me that Stephy was simply swimming and hadn’t drowned in the water because I wanted to make sure she was okay. I was a very imaginative child with a big heart and a desire to help everyone around me.

Flash forward to present day: I’m a strong, independent, sometimes stubborn business owner who still has a hard time saying “no” to people. It’s not that I avoid confrontation… I simply love new projects, enjoy exploring new ideas, want to be as open and as welcoming and as helpful as possible, and have a difficult time balancing that with the reality of my time, energy, and budget. Sound familiar?

When I first asked DevRel professionals about the hardest parts of their job, one topic that came up often was how difficult it is to say “no” to coworkers, managers, and worst of all, our company stakeholders. So how do we get to a point where we can say no in a way that not only leaves us guilt-free but also helps others understand and accept our answer?

Define Your Goals

As I mentioned in the first post of this series, having a clearly defined team mission is the first step on this path to freedom, as each request can be evaluated against the mission and goals. When there are questions of prioritization or whether a particular goal is a good fit, it provides a “North Star” for you to refer back to. It’s also useful for your colleagues, as it helps delineate what is (and isn’t!) your responsibility.

This mentality allows you to clearly lay out your current priorities and how they relate back to the overarching company goals. You can easily identify how much time each one is taking and whether you have the time to take on another large project. If you’ve got too much on your plate, this awareness of why the current goals are important makes it easier to explain that unless this new project will have more impact on the team goals, you won’t be able to take it on at this time.

Know Your Data

Having data to back up your decisions is the second step. By knowing the “why” behind your priorities you’ll be better equipped to defend your decisions. Perhaps you’ve done research into your various developer personas and know that your core audience tends to prefer Vue over React, even thought React has been what most of your customers have gravitated to in the past. Because you’ve done your research and know that Vue is the best area for you to expand into, you’re able to turn down projects that are focused more purely on React, and you have data to prove it.

As a client of mine said recently, “We may be wrong, but at least we’re not confused!” While you hopefully won’t find yourself in a position where your data has led you astray, if you can show your work as we were required to do in middle school Geometry class, you can build a strong case for why you’re pursuing a particular audience, writing particular content, or not letting yourself getting pulled into various projects that aren’t in pursuit of a singular goal.

Document Your Role

There are times when we’re asked to contribute to projects because it can be difficult to define whether a task should fall under Marketing, Product, Engineering, or Developer Relations. However, there are other times when a project is handed down to us simply because we’re the only ones who know how to do that work.

I’ve found that many of us have an underlying fear that drives us to maintain our aura of expertise. Being the only one who knows how to do a particular task has a kind of security to it — if we’re the only expert on a particular topic, we’re indispensable! However, this mentality leads us to owning more and more projects with no true vacation or downtime in sight. 

If we instead take the time to document our roles — the day-to-day minutiae as well as the larger weekly, monthly, or annual projects that we’re responsible for, we may find ways to delegate some of that work back to the appropriate teams. Instead of providing someone with freshly fried fish, we can teach them how to fish, and use our valuable time to contribute in other, more important ways.

This documentation can also lead stakeholders to be more aware of the laundry list of things you’re responsible for. For example, rather than them only seeing the end product of a talk you gave at a conference, they’ll start to understand that you first researched various conferences, found one that might be a good fit, wrote an abstract, submitted a CFP, made it through the acceptance process, wrote the talk, booked travel, interacted with community members for 1-4 days straight, collected feedback and built important relationships, and also happened to give a presentation.

Find Your ScapeGoat

I save this option for last because frankly, it’s my least favorite and should only be used as a last resort. However, there are times when the person asking you to take on yet another project simply won’t accept that you don’t have time, that you’ve researched your priorities, or that this task doesn’t fit into your current goals. When this happens, you need a scapegoat.

Let’s be clear: I’m not suggesting you throw an innocent person under the bus. Rather, have a conversation with your manager, whose job it is to protect your time and keep you on task with the projects that you’ve jointly decided are the top priority. Make sure that they’re on board with you passing the buck off to them, and then the next time someone tries to force a project on you, let that individual know that your manager has forbidden you to take on more work.

If your manager decides that this is indeed a project you should be involved in, you can figure out as a team which of your current priorities can be dropped in order to take on this new task.

Be Your Own Advocate

These conversations aren’t easy ones to have, but they’re necessary for an industry that hasn’t quite figured out what does (and doesn’t) fall into the realm of Developer Relations. Working on being comfortable saying no to more work is an important part of self-care and preventing burnout. As always, if you’re interested in chatting more about how to set priorities as a Developer Relations professional or how to set your team up for success, my door is open! I’m passionate about encouraging teams to balance their desire to help people with their need for self-care.