Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What are some concrete suggestions and techniques for communicating with management?

My premise for this question is that as programmers we think in a much more granular/detail-oriented way than managers. It's not that managers can't think at this level, it's just that their decision making and judgement applies to a different spectrum.

Where the manager may think in terms of "done" / "not done" the developer may think in terms of individual features, test cases, or bugs. Where a manager may be thinking "lots of bugs" / "bug free" a developer may think in terms of a ratio of feature to bugs or feature complexity or test coverage.

share|improve this question

closed as too broad by MichaelT, durron597, Kilian Foth, GlenH7, Snowman Jul 11 '15 at 23:20

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

What do you want to communicate? If there is something specific you want to let them know do so in writing other than a verbal communique. – Fanatic23 Jan 27 '11 at 16:21
up vote 7 down vote accepted

IMO the most important is to try to understand things from their point of view, and justify your opinion accordingly. Managers tend to think along a cost / benefit line, so they are much more easy to convince about e.g. a technical choice or a refactoring if you can argue like "if we choose option A, this means we may need lower investment right now, but over time it is offset by the higher maintenance/development costs. Whereas if we invest into option B, according to my calculations here our initial investment of $x may pay off in about 2 years."

Rands in Repose has a relevant post about this: Management Cheat Sheet.

share|improve this answer

How to Win Friends and Influence People would have some suggestions that I've used with reasonable success at times:

Fundamental Techniques in Handling People

  1. Don't criticize, condemn, or complain.
  2. Give honest and sincere appreciation.
  3. Arouse in the other person an eager want.

Six Ways to Make People Like You

  1. Become genuinely interested in other people.
  2. Smile.
  3. Remember that a person's name is, to him or her, the sweetest and most important sound in any language.
  4. Be a good listener. Encourage others to talk about themselves.
  5. Talk in the terms of the other person's interest.
  6. Make the other person feel important and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

  1. Avoid arguments.
  2. Show respect for the other person's opinions. Never tell someone that he or she is wrong.
  3. If you're wrong, admit it quickly and emphatically.
  4. Begin in a friendly way.
  5. Start with questions to which the other person will answer yes.
  6. Let the other person do the talking.
  7. Let the other person feel the idea is his/hers.
  8. Try honestly to see things from the other person's point of view.
  9. Sympathize with the other person.
  10. Appeal to noble motives.
  11. Dramatize your ideas.
  12. Throw down a challenge; don't talk negatively when a person is absent; talk only about the positive.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

  1. Begin with praise and honest appreciation.
  2. Talk about your own mistakes first.
  3. Call attention to other people's mistakes indirectly.
  4. Ask questions instead of directly giving orders.
  5. Let the other person save face.
  6. Praise every improvement.
  7. Give the other person a fine reputation to live up to.
  8. Encourage them by making their faults seem easy to correct.
  9. Make the other person happy about doing what you suggest.
share|improve this answer

It really depends on the manager.

I've had some terrible ones for example: - they only care about their career to the detriment of everything else - they won't stand up for their team - they just generally treat you like something they found of the sole of their shoe

Being able to summarise what you want to talk about at a high enough level that it makes their life easy is important. They most often don't need all the minute details, but be fully prepared to give them to backup what you are saying.

share|improve this answer

Managers come in all sorts of shapes and sizes. I have been fortunate in that the majority of those with whom I have worked have not thought of things in an all-or-nothing mindset.

Work items have deadlines, priorities, and a "progress bar". Each item has an associated cost and risk--both for doing it and not doing it. Think in these terms and speak to them in these terms, and they are generally receptive for you are showing them that you are capable of understanding (some of the) things from their perspective.

share|improve this answer

Find out what is important to them. Some examples:

  • Overall quality of the product delivered (usability, features, stability, performance, ...)
  • Specific targets set by their bosses; keeping project deadlines, controlling budgets, ...
  • Own career objectives; passing blame / getting credit for whatever the result happens to be.

So if they ask: 'how is the project going?', give them an answer they can work with. They probably don't want to know: we fixed bugs 124, 128 and 129, but 131 is really difficult because of module ABC is interacting with.... They just want to hear: 'we are mostly on schedule, even finished that feature the CEO was asking about, but are having problems with a very difficult bug and could use some help with it'.

Don't be too literal. Think about what they want from you, and what they can help you with.

share|improve this answer

This is all contingent on the subject at hand but in general focus on providing quantifiable data. Managers, programmers, teachers, chefs, etc... all understand quantifiable data.

Opinions and theories are when the communication typically breaks down. This leads to assumptions being made and unfortunately not conveyed.


  • Programmer to Manager: We have a lot of bugs to knock out before the next release
  • Manager to VP: We might not make the next release
  • VP to SVP: We are going to miss the next release by about 6 months


  • Programmer to Manager: We have 10 bugs to knock out before the next release; which will take about 2 man hours.
  • Manager to VP: We are on schedule for the next release
  • VP to SVP: We are ahead of schedule for the next release

While exaggerative in nature the above can hold true. The initial presentation to the manager involving theory without any substantial data for the manger to go on forces the manager to in turn make use of theory as they present the data.

share|improve this answer
Love the VP to SVP comments. – HLGEM Jan 27 '11 at 17:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.