Leadership and the solo technical writer


It’s easy to feel like you are kicked to the side as a technical writer at times. I’m convinced that in order to prosper in today’s climate being a technical writer requires a certain amount of leadership skills in order to be effective. While it may not be, the traditional leadership in the sense of a PMP certified project manager but leadership nonetheless.

Avoid taking meeting minutes. When I was just starting out, a programmer told me that as a technical writer I should always avoid taking meeting minutes. His reasoning was that once a technical writer accepted the role of taking meeting minutes the technical staff could never consider the technical writer as anything more than clerical help thus diluting the role. I’ve written before my disdain of meeting minutes in general and have come to see that a technical writer needs to have a seat at the table just like the other members of the project team.

Be the voice of technical documentation. Even in organizations where technical documentation isn’t an afterthought there still needs to be a voice for technical documentation to provide management and senior staff expert guidance on the technical documentation elements of the projects. When a technical writer can take away some of the worries that can abound about technical documentation on a project can they be seen as a leader by the rest of the organization.

Be technically aware. Another piece of advice I got from an engineer early in my career was to try to at least figure out technology myself first before getting help from a programmer or other technical team member. This advice also led me to have some technical interests of my own. While, along the way, my technical interests have changed with the state of technology, but I can call them my own and speak to them accordingly.

Know your audience. Depending on the organizational culture, some technical documentation decisions are best left to the technical writer which requires having the confidence to make a decision on a technical documentation issue and sell it to management and the rest of the team. It is also important not to get lost in discussing the minutiae of technical documentation with other team members unless they specifically request it. Knowing your audience begins at the interview stage where it is important to qualify what the hiring manager is seeking in a technical writer, how you can fulfill their requirements, and take some of the pain of technical documentation off them and onto yourself to deliver technical documents that meet or exceed expectations.

How do you show leadership as a solo technical writer?

Image by freeimages.com user:pnijhuis

Will Kelly is a technical writer and analyst based in the Washington, DC area. His writing experience also includes writing technology articles for CNET TechRepublic and other sites. Will’s technology interests include collaboration platforms, enterprise mobility, Bring Your Own Device (BYOD), project management applications, and big data. Follow him on Twitter: @willkelly.

Originally published at willkelly.org on March 14, 2012.

Managing part time freelancing while working a full time job


Note: I originally wrote this post when I was working a full time technical writer job and saw the need on the horizon to return back to freelancing.

I currently work for a federal government contractor for 40 hours a week but still pursue freelance writing projects on the side. Having such projects makes me feel safer with a second income stream but also help provide me with new professional challenges and keep my skills sharp.

Working a full-time job and freelancing may seem daunting to some but there are some simple things part-time freelancers can do to ensure success in their day job and freelance projects, while living a good life.

Set clear expectations about your schedule. I’ve been pursuing part-time projects for large chapters of my career and every so often come across people who want to hire a part-time contractor, but expect full-time availability. Over the years, I’ve come to spend a bit more time up front qualifying part-time projects and coming up with a list of communications options between my client and me that won’t jeopardize my day job while maintaining a professional level of service.

Reserve time for yourself. It’s easy for some personality types to get lost in work much more so when they pursue off hours projects. My biggest advice here is to reserve time for yourself (away from the PC) every week so you don’t spend your life going from PC to PC. My weekly calendar includes time blocked out for me to go to the gym six times a week.

Look into adjusting your schedule at the day job. Many employers offer flex time for their employees, and I recommend you looking into it if you want to freelance on the side. Because of my employer’s flextime, I am off work at 3:00 or 3:30 pm meaning it is not too late for me to make calls or return emails about a freelance project during regular business hours. It works out even better if the freelance client is in another time zone. Take, for example, the time I was able to attend a product briefing for an article after work but before the gym.

Learn your natural rhythms. I am a nighttime writer for sure and have some colleagues who do their best work in the morning or late in the afternoon. Time has taught me to become a morning writer especially when I am working on a client site that gets noisy. Another example, Saturday afternoons are more productive for me than Friday afternoons. These are all examples of knowing your natural rhythms because if you can’t be productive in the evenings after changing gears from your day job than part time freelancing is going to be next to impossible for you

Move your project files to the cloud. A local hard drive or external drive is the traditional means of storing project files in a home office. However, as a part time freelancer you may run into situations where you may need to access a project file while you are not in your home office. I recommend looking into a Dropbox, Box, or OneDrive account for your freelance project files. Even if your client is averse to sharing files through one of these services, you can at least have peace of mind that the files are available and accessible if needed during the day or at another time, you are away from your home office PC and your client contacts you about needing a particular file.

Move your email to the cloud. Cloud-based email services are a popular option for email these days, and a must have for part-time freelancers. There is a load of options out there even if you own your domain. My email is current hosted on Google Apps for Work. Just the other week, I was at the pool on my day off and got an email from a freelance client who couldn’t find a reviewed document I sent them. Using my iPhone, I was able to go into my email’s Sent folder and resend them the email with an attached file. All of this was done without ever leaving my poolside chaise lounge. After resending the file, I was able to enjoy the rest of my sunny afternoon.

Move your calendar to the cloud. Successful part-time freelancing is going to require even more diligent scheduling of personal and professional time. My calendar has been in the cloud since Google Calendar launched but now resides in Google Apps for Work. Because it is in the cloud, I can access it from any of my mobile devices or PCs.

How do you manage part-time freelancing while having a full-time job?

Image by stock.xchng user: dekok

Originally published at willkelly.org on August 27, 2011. The post has been edited and revised since its original publication.

Will Kelly is a technical writer and analyst based in the Washington, DC area. His writing experience also includes writing technology articles for CNET TechRepublic and other sites. Will’s technology interests include collaboration platforms, enterprise mobility, Bring Your Own Device (BYOD), project management applications, and big data. Follow him on Twitter: @willkelly.

Conducting a technical documentation audit: The first thirty days onsite as a technical writer


Recently during an interview, the director level person I was speaking with asked what I do when I come in as a new technical writer that is the first one inside of an organization. Some of my technical writer roles in the past have been working directly on technical teams (and have been the first technical writer more than once) so I do have a process I’ve come up with over the years but had yet to write down. The key for a successful document audit is to couch everything in business terms especially if the technical writer position is to either start a new group or be a part of a technical team

Here is a basic overview of my documentation audit process:

Get access to existing documentation. I like to read all the existing technical documentation before speaking to anybody. At this phase, I like to look at the documentation based on my own experience tempered against any preliminary discussions about the current state of the organization’s technical documentation as discussed during the interview stage and any preliminary discussions that have taken place. I usually keep a running list of observations of what I see in the documents at this stage.

Get access to existing systems (if workable). An optional step is to get access to existing systems to compare the existing documentation against systems for a document freshness test. I realize this isn’t always workable or even necessary, but I’ve gotten a lot of insight doing this when the project involves reverse engineering requirements documents, software requirements specification, or functional specifications.

Discuss organizational priorities for technical documentation. I don’t admit to having all the answers about the direction of the documentation plan, so I always try to get the organization’s priorities for technical documentation early in my documentation audit. Technical documentation needs to align itself with the business early in the process.

Interview internal customers about the documentation. I’m a believer in aligning technical documentation to the business making me a big proponent of talking to the internal customers for the documentation and getting a handle on their likes, dislikes, and requirements. I especially like to talk to staff members who work on different shifts about their views on the existing documentation.

Interview stakeholders and managers about the documentation. After speaking with the internal customers about the documentation, then it is time to speak with the manager and higher level stakeholders of the documentation.

Develop and present a list of findings. Based on my discussions with staff members, I write up my list of findings and present them to management and/or stakeholders either through a written report or a presentation.

Develop an action plan. Based on the discussions during the internal customers and stakeholders and the presentation of the list of findings then it is action plan time. My action plans typically include:

  • Document priorities
  • Proposed document overviews
  • Project schedule/dates for document development

Execute on the action plan. I like to align my action plan with the projects that the documentation supports and set 60 and 90-day goals for new technical documentation efforts especially if technical writing is a new addition to the organization.

What sort of upfront analysis do you do as a technical writer starting on a new contract or in a new full-time position?

Image by stock.xchng user: forwardcom

Will Kelly is a technical writer and analyst based in the Washington, DC area. His writing experience also includes writing technology articles for CNET TechRepublic and other sites. Will’s technology interests include collaboration platforms, enterprise mobility, Bring Your Own Device (BYOD), project management applications, and big data.


Originally published at willkelly.org on November 13, 2011.

Lessons learned from my former life as a computer book technical reviewer


I was a computer book technical reviewer earlier in my career. It was a freelance gig, but I still consider the work one of the most formative chapters in my professional writing career even though it wasn’t writing work.

Computer book technical reviewers sometimes called technical editors are responsible for ensuring the technical accuracy of computer book manuscripts. The work taught me to pay attention to technical details, which in turn went onto influence my work as a technical writer and freelance writer.

The lessons I learned include:

Don’t forget industry best practices. The gray underbelly of computer book publishing is that some of the authors have never done real work with the applications they write about. The home office in the spare bedroom just can’t be a bellwether of how the software or service works in the corporate enterprise. The lesson for technical writers here is to know your audience, how they do their jobs, and the industry they work in.

Write substantive comments that engage and stand on their own. None of my former clients in the computer book publishing industry ever met me face to face. There is only one book author I’ve ever met in person. This means my comments on book manuscripts had to be substantive and stand on their own because it wasn’t like I was down the hallway if somebody had a question or needed clarification on a comment I made. Substantive comments also helped where the publisher’s staff may not be technical. As a technical writer, you should be able to back up anything you say or write with facts enough so you can at least follow along in a technical discussion. Remember, the (non) technical writer and ignorance as an asset are industry myths.

Be fluent in multiple browsers and OSes. Some of the finer points in technical manuscripts can be lost with a simple change in Windows OS or browser versions. So it is important to know the OS and browser versions your audience is using. It’s a minor detail, but something to be conscious about especially if you are documenting web-based applications in the Microsoft Windows world. Technical writers need to be conversant in the OSes and browsers their user community uses on a regular basis.

Have you ever had a formative non-writing job that later contributed to your writing career?


Originally published at willkelly.org on October 8, 2011.

Image by freeimages.com user: mrsmarshah

The best advice I’ve ever gotten about technical writing…from programmers


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?

Image by Stock.xchng user: svilen001

Originally published at willkelly.org on November 25, 2011.