Why you shouldn’t do it all

Responding to my post about startups vs. large companies, Anindita Basu asked, “I am curious why you don’t recommend stepping up and taking on as many things as we can (when in a small company).”

Not too long ago, I would have replied that it’s exactly what you should do. I would have explained that it’s important to try to do as much as possible because that’s how you establish and maintain your relevance and authority in your company.

But that’s the wrong answer. Doing that will lead to burnout, frustration, and disappointment. Let me explain…

How I used to think

This one is easy: I used to think that to be successful, I needed to take on as many roles as possible. It’s easy to start with the things closest to technical writing: editing, creating images, publishing. In my first tech writing job, we had a large tech pubs organization that included editors and a publishing team that handled graphics and publishing tasks. Because users could run our product on multiple platforms, it was decided that instead of screenshots the docs would use generic line drawings. Yes, they were simplistic, but at least they wouldn’t confuse the poor Mac users by showing them Windows-style layouts.

Even at that job, I pushed to do more than write. I was working on SQL commands, so I learned how to create railroad diagrams. Then I learned how to generate books from FrameMaker, which really means that I learned how to troubleshoot font consistency errors.

I was also really good at building an index. That’s a mostly useless skill these days, but it does help when I’m creating metadata tags.

After I went to a smaller company, I had to learn to edit my work. There was a doc manager, but he was busy writing his own docs. We did some peer reviews, but only until he was satisfied that I had learned enough. In that job, I had to write, edit, capture and edit screenshots (no time to create line drawings!), then generate PDF and online help. (Not to mention installing, configuring, and running the products that we were documenting.)

At each subsequent job, I added more tasks to that list. There are different types of documentation to write: End user help, installation guides, release notes, admin guides, API references. Technical communicators can work on other types of documentation, like technical specs, whitepapers, troubleshooting FAQs, and blog posts.

What I was missing

All of these things are “head in the weeds” activities. Doing all of this left me little or no time for larger planning tasks. I tried to do all of the strategic tasks in an afternoon. Then I realized it would take at least a day. Or two days. Or longer.

At some point I realized that poking around at some spreadsheets wasn’t enough, and I had to spend a few days in a meeting room with a rapidly-diminishing pack of whiteboard markers. I had to get away from my desk and the constant stream of just-one-more tasks, take a breath (before I opened the markers), and re-orient myself to a higher level view of my projects.

I think it was at that point where I realized I had 8 months of doc worked piled up. Selfishly, the engineering team wouldn’t agree to take a long vacation to let me catch up.

It was difficult because I enjoyed what I was doing. I loved the ability to switch between different types of documentation, and I felt needed and necessary. Giving up some of that to another writer was difficult. But it meant that I wasn’t constantly apologizing to people because I couldn’t fit one more doc into my day (and I was working pretty long hours).

To be clear: “I have a lot of documentation to write” isn’t going to convince anyone that you need to hire another writer. “I have 65 tasks that will take me 704 hours to write, and that means I’ll have the documentation ready 5 months after the project ships” is a much more convincing argument.

The problem with being a hero

Taking on every available job, and inventing new ones, is often considered heroic. But as my new boss keeps saying, “Heroic doesn’t scale.” If your company is doing well, you’ll need to have plans to handle that growth, and “I’ll take on more tasks” isn’t a viable plan.

This sounds contradictory: I’m encouraging you to take on new tasks to build your skills, but I’m also saying that it’s bad to take on too much.

Moving the needle

I’m not talking about writing more documentation, either. I’m suggesting that you expand your role, which I think it vital for a technical communicator to remain relevant. But we need to consider how this helps the companies that we work for. Maybe we’re more comfortable writing feature-based documentation, and it’s easier than writing FAQs for a customer support knowledge base. But which one is more helpful, overall?

Or as Kate Matsudaira writes:

Get clear about what moves the needle forward. Take a long, hard look at your to-do list and your big-picture goals. Some of these items are critical and must be done by you, but most likely many aren’t. Ask yourself, “How does this grow my business?” and be ruthless about cutting out anything that doesn’t fit.

What moves the needle forward for your business? Trust me, it’s not another “Click Save to save the file” topic. The user can figure that out (unless your product team has done something very, very wrong), and they can even figure out the available file export options. But file import options are often less obvious, to both the end user and to the person creating the help content.

