There’s nothing wrong with saying no.

During my career as a software developer I’ve spent what feels like an inordinate amount of time saying no. During the early stages I was reluctant to do this, fearing that it would make me seem difficult, not a team player, unambitious etc, but after a while I realised that the negative effects of saying no far outweigh the negative effects of saying yes when you really shouldn’t. “You’re really good at saying no” is a judgey, sort of compliment that many of my colleagues have paid me over the years, usually with a soupçon of envy.

Before saying yes to something outside of your remit, find out why you’ve been chosen for this honour. It’s usually a variant of one of the following:

  • We don’t want to disturb anybody else
    This is probably my least favourite reason for being asked. The message behind this is that everyone else is doing important work that can’t be interrupted, whereas what you are doing can easily be put off or not done at all. This doesn’t mean your work doesn’t need doing, just that it doesn’t affect the person asking if it is done or not.
  • Nobody else is available
    Aka we didn’t think this would happen so quickly, or at all, and we’ve planned things so tightly that there is no scope to move things around. Like the previous point, the person doing the asking typically has no skin in the game around your work, so you are seen as a sweeper that can pick up the overspill.
  • You are the only one that knows how to …
    Usually the hardest to say no to, but it’s still possible. If you’ve offered in the past to upskill someone else to avoid being single point of failure, and this has been rebuffed (because we don’t want to disturb anyone, everyone else is too busy etc) then you are under no obligation to drop everything due to your unique knowledge that you already tried to share.
  • You did it last time
    You did us a favour at short notice, so you’ve been identified as someone who will bail us out whenever we encounter difficulty. Often the requests will increase in frequency — you fixed a couple of bugs for us last week, here’s another five you can fix for us this week. No good deed goes unpunished.
  • It will only take you a few minutes
    In which case it will only take the people who are actually paid to do it a few minutes. This is often a short cut to We don’t want to disturb anybody else and typically isn’t true. It’s minimising in the hope that you won’t find out what is actually involved until you have agreed to it and thus feel duty bound to finish it.
    When you are told this make sure to question the full extent — is this really everything that needs to be done? Typically you’ll find that there are a bunch of follow-on tasks that you are implicitly agreeing to pick up.

Before agreeing, ask yourself the following questions:

  • Are you the best person to do this?
    If not, why isn’t the best person being asked ? Don’t be surprised to find that you aren’t the first choice and that others have been able to decline.
  • Will it impact your existing deadlines?
    If so, are you happy to make up your work evenings and weekends? Typically this means you’ll be saying no to your family and friends in order to say yes to your co-workers — are you okay with that?
    Make sure that your existing line/project management knows what you are being asked to do and the impact — you won’t be popular if you screw your project up quietly saving someone else’s.
  • Can you do it?
    Make sure that you are actually capable of doing the work — what you don’t want is to be on the receiving end of a dressing down because you assumed you could learn while fighting someone else’s fire. The impact of this on your morale should not be underestimated — while you might be expecting an ego-boost of saving the day, you might end up being blamed for the failure.
  • Will it be repaid?
    If you are prepared to take the hit for someone, are you confident that they will return the favour, or is this seen as a one-way street where they can call on you but are too busy/important/special to help you with anything.

There’s nothing wrong with saying no. Just because somebody else is encountering problems, it doesn’t mean that you have to put everything else to one side to fix them. This is especially true if you are being asked to help without going through the chain of command — that often means that an attempt is being made to cover up problems with your time.

As you progress in your career, you’ll take on a lot of additional responsibility but you’ll also be carrying a lot of baggage. If you stay with a company for any length of time you’ll understand an awful lot about what has been done in the past — how systems work, why they work that way, how similar problems were solved in the past. Because of this, you’ll be the target of an awful lot of requests, because it will be an easy way for someone else to get something done. For them. Not for you, as you’ll be trying to do your current job while dealing with constant distraction.

If you are busy when asked if you have time to help out, then say so. Being too helpful all the time not only threatens your deadlines, but it can make your co-workers dependent on you. When you do decide you have time to help, ask what they’ve done to try to solve the problem themselves. If the answer is nothing, expect plenty more distraction from them.

This is the point at which you really have to question if it really requires you skill set. If you neglect the CTO work that you should be doing to pick up some junior developer tasks to make someone else’s life easier, is that really what is best for the company? No, it’s not.

The good news is that as you become more senior, no will be accepted more easily. The bad news is you’ll be saying it more often and feeling guilty about it.

You shouldn’t take from the above that you should be relentlessly negative, saying no to everyone all the time. This isn’t about becoming a refusenik who your co-workers are scared to approach, it’s about making informed decisions rather than blindly saying yes to everything you are asked to do. It’s also about making sure the effects of you saying yes are understood – typically that something else isn’t getting done.

There will be times when you’ll say yes even when according to all logic you should say no — in my case if something sounds interesting I’ll get drawn into it even though I really don’t have time to get involved. There will also be times when you aren’t the best person to take something on, but you are the one prepared to work the weekend, be on call or go and have that awkward meeting with the customer. As long as this is being recognised then going the extra mile can be great way to speed up career progression.

I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom who are hiring.

You can find my (usually) more technical thoughts at the Bob Buzzard Blog

CTO at BrightGen, author Visualforce Development Cookbook, multi Salesforce Developer MVP. Salesforce Certified Technical Architect. I am the one who codes.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store