Scholarship Winner: Discovering the Breadth and Depth of Technical Communication and Technical Editing

Lindsay Taylor

Editor’s Note: Once again this year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the first of such articles from our undergraduate scholarship winner.

Before taking my first undergraduate courses in technical communication at the University of Wisconsin-Madison, I had never imagined how complex and broad the field of technical communication really is. My coursework made it clear how much more I had to learn about technical communication, such as the different fields one can work in (science, engineering, etc.) or the different approaches to editing (individually and in a team).

To exemplify the variety of lessons I have learned—all precedents for future studies—I would like to describe two projects that were of particular value. Each demonstrates very different but equally important elements of my technical communication education. The first, for an introductory technical communication course, was writing and editing a semester-long research project on treatments for Parkinson’s disease in the fall of 2008. The second project, for a technical editing course, was a comprehensive team technical editing assignment on the UW Engineers Without Borders (EWB) handbook in March of 2009. I will describe what each project taught me about technical communication and how I will use that information in my future work as a technical communicator.

As an English major, I have written many research papers throughout my undergraduate career. In my first semester of the Technical Communication program, however, I was assigned to write a comprehensive, 15-page research paper on a scientific or engineering-related concept. While my background in science prepared me for the material, I was intimidated by the idea of writing a research paper of such magnitude outside of my own discipline. Even my work directing an interdisciplinary writing-tutoring program did not fully prepare me for the writing style used in technical communication, a style very different from what I was used to in the humanities. To write this particular research paper, I read countless samples of science writing and technical documents, meticulously followed my professor’s (Laura Grossenbacher’s) handbook on technical communication, and capitalized on peer-editing sessions with my classmates, all of which exposed me to different styles of technical writing. Though the report was supplemented by the edits and comments of my classmates, the paper was essentially an independent project that tested my ability to think critically and learn a new skill. By the end of the semester, I felt that I had produced an effective research paper and had discovered a new appreciation and passion for technical communication. This individual project reminded me of the importance of revision, word economy, and researching skills, all of which continue to contribute toward my success writing in a variety of disciplines. I know that I will remember this project one day when I am faced with a challenging technical communication assignment that tests my ability to be flexible and open-minded in learning new skills. I also value the independence that this project gave me: the ability to own a document from start to finish.

The second compelling technical editing project I worked on was with UW’s Engineers Without Borders (EWB) handbook in a technical editing course in spring 2009. Last year, two senior UW-EWB members informally produced a comprehensive, 50-page manual for new EWB members, describing everything from the group’s mission to how to use Skype when working in developing countries. The handbook was an important resource but would benefit from improvements in content, organization, and design. Our class was assigned to help improve the overall appearance and effectiveness of the document. In teams of four, our class worked to comprehensively edit the entire document. I’d like to describe this project because the team editing approach was so distinct from writing an individual technical document.

While I have worked on group projects before, I had never quite tackled a project of such magnitude. I learned how to collaborate with a team of editors who all see different positive and negative elements of a document. Just to interact within a group of four editors was challenging, but beyond that, the five groups in the class had to agree upon several universal editing points within the document. This project was particularly fascinating because of the amount of communication that went on among and between groups. Editing this large document would have been time-consuming and rather impractical for just one editor. This team editing project truly taught me about the effectiveness of a group of editors, something that I had not completely understood before this course.

One additional technical editing lesson I learned from the EWB handbook editing project was the great difference between copyediting and comprehensive editing. As a Writing Fellow (a UW writing tutor), I was trained to prioritize global issues in a document; then, as the copyeditor of the Wisconsin Engineer magazine, UW’s undergraduate engineering publication, I focused specifically on local, mechanical edits in documents. However, in addition to these issues, my work on the UW-EWB handbook taught me that the field of technical editing also requires analysis of organization and content and maintaining an open communication line with the author. My group and I closely collaborated with the authors of the handbook, and we were responsible for making universal changes throughout the document on both objective items, such as capitalization, and on more subjective topics, like the tone of the handbook. I discovered that several elements of editing are interdisciplinary, despite the great differences between writing styles and fields.

Both of these projects stemmed from great assignments set by excellent professors. I am grateful for the distinguished professors I was able to learn from during my undergraduate technical communication studies at UW. The lessons I gained from their projects were diverse, yet each provided fruitful practice for a future career in technical editing. I realize now that technical communication crosses many disciplines, topics, and writing styles, and as a recent graduate deciding on a career path, the diversity of the field is the most compelling factor to me. I will retain the lessons I have learned from both of these projects and will apply that knowledge in my continued education of the field of technical communication.

Setting Up an Editorial Review Process

Sarah Barczyk

So you want to be a technical editor. You’re well-versed in grammar, style, punctuation, and the mechanics of the English language. You know what it takes to produce a clear, concise, readable paragraph and a coherent technical document.

Subject-matter experts within your company recognize that you’re an asset and routinely seek you out for writing help and perhaps enlist your aid in editing large documents. But you know that so much more can be done. All you need is a process. It sounds so simple…

But simple it’s not. As someone who’s suffered the bumps and bruises that come along with setting up an editorial review process, I can attest to that. I can also offer a few tips for integrating the editorial review into the documentation process.

First and foremost: start small. If you work for a large company, pick a particular department or project and garner managerial support by putting together a concise proposal that outlines the advantages that an editorial review process can provide. Mention benefits such as consistency across documentation for the end user and a more polished and professional look to customer deliverables. A clean document will require less rework down the road, resulting in an overall cost savings to the company, and will improve customer satisfaction. If a customer receives a document with a high rate of errors, there is a good chance the technical content will be perceived as erroneous as well. Once you have the backing of upper management, the establishment of a process will become much easier.

Be flexible, yet firm in setting up your process. Understand that the unknown is scary (and fond reminiscences of English class probably do not exist in the minds of your technical coworkers), but stress the importance of a standard course of practice. Research the place that an editorial review will fit in your documentation workflow, and gather feedback from authors, document coordinators, and mangers. I have found that the editorial review fits best at the end of the writing process, after any technical reviews. In this placement, the author and editor can work together to resolve any last-minute language issues, and the document will have a professional and polished look and feel before manager approval. There may be instances due to time constraints when this process may have to be relaxed. Be prepared to be flexible, but do everything you can to enforce a standard process.

Expect resistance. Most nonwriters view documentation as a necessary evil. Be they doctors, architects, or engineers, the technical work comes first; documentation is simply a means to transmit knowledge. What’s important is the content. I can’t count the number of times I’ve been told, “It doesn’t have to read like a novel. It just has to make sense.”

You’re going to encounter people who view editors as formatters or spell-checkers. They don’t understand that an editor can provide consistency across company documentation. They don’t recognize that an editor can make each document more readable for the intended audience. They don’t appreciate that an editor can catch simple mistakes that have previously gone unnoticed because the author happened to be too close to the document content.

In short, you’re going to encounter people who just don’t care about the editorial review process. They’ll view it as an extra step, which means extra time and money that they’re not willing to spend. And they won’t hesitate to let you know it. Here’s where managerial support will be a great asset.

You’re also going to have to prove yourself. You must prove that you’re just as much as an expert in your area as your technical coworkers are in theirs. You need to be able to back up every edit you make with information found in style guides, well-documented conventions, and company policies and procedures. An engineer may have earned a PhD in quantum physics, but that does not mean that he or she has ever taken the time to learn the proper way to punctuate a gerund phrase.

Each edit must be clearly communicated, and communicated with tact. Pose your comments as suggestions rather than directives, and be open to explanation. An author may have deviated from the standard, but he or she may have a very good reason for having done so. And always remember that the document is the author’s property. There may be times when you disagree regarding a particular point, but know when to pick your battles. If the author is dead-set against a change that you’ve suggested (whether or not he or she is correct), keep a record of the conflict and move on. Resist the tendency to engage in a power struggle, which may result in costly delays.

Keep in mind that a face-to-face conversation is a great way to take the edge off of a critique. Schedule a time to discuss your edits and to ask questions of the author. Build a relationship and show your own willingness to learn about the technical content of a document.

Consider creating an editorial review checklist. This is an efficient way to keep track of items (such as formatting and numbering conventions, capitalization standards, and rules for including acronyms) that may need to be assessed for each document. It’s also an appropriate place to document any specific disagreements that you may have with the author’s rejection of a suggested change. A checklist can serve as a tool for gathering metrics and tracking common mistakes and issues that regularly arise during the editorial review process. Finally, a checklist provides a means by which to secure your job as a technical editor; it will serve as the proof of your value to the company.

In these tough economic times, it may be difficult for a company to justify the added expense that an editorial review process may bring, but in the end, error-free deliverables will save the company effort and money. All documentation can use a little polish; as an editor, it’s your job to make it shine.

Editing for the Next Generation of Readers

Jeffrey Japp

As I read Tony Self’s article “What If Readers Can’t Read” in the February 2009 issue of Intercom(external link), I began thinking about how editors should revise the way they edit textual content for the next generation of readers.

According to Self, “The speed at which information can be retrieved through tools such as Google is causing readers to become impatient. An Akami study in 2006 found that 75 percent of people would not go back to a website that took more than four seconds to load.” He continues by asserting that “our reading is moving toward skimming information horizontally, or reading snippets of text from different sources, rather than in-depth vertical reading.”

So how should we as editors respond to this trend? First, it is imperative that we shorten and streamline copy by removing all superfluous information. Too much text in a topic, whether it is in print or online, will increase the reader’s frustration at not being able to locate information quickly enough. Shortening text can be difficult because we deal with writers who may view every word as important and SMEs who feel that every possible bit of information should be covered in-depth. However, to ensure that we are communicating effectively to the target audience, we must be firm in our resolve to shorten and streamline copy.

The other area where we as editors can make an impact is in creating and editing indices. While this is less of an issue when a professional indexer is involved in the project, often budgetary constraints force writers to create their own indices which may not be as functional. On a recent document I edited, the index was little more than a copy of the Table of Contents. Because an index can help readers locate the precise location of the information they need, it is likely that there will be a shift from using a TOC to locate information to using an index. Self goes as far as suggesting that we abandon TOCs in electronic documents altogether.

If you are an editor who is not also tasked with writing, it may be prudent to get involved with writers early in the project. With an understanding of how documents should be structured to facilitate rapid location of information, we can assist writers in the development phase of a project by suggesting guidelines on how to design hierarchies of information. While this is less of an issue for organizations that employ structured documentation, it is invaluable for those still using more traditional documentation practices.

As content delivery changes, we as editors need to adapt the way we work to ensure that we assist in delivering content that is helpful and intuitive to our users.

Creating an Anthology on Editing

Avon J. Murphy

Pulling together New Perspectives on Technical Editing, an anthology on editing, was a complex, yet exhilarating experience. The process fell into four stages.

The longest stage was the gestation stage. I’d written an annotated bibliography on technical editing for the National Council of Teachers of English two decades earlier. Long a highly organized pack rat in careers as academic researcher, government research analyst, and finally editor, I had several hundred articles and a hundred books on technical editing. But something was missing from all this literature. As much as I’d gripe about the hole over the years, I couldn’t quite identify what I wanted. Tom Warren, of Oklahoma State University, challenged me to do something about it.

Energized by adrenalin, I charged into the second stage: What would we learn by looking at our discipline from different points of view at once? This question morphed into another: How much would we learn if recognized experts wrote separate chapters addressing the deeper questions suggested by their specific approaches to editing? Thus was born the idea of a collection of research-based and experience-based chapters looking at technical editing from various angles.