Similarly, the answer to “What roles should I take on?” is: What can you do that really moves that needle? Will a few grammatical errors in a whitepaper do any damage to your company, or can you take the time you would have spent editing that and instead work on a troubleshooting guide for your product demo team?

Conclusion

Try new things and expand your role, but don’t try accept every possible task. I’ve learned that instead of diving into one task after another, it makes more sense to take some time to evaluate the relative value of those tasks.

Advertisements

9 thoughts on “Why you shouldn’t do it all

  1. Good advice, Neal. Thanks. Just as a company gets into trouble when it diversifies beyond its core competencies, so we become harried and unfocused when we try to take on too many roles. It’s important sometimes to step back and ask “What are my core competencies, and where do I want to go from here?” Have a strategic plan for your life and your career, and take on work that aligns with the plan. (Sometimes that’s easier said than done, I admit.)

    1. Thanks, Larry. I recommend that people take on tasks that expand their skills, but as you point out, that needs to be done strategically. Choosing random, unrelated “that sounds cool” tasks is a fine hobby, but a poor business model.

  2. That is some good advice, Neal. I recall the short moral stories that I’d read when I was a kid. Each paragraph had its own place in the story, and each story would have a conclusion.

    Based on what I’ve gleaned within the three years of my freelance writing work, I have the following points to share on top of what you’ve said:
    Generic guidelines:
    – Try to realize your core competencies.
    – Keeping busy is good; keeping too busy is just too risky.
    – Doesn’t matter if you start slow; everyone does. What matters is for how long you keep going.
    – Learn to say ‘No’, even if you know that you can do it.
    – Spare some time for yourself. In the time that you keep for yourself, try to be objective towards yourselves, play your own critic. If time still permits, meditate towards a larger objective.
    Specific guidelines:
    – Set a timetable. Assign each activity its deserved time. Take time to rest, refresh, and plan.
    – Don’t work too much today, so that you don’t have any work for tomorrow.
    – Assign time for non-work activities as well. Achieving work-life balance is important.
    – Take out some time to learn and hone your skills.

    1. Thanks, Suyog. I don’t have much experience as a freelancer, so I appreciate the perspective. Those guidelines are very sensible; it’s taken me longer than three years to stop trying to do everything, and to push for realistic schedules for the really important tasks.

      Although not having any work left for tomorrow has rarely been a problem!

  3. Suyog is absolutely right – it is vital that we learn to say no and that we allow ample time for not only the work, but reflection on it too.

    Strangely, I wrote a post on a similar theme earlier this week (http://straygoat-technicalauthor.co.uk/technical-writing-tools-need-know-every-tool/), only more focused on self-learning. I’d been experiencing the frustration and burn-out you describe, not from work itself, but from trying to learn too many new things at once. Sometimes, I get paranoid that I need to know every tool and technique for creating documentation and it just isn’t a healthy way to be.

    1. Thanks, Craig. I like your analysis of this from the tools side, and I can see why some contractors limit themselves to working with one or two tools.

      1. I’m not sure what is the right approach, to be honest. Do you become a jack of all tools and master of none, or do you specialise in one or two and hope they don’t become redundant? I lean more towards the jack of all, because you’d expect there to be some transferable knowledge/techniques.

  4. Yes, yes, yes, and yes! I have been talking about this very thing with my team the last few months. How are we adding value? I guarantee it’s not by keeping up with every bit of documentation minutiae everyone wants us to. It’s letting some of the minutiae go so you can focus on high-value items you choose to do on your team and for your customers.

    One important point to this is that managers *allow* their team members to step back from the everyday firefighting long enough to make these important assessments, and support them in pursuing high-value work that helps their careers and the overall organization.

    Of course it goes without saying that in order to support their team members in focusing on those 3-4 high value items, managers must also be able to step back and get that analysis time every now and again too.

    Great post!

    1. Thanks, Alyssa. “Don’t sweat the small stuff” has to become part of a tech communicator’s mantra in the new, agile environment. (I’ve read your articles about tech comm and agile, so I know you’re the expert on that.)

      That’s a great description of what makes a good manager. My best managers have done exactly that. I’ve also had managers who didn’t understand why I needed that time (“Why do you have to ‘plan’ documentation? Don’t you just write it?”), or who kept me buried under a never-ending list of tasks. I’ve tried to avoid doing that, but I’ll admit that I’ve had varying degrees of success. I have learned that being a good manager isn’t easy, and too few companies provide the training and mentoring required to develop those skills.

Comments are closed.