Monthly Archives

March 2014


31-Day Blogging Challenge: Who are the Bloggers?

March 8, 2014

Day 8 of the 31-Day Blogging Challenge (#31dbc)

Today, I finally had time to look at the list of bloggers who joined me on the blogging challenge, which is being led by Lesa Townsend. I actually read at least one post by each blogger.

Most of the participants are women who do some form of life coaching (spiritual, physical, business, dating, etc.). There are also a couple of homeschooling mommy bloggers and fashionistas, plus 2-3 business consultants and 2-3 male bloggers. About half were work-related blogs and half were personal. Brenda Huettner and I are the only Technical Communicators on the list.

What struck me was not the wide difference in politics, approach, focus, or writing skill. But rather, I was struck by the common themes, expressed by almost everyone, either in their posts or in their About pages:

  • Make the world better by your actions and presence.
  • Be conscious in your dealings with others.
  • Be kind.
  • Have a gratitude attitude.
  • Our stories matter and are part of what makes each of us unique.
  • We all want to be heard and understood.
  • Many of us have quirky, interesting hobbies and interests.
  • We all have something to contribute.
consulting, inspiration, mentoring, thought leaders

Mentor Highlight: Pam Slim

March 8, 2014

Day 7 of the 31-Day Blogging Challenge (#31dbc)

In an earlier post, I mentioned that I do a lot of mentoring in technical communication. Today, I want to give a shout out to Pam Slim, a business coach who has an awesome blog: It’s one of the few blogs that I read religiously.

She recently published her second book, Body of Work, which I contributed to by periodically answering a few questions about my experiences.  Pam and I have never met in person (though I hope to fix that when I’m in Phoenix for the STC Summit in May). And yet, she is one of my mentors.

In her blog, she shares her great advice, connects us to other thought leaders in business, and is unflagging in her support of people wanting to run their own businesses. In addition, she exhibits values that I admire: integrity, inclusivity, generosity of spirit, a genuine desire to make the world better, curiosity, plus she’s funny. I love that she calls her stepparents “bonus parents” and that she calls herself a “bonus kid”. (I hope my bonus kids feel that way about me some day.)

It’s almost like she reads my mind with her posts…I will be worried about something or wondering something, and then her post on that very topic shows up in my in box. It’s like a breath of fresh air and a respite from drinking from the firehose of the interwebs. She makes me think, too.

My copy of Body of Work just arrived; I’m going to go read it now…

consulting, getting started in tech comm

Getting Started as a Consultant: Determining Your Hourly Rate

March 7, 2014

Day 6 of the 31-Day Blogging Challenge (#31dbc)

Note: This article originally appeared as a sidebar in an article I did for STC Intercom in June 2012. The information is still applicable.

Before deciding how to charge (hourly, page, etc), you need to know what your cost basis is. This is the minimum amount you need to charge in order to make money on a project. I calculate it based on an hourly rate, which you can then convert to whatever type of rate works best for the project you are doing.

Here’s how you do it:

Base rate before profit

[(annual salary when you were working for a company)/2080 hours per year] + [(annual salary X 30%–to account for benefits)/2080] + [monthly overhead/160 hours per month] = base rate before profit

Base Rate after Profit

Now, take your [base rate before profit X 10%] + base rate before profit = base rate after profit.

But, this result doesn’t account for hours that you are marketing and not billable (most freelancers are billable about 1500 hours per year.

Average % non-billable time

So, take your [base rate after profit X ((2080-1500)/2080)] = average % non-billable time

Minimum amount you should charge if you want to make money

Now, take your base rate after profit + average % non-billable time = base rate you should charge if you want to make money.

Example Calculation

Here’s an example in USD, assuming a 40-hour workweek (rounded for ease of calculation):

annual salary = $50,000

monthly overhead = $500

 [$50,000/2080 hours] + [$50,000 X 30%/2080] + [$500/160 hours per month] = $24.04/hr + $7.22/hr + $3.13/hr = $34.39/hr is base rate before profit

[$34.39 X 10%] + $34.39 =$3.44 + $34.39 = $37.83/hr base rate after profit

$37.83 X (580/2080) = $37.83 X 28% = $10.55/hr to account for non-billable time

Minimum rate you should charge = $37.83 + $10.55 = $48.38/hr (round up to nearest $5), so your actual minimum rate would be $50/hr.

Once you know this number (it will vary greatly depending on your expertise, locale and so on), you can figure out a per page rate or fixed bid rate, if needed.

Assumptions in proposals

In addition, your proposals should always contain assumptions and risk management statements for each likely scenario for a potential problem.

For example, “This project assumes 2 SME reviews and 1 editorial review. Additional reviews will require a change order. If the SMEs do not return their comments by the agreed due date, this will cause a day for day slip in the schedule.”

These kinds of statements are especially important in fixed bid or per page bids because they give you leverage to go back to the client if there is scope creep or delays on the client side.

If travel will be involved, state how you will charge them for it in the bid. I always charge this as a separate line item from the actual work, and provide an expense report and copies of receipts as part of my invoice.

localization, Vendor Management

11 Things You Didn’t Know About Your Localization Vendor

March 6, 2014

Day 5 of the 31-Day Blogging Challenge #31dbc

I work with a lot of clients who are just getting started in localization. To many of them, localization is a black hole into which they pour their source content, then magic occurs and Presto! out comes a language product.

Let’s take a peek inside the box:

  1. The pool of translators is finite and the vendors all fish from the same pool. Most translators work freelance for several localization vendors, and the good ones are in high demand. Vendors hire translators for jobs based on language combination and industry expertise.
  2. A couple of large localization companies make most of the tools used in the localization industry. This means that many vendors are competing for work with the vendors that also create the tools that the industry depends on. Naturally, this doesn’t always sit well, and many vendors are looking for ways to reduce this dependency.
  3. Process and customer service matter more than cost per word. See #1 above. Working with a localization vendor is a long-term relationship. Focusing on cost/word is the wrong way to look at things, particularly if quality is important. Look at the value-added services the vendor provides, how they treat you as a customer, and how they treat their employees and contractors.
  4. For most customers, the mid-sized localization vendors will be the best fit. Unless you are a Fortune 500 company, the mid-sized vendors will generally be a better fit for you. They are small enough to be hungry for your business and big enough to scale with you. The big boys in the localization industry focus on enterprise level projects (large volumes, many languages, complex designs). The single language vendors can’t scale with you.
  5. When you fail to pay on time, a translator might go hungry. Localization is a people-intensive process, even with support of translation memory and machine translation. Many vendors have difficulty paying their translators and other contractors on time if they have big customers who don’t pay them on time. While 60 days isn’t a long turnaround for a big public company or one that is well-funded, that time frame causes major cash flow issues for a small sole proprietor (aka most translators). Be a good customer and pay on time (If you pay net 30, your vendors will love you).
  6. Pushing your source content drop date without pushing the product release schedule significantly affects the quality of your language product and increases your costs. Localization takes about 80% of the time that the initial content development takes, so expecting 50,000 words in 30 languages in 2 weeks is really unrealistic and undoable with any sort of quality. Consistently abusing your vendor will result in lower quality, significantly increase your costs, and potentially, will get you fired by the vendor. Fixing your upstream processes for product and content development, having good QA, editing, and change management processes helps to prevent this issue.
  7. DTP/engineering is ~50% of your localization costs if you are using traditional content publishing methods. First, the content gets pulled into the translation memory tool, where the translators do their thing. Then, the translated content gets put back into the final output format via desktop publishing (DTP) or web/help engineering. If you are not using XML and XSLTs, reformatting is a manual process that must be done separately for every language. Template problems, content issues, graphics issues grow exponentially with the number of languages. If you have 10 errors in the English and are translating into 30 languages, suddenly you have 300 errors that are likely to get perpetuated.
  8. Your in-country reviewers cause some of the biggest headaches for the localization vendor and increase your costs. In-country reviewers are typically subject matter experts (SMEs) who have product knowledge and fluency in both the source and target language. However, if you do not train the reviewers properly, or if you do not make the language review part of their job responsibilities, they can completely bollox up the process with preferential/spurious changes, delayed responses, and so on. Create effective review processes and train your people! If you have a relatively large volume, t’s a good idea to have a localization manager who can vet the comments before passing them on to the vendor.
  9. You, the client, own your translation memory files. Just like you might hire a contractor to develop the source content, you are hiring the localization vendor to create the language product. In both cases, this is considered “work for hire”. You own the copyright (after you’ve paid your bill, of course).
  10. Lack of re-use and poor terminology management are costing you big money. If you aren’t reusing your content and managing your terminology, you are paying multiple times for translation of the same content. If you think you don’t have re-use, think again. Notes, cautions, warnings, product specifications, warranty, trademark, and copyright information, UI field names, glossary terms, etc. get used in multiple places in your content. In the translation memory, the translator must review every fuzzy match to make sure that it is contextually correct, so randomly changing the wording of a sentence requires it to be re-translated.
  11. Your localization vendor has a list of issues with your content, but they might not have shared it with you. If you have done a couple of projects with the same vendor, they will likely know what the issues are with your templates and content. Unless you have a mechanism (e.g., bug/change tracking database) for sharing that information with your content development team, the feedback loop isn’t being closed and the mistakes are being promulgated with every language and iteration. Ask your vendor for the information. If your team needs training on creating global-ready content, make sure that they get it. It will save you big money in the long-term.

There are, of course, many other things that you need to know when you are localizing your content. But, being aware of these things and fixing issues in the source will get you a long way toward improving your quality and global customer satisfaction.

getting started in tech comm

Getting Started in Technical Communication, Part 1: FAQs

March 4, 2014

Day 4 of the 31-Day Blogging Challenge (#31dbc)

I do a lot of mentoring in my roles as a small business owner and as a Fellow and Board member in the Society for Technical Communication (STC). I love it because I always learn something new, get to meet some really bright and engaging people, and I like to help people achieve their dreams.

Here are 3 questions I get asked frequently and my responses. Feel free to chime in with your own experiences, or to ask other questions.

My degree is in X, but I’ve always loved to write. What skills do I need to get a job in technical communication?

It’s great that you are interested in technical communicaton! It’s a fun career with a lot of opportunity to grow in the direction of your interests. Having technical domain knowledge in X field and writings skills are important, but not sufficient for being a good technical communicator (TC). Certain personality traits and skills lend themselves well to being a good TC.


  • Curiosity
  • Desire and ability to understand how things work
  • Flexibility (in thinking and in attitude)
  • Penchant for asking impertinent questions
  • Exploratory, can-do attitude (most TCs I know have myriad interests and are really interesting people)
  • Somewhat geeky mindset
  • Ability to play well with others
  • Ability to see both the forest and the trees (most people tend toward one or the other; the ability to bridge the gap is valuable)
  • Honesty and integrity
  • Desire to know the story and to tell it
  • Ability to see patterns and relationships
  • Ability to learn and take constructive feedback (you need a thick skin)

Skills (besides the obvious writing and editing):

In the beginning of your career, focus on the basics. Look for opportunities to try new techniques and learn new tools. (I once moved to Fargo, ND so that I could work with a really good online help development team.)

  • Good organizational skills (it helps to like organizing and categorizing things)
  • Topic-based writing/structured authoring techniques
  • Working knowledge of at least 1 authoring tool, 1 DTP tool, 1 graphics tool (once you know how one of each type works, it’s fairly easy to figure out the others in the genre)
  • Working knowledge of the jargon used in technical communication (e.g., content strategy, usability, localization, UX, etc.)
  • Understanding of visual design
  • Understanding of audience analysis
  • Familiarity with XML and content management
  • Familiarity with metadata and with indexing techniques
  • Familiarity with writing for a global audience

There are other skills as well (depending on your focus), but this list is a start. You can get information and access to educational sessions from STC and other associations, or from many universities.

I’ve been looking for a TC job, but there aren’t any advertised. How do I break into the field?

Technical Communication touches every product, process, and service on this planet (and off of it—ala the Space Station). We are everywhere, but we are often well-hidden in the companies, governments, and non-profits that we serve, and sometimes called something else, like publications specialist, graphic designer, content manager, etc. Jobs are often not advertised.

First, pick an industry. Make it something you are interested in. Have a degree in biology? or nutrition? or engineering? or music? or economics?  Narrow your search by focusing on your area of technical expertise and interest.

Start networking. Join STC and other professional organizations (you can see the job bank and make connections). Volunteer for your associations or another non-profit that attracts people in your chosen industry. Join your alumni association (or at least the online communities). Ask people about their jobs and, if it’s something that sounds interesting, dig deeper. Ask for informational interviews. (People love being asked about themselves and generally like helping newbies.) Research the top companies in your selected industry.

Establish your online presence. Most TCs are fairly tech-savvy, so connect with them on LinkedIn, Twitter, etc. Subscribe to TC blogs and forums that interest you. Be diligent about presenting a professional persona. (Make sure that your profiles are grammatically correct and typo-free. We check, and TCs can be a bit anal-retentive about that sort of thing).

A word about LinkedIn etiquette, if you ask to connect with someone you’ve only met once or twice or (only have met virtually), say a bit about who you are and why you want to connect. Most people won’t connect with you if they don’t know anything about you.

Be polite, follow up, and follow through. If someone has taken time out of their day to talk to you, be sure to thank them in writing (email is OK most of the time, but if they really went out of their way, a personal note is better).

I’m changing careers. What should I do about my résumé?

I generally recommend a functional, skills-based résumé for most people. When I’m hiring, I want to know what you know, and really couldn’t care less about where you have worked (except when it comes to checking references, or out of curiosity to see if I know anyone there).

I start with a “kitchen-sink” résumé, where I put in everything that is relevant to what I do. Then, I adjust it for each job (change the order, level of detail, emphasis as appropriate). If you are just out of university, you will probably put almost everything in. Until you’ve been working for several years, keep it to 1 page and to the most relevant information.

The skills-based résumé has the following sections:

  • Related Skills: List 3-5 skills that you have and want to highlight, such as Project Management, Training, Writing/Editing, Content Strategy, Usability Research, etc. Under each skill, put 3-5 bullet points that specifically show your skill in that area (e.g., “Managed 15 content management projects to implement DITA” is better than “Responsibility for a bunch of content management projects.” )
  • Related Positions: In reverse chronological order (most recent first), just list titles, companies, dates, and locations here. All the important stuff is under the skills.
  • Education: In reverse chronological order, list your degrees and certifications. If you are a new graduate, you might want to include some of the coursework you’ve taken, if it’s relevant.
  • Related Technical Skills: List the software packages you know, special knowledge (if it’s relevant).Caution: if you list something here, you need to have a working knowledge of it. For example, if you list MS Office, I will expect you to know how to use templates and styles in Word, pivot tables and basic functions in Excel, and do snazzy presentations in PowerPoint. If you don’t use styles and format things properly in your résumé, I will know that you don’t know Word…

If there’s room, you can include a list of volunteer work and awards (again, only those things that are directly relevant to the job you are applying for. In the US, employers are not allowed to ask about gender preferences, marital status, religion, etc., so don’t include those volunteer activities on your résumé.

Always be truthful in your résumé.

When you are responding to a particular job ad, I recommend using a T-letter. TECHWHIR-L had a great article about these letters. Try it out and see how it works.

I will post periodically on “Getting Started” topics. Let me know if you have a burning question, or need advice.