Eradicate buzzwords from your workplace vocabulary

people at a meeting

Startup Stock Photos

In a previous post I mentioned Buzzword Bingo, the subversively fun game to play at your next conference or meeting. Buzzwords are those feel-good but meaningless phrases (like “bleeding edge”) that seem to creep more and more into our daily workplace vocabulary. It’s not just a phenomenon of the realm of marketers and salespeople, either. When was the last time you told someone that you were “thrown under the bus”?

It’s tough to figure out how or when these phrases became so popular, but we’re now seeing a backlash. Certain phrases have become so common that they have taken on an ironic or humorous cast. A great article that covers this silliness is Travis Bradberry’s Please Stop Saying These 25 Ridiculous Phrases at Work.

My personal pet peeve is anything that makes it sound like we’re in the military. Equating a workplace meeting with a military exercise is both overblown and disrespectful, in my opinion. But does it slip into my vocabulary? Of course.

What are your favorite buzzwords to banish?

Skype your way to learning

Music lessonAs a musician, I used to think that there were some things that could never be taught online. For example, learning to play a musical instrument seemed to call for a face-to-face interaction without question.

But I was surprised to learn that there are many teachers conducting class and individual lessons over Skype. Some of these teachers have students who are miles away, and others use Skype to occasionally supplement face-to-face lessons. You can imagine that if music can be taught this way, many other subjects can be as well. A wealth of how-to videos can be found on YouTube.

