A Software Engineer’s Guide To Speaking With Non-Technical Managers

Book Cover How ToThe 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 their deliverables based on the current deadline.  Our development and productivity is only going to get worse the more we are rushed.”

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

  1. Present the root cause of the problem, not just a symptom.
  2. If possible, present a solution to the problem.
  3. In English, please.

That’s it.  Easy, right?

Engineers and Verbal Shorthand

People Talking Communicating BalloonsIf 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, it sucks” 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.  The tone of Sid’s voice gives away his frustration.  Since Sid has a fair amount of experience with Eclipse, he has likely tried to troubleshoot it to see if he can resolve the issue and get the memory usage down.  At this point he may simply need a more powerful machine, and additional RAM may be the answer.

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, it sucks” 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 likely won’t lead to a resolution, because it sounds like Greek to them as well.

Speaking The Language of Non-Technical Managers – An Example

Bad

“I can’t work like this, Eclipse keeps chewing up all my RAM.  It sucks.”

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?  What sucks? A good manager will follow up with these questions and (hopefully) get to the root of the issue.

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 and I’ll be more efficient immediately.”

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

People Meeting Bored Pen Explain Coffee CupsIf 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 the estimates were unrealistic to begin with.  The reason for this is because our users don’t know how long development takes.  To resolve this issue, either an engineer from our team or our manager needs to be present to help create a realistic schedule.

For our current status, 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.

Our development and productivity is only going to get worse the more we are rushed.  The reason for this is we will be forced to cut corners when our schedule is tight, and we are not able to do adequate amounts of user testing. When this happens we are sure to miss bugs.   These issues will cause further losses in productivity as we will have to go back after the fact to fix them, which will impact the schedule for our new projects.  To resolve this issue we should constrain our development to a reasonable amount of new functionality being developed, so we keep time for testing in our schedule.”

Is this perfect? Maybe not – but it sure looks like an improvement to me.  Of course your project manager may throw your concerns out the window.  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.

Mixx Button

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.

What are your thoughts?  How else can we improve communication between managers and employees?  Am I totally off base here?  

Update:  Check out Larry Kyrala’s response, which points challenges the assumption that a non-technical* manager can be an effective manager of a technology group with the right communication.

Enjoy this article? Share it with your friends with this short link: http://tr.im/managerspeak

Get On The List and Get Your Free Course and Ebook!

Personal Development 101 Cover
  • Your free personal development course, Personal Development 101
  • Instant updates when new articles get published
  • Your free copy of The Little Book Of Big Motivational Quotes

Enter Your Email Address Now:


Did you know ... this list of articles is custom generated for you? If you enjoyed this article, you may enjoy these similar articles:

  1. Speaking in Public: A Step-By-Step Guide to Overcome Public Speaking Anxiety