The collection eventually came to include such disparate angles—the “Perspectives” in the book title—as research methodologies, editing with electronic tools, editing within particular environments, the teaching of editing, and so on. Dozens of questions wrote themselves. For example, what methodologies can editing researchers best use? Is technical editing more complex than it was in the mid-20th century? What choices do teachers of technical editing have for designing their course? How can the structure of an organization dictate editorial career paths? How can copyeditors ensure quality? How have computers changed technical editing? What special problems do science editing and journal editing present?

The most challenging stage personally was getting the right people on board. As Technical Communication book review editor for nearly two decades and as manager of several research efforts, I’d been monitoring the careers of several accomplished editors; my short list of candidates was almost ready before I wrote it out. I was looking for original thinkers within their niches who had published a good deal, were dependable, and would keep me informed about their progress. Michelle Corbin, Angela Eaton, Barbara Gastel, Geoff Hart, George Hayhoe, Carolyn Rude, Tom Warren, and Jean Hollis Weber were all such people. The time-consuming part was to convince each individual to participate. I showed them the shape of the book, its contribution, the possible main points and resource leads, how the editors could individually contribute within their specialties, and the impact of this writing upon their careers. After some anxious weeks for me, all of them finally accepted the challenge.

The final stage was comparatively easy. Having lived so long with the book-to-be, I watched the proposal write itself. Baywood Publishing was the only company I seriously considered, and it quickly accepted the proposal. With schedule, style sheet, and chapter template on their computers, my contributors then set to work on what has become a most rewarding book.

As the writers submitted their chapters, my developmental editing focused on innovative thinking about questions, acceptable research methodologies, avoidance of excessive duplication among chapters, and incorporation of already published literature. On the second and third drafts, I focused more on voice, paragraph structure, sentence clarity, and formatting within my template restrictions.

The full manuscript went to Baywood in late September 2008, Baywood approved it in mid-November, and I sent the slightly revised files in early December. The manuscript is now (late April 2009) in typesetting. After proofing, correcting, and indexing, the book should appear in something like 15 weeks. I’m certainly happy to be working with a publishing firm that stresses the importance of high-quality procedures, including editing. Would I want to edit another anthology? Ask me after I’ve recovered from this one!

Managing the Chaos of Freelancing by Taking Control of Your Schedule

Geoff Hart

As freelancers, we all face the problem of feast or famine: sometimes we’re overwhelmed with work, and can hardly find time to think, let alone keep up with our other responsibilities, but other times dust gathers on our computers while we wait for new work to arrive. Clearly, marketing our services and finding new clients is important to avoid the “famine” part of the freelance lifestyle, but what do you do when too much work is arriving?

As a freelance editor, my work primarily involves a large number of small jobs rather than a small number of large projects over the course of the year. In this article, I’ll use this situation, which many other freelancers are familiar with, to provide some suggestions on how to manage your work schedule more effectively and attain a slightly more sane work life. The advice I’ll provide is equally suitable for freelancers who work on a few large projects, since even the largest projects can be broken down into smaller and more manageable chunks. (Indeed, the really big projects can’t be managed any other way.) The same strategies apply, but with an obvious modification: you’ll need to budget time at the end for cleaning up and finalizing the whole project.

There’s no foolproof solution to the chaos of freelancing, since life sometimes happens all at once and there’s nothing whatsoever we can do about it. But there are several tricks that let us juggle life and work considerably better than if we give up and simply accept whatever life throws at us. One of the first and most powerful solutions involves gaining more control over our schedules. Doing so requires only four simple steps:

  • Learn how much work you can complete within a normal-length day.
  • Use some form of calendar to reserve dates for anticipated work and your known commitments.
  • Always build some slack time into your schedule.
  • Develop a support system.

 

Learn how much work you can complete per day