In case you’re unfamiliar with Skype (, it is is a peer-to-peer service that enables you to make and receive video and voice calls with your computer via the Internet (known as Voice over Internet Protocol or VoIP). Skype also works nicely on tablets and smartphones. And in addition to video calls, Skype can handle phone calls, text messages, file attachments and more.

Because connecting to another Skype user is free, Skype has become popular for international calls. Skype makes money by charging for connections to and from landline and cellular phones.

How does it work?

1. Download Skype or a Skype mobile App.

2. Create an account sign in, and add contacts.

3. To call Skype contacts, click the person’s name and choose video or call. To call a phone, click Call phones and enter the number.

Tips for successful Skyping

  • Begin with the basics. A higher-grade webcam, headset and microphone can help filter out background noise and improve audio or video quality. And a high-speed WIRED Internet connection will make the experience more pleasant. On wireless connections, audio conversations will cut out more frequently and the video will not be as responsive.
  • Make sure that both sites are using the same and the most up-to-date versions of the Skype software.
  • Keep other system demands as low as possible when Skyping. Even so, some issues cannot be controlled (bandwidth, firewalls, excessive number of connected users.) If your connection is poor, try reconnecting one or more times to get a better connection.
  • To improve video quality, make sure both sites are well-lighted. Video is best viewed on small screens; it becomes grainy when displayed on a projection screen
  • Unscrupulous Skype users sometimes contact strangers and pose as a friend or family member to get personal information, such as bank account numbers. Be skeptical of any contact that you were not expecting through Skype. Be especially wary of following any web links sent to you through Skype.

That’s the quick and dirty version. Try it out and let me know what you think!

Image:  Gerard ter Borch  (Dutch) The Music Lesson.

Breaking the Silicon Ceiling

The American Association of University Women (AAUW) has been asking the question for years: Why are there so few women in science, technology, engineering, and math (STEM)? These careers are lucrative and vital to our economy, but according to AAUW, women make up only 12 percent of engineers and 26 percent of computing professionals.

I don’t think I have any answers, but I do think there is reason to hope that young women coming up through our universities may be poised to change that equation.

First, let’s look at an ignominious moment in recent history: the release of Dell Computer’s “Della” site. According to Jenna Wortham’s 2009 blog post, “The site originally featured tech ‘tips’ that recommended calorie counting, finding recipes and watching cooking videos as ways for women to get the most from a laptop.” So a mere six years ago tech companies thought that women wanted cute, colorful machines to help them with lady computing. Heck, maybe they still think that. Seems a  little depressing if you are an aspiring female programmer.

But here are some things to give you hope. At the same time Dell was gendering its netbooks, the President of Harvey Mudd College, Maria Klawe, was quietly building an engineering program that was designed to bring more women to the field.

NPR profiled President Klawe in 2013, and her story makes a fascinating read. By hiring more women faculty, adding more introductory courses, and by integrating research experiences and conferences, the college became a case study in how to break the Silicon Ceiling. By 2014, the college awarded more engineering degrees to women than to men. Take that, Silicon Ceiling!

Finally, let me circle back to AAUW. They recently posted 10 Ways to Get More Women into Engineering and Tech, which includes practical and simple ideas for those who have the power to help: employers, practitioners, and….parents? That’s right. If parents show their little girls that science is cool and encourage a problem-solving mindset, those girls may grow up to be the engineers of tomorrow. A simple yet powerful message to take to heart.

3 Agile Insights or: How I learned to stop worrying and love the Scrum

For over a year, I have been the lone tech writer on an Agile team full of top-notch system analysts. I have to confess that I was nervous about the prospect of spending my whole morning working on the same project, with the same people. And my development skills are limited to HTML and a few ill-advised forays into JavaScript and Ruby. How would I contribute to such a team?

I’m happy to announce that although I am still not much of a programmer, I have discovered some interesting things about Agile. So off we go…

1. Agile is a mindset, not a prescription. When people say they are “doing Agile” or a project is being run as an “Agile project,”  I’ve discovered that there is probably some room for argument. They might be confusing Agile with something else.

The characteristics of Agile were cherry-picked from a variety of software development project approaches, including Waterfall, Extreme Programming (XP) and Scrum. Eventually some developers formally codified these principles in the Agile Manifesto. Although this makes it easier to describe Agile, it also makes it a bit more challenging to define it.

To work in Agile, team members gradually develop an “Agile Mindset” that favors consensus, small changes, continuous feedback and learning, and individual interaction. Being Agile means that team members operate under shared vision and personal accountability, while enjoying the autonomy that allows them to choose how to tackle the tasks they work on.

In my time with the Agile team, I found that this way of working was both more efficient and more satisfying. Each day was organized around value-added priorities rather than a fixed schedule.

2. The Agile Manifesto is open to (mis)interpretation.

In 2001, a group of 17 experienced programmers gathered at a ski resort in Utah to codify their common beliefs by creating the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I recently heard a project manager say that developers don’t like to write documentation because “the Agile Manifesto prohibits it.” As a tech writer and an Agilist, I had to object. Another person in the room helpfully piped up, “People over documentation, right?” No, not quite.

The second bullet above is the source of much confusion. Lazy developers might use this statement to get out of documenting their projects, but the developers I worked with understood that “working software over comprehensive documentation” didn’t mean “eliminate all documentation.”The clue comes in the final, bolded statement: “while there is value in the items on the right, we value the items on the left more.”

In an Agile mindset, documentation flows from working software and constant communication. It may come later in the process, or it may grow out of the user stories that guide each sprint. In a complex project, a technical writer can take on many of these documentation duties.

3. Tech writers have a stake in Agile development. At several junctures, our Agile team was threatened by reorganizations and efforts to mirror our success in other teams. We usually were able to fend off these threats by emphasizing team velocity: it takes time to bring a team through the “forming, storming, norming” stages, and we were unwilling to lose what we had.

But why keep a technical communicator embedded with the team? In my organization, only a handful of other projects had used Agile or Lean methodologies, and as far as I know, they never included technical communicators like me.

Technical communication experts suggest  that even though technical writers on Agile teams focus on content, they can contribute to the team effort by providing usability input or helping with end-user testing. This type of participation creates a more visible role for writers, and allows us to offer more informed opinions—assuming we’ve been paying attention all along, as we should.  It is also important to insist on accuracy by asking questions, gaining access to test systems and prototypes, and learning as much as possible about how the product works.

One of the criticisms of Agile is that its fast pace does not always lend itself to improving the user experience (UX) through testing. My presence enabled us to do a modest amount of usability testing to improve the interface. With limited resources, we performed 20 tests during a single four-month project. Because of the iterative nature of Agile, we were able to conduct two or three tests after each of the latest builds, recording impressions and problems to take back to the development team.

In conclusion, I plan to bring my Agile Mindset to future projects, whether or not they are using an Agile framework. The availability of different project management models means that teams can always figure out a way to work to best meet the needs of end-users.

Roger Boisjoly and the Challenger Disaster

January 28, 2015 marked the 29th anniversary of the Space Shuttle Challenger disaster. Seventy-three seconds into the flight, the shuttle exploded high over the ocean, sending the astronauts to their deaths. The nation and the world were shocked and grief-stricken at the loss of life. Furthermore, thousands of schoolchildren were watching the launch live, and were psychologically scarred for years to come.

In the immediate aftermath, people couldn’t fathom how such a thing could happen. As it turns out, engineers had known for years that there was a potentially fatal flaw in the shuttle’s design. Even though they had tried up until the night before the launch to warn NASA of the likelihood of failure of the O-rings (a part designed to prevent blow-by of hot gasses), the engineers were overruled and ignored by their own management.

Roger Boisjoly (1938-2012), a mechanical engineer working for Morton Thiokol (the manufacturer of the solid rocket boosters) participated in that late-night conference with a heavy heart. In late 1985, Boisjoly explicitly warned his managers that if the problem was not fixed, there was a distinct chance that a shuttle mission would end in disaster. He and the others watched the launch and witnessed their predictions coming true.

Boisjoly’s testimony during the investigation of the disaster cost him his friends and ultimately his job. But it also led him to speak out against ethical lapses in the workplace, earning him the Award for Scientific Freedom and Responsibility by the American Association for the Advancement of Science in 1988.

Doing the right thing

In the workplace, we are faced with ethical dilemmas every day. Writing ethically might not require us to rise to the level of Boisjoly’s bravery, but it’s important to understand what stops us from doing the right thing.

Bruce Weinstein, the ‘Ethics Guy’, believes there are three obstacles:

  • Fear of not being accepted by peers, or of reprisals
  • A focus on short-term benefits, not looking to the future consequences of a decision
  • Foul mood: one’s own emotional or physical health prevents you from acting selflessly.

Boisjoly and his colleagues overcame those obstacles, and did their best to prevent the disaster. As writers, we can follow some practical rules for our communications.

  1. Use language and visuals with precision. Don’t use “weasel words” or play with statistics to make things seem better than they are.
  2. Prefer simple, direct expression of ideas. Avoid “legalese” or Byzantine language that hides the true message.
  3. Hold yourself responsible for how well the audience understands the message. Don’t violate your readers’ trust in you. If someone tries to get you to back down, stand your ground.
  4. Observe copyright laws & avoid plagiarism. A no-brainer, I think. Litigation is no fun.
  5. Respect your audience’s privacy. Don’t spam them or sell their names to spammers.

Anything else? Please add a comment!

8 tips for pain-free progress reports

Bored man snoozing on computer keyboard

via Flickr user Brandon Heyer

A progress report (also known as an activity report or status report) is requested by those who are interested in the past, present, and future of something you are working on. Unlike a more formal research report, a progress report can be brief, with no need for cross-references or detailed front and back matter. A progress report can even be delivered verbally, although most organizations also require something in writing. Often a template will be provided, but occasionally you may be asked to draft something on the fly.

Planning the report

1. Assume the reader is 100% unfamiliar with your work. Even if your supervisor is familiar with what you do, a future supervisor or different department may not be. Plan to write the report to account for those things that are internalized: things you might (incorrectly) assume everyone already knows. Don’t skip or gloss over the details that your reader needs. This is where a journal (tip #8) can be a lifesaver.

2. Understand the time-frame you will report on. By definition, a progress/activity report is not a summary of your entire project. It covers a specific time segment. Progress reports can be weekly, monthly, quarterly, or some other combination. In any case, the basic format is to explain what you have accomplished and what you still plan to do. Stick to this time-frame so that your content does not become bloated.

3. Define the purpose, audience, and format for your report. Even in a short, informal report, the good old “reporter’s questions” are a fine starting point. Two important things should be considered:

  • What are the special needs or interests of your readers? Do they like lots of detail or just the big picture? Do they prefer graphs and charts? Are they interested in reporting to stakeholders outside your organization?
  • Who else might read your report? In addition to your supervisor and any stakeholders, consider your organization’s executive level, future employers, auditors, and even lawyers. The need for accuracy and ethics is higher than it might appear.

4. Structure your report logically. A structure will help you cover all the highlights. Your employer may give you specific guidance, but a progress report typically contains these items:

  • Introduction
  • Summary and Results of Activities (past, present)
  • Future Activities
  • Conclusion

Some employers also ask for things like expenses and risks to be called out separately. A simple table or bulleted list often does the trick.

Drafting the report

5. Find a quiet time to write your report. (Good luck with that!) If you try to write when you are busy or distracted, you might forget important details.

6. Take a straightforward approach. Write in plain style and keep your page design simple. Avoid long paragraphs if a short paragraph (or list, or visual) will do the job. Brevity is both a requirement and a bonus for progress reports. As we know, most readers prefer short communications, even when the content is important.

7. Proofread! Carefully review, edit, and proof your report. Even though it is tempting to dash off a progress report without taking time to check your spelling and writing style, your supervisor will appreciate the extra attention. And as tip #3 suggests, other people may read your report and make judgments based on what they see.

Going forward

8. Keep a project journal. Depending upon your organization’s tools and customs, you may already be recording tasks at a granular level. But if not, find a way to record your daily activities–in a wiki, an online journal, or even a paper journal. You will save time in the long run.

What other tips do you have? Add them in the Comments below!

More grammar “rules” that were meant to be broken

(I seem to be very rules-adverse lately. Check out my previous post, Breaking grammatical rules–why not?)

Both my husbanddog with sign and my students have had occasion to think about grammatical rules lately. My students are revising projects to hand in for a grade; my husband is completing a dissertation. Both types of writing place value on correct grammar, but there are some things you just don’t need to stress over.

For years, I was under the impression that there was a rule against ending a sentence with a preposition. I’ve since learned that it is more a matter of style, going back to an attempt to Latin-ize everything back in the 17th and 18th centuries.

In fact, according to Oxford Dictionaries, there are times that an ending preposition is completely appropriate:

  • passive structures (she enjoys being fussed over)
  • relative clauses (they must be convinced of the commitment that they are taking on)
  • infinitive structures (Tom had no one to play with)
  • questions beginning with who, where, what, etc. (what music are you interested in?)


Another “rule” concerns the split infinitive. The famous Star Trek example (“To boldly go where no man has gone before”) is arguably weakened when the adverb gets moved (“To go boldly where no man has gone before”). Once again, the attempt to turn English into Latin is at the heart of this rule.

There are times when a split infinitive avoids ambiguity. In the sentence. As Oxford Dictionaries points out:

The sentence 
You really have to watch him. [i.e. ‘It’s important that you watch him’]
doesn’t have quite the same meaning as:
You have to really watch him. [i.e. ‘You have to watch him very closely’].


Because split infinitives tend to tick people off, experts recommend avoiding the split infinitive in professional writing, including job application letters.

But don’t let anyone tell you that there is a “rule” against split infinitives or ending a sentence with a preposition. Rules like that are meant to thoroughly be broken…er, you know what I am getting at.

Another entertaining read about grammar “rules” is available at