The art, and the power, of saying no

Recently, I needed to let a product team know that our tech writing team couldn’t take on the task of creating a particular doc. The doc was outside our normal area of responsibility, but one where we could certainly have added value. The problem was, we just didn’t have bandwidth. My manager showed me a published procedure which outlines our priorities. It was very useful to be able to refer the product team to the procedure, and to have at my disposal those words in the procedure which had been so carefully written for just this sort of situation. I was also able to offer the product manager our help in reviewing the doc once the engineering and product teams had created it.

This experience led me to think about the art, and the power, of saying no.

Saying no feels bad. You’re letting the side down. You and your team are underachieving.

Not so. I’ve come to the realisation that saying no is a good thing, provided it’s done under the right circumstances and in the right way. It’s good not only for you, but also for the people you say no to, for your manager, and for your team members. Even more, it’s good for the organisation as a whole.

How so?

When an organisation has had the luxury of a tech writer or two for a while, people start appreciating the skills we offer. They start asking us to create documents that are urgent, high profile, sales critical, and more, but that are sometimes outside our scope.

It’s fine to help out if the tech writing team has time. But often the team is fully taken up in other work that’s of equally high priority, and which is part of our primary responsibility. In such cases, it does the team and the organisation a disservice to say yes. Writers will end up working overtime, or the  docs under our primary care will suffer.

If we say no, people in the organisation may realise they need to hire more tech writers. In many cases they already know they need more writers, and our saying no can give them the data they need for their hiring requests.


If time allows, it’s good to be able to offer a little more than just a “no”. Here are a few ideas. Some of them involve preparation ahead of time, under the assumption that you’ll have to say no at some time:

  • Write up your team’s policy and responsibilities clearly, so you have somewhere to direct people to when they ask the impossible. Don’t be afraid to adjust the policy doc as time goes on, and as your team changes or you discover more situations which you can or cannot support. The team’s policy is not set in stone. It changes with your team, your stakeholders’ teams, and the organisation as a whole.
  • If you have a helpful suggestion or recommendation, include it when you say no. For example, point people to templates and style guides that will help them write the doc themselves. Look for existing documentation that may be similar to what they want.
  • If you have the bandwidth, offer to review the final draft after another team has created it and pushed it through initial review.
  • Encourage the product and engineering teams to contribute to the docs on an ongoing basis, so that they’ll feel able to write their own doc in this sort of situation. Create a quick-start guide to your doc tools and review procedures, and point them to that guide. On the topic of writing such a guide, you may find this post useful: the importance of audience.

Have you found yourself in a position where you’ve had to say no, even though you know that you and your team would add value to a task if you had bandwidth? I’d love to hear any tips you have on how to handle this sort of situation, and what you’ve learned from saying no.

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 14 March 2018, in technical writing and tagged , , , , . Bookmark the permalink. 8 Comments.

  1. My case is a little different than this because I’m a one-man company. But when an author asks for my help, sometimes I just have to say no because it’s not a good fit for my skills and/or interests. But as a novelist, I know very well what a rejection letter feels like.

    I’d been back in North Carolina for two years before I realized that I had no customers in North Carolina. So, I started in-person networking. That solved the problem, but even more importantly, now I know some good people who would love those jobs I’m rejecting, so I can replace “no” with “not me, but ____” and feel a whole lot better about it.

    Time and resources you invest in something you should’ve rejected are time and resources you can’t invest in what you should be doing instead.

    • Hallo Michael

      Thanks, that’s a very interesting perspective. I love the idea of sending the job on to another person who could do with the work.

      You put it very neatly:
      “Time and resources you invest in something you should’ve rejected are time and resources you can’t invest in what you should be doing instead.”


  2. I die a little bit inside any time a tech writer refers to the product team or development team as a separate entity from the doc team. No matter how many tech writers work for a company, and how much coordination is needed to standardize output and style across products, a tech writer ideally considers themselves a member of the product or development team first. They are the members of the product or development team that design and develop the information piece of the product.

    • Hallo Janice
      You’re right, we are members of the product or development team. We’re a part of the team with a particular speciality, as are the other teams within the team.

  3. I find that saying “yes” as often as you can makes it much easier to say “no” when you have to. I make a point of being willing to help promptly with small tasks (“help me wrangle Word” for example), so that people are more understanding when I have to turn down a big task.

    • Hallo Julia
      Thanks! That’s a great point. Also, your comment made me think, apart from saying yes whenever we can, a smile or a pleasant attitude when we say no is also important. So people know we respect and appreciate their request.

  4. As food for thought on the topic in general, consider Caroline Webb’s How to Have a Good Day. Also Tim Ferriss’ Tribe of Mentors

  5. Reblogged this on Activevoicer and commented:
    Doc teams can create boundaries and still be collaborative. Learn how to say “no” to work requests with this sage advice from Sarah Maddox.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: