By Jack Ganssle

Talking to Management

Published 3/26/2006

Ward Silver, frequent correspondent and author of "Ham Radio for Dummies," and "Two-Way Radios & Scanners for Dummies" recently wrote with his thoughts on communicating with management:

<i>One bit of wisdom that I rarely hear on the engineering side of the fence but did wonders for my relationship with management is about what they want to know from engineers. They rarely want to hear technical tales - "Well, the framistan turns out to be undersized but if we make it out of unobtanium and secure it with Thelman wire..." That's for project lead engineers to worry about, not management.

Management cares about three things: schedule, resources, and risk. I changed all my reports to this format and starting communicating:

1) Are we on schedule? If not, what tasks are not and by how much?
2) Do we have the resources we need to stay on schedule. If not, what is needed and at what cost?
3) What are the significant risks to the project schedule or technical success?

Technical stuff is only a fraction of this information. This is what managers want to know and they don't want to have to winnow it out of a heap of technical chaff about which they can do nothing.

I wish someone had told me about this at the beginning of my career! </i>

Amen to that, Ward! While I hear a steady stream of complaints about pointy haired bosses, more than a few managers write despairingly of engineers who babble on in the incomprehensible argot of engineering, a language that's as foreign as Esperanto to most listeners.

Engineers manage binary values and Verilog equations. Managers manage money and time, risks and resources, customers and other stakeholders. Problems with a function's reentrancy may be real and severe, mean nothing to those higher in the company's hierarchy, and are sure to produce glazed eyes.

This is the communications age, one that we engineers invented, yet too many of us haven't learned to communicate effectively. Know your audience, and speak using language and concepts that are meaningful and important to them. You wouldn't use differential equations to help the 7 year old with her homework, and probably can't solve a relationship problem by drawing a UML diagram on the handy napkin. (Hmmm, actually there <i>might</i> be some benefit there. Have to try that one!)

We must, as Ward notes, phrase our reports in terms that get the boss's attention, motivates him to act, and that obscures nothing.

I'd add one additional aspect to Ward's thoughts: give the boss options. That's the first rule of boss management. Don't complain about the aperture grommet to the flywheel vacuum gasket; tell the boss the grommet is frimfrazzled but this simple (2 days, no risk) bit of reengineering let's us replace it with a $50 gimcrackery. Or we can replace the whole mess with a 32 cent PIC processor (four weeks, risky as none of the mechanical engineers knows PIC assembly).

Obfuscation, whether in oral and written communications or in coding, is sophomoric. Professionals communicate clearly using a common language to help others understand what may be complex issues.

What do you think? Is clarity important. or is it just fun to speak in computerese and time how long it takes the listener to start snoring?

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: