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:
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!
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 might 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?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. Join him to learn how to develop better firmware faster in Dallas and Denver April 26. Contact him at . His website is .
I totally agree that management usually ONLY care about: schedule, resources, and risk.If that would be the only time one has to deal with managers it would be fine.But NO. One example is when they specify a communication protocol OSI in micro proc. A student once implemented it according to spec. BUT memory speed, with all the copy of data didnt work. What could be said to the management? WOPS!One has to be careful and distinguish between what they say and what they want.
PS: Always remember that if it doesnt work, even if the specification is flawed. your job is on the line ….. Always.
– Martin Lundström
Management is somehow… in an “Ivory Tower”.
aloof from the cares and practicalities of daily life. That’s how we use the idiom today: someone living in an ivory tower is—by accident or design—sheltered from the realities of existence, out of touch with the real world.
– Steve King
Now that the conversation is a bit less political; I will weigh in.
1. Communications go both ways. Engineers need to be empathetic to managers, and managers need to be empathetic to engineers.
2. In general, engineers have never been managers, but most likely managers have been engineers.
3. It is important to know your audience. Engineers audience is/are; each other + managers. Managers audience is/are; upper-level managers/execs + each other + engineers.
4. Run your communications and relationships based on trust.
5. The only bad questions are the unasked and the unanswered questions.
6. In general, plain English does wonders.
7. Most important, accept responsibility and demand accountability!
– Ken Wada
Response to Ken Wada:
Notes from Aerospace and Telescope reality:
8. Engineers deal with Customers and Vendors/Suppliers.
9. Sometimes schedule cannot be met because the parts are delayed, or needed test equipment is not available.
10. The part is delayed because the customer was slow in getting the specification and requirements to the Engineer.
11. SW tools are not complete and time is “wasted” talking to the SW manufacturer to solve SW bugs and installation glitches.
12. Harware & SW intergation issues appear because the sw that the manager ordered is not “fully” compatible with the HW interface.
13. The customer calls back with a “small” modification that takes weeks to implement but still want the schedule to be met.
14. This small modification adds months to the schedule because the SW has to be seriously modified and TESTED.
15. Requirements are being changed as the SW is being written.
16. Executives want repeat business from the customer and therfore don't care about the technical issues — just get it done so my picture can appear in business weekly as a “Can Do Guy”.
Recall that for every change you make, a test has to be run to verify the change was implemented correctly.
Managers and Executives think only in terms of “design”, they tend usually not to think in terms of implementation time, test time, debug time, and retest time.
The above does not happen at my place of employment, but I have worked in a compnay where this did. I don't work there anymore.
– Steve King
Engineers have to consider that their jobs and pay-hikes (rare in these times of market uncertainty) are under the control of their manager so it helps if we (I am an Engr.) take responsibility of ensuring that our Managers understand what we are doing and saying. 🙂
– Ani Phatak
There are as many kinds of managers as there are trees. I had one schmuck manager who refused to let me do anything he did not understand himself. He did care about the details and did not understand them. Example of his level: When we moved to a different location, I put the server in the front seat of my truck and hand carried it over to spare it the tender mercies of the moron movers. I had just unplugged it, moved it, and reconnected the cables. A month later, I found out I was the network manager because I had moved the server and was thus competent because I had installed it.
– Tom Sullivan
I had a VP once (who had been an engineer) who took the time to explain to me how to talk to managers. “We don't care about the technical details,” he said. “We want to know what are our options, what will they cost, and what are the risks. Now, I realize you probably already know the right answer, but you don't need to come in and start defending it right away. Tell me what you think we should do, and if I need more information I'll ask for it. But in most cases I'll just take your word for it.”
He also pointed out one of the greatest benefits of speaking managerese: it makes meetings much shorteer!
– Dave Hinerman
The theme of the topic is on target, but it presupposes that management works on logic akin to that used by engineers. Having straddled both sides of the fence for more than a few years, I can attest to a very separate reality.
Management far too often lives in a fantasy land illustrated by the latest management consultant book-of-the-month club selection. That, or whatever wisdom oracles such as Gartner are willing to spit out this particular day.
More to the point, they typically don't think to reality check, critique, verify or validate what gets presented to them. If a consultant were to tell many of them that the sun is green and made of rubber, they'd buy it (especially if they paid a lot for the consultant's advice).
Dropping back from the rant mode, a little reality is in order. True stories:
A company outsorced its shipping facilities a number of years ago. No risk analysis was done, including of what might happen if the service provider didn't ship their products on schedule. After not a little damage, including the loss of the staff that knew how to get things done, the company brought the function back inside. A few years ago, a new management team contemplated the same move. I am not making this up. Fortunately for the company, there was enough historical memory to pound in the lesson from years prior. Details? Who needs details? Just show me the bottom line.
A friend provides IT services for a large company that has cut staffing because Gartner has published that you need one IT person per 100-or-so client workstations. Doesn't matter that my friend support two sites about 20 miles apart. Doesn't matter that in addition to workstations he supports servers and all the others frimfrazzledy stuff that is needed to make the magic work. Etc. Management heard The Truth from the Mouth of Gartner: Gartner said it, I believe it, and that settles it.
Etc. Who needs V&V?
Jack, you're right about boss management, and it's the only way out of this mess. But it's easier said than done. The devil is almost never in the abstractions. Minimally, bosses need to be educated in some continuous fashion. I often copy mine on copies of articles that deal with technical issues, highlighting for instance sections that point out riosks associable risks and benefits to an approach. That way, but the time is't proposal and/oe explanantion and/or defensive maneuver time, I can cite information that I provided during a lot less volatile period.
I'm fortunate, though, in that I have bosses who will listen (and who are/were engineers or technologists). If you have a boss who doesn't have five minuutes a month to even begin to care about what it is you think about when you're working, you've got the wrong boss.
– Rick Schrenker
Perhaps it might be worthwhile to ask the manager, “How much detail do you want?” when a question comes up about shcedule slips or why we can't implement the customer's latest request. If they just want a bottom-line answer, then we might say, “Dave's computer died, and we can't get a replacement until xxxx.”
If they want more detail, then it can be supplied. I try to send written reports (email), as this allows me to speak in detail, but the recipient can skim to his or her level of understanding. It also prevents the “You never told me” syndrome, as there have been several times when I have been able to refer to previously sent emails as confirmation that I DID inform them of a particular issue.
– Dave Telling
The key thing I learnt, when I started dealing with management is this: It's all about the money. Now this appeared unseemly to me when I first came up against the attitude but I realise now that management is, mostly, right.
It doesn't matter about the engineering challenge, it most certainly doesn't matter about engineering elegance or any other measure of “correctness” beyond getting our product sold. If the gadget is selling it pays all our salaries and might just allow us to do things better next time… If the money comes in. Time is money so manangement is very rightly interested in schedule.
I also second Jack's point about giving the boss options. I once had a boss who would say, “Bring me solutions, not problems.” That phrase used to irritate me intensely until I realised that it meant I got to pick the solutions I had to implement later.
On a lighter note, I don't want my management too interested in the engineering aspects of what I do. They might see the pleasure I take in the engineering and work me harder or pay me less.
– Richard Thompson
How about we make a list of the types of managers we commonly see:
1) The technophobic manager. Typically near retirement, last programmed a computer in Cobol in the punched tape days.
1a) The public relations manager. When there's a yellow ribbon to be cut, he'll be holding the giant scissors in front of the TV camera. A master of public speaking – aspires to become director of a facility.
2) The techno obsessive manager. Understands all the technical issues of the project and is not scared of any technical lingo thrown up his way. Obsessed with the technical aspect of a project. Often does development on the side.
3) The secretarial manager. Primarily concerns himself with schedules, resources and budgets. Could care less about technical details or what makes the product work. Often does what a secretary could do.
4) The status reports manager. Wants every activity accounted for in weekly, biweekly and monthly reports. Every t crossed, and i dotted. These are the same people who get obessive about status meetings, timesheets and time charge codes.
5) The micromanager. Constantly watching over your shoulder, wants to understand every single thing your doing, inserting “helpful” advice at many steps. A need to understand everything.
6) The employee performance manager. Concerns himself, with employee performance reviews. You don't abuse flextime under the watch of this manager. A shark for any areas of improvement, he knows when you've been sleeping and knows when you're awake….
7) The conductor manager. The guy who is also the principal architect, comes up with the infrastructure ideas. Similar to the conductor of the orchestra who leads. Savvy on what exactly needs to be done and the best way of doing it. Leaves the details to those who play the instruments. Keeps work INTERESTING for all his workers.
Honestly, I have seen them all, but IMHO the best manager is one who has the incredible insight to come up with the best way of doing something based on extensive technical experience. I have found this type of manager (#7) best able to instill synergy into a team, and that, is probably one of the most important things a good manager can accomplish.
We engineers work best when we're motivated. Manager's job is to keep us motivated.
We've all seen a team with synergy and wished we were on it. Perhaps we have been on such a team in the past and we all wish the project was longer.
– Tiger Joe Sallmen
I think the primary job of a manager is not strategic thinking but understanding the techy explanations of engineers' and translate/transform that into a management report/idea.
But, if the engineers know in what detail/depth to give to their managers, thats good. After they will soon be Managers..!!
– V.Satheesh Kumar
Is clarity important?
1. Tech Talk AND Concept talk is important.
Concept talk. It's an acquired skill that many engineers need to master. Analogies do wonders for those
As a brief aside, there is something to be said for integrating upper management 'cares' such as monetary cost, resources, and risk into ones engineering decision making. Nearly all engineers are in their chosen profession because they think it is, in a word, cool. But what is clever or interesting to an engineer does not always contribute to the so called 'bottom line' of a project.
2. Talking clearly. It makes for a harmonious work environment.
It takes a good engineer to master the science of Discrete Time Fourier Transforms, Priority Inversion, and the like. But it takes a great engineer to give 'bottom line meaning' to the said concepts. By communicating clearly, one can filter out the spurious signals and, quite happily, give management what they want to know. More often than not it will be appreciated in that people will want to work with the person that gets to the point.
– Bryan Fishell