#44: Give words power.

"The more words are used to express an idea, the less powerful they become."
--Hazrat Inayat Khan

A wise woman once told me that, when communicating with a man, it's best to express just one idea at a time. Any other points you make will be forgotten.

Memorable content is concise. It conveys a message without being didactic or haranguing the reader. It expresses one idea succinctly, so that idea has power.

Writing tight is no easy task. You have to cull superfluous words, then smooth out the rest. This gets easier with practice.

For The Year in Infrastructure, I read the 2,000-word documents submitted by the engineering teams and wrote 125-word profiles for each project. Each profile is a mini case study: challenge, solution, result.

The yearbook is a powerful marketing tool because it makes one idea clear: Bentley technology delivers a return on investment for intrastructure projects.

As the writer, I am confident that any man (or woman) who reads the yearbook will get that message.

#43: Have a diverse specialty.

Freelance newbies often take any and all assignments -- for cash flow and a portfolio. But to get from novice to expert status in this competitive market, you have to select projects in the areas where you excel.

For me, that has meant graduating from writing small-business brochures and newsletters (the meat and potatoes of marketing), to journalism with a marketing twist. As an expert storyteller, I help clients tell compelling true stories that illustrate their brand benefits.

To further narrow the funnel, excellent writers need a market niche where their subject matter knowledge can save time and shorten review-and-revision cycles. For most of my career, I've worked with engineers, architects and contractors to illustrate their value proposition in the markets they serve.

The sweet spot is where a writer's skill set uniquely qualifies him/her for a project that few others could do. It's the intersection of ability, experience and expertise that enables a writer to deliver an assignment in the time-quality-budget triangle.

I discovered that sweet spot in engineering technology for the A/E/C industry. I first started writing about technology applications for infrastructure in 1989 and have built a strong portfolio. (See the Content by Cathy sidebar.). Since then, I've diversified my specialty to write about applied technology that delivers business benefits in other industries.

When I'm tempted to take an assignment outside my area of expertise, I stop and consder the client's needs. I routinely refer people to other experts -- usually my colleagues in IABC, ASJA and FPRA.

In the end, it's about getting the client's story out in the best way possible. For corporate marketing professionals working for their demanding business units, this may mean making the case for outsourcing special projects. But honing your own writing skills and developing a diverse specialty can also secure you a position as the go-to resource in your own organization.

 

#42: Work as a team.

I do not speak Chinese. And Google Translate is good, but not that good.

For detailed answers to specific questions about environmentally friendly hydroelectric power generation in China, I needed a translator. My client's marketing manager in China translated the questions into Chinese, sent them to people in the know at HydroChina Huadong Engineering Corp., then translated their responses back into English.

That is going above and beyond, if you ask me.

The insights into their design strategies and engineering information management made for a fascinating case study. Without that first-hand perspective, the story would have been sketchy indeed.

For another story, the client's customer was the team player. I emailed questions about the ROI for a software integration project, and he forwarded them to his team for input. The follow-up phone interview delved into more detail than would otherwise have been possible.

Happy customers make great stories.

I work alone, mostly. But working as a team sometimes produces better writing.

#41: You had me at hello.

A good lead paragraph is like a finger snap in the face. It gets your attention, beckoning you into the story with a come-hither look at a few fascinating facts.

A bad lead paragraph is also like a finger snap in the face. It's annoying, evoking a talk-to-the-hand sort of gesture that says no one is listening to this bunk.

If you write a bad lead, don't bother writing the rest of the story. No one will read it.

If you write a good lead, you set the bar. Now your job is to keep up the intrigue, pull your audience along by the nose like the whiff of Cinnabons wafting through an airport terminal.

One of my favorite leads lately is visual:

"If an angry 14,000-pound elephant rammed his head against a 40-foot artificial tree, how much force would he exert on the structure? Of the 98 loading combinations analyzed during the design of shade structures for the Toledo Zoo elephant exhibit, that particular criteria was not found in the ASCE 7 Standard for Minimum Design Loads for Buildings and Other Structures."

"Man-Made Shade Trees to Weather Elements and Elephants," Sun-e News, March 25, 2011

Now I know you are terribly intrigued by this engineering conundrum and will click through to read the full story. No worries, I'll wait for you to get back.

Ok, so here's the challege: Post your favorite lead paragraph here, and we'll talk about what makes it great. Looking forward to it!

#40: Rewrite.

Never thought I'd say it. It's my not-so-secret bugaboo. But there comes a time to admit: The client is right. And if she wants a rewrite, I'll do it.

I recently wrote a feature story about a topic I had some knowledge of, but I did extensive background research to get up to speed on current practices. I talked to a few people who kindly gave interviews with no expectation of reward (other than a mention in a prestigious newspaper).

One interview was so compelling, I dedicated a sidebar to the subject and also quoted the source in the main story.  

Writing this story was tough. Too much information. Too many angles on the topic. Too many on-point quotes. The lead alone took the better part of a day. That should have been the tell-tale sign.

I tried to wrap too many ideas into a 3-paragraph round-up lead that just did not work. But I was hung up on it, so I went with it. Each example I used set the stage for a subsequent section of the story.

And the client did not like it. Not. One. Bit.

