Resolution for 2011: Attend a conference!

Attending a conference is the perfect professional new year’s resolution for us tech writers: Regardless of what other plans for improvement you (or your boss) have, tech comm conferences are the perfect platform to exchange ideas, learn about new methods and tools and generally recharge your enthusiasm!

If you’re a manager: Sending your tech writer to a conference is one of the easiest and best ways to motivate her or him and to ensure that your documentation is in step with trends and developments! See my previous posts about conferences for insights and raves.

(Alan Houser at tekom 2010, photo by jophan).

To start you off, here are some of the pivotal conferences in the US and in Europe – with one “write-in” conference in Israel added by commenters. The list had great help from Linda Urban who suggested most of the events in response to a twitter query. Thank you, Linda!

The list is sorted by date; the quotations are taken from the event web sites. If you have any advice about events listed or missing, help us all out and leave a comment below.

MEGAComm

February, 20; Ramat Gan (Tel Aviv), Israel

MEGAComm combines two related communities, technical communicators and MARCOM professionals, offering sessions and networking opportunities for both.

WritersUA

March, 13-16; Long Beach (Los Angeles), CA, USA

Developing the best possible user experience for all types of software applications through well-designed interfaces and helpful and accessible support information

CMS/DITA

April, 4-6; Baltimore, MD, USA

Content management and DITA in four conference segments: Management, information design and development, technical solutions, and tools and technology

STC Summit

May, 15-18; Sacramento, CA, USA

More than 80 sessions covering all aspects of technical writing, editing, project management, and publication production

Congility

May, 24-26; Gatwick (London), UK

Content Integration: Leveraging Content Standards to Improve Customer Experience; reducing cost of content and translation; implementing XML, DITA, reuse and dynamic publishing; applying content standards and best practices

UA Europe

June, 16-17; Brighton, UK

Latest industry trends, technical developments, and best practice in software user assistance and online help

CS Forum

September, 05-07; London, UK

Talks and interactive workshops for content strategists, web editors, user experience designers, technical writers, CMS developers

Technical Communication UK

September, 20-22; Oxford, UK

Technical Communication UK is the annual conference that aims to meet the needs of technical communicators, their managers and clients, from every corner of the industry.

tekom

October, 18-20; Wiesbaden, DE

Nearly 200 lectures, workshops, tutorials, and discussion groups on latest developments in technical communication and documentation

DITA Europe

November 7-8, Prague, CZ

Technical writers, IT professionals, information architects, publications managers meet publications professionals who have implemented DITA in their organizations and hear from representatives of key tools vendors who are actively supporting the DITA community.

Advertisement

Lone writer, meet the community network

As part of his excellent review series of the tekom conference, Jason Nichols comments on

the dichotomy between the single-author versus everyone-is-an-author scenario, and why technical communicators not only need to produce documentation, but facilitate the publishing of it from others.

Jason contrasts the reach and limits of a lone writer with the possibilities of a network such as SAP’s community. It’s an unlikely combination to be sure, but his argument about the changing scope of the (lone) writer’s environment are insightful.

I highly recommend this post, as well as his entire review series.

Two words every (lone) writer should know

Many technical writers, especially lone writers, wear many hats, and they like it that way. Some may proofread reports and marketing material, some may spruce up presentations, some may translate. It’s that variety that often makes a tech writer’s job more interesting. But it has two drawbacks that you might want to avoid if you want to heighten your profile and get recognized as a serious, responsible professional. Fortunately, each drawback can be deflected by a single word which you may want to add to your vocabulary.

Learn to say ‘later’

The first drawback is that you need to juggle very different deadlines. Often, these interesting extra tasks are small, but on short notice. Collect a lot of them, and they start to interfere with your long-term deadlines and your larger documentation tasks. If you negotiate deadlines for the smaller tasks, with your manager or directly with whoever requests them, you show responsibility and that you take the task seriously and don’t want to do it ‘on the side’. In other words, learn to say ‘later’.

Learn to say ‘no’

The second drawback is that lone writers often get defined by what they do – and it hurts them, if they are best known for their smaller, more visible tasks. If you’re the proofreader-in-residence or the person who edits reports to make them ‘nice by noon’, ask yourself if that is what adds the most value to your life and to the organisation. If it’s not, try to get rid of such tasks or at least limit them. Ditch the dirt that defines you. In other words, learn to say ‘no’.

Your turn

Have you added ‘later’ and  ‘no’ to your vocabulary? How successful have you been with them? Are the other words you recommend that tech writers should know and use? Leave a comment!

---

This post will appear in somewhat different format in the forthcoming Winter issue of ISTC’s Communicator. It will be my first publication in the field of technical communications, yippie! 🙂

 

Getting ahead as a lone author, my TCUK presentation

I’ve just held my first presentation at a technical writing conference: On September 22, I spoke about “Getting ahead as a lone author” at the ISTC’s conference “Technical Communication UK” near Oxford.

If you’ve been following this blog, you will recognize the theme: I’ve covered several angles of this topic throughout the year. My presentation was basically a condensed version of many of the ideas on this blog, neatly wrapped into 5 best practices, and with the opportunity to ask questions or to comment.

I was glad to have the first slot after the opening keynote, so I could get my presentation out of the way: As much as I was looking forward to it, it did interfere with my attention and general enjoyment, as I kept thinking about whether it was too long or not appropriate in some way.

The opening keynote then set a very comfortable tone: The topic was serious, yet delivered with an ironic sense of humor. “Yeah,” I thought, “I can follow this…”

I counted 23 people in my audience – not a lot in a conference of 180, but it suited me just fine. While my pacing was brisk, I think, it was still easy to follow and engaging.

I finished after 30 minutes to leave 10 minutes for questions and answers. After all, I can’t claim to have any more experience or any better answers than any other lone author. Most of the questions asked for clarifications or further explanations and showed that many lone authors have similar concerns.

As I’ve found out from the comments, one of the weaknesses of the presentation was that I didn’t make all of my assumptions clear. For example, someone helpfully pointed out that authors in a (well-defined) agile programming environment don’t have many of the problems of authors in a waterfall project model as I described it.

On the whole, it was a very valuable experience: I now know I can hold a presentation and get a point across to a room full of fellow tech writers. And I hope to do it again someday.

I had some help on the way: I thank Linda Urban for first suggesting that I could do this. And Karen Mardahl for keeping me pointed in the right direction when I was getting nervous the evening before.

If you have something you are passionate about in your job, I can only encourage you to “get it out”. Write an article, start a blog or hold a presentation at a conference. Chances are it will mean something to your colleagues, either because they are concerned with the same topic or infected by your enthusiasm. And don’t be afraid to seek out help, none of us has been born an author or a presenter, and you’ll find many people willing to help you along.

Resources

• My presentation slides: You can see and download my slides which have been enriched to link to blog posts and web sites with more resources.
• How to hold a presentation: There are a lot of web pages about this, these two have helped me to prepare and to make me confident that I didn’t forget anything.

If you have any feedback on the presentation, whether you attended it or not, I’d be happy to hear it!

Getting ready for TCUK

Take half the slides and twice the nerves.

That’s the lesson I learned as I spent last week getting ready for the TCUK conference and my presentation “Getting ahead as a lone author”. (The lesson is a variation on the old travel advice “Take half the clothes and twice the money” which was useful before credit cards and ATMs…).

Finishing the presentation

… took much longer than I thought. Basically, it’s just as writing good documentation: Knowing what you want to say is a prerequisite. But saying it in the most effective way is what takes time.

But it was worth the trouble. When I was done, I had a nice presentation: A catchy introduction nicely segued into an elegant sequence of nine best practices, followed by a concise summary and conclusion. 30 minutes, plus 10 minutes for Q&A, didn’t seem so terrifying anymore.

If you’ve presented before you probably worry now. It took me some practice to find out what you already know:

30 minutes is much shorter

… than I thought. There’s no way to fit all this into 30 minutes. So I spent more time yet on taking stuff out again. I conflated 2 of the 9 points and dropped another 3, so I’m now down to 5 best practices. That clocks in at around 30 minutes.

Again, it was worth the trouble since I’m now sure I have the best, most focused content ready to present. Highlights include a painting by Carl Rakeman and the “Kick Ass Curve”.. 🙂

If you attend TCUK, consider attending my session on Wednesday at 10:00, right after the keynote address. If you don’t, stay tuned, there will be post-conference notes in this space!

Welcome to summer reruns, part 1

My blog and I are taking it a little easier towards the end of the summer.

I’ve had a wonderful time with this blog so far, and I thank each and every one of you for reading, lurking or commenting. I’ve learned a lot from your comments, and I appreciate your support! It’s been a walk on the beach… 🙂

As we’re gearing up for the new season, here are some reruns from the last year or so.

Popular posts from my blog

Trends in technical communication 2010

