Usually people like when they understand specific action. For e.g. if I ask then to do TDD, I try to explain why it is important.

The issue, starts when they do not agree with the decision, or when I don't have time to explain deeply all the aspects of the decision.

So the question is: Are managers required to explain why for every "command" they give?

  • 2
    Your title says "any" but the question says "every". The answer is somewhere in between. Aug 27, 2018 at 18:32

7 Answers 7


It is beneficial in several aspects to explain your decisions.

  1. Employees feel treated like humans instead of robots. Even if they cannot influence the decision anymore, they feel heard instead of ignored. I'm sure I don't need to explain the benefits towards a positive work environment.

  2. People might change their mind when they understand why you decided to do what you did. Even if it was a decision many employees find unattractive, they might accept it if they know why it's neccessary.

  3. Employees do a better job if they understand what they are doing. If you just slap a new form on the desk of a secretary, proclaiming "I want you to use this form from now on", they will make mistakes, misinterpret contents or even abuse forms for things they were not intended. If you explain the form and it's purpose, the secretary can actively try to fullfill this purpose and avoid mistakes.

  4. An employee who has a deep understanding of what they're doing and what the result is supposed to be can give you information on how to improve processes. An employee who puts this object into this container because that's all they know about their job will never know that putting the object upside down accelerates the next processing step.


Others already pointed out the benefits of explaining the rules and decisions you make.

Let me add that, in a sane, working environment, your team will not question every single decision then few words should be enough to let them investigate further (if they feel so). If you have to go through all the details for most of your decisions then you have another problem to solve:

  • They may not trust you.
  • They may not accept your leadership, do you have any other clue? Investigate further.
  • You have a history of dubious, bad, or sub-optimal decisions.
  • They may want to know every detail instead of just an hint they can use to investigate by their selves.
  • You're deciding something which should, ideally, be a technical decision made inside the team (like in this case). Are you their manager or their tech lead?

Assuming none of the above.

In general, for somehow important decisions which directly affects the team (like TDD in your example), you should discuss with your team BEFORE YOU MAKE A DECISION. This will lead to better decisions (after all you will always have the last word) because:

  • Shared knowledge.
  • As a manager you might not have all the technical expertise required from, for example, a tech lead.
  • Different points of view.
  • Maybe you are trying to solve an XY problem. Why are you pushing top-down a technical decision?

Plus the benefit to make the team involved in the decision process. This way you can also dismiss them when they're asking you to justify something in your own field:

TM: why feature X is scheduled before Y? I think we should first do Z.

You: Thank you but I decided to do so, let's discuss about how X will be implemented..."

  • I like this answer, but I don't think talking about lack of trust can achieve anything. Honest critique of your boss isn't really possible without trust to start with.
    – monocell
    Aug 28, 2018 at 19:02
  • @mono you're right, in that case just talking won't probably help. Editing thst Aug 28, 2018 at 20:28

For things like TDD, buy-in is extremely important: you are not the one that has to do it, your developers are. Test-Driven Development requires a bit of experience, knowledge, and creativity and a lot of perseverance to do it well. It doesn't work well for everyone, and dogmatic use isn't necessarily better than writing tests after the main code.

If you force them to TDD, you will get Test-Driven Development in name only, which will just lead to low-quality tests and code (maybe even worse than now) instead of the quality improvements that - I hope and assume - you want as result of this change.

But even for less creative, more mechanical changes, sharing the reasons (or reasoning) will usually lead to people being more accepting of the change, and knowing the reasons may also lead to them actually embracing the change and applying it effectively instead of only going through the required motions.

Better would be to get people 'from the floor' on-board in the change or decision process before final decisions have been made. This will usually lead to more informed and better decisions, and the people that actually have to work with it will probably be more accepting of it then something that feels like it is just being rammed down their throats.

Personally, if my manager would come up and say "You must do TDD", I would roll my eyes and wonder what management magazine or conference sold him on TDD as a snake oil that solves all software quality problems. It doesn't when applied without thought or willingness to really do it, nor without some flexibility (eg ideas for some tests only emerge when you have actually written code).


Well, sort of yes.

Let me try to give you another perspective. You really need to make your employees understand your actions, decisions and words. These are your tools. Unless you are one of these managers who just really don't need skilled employees, you profit every single time your employees learn something. For them to learn something they have to understand it. If you make seemingly irrational decisions, your team is going to start copying that. Everyone doing irrational things sounds like a bad business strategy. Don't go there.

Does this mean you have to explain everything? No, in fact, quite the opposite. Don't explain directly, but help them understand. That is how people learn - by figuring out stuff themselves. But you have to help them understand, and take the time necessary to achieve that. Which initially is a lot slower than explaining stuff to them.

  • 1
    Great answer! I think you meant to end with "which initially is a lot slower"... over time, it ends up being faster to have employees that can figure out the explanation for themselves. Aug 26, 2018 at 20:32

Required? No. But it helps (when feasible).

It is significantly easier to get buy in from your team if they understand the why behind the decision. Turn the team into true believers, and they can work wonders.

  • 5
    If an employee disagrees, ask, "Is there a reason why we shouldn't do X?" Usually your reply would be "I considered that, but..." Very occasionally you may say, "Holy smoke! I never thought of that. Thank you!"
    – Bob Brown
    Aug 25, 2018 at 19:16

Of course not.

(Others pointed out positive aspects of doing so, I'll refrain from triple posting those.)

As manager you're privy to information your team won't and often mustn't have.

As manager it is expected to conclude the best course of action for the project, the company and all other aspects of the business directly under your supervision and impacted by your actions. Managers may do so with or without consulting their team / third parties.

Employees in turn are expected to follow these guidelines to their best of abilities.
They may voice concerns and propose alternatives, however if the manager still persists on what was laid out, that should be the end of it.

Additionally in very hierarchical company structures and societies it might be seen as weakness and an employees unwillingness to follow as disrespecting authority / insubordination.


"You ask them to do Test Drive Design".

That is something that never in a million years should come as an order by the manager. It turns all development upside down. Expect nothing to be delivered for quite a while. If the developers are not experienced in TDD (which the obviously are not), then you need some significant training first. And if you are not an expert in TDD, worst case, if it's something that you want to introduce because it's the next big thing, this will end up in disaster.

If my manager told me "tomorrow we will start test driven design", I would tell him "this is a very bad idea" - because I actually know better than my manager what's a good way to develop our product (that's why he hired me). But (thanks, Mark) my manager is not a believer in snake oil so this isn't going to happen.

  • 1
    Not to mention that the code base is likely not in good shape for TDD. That can be dealt with over time, but it will be a considerable drag at first. Aug 28, 2018 at 17:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .