The news wasn’t good, but bad news doesn’t get any better with age. I presented our project manager with the facts:
“We can’t complete our development in time based on these ridiculous estimates” I said bluntly.
“Everyone has been behind schedule, just like we said last week. There is no way that our team is going to make the current deadline. “
After the meeting, the best manager I’ve ever had, Moe Nwankwo, told me he appreciated that I had been frank – and then gave me some constructive criticism and advice I’ll never forget:
“Sid, you can’t talk to project managers like that. You can talk to me and developers that way – but you need to speak to our PM in terms she can understand and act on.”
I did not fully absorb what he meant at the time, but as I grew as a software engineer I am amazed at how poorly I communicated my concerns in the past. I have since learned the secret of communicating effectively with my non-technical managers.
How To Speak The Language of Non-Technical Managers
- Present the root cause of the problem, not just a symptom.
- If possible, present a solution to the problem.
- In English, please.
That’s it. Easy, right?
Engineers and Verbal Shorthand
If the solution is so simple, why did it take me so long to figure it out?
As engineers, we often use verbal short hand to present a problem.
For example, if I tell another software engineer “I can’t work like this, Eclipse is chewing up all the RAM on my box” they immediately know what I’m talking about.
Allow me to walk through another software engineer’s thought process when they hear me say that:
- Eclipse is a development environment used to develop software.
- The problem of it utilizing lots of RAM is fairly common.
- This issue could be too many plugins, a memory leak, or perhaps a lack of RAM – a hardware problem.
- At this point, based on the plugins and what he is using for development, he may simply need more RAM.
If that sounds like Greek to you don’t worry – understanding all of it isn’t the point.
The point is that by simply saying Eclipse is “chewing up all the RAM on my box” I have conveyed a large amount of information to any engineer familiar with the domain I work in.
We don’t explain what the root cause is because we don’t want to insult each others’ intelligence.
This is the same reason we don’t lay out all the details for our managers – out of respect for their intelligence, and perhaps an expectation that they should understand what we’re talking about.
The bad news though is for many non-technical managers, presenting it that way may not lead to a resolution.
Speaking The Language of Non-Technical Managers – An Example
Bad
“I can’t work like this, Eclipse keeps chewing up all my RAM.”
Complaining that Eclipse is chewing up my RAM is not going to get me anywhere, because my manager does not understand what that means. They may be wondering
- What is Eclipse?
- What is it used for?
- How is it “chewing up RAM” and what does that mean?
Better
“I can’t work like this. My computer is unable to run the applications, such as Eclipse, that I need in order to develop our software. The reason for this issue is I do not have enough RAM.”
Managers can’t act on the first one – but the second statement is much easier to deal with – and you’ve explained why it is important to the project/business (“I need these applications in order to develop our software”). It is even better, though, if you are able to present a solution to the problem.
Best
“I can’t work like this. My computer is unable to run the applications, such as Eclipse, that I need in order to develop our software. The reason for this issue is I do not have enough RAM. To resolve this I need more RAM in my computer or a new, better computer. I called Gary, and if you sign this form they can upgrade my computer.”
Of course, depending on the bureaucracy in your organization, your boss may not want you calling your help desk and requesting an upgrade yourself – do whatever is appropriate.
Rewind – Trying It Again
If I could go back in time, I’m sure I would do things differently. Perhaps I would have instead told my project manager something like this:
“We can’t complete our development in time, because everyone has been behind schedule, just like we said last week.
The reason for this is the unrealistic number of features in the time allotted. Based on our past performance, we know that if we don’t cut features now, we will not make the deadline.
To resolve the issue we need to revise the schedule or cut features.”
Is this perfect? Maybe not – but I hope that this example gets the point across, that you need to speak in terms people can understand.
In my experience, if the concerns are escalated high enough and with these kinds of reasons and resolutions, you stand a much better chance of success.
While the examples I have provided are specific to software engineering, I have a hunch the lesson here applies across disciplines.
It’s a good idea to inform your managers of the symptoms, but it’s better if you can pinpoint the actual problem, and if possible, a solution.
It’s not enough to just be accurate – we have to know our audience as well.