Tracking your productivity is important, because it’s the only way you’ll ever be able to know how long a job will take and thus, how many days you’ll need to reserve for a given job. This knowledge is what lets you schedule your work. Each job is at least slightly different from the work you’ve done previously, but over time, you’ll gradually get a feel for your range of productivities, including both your long-term average and the worst-case scenario. A conservative approach to scheduling your work relies on using the worst-case productivity, since that way you can be reasonably confident you’ll finish ahead of schedule. Basing your schedule on your average productivity may be more realistic in the long run, but it also means that you’ll end up working under significant deadline pressure for half of your jobs and severe deadline pressure for a significant number of jobs.

If you track productivity separately for each client or each type of product, you can further refine your estimates. Best of all, if you get a chance to examine the whole job (e.g., the full text of a manuscript to be edited or a carefully defined functional specification for software) before you are asked to provide a quotation, you can base your estimate on the actual work you’ll be doing and come up with a much better estimate for that specific job. However, there’s a common gotcha to be aware of: early chapters in a book that you’ll be editing or the initial product features you’ll be documenting in a help system tend to have been developed early in the project, while the author or developer was still well-rested, excited by the project, and not facing insane deadlines. Later parts of the job often take longer than early parts because of creative fatigue, loss of interest, or simple lack of time to do the job right. So try to examine the whole project, not just one or two initial components, before you create an estimate.

The first step to gaining control of your work life is to learn the trick of estimating how long a job is going to take each time a client contacts you with more work. For suggestions on simple ways to track your productivity, I’ve provided two resources on my Web site:

 

Use some form of calendar to reserve dates

Once you know how long a job will take, the next step is to schedule the work. Doing so requires some form of calendar, whether you implement it on paper or in software. (Different strokes for different folks!) Basically, your goal is to recognize that there are only so many working hours in a week, and that all your work must be fitted into those available time slots. Once a slot is full, it’s no longer available for other work, and finding a way to account for this in your schedule is the key to regulating your workflow better.

In the previous step, I asked you to determine how much time a job will take. Now your goal is to look at your calendar and find the first day when you can begin that work. Mark the day (or days) on your calendar as “Reserved for [name of job]” so you won’t double-book those days for other work. One of the biggest mistakes freelancers make is failing to reserve dates for future work on those rare and happy occasions when a client gives us advance warning about when a job will arrive. If you have clients that predictably send you work such as annual reports, quarterly newsletters, or annual funding proposals at specific times of year, reserve those days each time you start marking up your calendar for a new year, and add a note in your reminders program a month before these periods so you can contact your client and confirm whether the work will arrive on schedule.

Don’t forget to include down-time and other non-work time commitments that will reduce the number of hours available for work. If you know you’ll be away or unavailable for part of a day, mark that part of the calendar as unavailable. Include doctor appointments, family gatherings, meetings, or anything else that will prevent you from working. Don’t neglect the obvious: for example, my first calendars were clearly marked “no work today, idiot!” on weekends and holidays because early in my freelance career, I was constantly working through the weekend and wondering why. As it happened, I’d simply neglected to block in those days as unavailable for work. (Sometimes I’m thick as a brick.)

Reserve all your known commitments (e.g., an hour a day for exercise or watching your favorite TV show) before you start allocating your time for the coming month. You won’t always be able to honor every commitment, but you’ve got a much better chance of success if you’re at least willing to try to give your real life equal priority to your work life. For longer allocations of time, such as vacations, add a note in your reminders program to notify all your main clients well in advance so they can plan around your schedule. (Many won’t bother, but each one that does is one less client likely to cause problems around that time.) One useful, though mildly unethical, approach involves telling clients you’re leaving a couple days earlier than you really are leaving. This way, if any emergencies arrive at the last minute, you still have time to handle them—or to find someone else who can do so. (More on the latter topic in the penultimate section of this article.)