And that terrific story-in-a-story that made the sidebar? Gone. Along with the source. I forgot the basic rules of the assignment and used a source that was not on the list. My mistake.

So I took the VERY red-lined draft that was returned to me and I rewrote the lead. I rewrote the sidebar. And I rewrote a fair amount of stuff in between.

I. Don't. Do. Rewrites.

Haven't needed to. Haven't been asked (often). And if I was asked in some distant past, I don't work for that person anymore.

But I have gained some perspective in recent years. And I'm here to tell you. The client (yes, you!) is right (this time).

#39: Sleep on it.

Ever finish a project in a state of high anxiety? I hate it when that happens. It's never a good sign. I have to fight the impulse to get the thing off my desk and alleviate the angst.

Instead of turning in an aggravating assignment as soon as it's done, I set it aside and do something else--preferably get a good night's rest. The next day, with a fresh (and rational) perspective, I reread and rewrite.

Granted, the occasional story needs to be propped up like Bernie Lomax. But more often than not, a quick edit can reanimate a bad day's work. The piece may not sing, but at least it's talking. Then off it goes.

#38: Get your geek on.

Call it fortuitous, or perhaps synchronous. About 2 weeks ago I emailed a contact whom I hadn't heard from in nearly a year. At that moment, she was talking to an editor about an article on a ridiculously tight deadline. Seeing my email, she referred me for the job. Sweet.

By the end of the day, I had outlined a 3,000-word article about cloud computing. It was due in 3 days.

I knew next to nothing about cloud computing.

How was this going to be possible? First, we had an article by a CIO to use as background. Turns out, he was willing to team with a ghostwriter. I examined the first-person narrative about how his company implementd cloud computing for building information modeling (BIM), and researched the concepts and enabling technologies.Then I kicked out an outline for the editor and author to approve.

Both gave me the go-ahead to draft the article for review, assuming the author would add content later. Over the next two days, I wrote a new introduction, reorganized the source material, rewrote each section in a style appropriate for an educational piece, amplified several sections with info from authoritative sources (with citations), extracted all the company-specific details and crafted a case study sidebar, and wrote a brief conclusion about the future of the tech based on what I'd learned.

To my amazement and the editor's delight, the draft sailed through a weekend review with only minor tweaks, and it published on deadline--exactly one week from the day I emailed my contact.

I attribute the success of this assignment to being just nerdy enough to get excited about the techie subject. Basically, I got paid to learn more. Now I have a nice portfolio piece, a folder full of useful bookmarks, and two new contacts who like my work. Cool beans.

Oh, lest I forget one crucial detail: The article's sponsor was also a client of mine. Happiness all around.

 

Tip #38: Be specific.

When I was 23, I worked on a nuclear power plant construction site as an assistant to the office engineer. Once a week I donned a hardhat and accompanied the guy who took progress photos. I wrote pithy captions using big numbers, like how many tons of rebar were laid or how many days the concrete cured.

These were details that put the project in perspective for me, because from inside my construction trailer, I hadn't a clue about the scope of work on the monolithic reactor being erected. All I knew was the fast-track design engineers were pretty cute and liked to party after hours.

But back to the point. Details make a story real. For engineers and architects, that means dimensions, quantities, percentages, time frames and costs. Efficiency and productivity. And results. It also means acronyms (spelled out on first mention), technical terms and phrases used correctly.

So even though it slows writing down to the speed of a dial-up Internet connection, I look up and confirm every detail I use to breathe life into case studies that would otherwise be in danger of tragically flat-lining.

Tip #37: Be versatile.

In the 6 months since I last expounded on how to write, I have been cranking out copy on fascinating subjects relating to technology, to wit:

• the broken windows theory of policing
• sustainable IT services and solutions
• a culture of risk management
• online, real-time floor plan management
• 15+ case studies on global infrastructure

I've been bopping from short and snappy web copy, to meticulously footnoted white papers, to persuasive marketing collateral, to engaging user stories with heartfelt testimonial quotes, to feature-length articles that have been fact checked and vetted by the customer's customers.

After such varied work, I am compelled to pinpoint how, exactly, my writing has improved. The one thing I can say with certainty is that I have been forced to vary my style--losing my own voice so that I can speak for the experts. Seeing products and services from the customer's perspective, and anticipating and answering their questions (especially WIIFM--always WIIFM.)

Some projects have been more successful that others. The ones that represent my best work, I think, resulted from really good interviews. Because when it comes down to it, I don't know diddley squat about security, IT, risk, floorplans or infrastructure. I'm a writer. But my job is ask the right questions, find out what the real story is, and tell it better than anyone.

Tip #36: K.I.S.S.

I have a client whose enterprise-level SaaS products have transformed the way their customers do business. But when we write case studies, we don't try to tell the whole story. We pick one measurable result and explain how it happened. 

This week, I wrote about a new mobile app that will help one customer save six figures in 2010. Though I was tempted to expound on other numerous benefits of the software suite, this single savings said enough.

Through a series of case studies spanning more than five years—about customers of all sizes and in a variety of industries—we've put together a puzzle that shows the Big Picture. This series of short stories has much greater impact than a few weighty tomes. 

When tempted to veer off course into a complex maze of features and benefits, focus on one thing and K.I.S.S.