Please review the Comment Policy.
  • Sid,

    I feel your pain. I am a project manager, and if you think explaining this stuff to them is tough, try explaining things to a client. Bridging that gap has become the focus of my job at times. It is not even that people don't understand what Im saying anymore. It's more, at times, they pretend they do, and refuse to listen to our suggestions. Like, 'hey, if you do that, you are going to have problems down the road'. And they respond 'Yeah, but I like it.' Ugggh!!

    Thanks for the reminder...I could always use some touch ups on my communication!
  • Hi Peter,
    Thanks for your perspective =). I think it was difficult at first for me
    because I treat everyone as an equal - but in the case of non-technical
    managers, clients, etc, it's not their job to know all the technical
    details.

    Still, you're right - the worst is when people don't understand but act like
    they do, and then just brush it off - not realizing the repercussions of
    their decisions. I'm sure I've been guilty of it in the past as well =)
  • Verbal and non-verbal communications are skills that should not be undervalued. As you are learning, even techies need to be able to communicate more efficiently with the less knowledgeable, who as this was the case, turn out to be your boss.
  • Sid, i can feel the pain....
    I can share even more ;)
    It's good how you identified the problem - speaking the right language. You do not want to make a point you are right and your manager is wrong. You want to make a point the project is behind the schedule. How do you persuade with non tech guy? I liked how you take a stand of presenting a problem at first, then showing how to solve it, preferably in English or any other language the manager understands. Sometimes though plain English is not enough so you need to maneuver. Anyway, telling your manager he is not right is pretty career limiting move and never gets results in solving any problems - that is for sure ;)
  • elango
    hi sid,
    its really very nice and use ful to other. i can feel it very well. keep it up.................
  • Hi Sid, I really like your article, it's very concrete and has some great insights into how we software engineers think. I'd like for that to be the end of the story, plain and simple, but I have a problem with the assumption that non-technical managers can effectively manage a technical group to begin with (http://quietlightfalling.blogspot.com/2009/02/n...). Your article helps our half of the communication problem, but don't let technology managers off the hook so completely just yet.
  • Hi Larry,

    Thank you for your comment, your support - and excellent discussion on your
    blog! I wasn't sure whether to reply there or here - I hope you don't mind
    that I am replying here rather than on your blog.

    I think we are both, in some ways, on the same page here. I don't know if
    it is an effective approach either (non-technical managers managing techies)
    as my primary, direct managers have tended to be technical. However, I
    think we both agree on this point: it's important for technical folks to be
    able to communicate with non-technical people when they come into contact
    with them, particularly in managerial roles.

    I took a read over your article and I think you make some great points. I
    agree that some domain expertise would make a non-technical manager more
    effective, and in some (many?) cases the amount of domain expertise required
    to manage effectively makes a non-technical manager a particularly poor
    choice.

    Often though I think a multi-team initiative is likely to end up with a
    fairly non-technical, but business/process savvy PM. That's the situation I
    was in, and I think it would be exceptionally hard to find an engineer, let
    alone manager, competent enough to make good technical decisions over all
    the moving parts =)

    Thanks for sharing your thoughts - I'm currently replying via email, I'll
    link up your article for readers when I get home =)
  • Thanks Sid. I think the essential issue between a worker and their manager is one of trust. Many times a non-technical manager feels like a non-car person taking their car to the mechanic... it's pretty hard to develop trust when the cost and time estimates are exceeded. Maybe this is because the driver never changed their oil, OR maybe it's because the mechanic is a crook. Trying to figure out which is which isn't easy. I don't think the manager necessarily needs to understand all the "moving parts" -- but they do need to understand the basics in order to be able to trust their team.
  • Pete
    You are 100% correct. I understood what you said immediately as it contained all the information I needed to make an informed opinion.

    And you're certainly correct in the way you spell it out: it will help the non-technical manager understand the issue and [hopefully] kick their ass into gear so that the problems get sorted. From that perspective I don't have an issue with it.

    On the other hand, I see plenty of corporate mail pass through, by managers who are blissfully unaware of "what this thing called electricity is for again?", in language nobody else understands. They use it as an octopus uses an ink cloud to confuse the situation so that they're allowed to get away with stuff. They have -no qualms- about using that kind of language on you and the worst of them cannot be "made to understand" that they're not communicating. Because they don't care to communicate, they only care to dominate.

    You know what the best way to communicate is? This: "“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 their deliverables based on the current deadline. Our development and productivity is only going to get worse the more we are rushed.”"

    When the time comes for mass lay-offs, your managers will have no problems being as blunt and as crass as possible in dumping people out on the street. The first message was clear enough. If they don't understand that much, they shouldn't be there in the first place.
  • Hi Pete,
    Thanks for your comment! I see where you're coming from with regards to
    some managers not looking out for the best interest of their team. In my
    case, I cherry picked a couple of managers I've had that I felt were really
    solid, and genuinely looked out for the well-being of developers ;)

    As you point out though, that doesn't mean all managers are as motivated to
    watch out for their subordinates!
  • Joe Coder
    Frankly, if they don't know what something like RAM is, do they really have any business being a
    software project manager ? Part of being a manager _should_ be being able to relate and
    communicate with those being managed. Too often the workers pay for the inferiority
    of their management.

    I say we bring back manager discipline by public castration. That way, at least they
    can't contaminate the gene pool any more.
  • scrottie
    You're still using the developer's mindset to model the mindset of the manager.

    A manager is not someone who wants to be technical but can't. They're often lawyers, sales people, and, in general, deal makers, and it works for them. Respect that.

    What's the fundamental problem? Is it that managers are stupid, and they make decisions they aren't qualified to make, and need to be handled in such a way that they some how make the same decision that a qualified manager would? Perhaps, but I'm suspicious of the conceit inherent in this. Remember that programmers and management both have a feeling of smug superiority over the other, and that country boys and city boys also both have a feeling that the other one just doesn't "get it".

    If management is unqualified and you try to handle anyone this way, they'll push back. Even a fry cook in a burger joint would if handled this way, and for good reason. They'll push back on principle, out of pride, and instinctively, as a defense against being duped.

    If they're unqualified, their reaction will be one of defensiveness and suspicion:

    You might tell them, "if you hurry this project, it will take longer, and there will be more defects". Your goal is to get this message, unadulterated, into their head. Without the aid of hypnosis, this is impossible. What goes into their head will be "Joe Coder wants more time to do this; he's probably unhappy that he's working an extra hour every day but I wish he would just not complain and work two extra hours every day just for a while until this is done, so I should probably be nice but firm; however, threatening me with more bugs if he has to work sounds like extortion, which I don't mind, but allowing that kind of behavior in front of the other developers would be bad for moral, so I might have to check that, even though I really am a nice and don't like to do those things".

    ... but that's exactly how a qualified manager would interpret that as well! A business person is a con man, and no one knows cons better than a con man. Or a sales man. Or a lawyer.

    There's a game some players on AfterHours LPMud (Multi User Dungeon) would play... when a novice logs in and asks what to do, how to do it, and where to go, some mean older players would send them to the acid swamp where the flesh would bet burned off their bones and they would die. But most players didn't ask for help because of exactly the kind of cynicism this causes. People who make it up through the management ranks probably have learned how to make it on their own, trust their instinct, and second guess advice as well as the motive for advice.

    In my own personal experience, even though they don't show it, management is usually scared as hell, unless they have one heck of a nice golden parachute. The ones with the parachute aren't the ones you're actually dealing with. Getting a middle manager to actually trust you is harder than taming a wild animal.

    This article makes the assumption that managers will show their hand, as technical people tend to do. Not so. A manager won't admit understanding something merely because he does. As a technical person, it's safe to assume that management admits knowing about 10% of what they actually know. Not showing your hand is important

    Suggesting that writing things out in ultra long hand was key made me laugh. Now, management, who knows what's going on even if they won't admit it, is in a position of trying to keep a straight face while you talk to them like a child. And further more, they have to work harder to keep up the illusion of taking cues from you even though it means skimming through these jumbo sized missives you're writing.

    What makes you think that "deadlines written in stone" actually are? Have you seen the terms of the deal? Many are written clauses where they get paid less the later they are. Some deals are breakable after a certain point. But the "written in stone" deadlines are generally fake, concocted by management well before the real "written in stone" deadlines. And management refuses to move those. They're practice deadlines. Dressed rehearsals. Management gets to see how developers react -- threaten to quit, work harder, pull out the stops, or what. They're calling your bluff when you say "we can't get that done". They're bargaining and refusing to back down on the price. And programmers don't even suspect them of this. They take it at face value that any deadline called a hard deadline in fact is. So think back, and how many really important deadlines got missed where the software was eventually delivered and the company got paid? In other cases, especially in startups, it's unknown how much time there is other than that isn't much, or perhaps the founders just don't want their shares diluted, in which case the deadline is effectively "now, or as close as possible". The deadline is a mix of what the company is able to entice the client with, what the client will ultimately put up with, the profit margin, and a computed ROI based on that. It is not a function of how long it takes to write software. Banish that thought from your head.

    I and almost every developer I know have worked harder rather than try to explain. We've all missed the deadline by a month when management refused to move the deadline. We've all worked long days, into the night, and slept in the server room rather than be allowed to meddle even a little bit in business dealings. Some times technical people quit the job, but for the most part, they fall for the con, and the lot of them will, all in all, work much longer hours and much harder. Oh, and they do this trying to prove their intelligence to management, who pretends to not see it.

    By being obstinate, pig headed, willfully uncooperative, and by flaunting their ignorance, they're using a very good strategy.

    Is management actually doing the meddling needed to keep you from refactoring and writing tests? Or are they just making you eat the cost of doing it?

    The premise of this little essay is that often, management is smarter than you think. There are still very bad managers. If they do keep you from doing what is necessary, including using the right tools, changing tack as needed, using the right people for specialized jobs, and so on, or if they misscompute the ROI so badly that the few deals that succeed don't pay for the ones that fail, then they're a bad manager.

    -scott
  • Wow Scott, thank you for your insight and the time you took to reply!
    I read the whole thing. I agree with many of your points, and I think you
    did an effective job of pointing out where our opinions differ. I think
    both of us are coming at this based on the experience we have, and perhaps
    in time I'll find I agree with more of your points and vice versa. For
    example, in some cases our deadlines were hard deadlines given to us based
    on deals that had been made outside the company - the software had to
    accommodate new types of data. Of course, nobody died if this didn't happen
    - but it wasn't always just a date thrown on the wall. I agree with your
    larger point though, that deadlines aren't always as firm as they seem, and
    in some cases may be completely fabricated.

    I do like the point you make that there are still very bad managers out
    there. I think that can't be overstated - sometimes, regardless of what we
    do, we can't everyone and we can't please everyone.

    Thank you again for adding to the discussion and providing such a thoughtful
    response. Sometimes people come here and write personal attacks, which (as
    you can imagine) I don't enjoy. I do enjoy reading well considered
    dissenting opinions though. I very much appreciate it.
  • @Scott: "A manager is not someone who wants to be technical but can't. They're often lawyers, sales people, and, in general, deal makers, and it works for them. Respect that."

    No. No, I don't have to respect that on it's face value any more than they would respect me walking into a court room or a board room and telling them how to run their business without the slightest clue of legal or business matters. Quite frankly this is the arrogant attitude that needs to be changed. We all come to the table with different skills and domains of expertise, and we should be able to work together, but to do that we have to open a dialogue with each other, not simply dictate ignorantly from on high.

    "By being obstinate, pig headed, willfully uncooperative, and by flaunting their ignorance, they're using a very good strategy.. often, management is smarter than you think."

    No, this type of manager just *thinks* they are being smart. Because of their skewed ethics, they believe that their workers would never tell them the truth up front, they are just lazy and exaggerate; they need to be "parented" or "motivated" to do any real work (see my comment on "trust"). In reality they've just made everyone's life (including their own) more difficult. Political manipulation and deception ("slash and burn") can make someone look good at the cost of everyone around them, but is it sustainable? And what are the hidden costs?

    Software engineers usually do what they do because they love to solve problems, but burn-out and dissatisfaction are more than cliches... a whole generation of people gave up big parts of their lives for many things that don't exist anymore by following "wheelers and dealers"... and that generation has directly (or through example) advised nearly everyone they know to get out of IT. ("It's a cost center" "You're a dime a dozen, offshore or Intern will replace you at half the cost" "There's no career path" "You have to choose between career and personal life")

    Does that sound like a healthy industry? Does it sound sustainable? Should it be emulated or admired as a management tactic?
  • LOL public castration!! Ouch!
    Perhaps the dig at managers not knowing RAM was a bit harsh ;). Though I
    *have* met people who were in roles that involved some level of leadership
    over technical folks who didn't know what RAM was (other than it was a
    number, and more of it was better). None of the managers mentioned in the
    anecdote at the beginning of this article match that criteria though ;)
  • Very nice and clear advices for new software engineers. I tweet your post:
    https://twitter.com/gsempe/status/1261599426
  • Nice summary, Sid! The only thing I can think of adding is that sometimes it's a good idea to present MULTIPLE alternatives solutions, and point out which one you think is best (maybe also adding the pros and cons of each alternative). If you only come up with a single solution, this might not be possible/acceptable/appropriate for the manager to act on, for any of a number of reasons.
  • Hi Tony,
    Thanks for your comment. I agree with your insight - presenting more options
    is definitely better!