Photo by Peter Heeling on Skitterphoto
Repeat something often enough and it will likely lose its luster, even a favorite thing.
One of my favorite things is tech writing. I’ve done it every workday for a long time now and, at the risk of sounding repetitive, I still love it.
What’s my secret? How the heck do I spend over 20 years doing this job and still look forward to going to work every day?
Good questions.
My answer so far is a secret sauce of job satisfaction with three key ingredients:
- Creativity: Technical writing is deeply creative work. Every new project is like a moment asking to be captured and shared with others. Instead of a brush or a camera, tech writers use technology and language. Instead of a painting or a photo, we create useful information. Our subject is the torrents of information that surge through every project and organization. My inspiration is empathy for my users and the challenges they face.
- Variety: I’ve been blessed with an ever-changing, info-omnivore’s smorgasbord of work. There’s always a new technology, a new audience, or a new responsibility to keep things interesting.
- Curiosity: After 20 years, I don’t know everything about tech writing. Not even close. This perpetual gap triggers my curiosity. What can I learn to make my work better? Is there domain knowledge that can make my content more effective for my users? Is there a technology that can make my process more efficient?
Ingredient #1 (Creativity) is a personal philosophy. Your mileage may vary.
Ingredient #2 (Variety) is just dumb luck.
I want to focus on Ingredient #3 (Curiosity). The urge to learn something new is powerful. An e-learning market valued in the hundreds of billions of dollars proves that.
But if you work for a functional organization with a functional doc team, you probably don’t have a lot of extra schedule and budget to learn stuff. Everyone can learn something new, but not everyone has a lot of time for professional growth.
I sneak learning and professional growth into my busy schedule with with personalized work projects.
Personal vs. Personalized Project
- A personal project is work that interests you but would be difficult or impossible to justify to a manager.
- A personalized project interests you and is either work already scheduled or is justifiable to a manager.
Both project types can involve learning skills and gaining experience for your job. The important difference is that a personal project does not benefit your employer or your users while a personalized project does. A personal project is purely selfish: you’re helping yourself. A personalized project is partly selfish, but your users benefit in the end.
For example, you’ve heard a lot about static site generators (SSGs) and you want to learn how to set up and maintain one.
In a personalized project, the SSG will replace your company’s hand-tooled internal API doc. The predicted benefits could include:
- Lower overhead for site maintenance (more time for writers to write)
- Improved user acceptance with fewer bounces and better conversion, leading to better informed, more effective developers
- Relevant metrics and user feedback with standard plug-ins to feed a virtuous circle of continuous improvement
- Possible follow-on application for external documentation distribution, with subsequent customer satisfaction benefits like self-service support-ticket deflection, reduced churn, and lowered customer acquisition cost
With all these upsides, you can craft a compelling argument to your doc manager for time, to the support team for their advice and guidance, and to IT for a virtual server as a sandbox for a safe place to learn and experiment.
On the other hand, you could develop an SSG as a personal project to drive your ethnic cooking blog. Good luck getting any resources from your manager and coworkers.
Discovery
How do I find work to personalize?
There’s no mystique about it. The muse of technical writing doesn’t exist. Instead of waiting on fickle, unreliable inspiration, I rely on processes:
- Groom the doc-team backlog. I often find important and interesting work that’s been buried in the churn of releases and priorities.
- Comb through other teams’ backlogs. The review reinforces my perspective on what other teams are working on and can yield interesting documentation projects. Be careful that you don’t step on anyone’s toes though. Folks can get understandably territorial about their work. Don’t let your enthusiasm override basic courtesy and respect.
- Talk to everyone. Ask open questions like “What do you think would help the most?” If your company lacks formal relationships between the writers and other teams like support, account management, and sales, this is the opportunity to establish them. I guarantee that your queries will yield gobs of interesting work to benefit your users. My only caveat is that you set expectations clearly. You’re asking for perspectives and advice, not directly soliciting for extra work. I’ve had folks assume that their offhand suggestion would be delivered in the next release.
- Go to meetups and conferences. Look for titles and topics that sparkle for you. Conferences in particular can be expensive in both time and money, but you’ll meet droves of enthusiastic, curious, experienced people with loads of experience and questions to inspire you.
- Dive into social media. Keep an eye out for fellow writers and doc advocates. Follow them. Don’t just follow tastemakers, thought leaders, and luminaries. High-profile personalities can attract a lot of noise. Sometimes the most inspirational and practical posts come from your peers.
- Check out industry websites like TechWhirl, natural aggregation points of interesting work, fascinating topics, and awesome people.
Benefits
The ultimate benefits of a personalized project are the same as any doc project: happy, informed, and successful users with effects that can be measured in balance-sheet metrics like better customer retention and reduced support tickets.
The benefits to your writers are less visible and measurable, but they are still very real and very valuable:
- Provide the writers some control and agency. This is a big one in a profession that still struggles to maintain status and legitimacy in tech. Writers can be lost in the shadows cast by the blinding glow of tech-wizard engineers and are often abused by development schedules. To quote a Director of Engineering I worked for, “We will never delay a release because of a doc issue.” A personalized project can give writers a real sense of ownership and influence over their work in a harsh environment.
- Avoid burn-out. Personalized projects encourage fresh perspectives and variety (job satisfaction ingredient #2) so you don’t have to rely on luck to stay out of a rut.
- Discover solutions. Time spent on personalized projects is a resource invested in research and development. There are no guarantees, but you’re likely to develop solutions not only to current issues but to issues you don’t even know you have.
- Keep your team engaged. I want curious and passionate writers on my team. If you don’t allow these talented people to do cool things and give them room to stretch and grow, they’ll look elsewhere for the opportunity.
As I mentioned in a previous column, every day of my career as a users’ advocate hasn’t been a picnic, but looking back over the last 20 years gets me excited about my next 20. I hope my experience can help you in your next 20.