Paper works adequately for calendars, but software solutions provide far more flexibility when it comes to rearranging your schedule. What software should you use? Options range from behemoths such as Microsoft Project to smaller and nimbler tools such as the task and calendar tools built into Microsoft’s Outlook or Apple’s iCal. Everyone eventually finds an approach that suits their unique needs, and the key is to invest some time experimenting until you find an approach that works well for you. For example, I’ve found an approach that, though kludgy and inelegant, works better for me than more complex and powerful solutions: I use iCal for reminders and small notes, but I use nested folders on my computer’s desktop to organize my work life. You can see what this approach looks like in Figure 1. The key concept behind my approach is that I use a single “Work” folder to gather all my work together in one place, and use Macintosh aliases (”shortcuts” in Windows) that point to the actual folders that hold the work for each project. Adding the date at the start of each folder name lets me schedule the work.

Figure 1. Using nested folders to organize your work schedule.
Image

Each month, I create a new series of named folders to reserve non-work days for weekends, holidays, and other times I won’t be available for work. For a weekend, a typical folder might be named “September 12-14 no work”. (Note that I’ve also marked most Fridays as unavailable for work. We’ll come back to that point in the next section.) Similarly, the screenshot shows a planned absence in the form of a working vacation during which I’ll be giving a workshop to a local STC chapter and then taking a few days of vacation: “October 12-20 no work (Phoenix trip)”. Folders representing dates when I’m not available for work are highlighted in red to distinguish them from folders representing work.

In Figure 1, you’ll see two different types of work folder: Folders such as “September 8–808078 Harada alias” represent a project I’ve already received and that is ready for editing when time permits, but no later than that date, whereas the folder “September 9–808061 Harashima (long review)” is a placeholder for a job that hasn’t yet arrived but that is due to arrive on the specified date. I’ll replace that one with an alias to the real folder once the files are on my hard disk. Folders that contain the word “alias” (the Macintosh version of Windows shortcuts) point to the actual working directory, thereby providing direct access to that directory without having to click my way several levels deep into my hard drive. This is important for me because I have clients in dozens of countries, and several large clients in two countries, requiring a strongly nested folder hierarchy on my hard drive.

Note that I’ve also used a yellow-highlighted folder that does nothing but separate ongoing tasks (such as the newsletter that I publish for STC’s Scientific Communication SIG(external link) and a list of presentations I’m currently working on) from the actual paying work. Because most operating systems sort names beginning with a hyphen before names beginning with letters, adding a hyphen to the names moves these folders to the top of the list. Other useful tricks such as adding a number before each name lets you take advantage of the operating system’s default ordering rules.

The resulting display provides an “at a glance” list of the work that needs to be done, and when it needs to be completed. Using a consistent naming scheme lets me use the built-in display options on my computer to place the work in correct order, but there’s an obvious problem: although the order of the folders is correct within any given month, you can see that my absence in October displays above (before) the work that must be completed in September. I could solve this problem by working in icon view instead of text view, since that would let me manually drag the folders into the correct order rather than being constrained by the operating system’s sorting preferences. I’ve found that I prefer the text view, and can live with the tradeoffs.

When I finish a job, I simply delete the alias pointing towards it, which has no effect on the actual folder that contains the project, and move on to the next project on the list. When new work arrives, I can see at a glance when I’ll be able to fit it into my schedule, and I can immediately propose that deadline to the client. If urgent work arrives, with a tight deadline, I can see (based on the dates in the work folder) which projects can be pushed back a day or two. For example, the folder “September 9 (due 18) 808062 Wada alias” tells me that I should try to get the job done by the 9th, but that I can let it slip by up to 9 days if more urgent work arrives unexpectedly. In the next two sections, I’ll discuss how to handle such surprises.

Always build some slack time into the schedule

When a client contacts you to discuss new work, learn to always ask them two questions:

  • When would you like to receive this job?
  • When do you really need to receive it?

Most of the time, there’s a significant gap between the two. When you record the job on your calendar, carefully record both dates. If unexpected or more urgent work arrives, knowing the true deadline provides an opportunity to juggle your schedule (i.e., push back the date on a less-urgent job) so you can fit in the new work.

This approach is a specific example of a more general principle: always build in a day or two per week of empty time that you can use when a job takes longer than expected or something urgent arrives. The more flexible the schedules of your clients and the more predictable your workflow, the less empty space you’ll need to set aside. Over time, you’ll gradually get a feel for how much work is likely to arrive in a typical week. For example, my major client typically sends me two to three jobs per week, and more than that during busy periods. Knowing this, I no longer accept more than two or three jobs from other clients in any given week because doing so might leave me unavailable to that primary client. If my major client is less busy than usual, it’s easy for me to complete other work earlier than originally scheduled or accept work I’d otherwise have to decline, thus giving my other clients a pleasant surprise.

Of course, whether to do work earlier than scheduled is a bit of a judgment call. If you’re as busy as I am, you’ll find that it’s a wise choice, because you never know for sure what will arrive on your desk next week, and freeing up time now by finishing next week’s work early makes it less likely that you’ll have to turn away work or pull an all-nighter. On the other hand, sometimes you simply need a day off to decompress, and the risk of longer work days next week isn’t the worst alternative.

As I noted in the previous section, I’ve implemented my own advice by marking my Fridays as unavailable for work. This serves two purposes. First, I’m growing sufficiently old and prosperous that free time is becoming more valuable to me than a few extra dollars. During slow periods, this means that I can often take a 3-day weekend and use the extra time to work on my own writing. Second, this automatically gives me one day per week of flex time that I can allocate to rush jobs or unexpectedly long jobs that require more time than I budgeted. I still often end up working most Fridays, particularly when I know that I’ll be leaving for a long trip and need to store away a bit of extra money to cover my lack of earnings during that period, but asking clients when they really need a job returned often lets me defer a job until the following week. Then, if I do need to work on a Friday, or if I know something big is coming the following week, I use the extra hours on Friday to avoid a serious work crunch the following week.

Develop a support system

All of this is great in theory, but in practice, sometimes everything hits the fan simultaneously and there’s simply too much work for any one mortal to handle. Pulling an all-nighter or working a 60-hour week is sometimes possible, but it’s not a good long-term survival strategy, even if you’re young enough to survive what programmers glibly refer to as a “death march”. (I no longer am.) Yet there’s always the fear that if you turn away a client because you’re too busy, they’ll never come back to you. Fortunately, there’s a reasonably effective solution.

That solution involves finding one or more colleagues you can trust to do work that’s up to your personal standards and who also won’t steal your clients. Yes, such people exist; I’m one of them. In those periods when you have some downtime, spend some time finding two or more colleagues who are willing to do this kind of work and who you can trust. Discuss the possibility of covering for each other during rush periods, with an explicit but informal verbal agreement that you won’t steal each other’s clients. (You can also make this a formal legal contract if you want more reassurance, but starting your relationship by making it clear that you don’t trust your colleague without a signed contract is not an auspicious beginning.) You may still lose an occasional client this way, but if you choose wisely, an ethical colleague won’t steal your clients and everyone will sleep a bit easier knowing they have someone to cover for them. Better still, an insanely busy period for one of your colleagues may coincide with a slow period for you. If you hit a dry spell, write to these colleagues and let them know. They may be happy to send you some of their work.

I work this way and refer potential clients to a few colleagues purely as a friendly gesture: I don’t charge them any money for this service, and I don’t count up their debts to me. I’ve been blessed with more than enough work, and have several colleagues who aren’t so fortunate and who could use a few extra billable hours. The benefit of this approach to me is that I’m not responsible for the quality of their work, and I make this quite clear to the clients when I give them the referral: “Here’s someone who can handle this work for you. I will not be supervising their work, but they’ve been doing this work long enough that you can feel confident in their expertise.” If you’re more entrepreneurial than I am, you can also subcontract such jobs, and then do quality control on the subcontractor’s work to ensure that it’s up to your standards. Personally, I find this way too much overhead, but it might be a very good solution for you, particularly if you’re still building your client list and need a bit of extra income.

