Hacker News Reader

Situational leadership :) Adapt your leadership style to the skills and confidence of those you are leading.

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.

I guess the key difference between my experience and this article, though, is that the article seems to be mostly focused in a non-technical boss commenting on benign/arbitrary opinions (like shades of color), rather than a technically skilled superior commenting on his area of expertise.

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.

I think the employee-boss relationship is a factor as well. Generally speaking, superiors should be able to make constructive criticisms to their subordinates without it impacting morale in a negative manner. That makes criticism a two way street.

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.

One-word redline => 10 minutes of billable hours.

::Shakes fist:: lawyers! ;-)

Because of the line of work, we were contracted with up front costs. We didn't have billable hours, but hot damn - those little corrections would have added up quickly.

Maybe the key is to effectively manage your team's morale such that they're not derailed by constructive feedback.

I think the point is that sometimes it's not constructive feedback. Sometimes you'd personally just prefer things to be slightly different. But that doesn't mean that the path your subordinate chose isn't just as good as your preference. In those cases, you should keep your feedback to yourself because it's not actually constructive, and in the worst case it actually undermines their confidence.

If you don't have good reasons for your feedback (beyond personal preference), then absolutely keep your opinions to yourself. But don't blindly rubber stamp work product in order to preserve feelings. There's a third way, which this article completely ignores.

The trick is to frame it as a question, so the original creator "solves" the problem on their own and thinks it's their idea. E.g. Instead of saying "make this blue darker", you ask "this might be hard to read on a lighter background. What can we do to fix that?"

Or even better: "I find this hard to read on a light background, what do you think?". By saying "what can we do to fix that?" implies you want it changed and are not giving the person a chance to explain their decision (if there was one). They could say "I thought the same, but then we tested it with 10 people and everyone found current version easiest to read".

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.

"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.

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.

"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 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.

If it's not important enough for you to explain the rationale, don't bother giving someone the feedback.

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.

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.

Highly technical advice from a mentor does not qualify as "2 cents".

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

I can agree that the article did not go into detail on the extent of "two cents", and instead kept it too simple for the inexperienced reader to understand.

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.

I generally agree with you. Part of this is just letting employees learn to adapt. At my first job out of college I was an assistant web dev to a talented senior guy in the marketing department. He learned that no matter what he did they were always going to have some small suggestion like the article points out, so he prepared for it.

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.

But that skill only exists because managers do stuff like this. If they didn't, then that skill wouldn't be needed.

You can't control managers but you can control yourself.

A senior/experienced person offering potentially-qualitatively-better "stuff" in the realm of something like code isn't the point. I'm sure there are exceptions, but in general no one is saying, "Let things be bad." If something would be a lot better, it's not two cents, it's two dollars.

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 both of you are right, if the Boss/Senior is more qualified in the subject at hand a 2 cent is more than welcome, the problem arise when the Boss/Senior is not more qualified.

The issue is that many will think themselves qualified. It would be too easy if the Boss/Senior in the case described in the article was aware of their non qualification in the domain.

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.

This was one of the hardest things when I managed people. Most solutions won't be how you would do them, maybe they are 75% 84% of the way there. Constantly judging and tweaking others work when it doesn't make a material difference has a mental and emotional toll on everyone. I learned to go with the flow, if I though that things could be slightly better I would give them a nonbinding code review a couple weeks later. If matters now, we discuss it now, if doesn't we ship.

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.

I find semi technical managers the worst to deal with - people who managed to get promoted to management early in their career. They think they know how things work, but really they have out of date experience as a junior developer.

Agreed. My advice would be to cultivate an environment where a subordinate can speak up and challenge a manager and not be threatened, fired, or feel like speaking up will hurt that person's career advancement at the organization.

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.

Most people have the urge to "pee on" every piece of work that goes by them; to demonstrate that they are doing things, to leave some mark that they were part of the results. This is one of the reasons committee projects suck so badly.

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.

Agreed, it depends on expertise. On the other hand, I think it's possible to read the article as "don't use power to overcome a lack of expertise". And in that regard the article is not really wrong. It's just not a fleshed out thought yet.

> From my experience on contributing to FOSS projects...

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.

agree. It's not that good of an article. What if the product really does need improvement. Kinda amazed this even got so many votes.

I imagine most people are able to tell the difference between a necessary improvement or criticism versus something that is really just opinion.

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.

At least hear the 2 cents out and have a discussion where common sense and honesty decide the outcome. If the boss has any history of good ideas, then only a fool would not want to hear any hunches from the boss or bosses.

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 you might be misinterpreting the advice in this short article. This is advice for managers for their interactions with subordinates, not for subordinates in their interactions with superiors. The advice states that their very position of power may give undue weight to their casual opinions or observations.

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.

I wonder if feeling better with feedback has the side effect of not shipping something world-changing in the long run.