As I mentioned in the previous post, for anything other than a status report, you can figure that you’ve got a series of “arguments” to make. But you’d better set up some context for them. You can do this with a dedicated slide, but I usually do this with the Title slide. Just start talking your story while the title slide is up.

• SLIDE SAYS: The Economics of Landfill Methane, John Doe, Adeer Engineering

• JOHN DOE SAYS: I want to present to you today our findings on the economical use of landfill methane. We found that it is very market dependent, but that it also depends upon access to a transport network, the efficiency of the collecting and conditioning processes, and the quality of the raw methane itself. It’s a very interesting story.

(It sounds self-serving to say flat out that “It’s a very interesting story,” but you’d be surprised how such a simple statement can color people’s views of what follows. Don’t be bashful.)

Okay, so you’ve got the context set. What now?

Lay out your arguments. They should look something like this:

• Argument 1
  • Slide 1 – Explanation (if required)

Explain the first technical problem and the solution. Use a good multi-colored schematic to talk to. In our example, you might show the flow of methane from the landfill to the user. Or you might have a good schematic of the new methane conditioning process you’ve designed. Aim to make the process clear. Dispense with the numbers for the moment unless they make the process more clear to the non-engineer. Which is seldom.

• Slide 2 – Impact (numerical if possible)

Bring on the numbers once you are sure everyone’s got the process straight. If the first problem is methane transport, you might show methane losses for various transport strategies. If it’s raw methane quality, you might show comparisons of moisture and other contaminant content. Whatever it is, use numbers here.

• Slide 2-1/2 – Conclusion (may be part of impact slide if only a single line)

I’ve gotta’ discuss conclusions a bit here.

There is no more attractive target to a hostile audience than an overblown conclusions chart. We have a tendency to want to give our conclusions a marquee presence. Don’t. Make the conclusion part of the Impact slide if it fits. Set it off in some appropriately subtle way. You DON’T need to deliver your conclusions like THIS!!!!!!! A single extra space between lines should do it. Or a different (but low-key) color font if you must. But if they don’t want to agree with you, they are not going to agree with you. Hitting them over the head with a larger font isn’t going to make them agree with you. It just gets their ire up.

If you need to use a separate slide for conclusions, that’s fine. Just keep it simple. And if you intend to stand there and read your conclusions chart to the audience, be sure to hand out the cyanide capsules first so people can check-out when they can’t take it any more. I’ll write more about alternatives to reading your charts to your audience in a later post.

Finally, make your conclusions explicit. I worked with a lawyer one time on some regulatory documents. I did most of the writing because it involved technical arguments. But after I was done, he went through and added a sentence to the end of each of my sections. I would end a section by saying for example that “…the sonic boom’s intensity would be below ambient noise levels outside the restricted area.” And he would add, “Noise levels therefore do not constitute a threshold environmental impact.”

I quickly realized that where I considered each section’s conclusion unavoidable, and left it to the reader to make the final step, he, with perhaps less faith in humanity, made the conclusion explicit each time. It was a good lesson! Don’t trust your audience to go where you did, to come to the conclusion you intended. Many of them may just wish to go where no man has gone before. Even if that’s off the deep end.

So then you just go on to your next argument in the same fashion until you get to the uber-argument. More on that next time.

But before I get to the Content, let me make a request: Please, just totally flush your “Assumptions” chart.

Nothing lands with such a deadening thud in a meeting as an “Assumptions” chart. It goes down early, and it goes down like a dead goose on a mudflat. As engineers, we can’t HELP but want to state our assumptions up front. But the fact is, in the meeting, no one yet gives damn about the assumptions. They haven’t seen the conclusion that they want to disagree with yet.

I’ve always found it better to just get on with what I want to say and get to my conclusions. As people see where the arguments are headed, they start filling their sandbags, trying to stop the flood of argument. And the first sand into their shovels is the questioning of assumptions. NOW those assumptions of yours are relevant! Not only that, but NOW the audience is engaged because they had to THINK about what you were presenting, what THEIR assumption might be. This makes for a more lively and impactful delivery. That’s a positive impact if you can spout your assumptions when they are questioned, and defend them. And a pretty negative impact if you fumble the questioning. So it’s yours to make or break. But no one will accuse you of being boring.

