It’s never fun watching a technical documentation, training development, or other writing projects get off to a false start or just downright fail. It can be a real morale blow and expose the writer(s) and their team to criticism from stakeholders. However, failures do happen, and it is best to do what you can to recover from quickly.
Writing projects can fail or stall for a myriad of reasons including poor planning, course changes in the project plan, and other risks that may or not be accounted for in the overall project plan.
Here are five ways to get past a failed or stalled writing project:
With each new technical writing contract over the past few years, I seem to add a new non-disclosure agreement to my NDA folder.
While not every technical writer can work on articles and documents that are in the public domain, but there are things that you can do to make sure you have work samples to show potential employers including:
1. Do volunteer work
Look to volunteer work as a potential source for work samples you can show potential employers and clients. The opportunity might be right in front of you, or you might have to target a volunteer opportunity where your skills are needed, and you can add to your body of work. For example, I once taught a job hunting with social media seminar for my old church. I uploaded the PowerPoint slide deck to SlideShare so it can serve as a work sample for me.
2. Seek compromises with an NDA
If your employer or client is halfway reasonable, have a conversation with them about using the work you perform for them as work samples. It might even come down to an agreement on using selected parts of a document or redacting out portions of an overall document to shield any proprietary content that doesn’t need to get into the hands of their competitors. Seeking work out for use as samples later can be a touchy subject in organizations so you should always approach it carefully even with managers and clients you trust.
3. Never let work samples leave your sight
Before I began writing for publications and websites in the public domain, I was taught never to let my writing samples leave my sight during interviews and still believe in that rule.
4. Treat your personal projects like a professional
Medium, LinkedIn Publishing Platform, and WordPress are great equalizers when it comes to publishing and putting yourself online. One way to get past the work samples dilemma is to treat any work you put online as your absolute best and most professional work even it is a personal site.
5. Wait for the work to age
Not every document or work project stands the test of time, but I am a big advocate of saving everything because some work especially writing projects can still serve as a sample for you at a later date.
My name is Will Kelly. I’m a technical writer and content creator living and working in the Washington, DC area. By day, I work in the solutions group of a major federal IT services firm developing thought leadership content. My articles about enterprise mobility, BYOD, and other iT topics have been published by Tom’s IT Pro, TechBeacon (An HPE initiative), Federal Computer Week, and others. Follow me on Twitter:@willkelly.
Progressively, over my writing career, I’ve come to rely on checklists and templates as part of my writing and editing workflow. These days, I’m primarily a solo writer, so templates, boilerplates, and checklists help me remain on task and productive when I’m writing.
Here are ten ways to template that s**t out of your writing life:
1. Use TextExpander
While a regular freelance contributor to CNET TechRepublic, I used to get an inordinate amount of PR pitches. Eight of ten of those pitches were usually off-target. Over time, I also noticed I was using the same responses multiple times for other emails. I added TextExpander (iOS/Mac) to my workflow and saw it save me time and frustration when I chose to reply to PR pitches. Gradually, I started using TextExpander for other repetitive email responses.
2. Use writing and editing checklists
To avoid the image of client editorial standards dancing in my head, I use writing and editing checklists when writing articles, blog posts, and other content.
I took some inspiration from Michael Hyatt’s blog post template and created a writing and editing checklist template that I customize to client standards as needed.
Over time, I’ve setup checklist templates for Todoist, Asana, Nozbe, and Omnifocus.
3. Use document templates
I got my start working as a technical writer developing user guides, operations guides, online help, and the like where I learned the value of well-crafted document templates. Often, I had to fix Microsoft Office, template, and style issues for clients.
Even today, I set up templates specific to client projects. It saves me time and lets me focus on the writing part.
4. Create a workflow for deal scoping
The latest area where I’m trying to apply templates and checklists is to manage the scoping of freelance projects. It’s a move I hope to make fully happen in 2016. The boilerplate I envision has a standard set of questions and qualifiers that I can use when considering a new project.
5. Create templates for your collaboration platform
I do a lot of work with collaboration platforms as part of my corporate client work. Whether it’s SharePoint/Office 365 or Atlassian Confluence, there are ways to create templates for your standard pages given you have the right privileges.
For example, in Atlassian Confluence, you can create templates with macros without having any programming skills. In my experience, templates are an underutilized and underappreciated feature in Confluence.
When it comes to SharePoint templates, you are entering power user territory but creating and using site templates is getting easier with each new version. Hopefully, SharePoint 2016 will continue this trend.
6. Create boilerplate for your bio
If you write for publications and websites, you always need to have a bio ready. I save short and long form versions of my bio in TextExpander to reuse, so I don’t have to dig through old bios or always have to write a new bio for each request.
7. Keep a template library
I’m a long time template collector. It’s something I confess only in hushed tones, but I’m admitting to it here. I save templates in the public domain and templates I’ve created for previous projects (where the contract allowed me). Here’s how I see the value of a template library for writers:
An archive of best (and not so best) document design practices
Lessons learned from previous projects
Templates you can reverse engineer to learn how to create new templates
8. Use an invoice template for each freelance client
We’ve come a long way from having to create client invoices in Microsoft Excel to today’s cloud-based invoicing platforms. Take the time and customize an invoice template for each client if your invoicing system allows it. Using a template will save you time and let you fire off that invoice with even less fuss.
9. Save your favorite style guides
While it’s rare for an organization to have to write their style guides from scratch these days, I still recommend keeping a collection of your favorite style guides. While it’s not a template in the traditional sense but sitting on my secret stash of style guides has helped me kick off more than one client style guide because I had a folder of inspiration to help me start on the new style guide.
10. Create templates for your client status reports
If you have to submit status reports to multiple clients, I say make a template for each of them. Even if you get a Word document from them, just save it as a template and you’ll be good to go when creating a new status report.
I was once asked if using templates and checklists might stymy my creativity. My answer is an emphatic No. In fact, using templates and checklists have helped me become more creative because they free me to think and focus on writing.
How do you use templates in your writing life?
Will Kelly is a technical writer and analyst based in the Washington, DC area. He has worked with commercial, federal, higher education, and publishing clients to develop technical and thought leadership content. His technology articles have been published by CNET TechRepublic, Government Computer News, Federal Computer Week, Toolbox.com, ZDNet.com and others. Follow Will on Twitter:@willkelly.
I came to the realization that even working with a group of trainers for the past two years, much of my career as a technical writer has been spent working with programmers and engineers. In my opinion there is a certain kind of magic when working with the right development team. In reflection, I enjoy being around programmers, engineers, and operations people because I like the launch of new products and initiatives so much.
In fact, I am going to say that I prefer working with technical staff and would choose to be a solo technical writer in a technical group versus being a writer in a technical writing group any day.
Here are some lessons about being a technical writer I’ve learned from programmers:
Align yourself to the business. A common complaint I hear about technical writers is how they drift in a world of their own immune to business drivers and technical accuracy where they can wring their hands over grammar, information design, and other topics surely to make a programmer’s eyes roll to the back of their head. It comes down to thinking strategically and asking how can the documentation I create help the business make money, save money, and increase productivity? Granted there are going to be some non-writer managers who are going to want more transparency into the writing side but in the end they want somebody else to worry about those things so the team can focus on the project.
Be as self-sufficient as possible An early technology mentor of mine taught me that there are few if any original ideas in software and if you know one piece of software like a database application, it is that much easier to learn a similar application. It’s never more frustrating to hear a technical writer or even a trainer demand a training class on a new application especially in today’s age of trial versions and demos accessible via the web.
Try to answer your own technical questions yourself first. I once worked with a manager who the programmers found particularly frustrating. To put it politely, she wasn’t too invested in her position and got her job because she was married to one of the company principals. I can remember speaking to one of the programmers after a conversation where he wanted to throttle her and he told me, “Will, always try to answer your technical questions first yourself. It will make it a lot easier for you to get along with programmers in the future.” I took his advice to heart and within reason, I try to answer technical questions first then get help from a programmer or other subject matter expert.
Avoid taking meeting minutes. While some compliance programs want meeting minutes of every meeting and some technical writers consider it a gateway into the inner circle so to speak it is a wrong move for technical writers. More than one programmer I’ve respected over the years has told me to avoid taking meeting minutes because programmers and engineers won’t respect a technical writer who takes minutes and think of them as just a secretary (the traditional role that takes meeting minutes). They also went onto remind me that meeting minutes are rarely ever read beyond the initial meeting. Besides what good are meeting minutes when everybody around the table is taking their own notes anyway?
Have you ever gotten good advice about technical writing from somebody other than a technical writer? What was the advice?
