Mixing
As manager, should I explain any decision to my employees?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
16
down vote
favorite
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?
professionalism software-industry management
edited Aug 26 at 14:35
Kilisi
96.5k53220380
asked Aug 25 at 18:19
Shluch
1105
add a comment |Â
up vote
16
down vote
favorite
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?
professionalism software-industry management
edited Aug 26 at 14:35
Kilisi
96.5k53220380
asked Aug 25 at 18:19
Shluch
1105
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
2
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32
add a comment |Â
up vote
16
down vote
favorite
up vote
16
down vote
favorite
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?
professionalism software-industry management
edited Aug 26 at 14:35
Kilisi
96.5k53220380
asked Aug 25 at 18:19
Shluch
1105
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?
professionalism software-industry management
edited Aug 26 at 14:35
Kilisi
96.5k53220380
asked Aug 25 at 18:19
Shluch
1105
edited Aug 26 at 14:35
Kilisi
96.5k53220380
edited Aug 26 at 14:35
Kilisi
96.5k53220380
edited Aug 26 at 14:35
Kilisi
96.5k53220380
96.5k53220380
asked Aug 25 at 18:19
Shluch
1105
asked Aug 25 at 18:19
Shluch
1105
asked Aug 25 at 18:19
Shluch
1105
1105
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
2
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32
add a comment |Â
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
2
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
2
2
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32
add a comment |Â
7 Answers
7
active
oldest
votes
up vote
26
down vote
It is beneficial in several aspects to explain your decisions.
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.
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.
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.
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.
answered Aug 25 at 19:27
YElm
4,95331025
add a comment |Â
up vote
9
down vote
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..."
answered Aug 26 at 8:31
Adriano Repetti
997412
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
add a comment |Â
up vote
5
down vote
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).
answered Aug 26 at 8:34
Mark Rotteveel
1677
add a comment |Â
up vote
5
down vote
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.
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
add a comment |Â
up vote
4
down vote
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.
answered Aug 25 at 19:04
Ian Jacobs
611146
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 at 19:16
add a comment |Â
up vote
2
down vote
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.
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
add a comment |Â
up vote
1
down vote
"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.
answered Aug 26 at 11:11
gnasher729
72.6k31135228
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.
– David Thornley
Aug 28 at 17:34
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
26
down vote
It is beneficial in several aspects to explain your decisions.
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.
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.
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.
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.
answered Aug 25 at 19:27
YElm
4,95331025
add a comment |Â
up vote
26
down vote
It is beneficial in several aspects to explain your decisions.
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.
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.
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.
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.
answered Aug 25 at 19:27
YElm
4,95331025
add a comment |Â
up vote
26
down vote
up vote
26
down vote
It is beneficial in several aspects to explain your decisions.
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.
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.
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.
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.
answered Aug 25 at 19:27
YElm
4,95331025
It is beneficial in several aspects to explain your decisions.
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.
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.
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.
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.
answered Aug 25 at 19:27
YElm
4,95331025
answered Aug 25 at 19:27
YElm
4,95331025
answered Aug 25 at 19:27
YElm
4,95331025
answered Aug 25 at 19:27
YElm
4,95331025
4,95331025
add a comment |Â
add a comment |Â
up vote
9
down vote
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..."
answered Aug 26 at 8:31
Adriano Repetti
997412
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
add a comment |Â
up vote
9
down vote
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..."
answered Aug 26 at 8:31
Adriano Repetti
997412
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
add a comment |Â
up vote
9
down vote
up vote
9
down vote
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..."
answered Aug 26 at 8:31
Adriano Repetti
997412
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..."
answered Aug 26 at 8:31
Adriano Repetti
997412
edited Aug 28 at 20:29
answered Aug 26 at 8:31
Adriano Repetti
997412
answered Aug 26 at 8:31
Adriano Repetti
997412
answered Aug 26 at 8:31
Adriano Repetti
997412
997412
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
add a comment |Â
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
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 at 19:02
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 at 19:02
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
@mono you're right, in that case just talking won't probably help. Editing thst
– Adriano Repetti
Aug 28 at 20:28
add a comment |Â
up vote
5
down vote
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).
answered Aug 26 at 8:34
Mark Rotteveel
1677
add a comment |Â
up vote
5
down vote
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).
answered Aug 26 at 8:34
Mark Rotteveel
1677
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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).
answered Aug 26 at 8:34
Mark Rotteveel
1677
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).
answered Aug 26 at 8:34
Mark Rotteveel
1677
edited Aug 26 at 8:42
answered Aug 26 at 8:34
Mark Rotteveel
1677
answered Aug 26 at 8:34
Mark Rotteveel
1677
answered Aug 26 at 8:34
Mark Rotteveel
1677
1677
add a comment |Â
add a comment |Â
up vote
5
down vote
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.
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
add a comment |Â
up vote
5
down vote
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.
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
add a comment |Â
up vote
5
down vote
up vote
5
down vote
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.
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
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.
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
edited Aug 27 at 4:32
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
answered Aug 26 at 1:42
Stian Yttervik
4,0752520
4,0752520
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
add a comment |Â
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
1
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.
– Chan-Ho Suh
Aug 26 at 20:32
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.
– Chan-Ho Suh
Aug 26 at 20:32
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
@chan-ho-suh good suggestion. Thanks.
– Stian Yttervik
Aug 27 at 4:35
add a comment |Â
up vote
4
down vote
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.
answered Aug 25 at 19:04
Ian Jacobs
611146
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 at 19:16
add a comment |Â
up vote
4
down vote
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.
answered Aug 25 at 19:04
Ian Jacobs
611146
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 at 19:16
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered Aug 25 at 19:04
Ian Jacobs
611146
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.
answered Aug 25 at 19:04
Ian Jacobs
611146
answered Aug 25 at 19:04
Ian Jacobs
611146
answered Aug 25 at 19:04
Ian Jacobs
611146
answered Aug 25 at 19:04
Ian Jacobs
611146
611146
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 at 19:16
add a comment |Â
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 at 19:16
5
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 at 19:16
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 at 19:16
add a comment |Â
up vote
2
down vote
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.
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
add a comment |Â
up vote
2
down vote
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.
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
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.
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
answered Aug 26 at 11:35
DigitalBlade969
2,1551314
2,1551314
add a comment |Â
add a comment |Â
up vote
1
down vote
"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.
answered Aug 26 at 11:11
gnasher729
72.6k31135228
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.
– David Thornley
Aug 28 at 17:34
add a comment |Â
up vote
1
down vote
"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.
answered Aug 26 at 11:11
gnasher729
72.6k31135228
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.
– David Thornley
Aug 28 at 17:34
add a comment |Â
up vote
1
down vote
up vote
1
down vote
"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.
answered Aug 26 at 11:11
gnasher729
72.6k31135228
"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.
answered Aug 26 at 11:11
gnasher729
72.6k31135228
edited Aug 27 at 17:21
answered Aug 26 at 11:11
gnasher729
72.6k31135228
answered Aug 26 at 11:11
gnasher729
72.6k31135228
answered Aug 26 at 11:11
gnasher729
72.6k31135228
72.6k31135228
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.
– David Thornley
Aug 28 at 17:34
add a comment |Â
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.
– David Thornley
Aug 28 at 17:34
1
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.
– David Thornley
Aug 28 at 17:34
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.
– David Thornley
Aug 28 at 17:34
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f118209%2fas-manager-should-i-explain-any-decision-to-my-employees%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
You can try to explain every decision but there are decisions where your team members will not have the fuller context you have, so they have limited ability to understand. For example, say the impact of a seemingly trivial change is extremely high, so you ask them to thoroughly test everything multiple times. Unless they understand the impact is high, this will seem ridiculous. However, sometimes it can be hard to understand why it is high impact (might have to do with reputational risk or some business risk that is hard to explain).
– Chan-Ho Suh
Aug 26 at 20:00
2
Your title says "any" but the question says "every". The answer is somewhere in between.
– kbelder
Aug 27 at 18:32