A good presenter – or writer for that matter – doesn’t harness the audience and drag them along. You get their little cogs and gears spinning and they self-propel themselves behind you. By plopping the assumptions down in front of your audience first thing, you pretty much shut down their whole gear-crunching, thought-spewing intellects until your conclusions chart. And then you have go slavishly flip back through your charts (at their command) to show your assumptions anyway.

It’s better to keep hold of the meeting at that point. If there is no “Assumptions” chart, they have to ask YOU about assumptions, usually one at a time. You maintain control of the meeting because you can spin out the assumptions and counter-argue at the same time. You remain the authority. You won’t win every time, of course. But your chances are much better if you keep control.

So now I have to post this Dilbert cartoon that tickled me.

So start by making clear to yourself what exactly you are trying to do with your words, and what is the environment (audience) in which those words must perform? Some answers may be:

• “I’m trying to spark interest in our product by reporting on hybrid ground source heat pump performance to a conference of other engineers.”

• “I’m trying to solicit comments from community groups at an environmental review hearing.”

• “I’m trying to convince regulators to adopt rule revisions for commercial space activities.”

• “I’m trying to convince management to continue funding the research I’m doing in Fog Computing.” (For the technorati, Fog Computing is something I envisioned as even better that Cloud Computing. I don’t ever want to trust to the Cloud, for one thing. (See “Lost in the Cloud”). And for another thing, use of the Fog – a closer in and more controlled Cloud – makes so much more sense. You buy one copy of an app for your company, and run it in the Fog. You are spared the storminess of the Cloud, and your IT is greatly simplified. I came up with this terminology on my own, but have now found it already being implemented, for example at Content Circles. Oh well.)

Now your requirements can start taking form.

Basically you have two sets of requirements – Form and Content.

Form means making a decision about what level you are writing on. By level, I mean technical education level. Getting technical with investors is generally a waste of breath for example. But resorting to non-technical summaries in a room full of engineers will breed suspicion, and no one’s going to buy you a beer afterwards. Choosing form is a bit of a judgment call. But you’re learning by doing, remember? Make note of the extent of responses you get – the degree of audience engagement, the number of questions, the queue of people standing in line after you speak – and consciously assess afterwards how well your form served the function.

Content means making a decision on what exactly to include. If you are writing a status report, the content will consist of the tasks you are doing or managing, and there won’t be much leeway. If you are advocating for or against something, content will be a series of arguments. Content is going to take a posting of its own, so I’ll post that later.

Now, have you ever been to a writing class where they describe a hundred rules, techniques, principles, skills, and sundry grammatical flotsam and jetsam, but never give you the chance to practice any of them, to “push the button?” I feel like saying, “Hey, we’re engineers. We learn by doing, remember?”

I’m starting this blog to create a place where engineers can share what works and what doesn’t work in their communications. I hope to post examples and exercises so engineers can sharpen their communications skills with practice, not just preaching.

I admit that I am somewhat inspired by Samuel Florman’s “The Introspective Engineer.” Florman wonders why we have so few engineers in leadership positions in this country. The simple answer is heritage. Did you know that in much of Continental Europe at the start of the Industrial Revolution, engineers were groomed for political leadership? They were seldom termed “engineers,” but had multiple titles such as “engineer, physicist, and philospher.” Since the 1800′s, Continental Europe, and especially France, expected its leaders to come from the polytecnic institute. The idea was that technology is a driving social force, and if you couldn’t understand technology, how could you expect to lead a country?

Not so in England. In England, where America derived most of its heritage, engineers were respected tinkerers, the guys in the garage making wonderful things happen for the rest of society to take advantage of. The political leaders – the barristers, lords, and professional politicians – took on the awesome responsibility to see that the technologies were applied in such a way as to most improve society, whatever that meant to them. So here we are in America today.

It’s no secret that in most organizations the individuals who communicate best are the ones most often given the spotlight, the chance to shine. I would like to see the people with the best understanding of the technologies and systems – the engineers – take back their share of the spotlight.

I will post exercises and discussions as time allows. (I do have  a day job.) And this blog will be growing by accretion more than by design. But I intend to keep it useful and above all practical. So let’s just do this. Feel free to send me samples and discussion, comments, thoughts, and even topics you would like to see exercises for. Or better yet, send me the exercises. I’ll post them for everyone.

Paul