5 ms·

The maxim I was taught was "If it's a question of good v. better; let the employee's decision stand; if it's a question of right v. wrong, intercede and direct,

The maxim I was taught was "If it's a question of good v. better; let the employee's decision stand; if it's a question of right v. wrong, intercede and direct, nudge if possible." When you get input you appreciate, you intrinsically appreciate it. The challenge is that statistically, the more senior guy understands why changes are needed, while the more junior guy is less likely to understand the context, or probabilistic benefit of the offered change. So, this has to be tempered, and like all things, has to be evaluated on a case by case basis.

jimbokun 10y ago
"The challenge is that statistically, the more senior guy understands why changes are needed, while the more junior guy is less likely to understand the context, or probabilistic benefit of the offered change." No, no, no, a thousand times no! The person most involved in the problem will almost always better understand the context of the problem, because they are spending far more time on it. This is another important reason for the boss to refrain from suggesting changes, unless it's clear and important. As often as not, the boss's change will be worse, but there is a lot of pressure to not push back and just do what the boss says. This whole topic is the punchline to many Dilbert pointy-haired-boss cartoons.
- late2part 10y ago
  Sometimes you're right. Do you think you're right all the time? Do you think the more senior guy should know when it is one situation (when the more senior guy knows) and when it is the other, where the more junior and more involved guy knows? You're making a black and white rule. The black and white rule I'm advocating is that the boss should know when it's black (intercede) and when it's white (let their good v. subjectively interpreted better decision stand). Of course, the counter-argument is that it's better to let the junior person make their own mistake and learn from them. And it is! Some/most of the time. But some some of the mistakes might cost too much and need to be avoided. If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make.
  - jimbokun 10y ago
    "If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make." Maybe this is a little too personal for me. Never been a manager, don't really want to be one. But I have been a developer for a long time, so I often have as much or more experience than my supervisor at this stage of my career. The anecdotes that stick in my memory, is when I knew the right decision, explained the rationale for the right decision...and my boss made the wrong decision, without being able to explain why his decision was better. I distinctly remember one incident where, several months after going with my boss's decision, which turned into a bug generating maintenance nightmare, my boss ruefully smiling at me and saying "Yea, I think we should have done (jimbokun's original idea)." Yea, thanks, now we're wasting who knows how many hours on the fallout of the original decision. I appreciate those who are willing to take on the hard job of management, and OK with them potentially making more than I do. But good managers find and hire people who know how to do their job and let them do it. So if a manager has an inclination to change something, they should first assume they are wrong and their subordinate is right, ask the person doing the work to explain how they made their decision, ask for clarification if the manager still thinks a change should be made, and only then suggest the change if there is something clearly and obviously wrong with the reasoning behind the decision, making sure to explain the reason for the change.
    - vmarsy 10y ago
      I agree with both late2part and you. I saw late2part situation happen a lot of times: A junior dev find a quick an elegant way to solve problem X. Senior dev comes and say: It's good but you should do it that way because it <will be more testable / require less maintenance / any advice only someone with more experience on the product's codebase can tell> If the senior dev is bad / doesn't have time at the moment, he will skip explaining the "because" part, and the junior dev might be frustrated. With good communication a good faith from both parties, the junior would later understand. The manager anecdote "my boss made the wrong decision, without being able to explain why his decision was better." would be a different situation, and in that case, that manager should definitely have kept his opinion for himself. At least he recognized his mistake later on. So 2 stories: One where the junior dev is too "know-it-all", one where the supervisor didn't put enough trust in his subordinates.
- mikeryan 10y ago
  I think the two of you are displaying my issue with the whole post which is that feedback is highly situational. Trying to distill this subject down to "Don't give your two cents" or "Only give your two cents when you're right" is pretty much impossible. There's so much context missing here. There's a much longer post to be written on the ways to provide feedback and create a constructive conversation around solutions and seniority is almost never the reason someone is right but experience most often is.
- TrevorJ 10y ago
  Highly dependant on the situation. There are a lot of extraneous details mostly related to budgets, client relationships and scheduling that the person doing the actual work may not have the most up to date info on.

jimbokun 10y ago

"The challenge is that statistically, the more senior guy understands why changes are needed, while the more junior guy is less likely to understand the context, or probabilistic benefit of the offered change." No, no, no, a thousand times no! The person most involved in the problem will almost always better understand the context of the problem, because they are spending far more time on it. This is another important reason for the boss to refrain from suggesting changes, unless it's clear and important. As often as not, the boss's change will be worse, but there is a lot of pressure to not push back and just do what the boss says. This whole topic is the punchline to many Dilbert pointy-haired-boss cartoons.

late2part 10y ago
Sometimes you're right. Do you think you're right all the time? Do you think the more senior guy should know when it is one situation (when the more senior guy knows) and when it is the other, where the more junior and more involved guy knows? You're making a black and white rule. The black and white rule I'm advocating is that the boss should know when it's black (intercede) and when it's white (let their good v. subjectively interpreted better decision stand). Of course, the counter-argument is that it's better to let the junior person make their own mistake and learn from them. And it is! Some/most of the time. But some some of the mistakes might cost too much and need to be avoided. If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make.
- jimbokun 10y ago
  "If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make." Maybe this is a little too personal for me. Never been a manager, don't really want to be one. But I have been a developer for a long time, so I often have as much or more experience than my supervisor at this stage of my career. The anecdotes that stick in my memory, is when I knew the right decision, explained the rationale for the right decision...and my boss made the wrong decision, without being able to explain why his decision was better. I distinctly remember one incident where, several months after going with my boss's decision, which turned into a bug generating maintenance nightmare, my boss ruefully smiling at me and saying "Yea, I think we should have done (jimbokun's original idea)." Yea, thanks, now we're wasting who knows how many hours on the fallout of the original decision. I appreciate those who are willing to take on the hard job of management, and OK with them potentially making more than I do. But good managers find and hire people who know how to do their job and let them do it. So if a manager has an inclination to change something, they should first assume they are wrong and their subordinate is right, ask the person doing the work to explain how they made their decision, ask for clarification if the manager still thinks a change should be made, and only then suggest the change if there is something clearly and obviously wrong with the reasoning behind the decision, making sure to explain the reason for the change.
  - vmarsy 10y ago
    I agree with both late2part and you. I saw late2part situation happen a lot of times: A junior dev find a quick an elegant way to solve problem X. Senior dev comes and say: It's good but you should do it that way because it <will be more testable / require less maintenance / any advice only someone with more experience on the product's codebase can tell> If the senior dev is bad / doesn't have time at the moment, he will skip explaining the "because" part, and the junior dev might be frustrated. With good communication a good faith from both parties, the junior would later understand. The manager anecdote "my boss made the wrong decision, without being able to explain why his decision was better." would be a different situation, and in that case, that manager should definitely have kept his opinion for himself. At least he recognized his mistake later on. So 2 stories: One where the junior dev is too "know-it-all", one where the supervisor didn't put enough trust in his subordinates.
mikeryan 10y ago
I think the two of you are displaying my issue with the whole post which is that feedback is highly situational. Trying to distill this subject down to "Don't give your two cents" or "Only give your two cents when you're right" is pretty much impossible. There's so much context missing here. There's a much longer post to be written on the ways to provide feedback and create a constructive conversation around solutions and seniority is almost never the reason someone is right but experience most often is.
TrevorJ 10y ago
Highly dependant on the situation. There are a lot of extraneous details mostly related to budgets, client relationships and scheduling that the person doing the actual work may not have the most up to date info on.