Parting thoughts

I started this article by noting that this approach can be modified to cover a range of other situations. For example, what can you do if you receive offers for two large projects that must be worked on simultaneously? Typical examples might be when two publishers ask you to edit large textbooks simultaneously, or when a software developer asks you to document two large modules of a larger program at the same time. Although it’s clearly more efficient to focus on one project at a time, it’s often appropriate to budget half your work week for each project, and switch horses every Wednesday at noon. Each job will take roughly twice as long as if you worked on only one project at a time, but if you designed your initial scheduling estimates to account for this situation when you accepted the work, you’ll often still be able to complete both jobs on schedule. This is particularly true for software documentation early in the development process, when many parts of the software are being delayed or constantly revised, and you may not have enough work to devote a full week to the product. Things become dicier towards the end of the job, as the software begins to stabilize, more features are complete, and deadlines tighten, but it’s unusual for this to happen at exactly the same time for projects from different clients. More often, different parts of each project progress at different rates, and a slow period for one project will overlap a work crunch for the other project; in that case, you can adjust your schedule to fit in more of the crunch project and less of the slower project. This can also happen with large books, particularly when multiple authors are contributing chapters over a period of several months.

For this approach to work, you need to discover factors that might impose the same deadline or a non-negotiable deadline on two large projects. In software documentation, this might happen when two programs must be released at the same trade fair, such as INTEROP(external link) or in time for the annual tax preparation season. For books, you might need to complete a project sufficiently far in advance that the book will be available at the start of the school year, in time for the Christmas book-buying season, or a big annual book fair. The only way to discover such pressures is to ask your clients whether any such factors might affect their delivery schedule for the product. (Note that I said their schedule, not your schedule. Clients can sometimes be amazingly clueless about how your schedule relates to their schedule, leading to unpleasant surprises.) For some additional tips on learning about organizational schedules, consult the “survival skills” part of my article on Improving your editing efficiency(external link).

Learning to schedule your life more sanely also has strong ties to what may be your most crucial task as a freelancer: establishing a slush fund to cover your expenses those times when the work stops flowing or illness prevents you from working. (This also helps you to afford periodic vacations.) This isn’t optional if you freelance: make it a priority to build up 3 to 6 months worth of savings that you can tap during slow periods or illnesses, even if it means giving up beer and movies for a couple of months to save that money. If you have a family to support, consider buying disability insurance to cover you against illnesses; other forms of income-replacement insurance may be available, so ask an insurance broker about your options. Knowing that your slush fund is full lets you sacrifice work on the occasional Friday, whereas knowing that it’s underfunded or that you’ll be drawing it down soon (e.g., to pay a quarterly tax installment) reminds you to work longer weeks. For some tips on this, see my article Tax tip: a personal savings plan that works(external link).

The freelance life isn’t always unpredictable, and is sometimes unpredictable in a very stressful way. But the first step in mitigating that stress is to take steps to gain some control over your schedule. This article covers a few basic strategies you can use to improve your control. Your own work situation will clearly differ from mine, requiring various modifications to the approach I’ve proposed, and there are other stresses I haven’t covered that require different solutions. But as this article shows, the important thing is to decide that you’re willing to devote a little time to developing strategies that will minimize those stresses—and these strategies don’t need to be particularly complicated. Such simple steps can take you a long way towards a more enjoyable freelance career.

Previously published as: Hart, G. 2008. Managing the chaos of freelancing by taking control of your schedule. http://www.stcsig.org/cic/pages/links.htm#Consult(external link)