This is one of my two most popular posts by far. With the help of several readers, we’re commenting on and discussing two trends from a Scriptorium webinar “Technical Commmunication Trends for 2010 and Beyond”. Sarah O’Keefe predicts that it will include content curation. And Ellis Pratt proposes that technical communications will soon also shape an emotional user experience. Incidentally, Ellis will speak on the same topic at TCUK, so go see him, if you have a chance!

Making it as a lone writer

This is the first post in a small series where I share lessons learned and best practices how lone writers can get ahead. Incidentally, I will speak on the same topic at TCUK, so come see me, if you have a chance!

Reading outside the tech writing box

I’ve found that reading helps my writing, even off-topic reading. Technology journalism works especially well for me. I share my favorite magazines and anthologies and link to five articles that you can read online.

Noteworthy posts from elsewhere

Speaking of reading around. If you want to read up on neighboring disciplines, I recommend these three excellent posts:

Complete Beginner’s Guide to Content Strategy

Complete Beginner’s Guide to Information Architecture

Standardized Approaches to Usability

How and why to estimate writing efforts

Estimating your writing efforts and deadlines is difficult, but essential.

Can you reliably estimate the time you need to write documentation? And the date when you can deliver? It often seems a daunting task because it depends on many external factors:

• The quality of specifications and designs.
• The availability of the finished product.
• The accessibility of subject-matter experts.
• The punctuality and diligence of reviewers.

It also seems futile to spend time estimating efforts when you know you don’t have enough time anyway. But even though it’s difficult and takes time, I recommend that you do it.

Why estimate?

If you don’t do it, someone else will make assumptions about your schedule. Even if you’re just left with the ever decreasing time between delayed development and scheduled shipment.

Estimating makes documentation accountable, in both senses of the word:

• You can explain the time you will spend on documentation. So it allows you to plan and budget the time. Share the estimates with your manager, and you can also share responsibility for the efforts.
• You can also be held accountable for the time you have spent. With estimates, you only will have to justify the specific difference that you ran over the plan. That’s much better than arguing about the complete time which may “seem kind of long” to your manager, though you know “that’s just how long documentation takes”…

Estimating makes documentation more transparent, in other words. It gives you and other stakeholders specific numbers to talk about ahead of time. It gives everybody more control over the documentation process.

For example, I once faced the complaint from product managers that documentation held everything up, that we could ship sooner, if only the tech writer got his act together. By introducing estimates and refining the reporting, I was able to show that it was specifically the reviewers which held up the process. Everybody took the estimated time, more or less, but reviewers delayed their tasks unduly. In fact, one late reviewer was a product manager who had voiced the complaint…

What to estimate?

You get what you measure and estimate. Or in the words of Tom DeMarco: “You can’t control what you can’t measure.”

If you estimate number of pages per day, you’ll get reams of paper. But that doesn’t guarantee that the documentation is useful and/or accurate.

If you count the number of features, options and buttons and base your estimate on that, you’ll get a thorough description of the user interface. And a customer who says, “Don’t tell me how it works, tell me how to use it.”

Apply task-oriented writing and estimate topics, instead:

1. Look at the specifications and designs to understand what’s being developed or produced from a user’s point of view.
2. Distill or translate what you find:
   • Identify modular concepts that users will need to know. A microwave convection combination oven can use descriptions of both concepts with their principles and different use cases.
   • Sketch out user workflows to set up and operate the product and break them down into individual procedures. That oven’s manual will probably have procedures to set it up, to thaw frozen food, to heat food (using the microwave), to bake stuff (using the convection), and to clean it.

A high-level view of the topics and their complexity allows you to make a rough estimate how long you’ll need to create useful topic-based documentation.

How to estimate?

Estimate efficiently. I once estimated a one-month project so well, I was off by two hours in the end. The problem was that it took me two days to crunch all the numbers… I can’t recommend that.

So don’t try to be 100% accurate in your estimate, if it takes you a long time to do it. Here are a few ideas to spend less time on estimates:

• Look at past efforts: Most likely, you’ll do some reporting anyway. Use this as the basis for future estimates. Maybe you’ll find an average time you take to write a concept topic. And one time period for easy and short procedures and another for more complex ones.
• Refine your estimates and average sizes over time: No need to get it perfectly right the first time, especially, if you start estimations on your own account. Try to run the numbers beneath the radar before you come forth with them.
• Trust the law of averages: What extra time you need for one topic, you’ll probably save on another.
• Trust your experience: After a while, you won’t need to sketch out individual topics. You’ll be able to take an adequate measure from looking through the spec or design.

Further reading

To learn more, check out:

