In a situation where your subordinates are unsure of what to do and they really don't have the skills to do it alone, you have to provide leadership and encouragement. Lead by example, show them how to do it, and let them iterate without too much micromanagement.

When your subordinates are competent but lacking confidence, it's often a better option to stand back and say nothing. The "ownership" piece is huge -- if this is the first big project you've "owned", you'll probably iron out the kinks even if I don't say anything to you. Also keep in mind is that there are many correct ways to solve a problem; while your solution may not be the one I would go with, you're more comfortable with your solution and can probably see things about it that I can't. I trust you to be the expert on the solution; I've got bigger things to worry about like how I'm going to continue servicing my same workload with a 10% cut in budget.

The goal is to move everyone up from "unconfident and incompetent" to "confident and competent". Some people also go through "incompetent and confident", which is also something where the best option is often to stand back and act as a safety net while letting the person learn whatever lesson they needed to learn.

The article is referring to things that are ostensibly subjective changes that don't make a tangible, measurable difference. The suggestions in question are often the boss putting their mark on something so demonstrate that they've made an impact.

Even if the suggestion actually improves the product, suggesting something that deflates team morale more than it brings to the design means the change isn't worth it. As a boss that's quite a hard lesson to learn because logic says you should be doing whatever you can to ship the best possible product. In reality, especially in the long term, the product is going to be better if you temper your suggestions in favour of the team.

Bosses must make sure that they're not all critic with no praise. No one wants to be critiqued all the time without kudos for the good portions and hard work. Tone, body languages, and timing all play into how an effective leader communicates positively or negatively to a team member.

On the flip side, staff need to be able to separate their personal worth from the work that they do. This can be especially tough in some fields and with some personality types such as art, design, and programming. When your work is highly subjective, when you're starting your career, or when their are a million methods to achieve the same goal (with some methods being better without obvious reason as to why), it can feel like critiques are attacking the person instead improving the work.

An anecdote from my personal life: I worked as a paralegal for a while. I started off mediocre at the job, but after a management change, my new boss had manuals that gave standardized instructions on how to do nearly everything. That's when I started to excel. There were many specific times when I would give my boss documents, but he never let them slide. Ever. He would say, "The language and structure of this document is perfect, but you know I can't let anything slide without having something to change." He'd mark something subjective such as substituting a synonym with the same meaning and tone or moving a sentence that didn't affect the language of the paragraph. It never bothered me, but I can see how that would definitely grate on others. In spite of this, he was always full of praise with nothing but positive remarks.

::Shakes fist:: lawyers! ;-)

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.

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.

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.

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.

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.

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.

"2 cents" is an opinion. Opinions are cheap, and as this demonstrates, they are noxious when coming from an authority figure.

But I know very well that when I put an incredible amount of thought and reason into picking every little detail, I DO NOT want some non-technical manager to come to me and say "the shade should be blue". His comments should not be so shallow to tell me he doesn't care, but neither should his comments be that decisive, when I cannot understand.

Your point of view comes from a person who is always looking for guidance, like someone fresh from college. The day you get lift off to the point where you are working for someone who has little expertise in your field or you have developed comprehensive depth where you can work independently, you will want ownership and you will feel annoyed at the "decisive" comments you receive.

To all others who are reading this: instead of being decisive or making shallow comments, learn to explore the work of your people, the great parts, and the weak parts. You will immediately hit upon the areas where the person is seeking guidance, and the areas where the person has resolved his mind with limited information.

He got everything setup how he wanted it and then added something that looked blatantly out of place, like a red border on one side of a div. Then they would say, "Looks great! If we can just lose that red line I think we're all set."

Worked every single time. He is somebody who's always been great at reading people and adapting to their behavior. If anything I'd say asking managers not to do the above costs people the opportunity to learn skills like this. It's a lesson that's served me well for my entire career.

The point is that when the difference is opinion (or close to), such as matters of color, font, position, etc., there is no reason to tweak things. If you're not going to make a big difference, don't make one at all.

I think the article is simply that if you are pushing for a very small change, one that would make not much difference, and is just a matter of opinion, then don't do it as it will impact negatively the original author.

Bosses shouldn't be bossy except in rare circumstances.

Most of aren't the creative director, so don't enforce your idiosyncratic aesthetic on your team members.

And I'm not only talking about issues where a non-technical manager critiques a technical project. If a non-technical manager has a comment about a UX choice, it should be valued not because it came from a "boss," but because it came from someone who did not make it. Something that seems really obvious to the implementer will not always be obvious to the general public and that is where non-technical feedback, even from your boss, is valuable.

This isn't about issues that can be right or wrong or technical expertise, it's about bike-shedding, except there's no argument about the color, there is simply someone changing the color to demonstrate that they can.

I agree with you in the open source situation that a more senior review adds valuable feedback.

Though I think that context is quite different from the employee-manager dynamic Derek describes in the article.

Boss sees a typo or brand color is wrong? Yeah, they say something. Boss just thinks their idea is slightly better on a hunch? Don't say something.

It's good advice.

The idea that "ownership" can be lost by 2 cent changes is absurd. What happened to wanting team input anyway? Weird piece.

It's likely that already the project has a combination of elements coming from more than one person anyway.

I think it's clear that this isn't suggesting withholding of all feedback when appropriate. It's saying that a casual, "I like blue" when the design being presented is purple isn't really helpful. If the boss has data that shows that actually blue increases conversion by 5% then it is not just this "two cents" that the article is talking about, it's an entirely different conversation that doesn't fall under the scope of this article.