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?
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.