• Donald LeVie’s Intercom article “Documentation Metrics”, available via EServer
• Steven Jong’s STC paper “Measuring Quality”, available as PDF
• Gretchen Hargis, et al., “Task-Oriented Writing for Techies“
• Wikipedia on software metrics which has the Tom DeMarco quote

Your turn

Do you estimate your efforts ahead of time? Is it worth the extra effort? How do you use the numbers to your advantage? Please leave a comment.

Buy yourself time as a lone writer, part 2

To be “making it as a lone writer“, you need time. Time to develop your skills, improve the documentation, reach out and network with other teams.

Last week, I talked about some strategies to buy yourself time. You can, for example, move to(wards) topic-based authoring. This eliminates internal inefficiencies, namely those you can deal with yourself.

To buy yourself time, you can also try to:

Fight external inefficiencies

These are inefficiencies that encroach on you from other teams and give you a hard time. Here are two common examples:

Don’t test the product when you should be documenting it. It’s late in the production cycle, and you’re already looking at a tight schedule. You really have to start documenting now to ship on time. And then you find bugs and inconsistencies in the product and interface all over the place…

Testing as a lone writer is not a bad thing as such. Often, it’s what makes the job so interesting and diverse. The problem is if the time isn’t budgeted. Make sure such time and efforts are accounted for. If you enjoy testing, make sure your manager knows you’re doing it, and that it you need extra time for it.

If you cannot test efficiently, or if it’s actually someone else’s job, try not to do it. Yes, “we’re all in this together, and we have to cover each other’s backs”, but that shouldn’t mean that you pick up all the loose ends, just because you’re last in line. Being in it together doesn’t mean taking it out on the lone writer.

Time and again, I’ve “given back” products for testing along with a list of 19 bugs I’ve found in the first hour of documenting. Most managers actually understand that I cannot write documentation efficiently on unfinished or buggy products. To fix this problem, you might need to address a larger issue:

Insist that documentation is included in the project plan. Often, lone writers drop off the radar, and their efforts are not planned appropriately in the project plan or the production schedule. It should be, of course. Your manager and your project managers might not like to hear it, but good documentation takes an adequate amount of time. If they don’t believe you, let them compare measly quick starts that can be thrown together in two days with tutorials or manuals that might take two weeks or longer.

Lone writers are often not used to stand up for their documentation like this. Still, I’ve found it well worth the effort: You can start small by simply inquiring about the project schedule. Maybe you’ve heard about a strategic project or an important customer, and you want to make sure you can deliver good documentation along with it. It shows you’re taking an interest in the project as a whole and your position in it. Managers can’t push you away so easily, once they’ve understood your engagement will help their project – even if it means budgeting extra time.

Usually, project managers have pain points that you can appeal to: Maybe a certain level of documentation is part of the requirements, so it should be planned like any other part of the product? Maybe they’ll latch on to better documentation to buy themselves time and appease the customer? (They can’t very well say they need the extra time also for last-minute development and testing…)

Your turn

What other inefficiencies steal your time and energy? How do you cope with them? Feel free to leave a comment.

Buy yourself time as a lone writer

If you want to be “making it as a lone writer“, one of the most difficult challenges is to find time. Time to develop your skills, improve the documentation, advocate it and network with other teams. One comment on my previous post raised that issue, and I’m taking a couple of posts to reply. Jim wrote:

I am a lone writer for three separate product lines that are mostly custom products (only half are standard manuals). None of these products lines are planned. I hardly have enough time to finish what is required, let alone look ahead to the future of my “department”.

My strengths are technical understanding and an ability to communicate with a technical audience. Weaknesses in planning and management.

So without divorcing my family and marrying my career, do you have any suggestions for employing the suggestions you offered to my situation?

Good question and good point! Today and next week, I present some strategies that have worked for me. They have bought me time to get organized, so I could produce better documentation more efficiently.

Eliminate internal inefficiencies

When you’re a lone writer, chances are you’re not working as efficiently as you could. I know I didn’t, and it wasn’t because I was lazy or incompetent. The “benign neglect” that surrounded documentation simply put a low priority on efficient documentation. As a lone writer, you are probably the first and foremost advocate to make documentation more efficient.

Moving to(wards) topic-based authoring is one good way to become more efficient. When I was a lone writer, no one in my company knew about topic-based authoring (or “TBA”; here’s a good first introduction). I didn’t know about it either, so I wrote user manuals in long Word documents with long chapters. They were hell to maintain: For each error, each update I had to sift through the whole document to find all the places that needed editing. Lone writers can benefit from TBA in these ways:

You can structure your documents using TBA, so most information is only in one logical place. This can help you to limit the scope of your updates from one release to the next. In a first stage, it might already be helpful just to chunk your chapters smartly:

• Move all conceptual “what is…” sections into one chapter.
• Move all the procedural “how do I do…” sections into other chapters.

You can introduce TBA incrementally as a lone writer, so you don’t need extra time to reorganize all content at once. And you can take it slowly as you become more confident about how to do it.

You can reuse topics. Even if you have custom products (like Jim above), look closely at them: Are they always completely built from scratch? Maybe they reuse some concepts, elements or workflows that you have documented before. You can isolate such documentation into topics and reuse them.

You don’t necessarily need a cool authoring tool for TBA (though your reuse won’t be efficient without one). The first goal is to get your content organized, so you can quickly identify and edit the few topics affected by each functional change or update. I’ve done TBA in Word more often than I care to admit… 🙂

You pick up a marketable skill: You’ll find it easier to get and move into a new job if you know TBA. In my experience, knowing such a method is more valuable than knowing any one tool. The method still applies while skills with an old tool version have become obsolete.

– You might also find other ways to tackle inefficiencies in the way you work today. Even if it’s only a more efficient way to prepare your weekly reports.

The strategy to eliminate internal inefficiencies has an evil twin which can be just as effective, but it’s more dangerous:

Skimp temporarily

This one is risky, it requires courage, good judgment, and some mutual trust!

When I was a lone writer, I have gotten away with skimping temporarily.  The requirements on my documentation were not standardized. Sometimes, the only formal requirement was that documentation exists. If you’re in such a situation, you may be able to get away with underperforming for one or two releases, while you get organized.

When I did this, my manager indirectly called me on it and suggested some improvements to the documentation. Then I was able to show him how I had started to move towards TBA to be more efficient in the future. When he realized that I was working on larger, reasonable improvements, he supported me.

– Next week, I’ll talk about a couple of strategies to buy yourself more time: You can also fight external inefficiencies which encroach on you from other departments.

Your turn

What is your experience when trying to improve documentation? Have thesse or any other strategies worked for you?

Making it as a lone writer

Lone writers have their work cut out for them. But the lack of processes and resources also gives them flexibility and freedom to work towards improving both, the documentation and their situation.

The plight of a lone writer

Life’s difficult for lone writers. They are usually the only person in the company who creates and maintains documentation. They are tucked in with the marketing or development department. They often operate without a dedicated budget or specific managerial guidance.

(Photo by jc-pics)

However, such “benign neglect” which treats documentation as an afterthought also offers opportunities – which are best exploited by the tech writer. After all, part of the problem is that many managers don’t fully understand what tech communicators could do if they let them. And change management is much easier when you only have to worry about management buy-in and not employee buy-in, too.

The promise

It’s a lot of work for a lone writer to re-invent how documentation is done and perceived at your company. It once took me a couple of years to get from a shaky reputation due to unmaintainable Word manuals to appreciated documentation written with MadCap Flare and delivered as web help as well as printable manuals and tutorials in PDF.

But if you’re up for it, it can be very rewarding, too. It can

• Increase the value and raise the profile of documentation
• Make your job more interesting, more diverse
• Secure your job in the mid-term
• Secure your career in the long term

A matter of type

There’s no one sure-fire way to do it. To give you the best odds, take into account your personality: Many of us tech writers are introverted types (else we might have gone into marketing or training… 🙂 ) If you are introverted, focus on your work, and let it speak for itself – but put it somewhere your colleagues can “hear” it!

If you are a more extroverted type, consider giving documentation a face – your face! You’re it, anyway… If you know you do good work, you might as well reap the rewards rather than amble along in anonymity.

Focus on your work and your strengths

Regardless of your type, I’ve found that these four strategies can contribute to raising the profile of documentation:

• Manage your work efficiently
• Make your work easy to use
• Know your strengths
• Leverage your strengths

These four things are basically what a good manager should be doing for you. But none are so difficult that you can’t learn them and apply them for yourself.

Learn more…

To learn more about making it as a lone writer, especially about implementing the strategies, check all posts about “lone writers”.

Update: Two posts about buying yourself time as a lone writer have appeared since this post was published. Check out part 1 and part 2.

If you’re attending the TCUK conference in September, try to catch my session “Getting ahead as a lone author” on the morning of Wednesday, September 22.

Your turn

What are your experiences as a lone writer? How have you been able to raise the profile of your documentation? Can you imagine that the strategies above could work for you? Leave a comment!