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?
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.
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.
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.
- 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.
- Use language and visuals with precision. Don’t use “weasel words” or play with statistics to make things seem better than they are.
- Prefer simple, direct expression of ideas. Avoid “legalese” or Byzantine language that hides the true message.
- 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.
- Observe copyright laws & avoid plagiarism. A no-brainer, I think. Litigation is no fun.
- Respect your audience’s privacy. Don’t spam them or sell their names to spammers.
Anything else? Please add a comment!
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:
- Summary and Results of Activities (past, present)
- Future Activities
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.
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!
(I seem to be very rules-adverse lately. Check out my previous post, Breaking grammatical rules–why not?)
Both my husband 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:
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 grammarphobia.com