I can't agree with this article at all. From my experience on contributing to FOSS projects, I feel much better when somebody senior makes adjustments to my code rather than leaving it as-is.
Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't otherwise have. Finally, it inadvertently means that the rest of my code passed their “high” standards for quality, which is gratifying - especially for large commits in which I only need to change little.
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. That might explain why I have such a 180° reversal from this article's stance.
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.
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.
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".
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 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 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.
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.
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.
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.
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.
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.
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.
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 think it's good to note, as Derek does, the distinction between "2 cents' worth" and larger changes that do require senior input - otherwise you're just being the manager that the team create ducks for [1].
This is where coaching skills as a manager can prove useful. If you feel there are some minor changes that could be an improvement, but don't want to impose your will/opinion, coaching ('ask') can be a better response than managing ('tell').
For example, you might ask "If you had to improve anything, what would you change?" It's an open-ended question that will encourage your team member to think. They can reply "Nothing" if they're confident in the final solution, or they may propose some tweaks they weren't fully happy with - "I'm not sure if that's the right shade of blue" or "I think that's the right call to action, but maybe we could get another opinion". If those are reasonable improvements, empower them to implement the additional change; if you disagree with the extras they raise, tell them you consider the version they proposed to be superior, which empowers their original decision.
Just don't be the manager who expects a detailed response and change every time ... then you're right back to where you started.
The open question does not always work. I'd say it never works, even.
If I take "coaching" attitude, I will take attitude of sports coach - observe, measure and explain why corrective action is needed. The action itself is a choice, mostly, but manager and coach should present a basis for it.
Continuing my my rant, I emphasize that manager and coach are external to the team, they view performance from outside (and often prohibited to look under the hood). This is the reason why open questions do not work - difference in view points creates difference in the context.
I thinks specific questions would work well. To use the bad boss example:
> I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great!
Let's change this to:
> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'.
(This honestly still needs a bit of work, but is getting there)
In this phrasing we show interest in the designer's work, respect their choices and don't assume our ideas are better than theirs. Instead we assume they know what they are doing and give them the space to convince us and also tell us what parts of the design do and do not matter to them, before engaging in giving proper feedback.
The big issue with the cited bad example is that the boss doesn't say why the design needs a darker shade of blue, or why the word ‘giant’ has to change to ‘huge’. It doesn't give any other feedback than "this is wrong, this is the fix". It's not open for debate.
>> I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great!
>Let's change this to:
>> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'.
Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way.
Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...".
Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys".
That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
> That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
Right, there's no reason the designer/software engineer shouldn't take the initiative
You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request.
Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough?
The only reason I, as a manager, would like to ask questions about "blue and huge" is to provide a way to me to experiment or allow some other people to experiment and fine tune (think A/B experiments). But that would be in SOW in first place.
> You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request.
First, you are still thinking in terms of a top-down decision where the boss has to choose between deciding what is best, or delegating that with no further input, whereas I'm talking about creating a collaborative dialogue which may or may not result in change at all.
> Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough?
I'm describing a generalised approach based on the examples in the article. If you think this is a literal example of what to focus on, then I might as well throw back at you that what you are describing with SOWs sounds a lot like the fixed, rigid waterfall approach where everything is set in stone at the start, which in the words of Winston Royce himself "is doomed to fail".[0]
Which brings me to my second point: for the sake of the example I'm assuming here that this is not a bike-shedding situation where a manager just wants to change something for the sake of feeling like they added something to the conversation (in which case your only hope is to add something so trivial that it functions as a lightning rod - see the Duck story of Battle Chess[1]).
Let's assume that the boss in this scenario has a reason to want to change something better than bike-shedding. Whether it's a good or bad one is to be determined. Instead of assuming either, the best option then is to engage in a (brief) dialogue to figure out said reason. The designer, being the expert, should be the best person to guide the boss and help decide the validity of said input.
So the goal of this conversation is not to propose a change to "blue and huge". The goal is to approach the design from the point of view of the designer; focussing on the points that still somehow feel uneasy is just efficient since that is most relevant. By asking the designer to work us through the design process we get to ignore the first gut-feeling "solutions", letting the designer keep ownership and acknowledging that they know what they are doing.
If you approach the conversation like this, most of the time it will quickly become obvious that that one of the parties forgot to take something into account: maybe the shade of blue would align more with company colours, despite not popping out as nicely; or maybe it's the opposite: the darker shade would look better, but the designer decided being consistent with the overall look of the company was more important. Furthermore, discussions like this are immensely helpful for making it clear to the designer what metters most to the client. In the end the designer can walk away with a better understanding of their client's wishes: "ok, I'll have to figure out a new balance between aligning with the the company colours while still having some pop in the overall look - and I have a bit more leeway than I originally thought."
>First, you are still thinking in terms of a top-down decision where the boss has to choose between deciding what is best, or delegating that with no further input, whereas I'm talking about creating a collaborative dialogue which may or may not result in change at all.
I think I can say exactly the same about your opinion.
I think that it is not me (as a manager) who should approach a design from a designer point of view. Not that I cannot, I should not. Shall not, if you may. And I explained what I may to do - up front specify a way for someone to change various parts of a design to experiment or alter.
Because if I have doubts about design I shall not order designer to change it. Neither shall I ask about the design rationale. Both variants are equally bad to me if I put myself in the boots of the managed one.
I have to measure through experimentation and then present my findings for designer to decide whether he is right in his decision. Because it is my job to measure and report for everyone to take actions (can be suggested by me, but that's all). "Everyone" here includes my management and employees I manage.
> I think that it is not me (as a manager) who should approach a design from a designer point of view
> Because it is my job to measure and report for everyone to take actions (can be suggested by me, but that's all).
Before you measure you first have to know what to measure, and if you really believe that engaging with your subordinates will not help you with deciding that, I hope to goodness that I will never work under someone like you. Because if you think you can determine that all on your own, that means you still are the one bossing over your subordinates. It implies tunnel-vision you have and systematic top-down tyranny (even if unintentional).
Actually, I should measure things external to "my subordinates". I don't know what example to present to you, let me try.
I am part of team building CAD system. What should I, as a manager, measure is an efficiency of a user of our system. E.g., time to complete a task of (un)trained user, delay distribution of a response time, something like that. These are external to the development effort, generally.
I emphasize that by diving into design (or, worse, development) questions I will not get a quality product. I have to measure things that no sane software developer will measure - that measurement is just not interesting as a process. I have to measure them and present to my colleagues as an external constraint to the system, for them to use that constraint to make system better.
As a leutenant, you cannot win a battle by asking questions about "why have you targeted that khata on a kholm?". You assess a situation (measure variables external to each member of the platoon) and... well, that depends then. Even if I order platoon to do something it is up to platoon members to develop their ways and coordinate them. This is the case of mission-oriented tactics, which is implicitly utilized by every good SW dev team.
If you still think I am bossing, have tunnel vision and enforce top-down tyranny, well, so be it.
Saying "this is how to improve" is fine and all, but it's much more effective when the methods to improve are thought of by the person they're for. That's what coaching is, helping people realise the steps they need to take to get to the end goal.
I cannot agree more. This is why I propose measurement and observations with the report of the results to the people who should change. Probably, with a set of options of "how to change", just to spark a thinking or discussion.
> The open question does not always work. I'd say it never works, even.
IMO whether it works varies a lot by the employee's experience level. For a long time I tried to help junior engineers in the same way I would want to be helped (minimally, open ended, high focus on code quality), then got frustrated when the results weren't what I expected. Catering your message to the audience is one of the best pieces of management advice I've received. I'm not actually a manager, but as a senior dev, similar situations arise in code reviews.
>For example, you might ask "If you had to improve anything, what would you change?" It's an open-ended question that will encourage your team member to think.
Yeah. They think you're too weak-willed to just outright state your opinion and instead passively-aggressively point out what you really mean.
Passive aggression. I was searching for the noun of passive aggressive recently and someone corrected me, and I'm glad they did! (Hopefully this is helpful not hurtful).
Don't worry about me. Only three people I know have managed to seriously annoy me over the last >15 years and they all had to work for it (although it seemed to be quite effortless for at least two of them : )
I view employment different than most people I have found anyway
Trust has nothing at all to do with it, nor does ownership as the article implies as I do not own any of the idea's or work I produce for my employer. That is the purpose of my employment, I trade my skills, knowledge and experience for currency.
My employer trusts my boss that is the only Trust that is required, I give my input based on how I see things, if they accept it great, if they want to go another route or use a different idea that is fine as well.
I do not have these types of emotional attachments to my work
As a manager, I tend to frame my feedback/opinions as 'Have you considered <something>?' or 'Can you explain your thinking behind this <feature/function/design>?'
Doing it this way, I get an understanding of their rationale and if I still think my idea is good, I can debate the worthiness of it against my employees reasoning. I feel this approach fosters a 'best idea wins' rather than a 'manager opinion trumps all'.
I agree with Derek's implied point that 'manager opinion trumps all is bad', but think it's a discredit to his staff if he doesn't challenge their ideas if he thinks he has something more worthwhile.
It depends on the culture, but I prefer cultures where everyone, including management, gives input, and the creator picks-and-chooses. Management, even upper management, giving input shouldn't necessitate a change.
Management has a big picture individuals often lack. That's an important part of the process. On the other hand, it shouldn't dominate the process.
This post is much better than the article. The manner in which you deliver criticism is very important. When criticising somebody on their method I find it is much nicer to say "I like to do it like this..." They will then be encouraged to try your method and they might like it. You are not attacking their method.
I find it unfortunate that most people take criticism as an attack, but they do and choice of language and delivery can soften the blow and bypass their defences.
> "I like to do it like this..." They will then be encouraged to try your method and they might like it
The danger here is that this will often be interpreted as "my boss wants me to do it like this", and they will do it not because the idea stands on its own merits, but because it was the boss's idea.
I love this, I have taught few people programming and I always do it this way.
My guess is that it also depends on the level of knowledge of the person doing the task. Since they were students, there are small things that they just don's know (for example, adding a class to make it responsive).
But since I'm always challenging my own decisions, I have no problem when someone adds their "two cents" and I have to show why it doesn't work that way (or I learn something new). After a couple of times they realize I know what I'm doing.
Was going to reply along the same lines. Much better is asking questions like "Why did you choose this shade of blue?" Which leads to improved understanding from both parties: The color may be more important than the original selection merited, or the selection was chosen specifically for reasons that the Manager wasn't aware. In general phrasing this as a dialog where the Manager (expert or no) and the Do-er both work to educate each other. "Did you consider X2?" becomes a valuable question if you think the implementation selection of X1 is "incorrect" or "sub-optimal"
I agree in part. Except for "have you considered" which always sounds patronising to me. It's very clearly a disguised way of saying "you should have done..."
There's another part too which to me is; if the point that I, as a manager, am making suggestions (even valid ones) is when looking at the complete "diagram" then I've failed as a manager. The point to offer an alternative option is the point at which the team was discussing it in the first place.
> Because of that small change, that person no longer feels full ownership of their project.
What kind of person is that who 1) thinks the ownership is 100% theirs when working in a team? 2) can't handle a little nitpicking? 3) feels it's less their work just because of a little change? 4) can't defend their work and resist those 2c?
This is advice for managing 2 year olds. As a manager, just be your reasonable self. The truth is key for a functioning team. Giving people feedback and letting them know where they stand helps build trust.
In every team I've observed, there has been a steady stream of comments from staff about how one manager or other keeps asking for changes they see as pointless or negative, often accompanied by further complaints about how the manager in question never thinks their work is good enough.
I've seen this be the primary reason for high performing team members quitting. I think you underestimate substantially how much negative feelings this type of thing can produce.
It's not that you can never make suggestions. It's about making sure that you don't always make suggestions, and to avoid making suggestions unless the change you're asking for is important enough.
It's also not about people not being able to "handle a little nitpicking" but that even though they'll handle it, it often creates resentment and feelings of not being appreciated. And the team members that takes the most pride in their work are often most likely to be annoyed by this, and most likely to have plenty of options to move on.
Constantly giving people feedback that says "your work wasn't good enough for me as is" does not build trust. If you want to demonstrate that you trust their judgement, then do that by letting their judgement stand.
> That's what I mean by giving reasonable feedback. Constantly being a dick is definitely counterproductive.
But it's not about being a dick. The point is that even feedback that is totally reasonable in isolation sends all the wrong signals if they become a constant factor.
By restraining yourself to asking for changes when there are actual, important reasons for them you minimise that. As a bonus, when it is clear that the changes you ask for are actually important, people tend to take them a lot more seriously.
> That is a symptom of a broken framework for managing a team, not a result of giving natural, reasonable feedback to the output of a person.
I agree with this, with the caveat of what I have written above:
If you have to give constant suggestions for change once someone comes to you with something they believe is ready, I don't see that as reasonable, no matter how reasonable each individual piece of feedback is.
I believe that in that case, either the suggestions aren't all necessary, or if they are necessary the team is badly managed as the staff clearly does not understand what areas they need to collect feedback on during the process, and don't understand when the work is actually complete and/or doesn't have access to the necessary skills and resources.
Note that there is also a clear difference between someone coming to you and asking for feedback or asking you to make a choice or suggestion during execution of a task vs. you giving unsolicited suggestions for changes when they come to you with what they believe is a finished piece of work. The former is generally, if given well, welcomed and appreciated in my experience. It is the latter which often produces negative responses.
It's a good example. Sometimes bosses will go even further than that and suggest changes that the employee feels are wrong. Then they argue about it. Then the boss says "I feel I'm right, and I hope I can convince you that this is the right decision, but you need to make the change now". That's the point where the employee feels like his input is worth nothing because he can't do anything against the boss's opinion and arguing was useless.
This is why a trivial example like this crystallizes the exact point: it's not worth micromanaging employees over some changes that are not that important.
That's exactly the vibe I got from reading this article. I immediately thought of someone trying to manage super-fragile millennials who wilt and pout without constant encouragement and affirmation. If I submit I project for scrutiny, I want constructive criticism and advice. The goal should to make the project as good as it can be, not manage the feelings of emotionally challenged workers.
People can be impacted negatively without them wilting and pouting over it. Feelings are also very intangible. They might not even realize it themselves if it demoralizes them. Just the same as many people don't fully understand why their boss is such "a great boss". Managing people is also about understanding that your feelings are not a model for other people's feelings, and you must actively compensate for how others may react.
The article is not about affirmation. It's pointing out that opinions of a manager often implicitly mean something more than an opinion, and your objective criticism isn't fully taken as such but rather in some part as an instruction. This is demoralizing for most people, even though it might be small. The conclusion is that perhaps-not-so-important opinions aren't worth the potential negative effect.
> If I submit I project for scrutiny, I want constructive criticism and advice
That's were you're misunderstanding the post: "2 cents" is unsolicited, minor advice that would be safely ignored from a co-worker, but with the cachet of a manager, its no longer just criticism or advice but an instruction. I suspect you assume that all teams are free to challenge their managers, but Derek's assumes the opposite (not all teams feel they are free to challenge their managers' opinions without repercussions).
> The goal should to make the project as good as it can be
That's entirely dependent on whether the manager is always right, otherwise they are making the project worse by fiat from time to time
But in most workplaces I've worked in this inevitably leads to the manager pulling rank and saying "do this because I told you so."
I've seen this again and again in creative industries, and I'm certainly not a millennial.
A family member of mine worked for a boss (owner of company) who would constantly derail projects with his bullshit suggestions, because he just couldn't restrain himself. Some proportion of his suggestions were actually good, but his belittling and badgering of staff trained them all to do exactly what he asked for, even when that wasn't what he wanted, or what was good.
The article isn't about objective criticism, it's about subjective opinion. Usually by a person with less experience, e.g. when a manager suggests a color change to a designer.
I find objective and subjective sometimes difficult to discern.
To the manager, and specially founders and visionaries, it all may sound objective. Frequently, management literature advocates for an instinctive response as a perfectly justified, even inherently better, contribution.
Steve Jobs and Elon Musk's celebrated style of input comes to mind. Fast, truthful and direct, even if subjective. Sometimes one lacks the time to add insight to support an opinion. "Green instead of blue" may as well be sound feedback only the missing objectivity may be left as an exercise to the designer.
Nobody are saying managers shouldn't ever give subjective feedback.
The issue is when managers always give subjective suggestions for changes, because it implies that the work isn't good enough.
If the work is never good enough, why is that person presenting stuff to you? (Or why are they even working for you?)
Clearly, if the work is never good enough, they need someone more on their own level to bounce ideas of, or someone slightly more senior to mentor them until what they present to you is good enough a reasonable portion of the time.
In other words: If you constantly need to suggest changes, the team is badly managed to begin with. And if the changes you suggest are not needed, then don't suggest them, or at least not all the time. Not only does it negatively affect team morale if you always do it, but the extra time spent costs you money.
If you are a visionary that people are clamouring to work for, then, sure, you have more latitude in the amount of suggestions you make. But most of us are not in that position.
The point was though that if your 2 cents' worth isn't constructive, if it's not the difference that could "make the project as good as it can be", you shouldn't give it.
Perhaps it's like SEO, where all the low-hanging fruit is obvious and sensible, but where further optimization beyond that point is stuff that looks really odd and counter-intuitive, or like it "couldn't possibly" have any impact.
Maybe people put out a 1.0 units of effort when you're just a reasonable person, but put out e.g. 1.1 units when you baby them, and so babying them is a "win" in some sense?
>Maybe people put out a 1.0 units of effort when you're just a reasonable person, but put out e.g. 1.1 units when you baby them, and so babying them is a "win" in some sense?
I'd contend that any worker that you have to "baby" in a business environment to get their best effort is a worker you are better off without.
Note that I'm talking about results, not effort. Someone could be giving their best effort already, resulting in 1.0 units of output. But babying them might be the emotional equivalent of blood-doping in a marathon, a psychological stimulus that actually partially restores or extends the willpower-resource that is spent internally to accomplish work.
I'm also not talking about a specific kind of person who "needs" babying. I'm proposing instead that your average neurotypical human brain might have this effect built in, such that it applies to anyone and everyone. It would just be an effect that most of the time goes untapped.
I think a truer kind of relationship is the most significant factor still. It's the common denominator that will take people to great results for a wider "audience" (a team here).
But I agree that fine-tuning your feedback and style per individual needs, even if counterintuitive, may also be productive, as long as it's not contradictory and leads to situations where one team member feels another is being babied around more.
That's not true. You could probably get better output out of most employees if you baby them just right. Who doesn't like a boss that lets them do whatever as long as it's beneficial to the company?
There's no objective feedback loop when the boss can use their rank to push through changes, though. I've seen multiple projects run into the ground based on wasting schedule for essentially arbitrary subjective changes backed by rank.
But this article isn't about giving constructive criticism and advice. It's about those 2c opinions which are not constructive, but rather just subjective.
In my role as employee: I usually ask peers/possible end users for a bit of feedback. This is especially true when writing any kind of extended text for use with the Great British Public.
In my role as manager/mentor: I would always encourage colleagues to seek feedback from others, and have, in the past, even done training on giving and receiving feedback ('don't argue or defend, just listen record then see if the statements are actually meaningful later on).
Disclaimer: I work as a teacher. It is mostly content/activities/text designed for communication of steps in a process that I have to produce.
If someone has gotten to be "the big boss at work" (per TFA) and hasn't learned this lesson yet, then there's a whole bunch of issues they'll need to sort out (unfortunately, that's not an uncommon scenario)
But for new managers I find it's quite a common issue. They think that being in charge means that they need to throw in "2 cents" on everything even if they're not really contributing anything of value. Though it's often not intentional, there's something in their mind that makes them think that if their team gets something done without their involvement, then that makes them redundant
For people new to those roles, it's helpful to stop and ask yourself questions like:
- "I just gave this 1 minutes thought and 30 seconds of feedback, do I want this person to go off and do a few hours more work based on that off-the-cuff remark?"
- "Am I throwing another opinion into the mix, or am I telling my team what I want from them. Have I set up the team dynamics in way that allows everyone to know the difference between those?"
- "What action do I expect to come from this, and who benefits from that?"
> there's something in their mind that makes them think that if their team gets something done without their involvement, then that makes them redundant
I don't think that's the intent. I think it's more like, "I'm not doing my job if all I do is rubber stamp". If the manager isn't helping the team to get better work done, then they are redundant. Nitpicky comments are probably not the way to help the team, but if I had a manager who just said "sounds good" every time I presented an idea or a piece of work, I wouldn't interpret that as empowering in any sense. I'd interpret it as "this guy doesn't even care".
>I just gave this 1 minutes thought and 30 seconds of feedback, do I want this person to go off and do a few hours more work based on that off-the-cuff remark?
It depends a lot on who the comment is being given to. I've got people on my team that I can make an off the cuff suggestion to, and they'll consider it just as if it came from any other senior person. I've got other people who will take an off the cuff suggestion from me and run with it for a week. I have to be much more cautious with my suggestions to the latter.
I think the nuance of this advice is in the final two paragraphs of the article. If there’s more than "2 cents" worth of stuff that needs to change, then this rule does not apply. But if your contribution is small, just let it go.
At first glance it seemed to imply collaboration is only possible between employees of equal grade, but I guess this applies more to unsolicited advice rather than an open discussion.
As long as the person offering their 2 cents is open to a fluctuating exchange rate, then I'm always happy to discuss my work with management!
If you work for somebody else, it's 0% yours, and that's it. While you can take pride on some of that, it's simply not yours. If you want it to be your don't sell it.
I think the suggested comment It’s perfect. Great work! Let’s ship it. has its own set of issues.
Firstly, while the conversation started with "I'm looking for input", the manager has suddenly moved it into a push for delivery.
If the design was ready to ship, then that won't be an issue, but if all you're looking at is a mockup, or a slapped together stylesheet, etc, then what was an attempt an encouragement has just lumped more pressure on.
Also, the comment assumes that the designer thinks it's "done". The request for input could mean "this is the direction I'm going in, does that look right". Telling them that you think it's "ready to ship" still takes ownership from them. You've just moved from being the boss who provides 2 cents on everything to the boss that wants everything to be done right now without taking the time to do it right.
Much better to say "I think it's fantastic. Great work! Is it ready to ship, or do you have more to do on it?"
I think your subtle focus on the semantics of the reply highlight a common block to agile feedback loops, small batches and generally getting things done. Sorry if that's harsh but you either missed the point of the article entirely or just overlooked it, the latter possibly being worse.
The primary point IMO is "don't squash ownership" because the cost of doing so is often not fully realised.
The secondary point is "don't sweat the details". You've kinda proven you don't get this yet.
> I think your subtle focus on the semantics of the reply highlight a common block to agile feedback loops, small batches and generally getting things done. The primary point IMO is "don't squash ownership" because the cost of doing so is often not fully realised.
^^^ Here's your comment without the pointless condescending remarks. Notice the difference?
I'm sure he can, but he didn't write this post in order to inform himself, he wrote it for others to read and learn from.
My personal & anecdotal experience has been that there are just as many managers who fail to engage well with draft-work as there are those who want to chip in their 2 cents on everything. There is definitely a class of managers who think they're offering encouragement but are so focused on the end goal that they fail to show respect for what has been achieved so far.
Of the two, I prefer those who offer unnecessary input to those whose only response is something them amounts to "is it ready yet?"
I would hate to see people read this advice and move from the first group to the second group without realising that they've traded one set of problems for another. I am quite confident that that is not Sivers' intent, but I think it is absolutely a gap in his post.
Or, to put what you just said another way: when evaluating advice, you should assume it's going to be interpreted by incompetents. Competent people filter advice they hear through their learned intuition, which turns most advice, good or bad, into good advice. Incompetent people, meanwhile, will at best apply your advice exactly as written. The only real point in advice, then, is helping incompetent people.
I like the way Joel Spolsky describes managers taking this even further at Microsoft back in the day.
They wanted to make sure the engineers knew that they were the ones designing the software, to the point where they would refuse to even step in and resolve a conflict between two engineers about the design. Even when those two engineers came up and asked for help resolving said conflict.
Now you've got three people in the room: a designer, a developer, and a manager. Who's the person who knows least about the problem?
TLDR: A project needs a dictator in order for the endresult to be well designed and directed (else, it can still be profitable according to speaker, but not excellent). Funny that parent mentioned it, (Ballmer-era) Microsoft gets an unhonorable mention towards the end, with their "meh" XBox concept.
Right, but you have the engineer saying that is not important, and the designer saying this is the most important part of the software and we might as well not do it at all.
This is where you need a decision from someone else.
I don't know if you need arbitration, there, so much as a willingness to allow each party to "pull in" others to help make their point. Like expert witnesses in a trial, but just for the sake of convincing.
Not necessarily. One of them may be right, or neither of them. Surely someone who says X is unimportant or that X the most important part of the software can prove it with data/measurement?
Something a very smart person advised me was to "Tell people what you want, not what to do"
It sounds so simple yet is surprisingly hard to practice. It really puts the onus on you to think carefully about outcomes you desire and explain it clearly.
Or as Neil Gaiman put it from the opposite perspective:"When people tell it's wrong, they're almost always right. When they tell you how to fix it they're almost never right."
To me that is a lot of the skill I have learned over the years, trying to figure out what people are trying to do when they say they need something. User suggested solutions are usually not the best.
What this article misses is that genuine feedback helps us grow, and being open to it is as important as being able to deliver it in a way that doesn't take something away from the recipient. Getting others' input and adapting to it (or learning when to accept but not heed it) is crucial for getting better at whatever endeavor one is engaged in.
If you have a suitable level of trust and respect between you and the person requesting approval or feedback, then your input can be valuable without it being undermining of their ownership of their creation. In fact, the opposite; by soliciting feedback (preferably early, not just at the end of a project), you can help build a sense of ownership from the person giving feedback.
I thought that was the point of the article—give people only genuine feedback that helps, not hassle them with minutia. Giving unsolicited advice to people you manage can undermine the "suitable level of trust" that you would otherwise have, if you're not careful.
There is a big difference, after all, between requesting feedback from someone you respect and getting approval from a superior in a hierarchical power structure.
What the article is touching on is the tendency for some managers to give feedback on everything just because they can. Other people in the organization won't have that privilege, and giving feedback on everything reinforces the fact that the other people in the organization are subordinates and don't have that privilege.
The article didn't miss that at all. The article wasn't about meaningful feedback. It was about petty, subjective feedback that doesn't really serve to make anything better, but to make the manager feel as if they did something.
Related: Parkinson's Law of Triviality, and the Queen's pet duck in Battle Chess (when developers become aware of management's need to unnecessarily "finishing touch" all work and begin making slightly-inefficient choices intentionally to give the work a "shear point" where the management can feel like they're contributing by removing something obviously incorrect).
Similar processes have been used for decades by movie and television creatives to move the Overton window on media censorship---early cuts of a project will have something obviously grotesque and culturally repugnant, so the censors lock onto that and miss the risqué thing the creator wanted to get to their audience.
Love the suggestion. So many times have minor suggestions from managers killed the enthusiasm for a project because it feels like the manager can't think about or appreciate the bigger picture. In fact, it looks like he is only trying to own the success of the project by picking on non-important stuff.
Some factors in motivation at work are the level of autonomy, mastery and purpose in your job.
A coworker giving minor feedback is only contributing to your mastery. A boss giving you the same minor feedback is cutting in to your autonomy. The exception is when the purpose is great and sweating every detail is necessary or when the boss is a recognised master of your craft and their feedback is almost always correct and regularly helps you improve.
An example of the first case might be engineering at SpaceX and the second could be Steve Jobs giving engineers and designers product feedback. What I think a lot of people are missing in this thread is that in most situations the purpose is relatively uninspiring and the boss is significantly less skilled than the person she is giving advice to.
I think the article/blog post is missing a key point in that the employee came to the manager asking what he thought.
This is a critical role that the manager plays that the article decides to come up with a unreferenced social psychology manipulation solution when there is a greater problem at hand.... the employee is nervous about shipping the product and wants approval.
The reason why this is because a great manager is supposed to protect and shield employees from the outside so that they can feel at ease with making decisions and working with out fear of making some mistake that costs there job (unlike the article I can site like 5 or so Harvard Business Review articles written by experts that show this is often the reason why employees come to ask questions like that.. yes I'm being snide but I think "What got you here want get you there" is basically on overrated Dale Carnegie rewritten).
Not getting any input sends a message of "I don't really care about your work". And if you really wanted to coach and you really believe this arm chair psychology then why not send a link of the article to the employee asking the advice and say "I would like to give some input but I want to assure you that I think you own this project... etc etc...".
Education is a powerful thing... manipulation is not.
The way I've always tried to approach this is by pointing out problems, rather than offering solutions, especially where I'm in a position that I'm giving feedback to someone who is more of an expert in the activity than I am. Expressing things as problems automatically eliminates a lot of the minutiae about wording, color, etc. (since those are just subjective opinions and not reflective of a problem), and it lets people still feel like they're owning the work and not making changes they disagree with because they're forced to.
Example:
Providing solutions: "Move the 'widgets' menu to the top.
And make it bold"
Expressing a problem: "So, when I'm using the app, one of the first things I usually want to do is look at my widgets. It took me a few minutes to find out how to do that."
The solution to this problem might be looking into whether accessing widgets is a common use case, or finding different ways of educating users about how to find widgets, or yes, even moving it to the top. But no matter which solution is chosen, everyone is going to come out of it with more information than if they blindly implemented the manager's uninformed opinion.
My experience with work is that everything can be slightly improved all the time. You have to stop at a certain point and I think the author has found the nicest place to stop, at least for employee happiness.
On the other side, if you have been working on something alone, I think it is a clever idea to accept the feedback of your boss just to have another perspective.
Dale Carnegie Rule #1: Never condemn, criticize or complain. In general, we're all not actually looking for input so much as support.
Human nature is such that even when we readily acknowledge someone better at something, we quietly indulge and seek out advantages we have in other areas.
We engineers like to think we're more rational and accepting of input. Working as a coder and manager for the last 20 years has shown me there's nothing further from the truth.
Man! I wish my boss had read it 5 years ago. I could never understand why I was not motivated in my job at all even though my boss was really brilliant. It basically reduced to this. No matter what I did the boss always had 2 cents that had little impact on anything but made be less interesting in doing the work. But for my next job the boss was much better, instead of saying change this and change that he would often ask me why I made certain choices and what inspired me. He would then say "ship it" but the questions he raised made me wonder how I could make things better.
I assume GP was refering to the "great work" part, but even then it's just matter of style; the point was only to show approval without nitpicking, not emphatic congratulations.
Part of working in a team is receiving comments and criticism from others. If you take these negatively and as attacks to you, rather than collective construction towards the final goal, then you have a problem and need to consider changing job.
I find that when I design something I become accustomed to early design choices and then eventually become blind to them. I need someone to come along with a fresh pair of eyes, see the whole thing and nitpick it. It's absurd to suggest that it's either perfect or needs to scrapped entirely.
Well, I was going to downvote, but figured it's better to comment.
> Ugh. This reeks of "safe space" nonsense.
What? I have very little idea what you are talking about, so I looked it up on wikipedia: "In educational institutions, safe-space (or safe space), safer-space, and positive space originally were terms used to indicate that a teacher, educational institution or student body does not tolerate anti-LGBT violence, harassment or hate speech, thereby creating a safe place for all lesbian, gay, bisexual, and transgender students."
Which frankly sounds like a good idea, but doesn't seem like it has much to do with this blog post about managing members of your team.
> Part of working in a team is receiving comments and criticism from others. If you take these negatively and as attacks to you, rather than collective construction towards the final goal, then you have a problem and need to consider changing job.
Yes, except the point of the blog post is that managers should be aware that comments and criticism they would have been happy to offer as co-workers suddenly start to look a lot more like commands when they are coming from a boss. It's a good idea for new managers to be aware of this changed dynamic.
> What? I have very little idea what you are talking about, so I looked it up on wikipedia: "In educational institutions, safe-space (or safe space), safer-space, and positive space originally were terms used to indicate that a teacher, educational institution or student body does not tolerate anti-LGBT violence, harassment or hate speech, thereby creating a safe place for all lesbian, gay, bisexual, and transgender students."
It was originally something like that but "safe spaces" just turned into echo chambers where everyone is only allowed to agree and encourage people and dissenting opinions are considered "unsafe".
> Which frankly sounds like a good idea, but doesn't seem like it has much to do with this blog post about managing members of your team.
The "safe space nonsense" grandparent was referring to is that when you attempt to stop people from being offended or thinking they don't own their work (or otherwise treating adults like children) by saying "just don't say this" results in a chilling effect that just makes everyone's lives worse. Nobody will come up with legitimate criticisms in fear of "being too mean" or "stealing your thunder", and people who need feedback will never get it as a result. I believe that's the effect that the grandparent was referring to. You get the exact same problem with univeristy campuses, where people wanted to be shielded from alternate views by claiming that you're offending them and that you're violating their safe space.
That's how it started, but now anything negative is met with "This is supposed to be a safe space!" whining. Unsurprisingly, some people either can't or won't make the distinction between things that matter (harassment) and things that don't (words like 'moist' or references to a phobia they have such as 'spiders').
You can imagine that it gets rather annoying to be told that you can't say "moist" in some place because it's supposed to be a 'safe place'.
If your co-worker looks at a designed object and says "needs more blue, change the word "giant"", that's feedback which you can then incorporate, but can also reject if you think it doesn't help the project.
If your direct boss says the same thing, and you don't have the understanding with them that you are totally free to ignore their feedback, you'll have somewhere between strong pressure and absolute requirement to implement their changes.
At that point, the pressure in many ways is actually on your boss.
If your boss has come up with good changes that you agree with, you'll probably be OK with it if you're as positive toward criticism as you say. (And if, say, your boss hasn't chosen the time when you've already been working on this thing all day, it needs to go out in an hour, and you thought you were ready to go home.)
But if your boss's changes are ones you don't agree with, and you do feel forced to implement them, then you'll probably start getting annoyed.
If that happens a lot you're likely to, as you say, change jobs. And if you happen to be very skilled, that's a problem for your organisation - one that could have been avoided if your boss had avoided dropping in his $0.02, or at least had chosen another way to do it.
OK, I agree that the boss's opinion is different. But then this should be more about how a boss can deliver criticism in a way in which it is not taken as a command. Because the article is pretty much saying that the boss cannot offer any criticism at all which is ridiculous.
The article is not saying that teams should avoid comments and criticism, nor is it saying that there is no middle ground between perfection and needing scrapping.
The article is pointing out that it is _particularly dangerous_ to give criticism if you are the boss, because whereas peer feedback will be weighed on its own merits, even casual feedback from a boss will frequently be interpreted as a command.
It's not safe space nonsense. It's power play. Acceptance to the change suggestion from boss is often based on power rather than merit. Managers often is oblivious to this. The blog simply reminds managers to be aware of the potential pitfall.
A better way to approach this situation: "That's great! Love it! Out of curiosity, what inspired you to choose those colors and fonts?" Then, they still have ownership, but they also are given the chance to justify their choice and it starts a conversation that could lead to improvements, if necessary.
Even if you are genuinely curious, such inquiries from a boss/"authority figure" can easily come off as threatening, so tread very carefully with advice like that.
Indeed - it only takes two or three easy questions like that to become a pattern, at which point every question is code for "guess what you did wrong", which is toxic.
Still passive aggressive. Any person with a brain would see right through that question. If you need to address something, it's better to be direct than to beat around the bush.
I don't think that is passive aggressive at all. In fact, I say stuff like that all the time, and mean it, because I do like what people come up with and want to know how they did it. How else would you express that?
It has good intentions, but it might make someone ask themselves if the boss thinks that their use of colors needs to be changed. If it was a good choice, then why bring it up, they might ask themselves.
Is it not possible to make it clear that your 2 cents is just a suggestion? This just seems like bad communication, and regardless of whose fault that is, the boss might as well try to solve it.
It's a "suggestion" from a direct superior in a hierarchical power structure. A little bit of communication isn't going to change the context.
So no, it is not something simple like "bad communication".
I think one of the main problems here is that people in power often feel like they have to justify themselves by giving technical feedback, even when it's not appropriate.
But there are ways of eliciting critical thought about the choices made and even about alternatives that the person in power has.
It is "bad communication" in that the person in power is communicating their desire in a way that is perceived, even if just a little bit, as being a command. And I do believe there are effective ways to mitigate this.
This conversation is a great example of bad communication, if you want a reference.
Communication is not just about how you communicate, but when. Good communicators know how and when to listen, and they keep their mouth shut when it's appropriate. That's the lesson of this article. If that's not a problem for you—if you know when to speak and when to listen—then maybe this article won't help you, personally.
And if my manager was always trying to elicit critical thought about trivial and mundane matters like font choice and colors on internal tools, then I'd want them to just shut up for a moment. I'd be glad to hear what your effective mitigation strategies are for giving unnecessary advice.
I think the issue I have is that the author is taking an all or nothing approach. Either something is all wrong and a larger discussion must be had or nothing is worth noting. There is a huge range of things in between there, many of which may be small opinions.
After reading the article a few more times and the comments here, I'm getting the impression the author meant "don't add pointless opinions or suggestions to things." The use of the phrase "my two cents" beguiles the author's intent, as in many cases that phrase is not used when one has a pointless opinion.
Yes, I've heard the "my two cents" phrase used with important or strongly-held convictions, but that's just an ironic use of the phrase to mean the opposite of what it usually means, no?
It may also be a dialect issue, like the old "let's table this" problem.
I was definitely not reading "all or nothing" from the article, more of "if you only have something trivial to say, don't bother." Hence, don't give your two cents, but put a dollar in when it matters.
It's a "suggestion" from a direct superior in a hierarchical power structure. A little bit of communication isn't going to change the context.
Why not? If I don't like the "suggestion," I - a professional ostensibly employed to provide my expertise - will do my job and use my expertise to push back on their suggestion while communicating that they're ultimately in charge and I'm willing to do something I disagree with.
Not everything from on high is an order. Having a relationship with a superior or an employee where you're both free to push back on each others ideas (and understand how hard the other side is pushing) is a critically important part of the relationship.
You're implying that no employer-employee or supervisor-supervised relationship can be such that suggestions from the former to the latter can be just that: suggestions.
This empirically isn't true, as I am one counterexample (as the employee).
I think this is the crux of the issue. The author's examples seem to have the sound of authority because they are coming from a person of authority. There are however, ways around this.
For example, using the first quote the author used, instead of outright saying "maybe just a darker shade of blue there" the boss should question why a darker shade of blue wasn't chosen. Perhaps the employee has a good reason for it. Maybe they didn't consider that shade. Either way, a suggestion is made but doesn't sound like authoritative directive.
It really is possible. I have received countless suggestions from my employer that we understand to be merely suggestions rather than orders.
This seems like one of the most basic communication requirements in a company hierarchy. I'm surprised people seem to think it's impossible to achieve, when I would sooner think that it's impossible for a company to be functional without having achieved it.
This exactly. At my current employer, I feel I can oppose pretty much anything my managers tell me - technical or non-technical. I can say "I disagree because X", and the reply might come back as "OK - that makes sense", "Let's discuss this in more depth because Y", or "I'm going to overrule, you must do Y".
If you have a functional relationship with your managees, they need to know they can disagree with you and that you know you're fallible and just need it pointed out. I always make sure that when I give technical feedback to others (whether higher or lower 'ranked' than me), they can come back and argue any bit they disagree with, and so far almost everyone has at some point.
Oh how I wish I had a downvote ability on this post. The first thing wrong with this is the fact that the post is nothing more than the author's 2 cents. The author doesn't know what they hey they're talking about and is just pontificating.
As someone who does a lot of creative work, I hate it when people just give useless positive encouragement and withhold actual constructive feedback, small or large. Only hypersensitive people feel worried about their loss of ownership because they accepted someone's suggestion.
A situation where a boss having a color preference means that a designer feels unable to reject the suggestion is a dysfunctional workplace. When the manager has that type of feedback, they are not being a manager. A good manager makes it clear that if they have color feedback, that's just their suggestions and not them acting in capacity as a manager.
I have to agree with a lot of what you say, but just as the article I think you haven't completely thought through what you are writing.
For instance, let's add two points that in real life can't be circumvented: a) most places that pay you will be dysfunctional work places, and b) you don't always have a choice of work since you need to pay bills.
And what are your standards for downvoting? I downvote when I think a comment/link is hurtful for the discussion or people involved. And yes, while it is not a very well finished article from Derek, it leads to a healthy discussion and in itself is not a bad/hurtful opinion to have.
>most places that pay you will be dysfunctional work places
This article is aimed at managers. It is advice on how to create a functioning work place. To the extent it fails to do so, it is entirely appropriate to say "Hey, this is bad advice for reason X."
It is not interesting to rebut this by saying "Yeah, but reason X isn't valid if the manager is terrible." The whole point is that the manager shouldn't be terrible. This isn't advice for non managers and it isn't advice for managers who aren't trying to be good managers. Managers who don't care about creating a functioning work environment aren't reading and discussing this anyway.
But once again, this isn't about constructive feedback. This is about nitpicky, subjective things. The article does not say to hold back constructive feedback. It says to stop nitpicking your employees to death.
The post doesn't say "don't micromanage", it says that if you provide your 2 cents when shown something and ASKED SPECIFICALLY "What do you think?" (!) that if you answer what you think, it will damage your employee's sense of personal ownership over their work, which is utter bullshit.
You can give the author credit for all sorts of careful nuanced views while excusing all the lousiness in the actual words they wrote, but I'm not going to do that. If the author can't take the time to think more critically and carefully about how to express their advice, they shouldn't be publishing, even on their own little blog.
"it says that if you provide your 2 cents when shown something and ASKED SPECIFICALLY "What do you think?" (!) that if you answer what you think, it will damage your employee's sense of personal ownership over their work, which is utter bullshit."
It says that if you give petty, subjective, not really constructive criticism, that you will damage your employee's sense of personal ownership of the work, which is true.
"You can give the author credit for all sorts of careful nuanced views while excusing all the lousiness in the actual words they wrote, but I'm not going to do that. If the author can't take the time to think more critically and carefully about how to express their advice, they shouldn't be publishing, even on their own little blog."
I'm sorry, but the article did do that. You just don't want to see it.
This doesn't necessarily invalidate the advice, but Steve Jobs clearly did not abide but it (would critique icons at the pixel level, etc.), so it is demonstrably not universal advice for building successful companies.
True, but I don't think the advice is about building a successful company but more about being a successful manager - which Steve Jobs was definitely not as he was famous for being a tirant.
I would argue that sj only critiqued things that he genuinely felt needed to be changed. Though he was also demonstrably the worst manager one could have so I wouldn't draw too many conclusions from him.
As an independent contributor I don't want my manager weighing in on my choices. I see them as out of the loop on the more technical aspects of my job and they should leave those decisions to me.
If I come to a more technically senior member of the team who is more knowledgeable, it is to _precisely_ ask for their opinion.
So in my mind: if you're a manager, don't bother; if you're a more senior IC, do, with the explanation of why your approach is better. You're more of a mentor at that point than a manager.
Oh, and if your approach isn't really better, just different, keep it to yourself.
> Oh, and if your approach isn't really better, just different, keep it to yourself.
This really is the heart of the problem, not giving feedback when it is solicited (unless it is really soliciting for approval rather than feedback).
There usually are many ways to do something, all of them roughly equal and it doesn't matter who gets to chart the road to take, as long as a road gets taken and you can move on to the next issue. Way too often the discussion will center around who gets to claim that their road was taken, which is more often than not utterly irrelevant.
Office politics is the silent killer of teams, projects, products and whole companies and this is one of the more immediately destructive manifestations.
Micromanaging without just taking the work off their hands is obnoxious. If I had a micromanaging boss, I'd ask him if that project was one he'd prefer to take on himself.
As long as you don't mind being micromanaged yourself, then I suppose it's ok. I'd quit as soon as I could though in such a case. My manager giving me his 2 cents annoys me, I'm already stressed out and it just adds more on top of it all. Especially if it's not a suggestion that decreases work to be done, which it rarely is.
This is a total straw man. There's something in between bikeshedding and blindly approving work you feel is less than perfect. What if the boss responded with, "Why did you choose this color of blue?" This indicates respect for an intentional choice, lets the employee provide a rationale and be heard, and still moves towards a better final product. There's a false dichotomy presented in the article, and it's crap.
Honest question - is this idea of individual ownership conducive to team morale, enough to protect ownership like this? I've seen a lot of examples of how "ownership" backfires when people are protective of their turf or disregard others' valid input. Ownership seems to be commonly used to get people to take personal responsibility as a proxy for motivation, it does help some people set better examples, but does it motivate a team and make it more cohesive on the whole?
I have seen 2-cents backfire a lot a well, but I think it's most often strong personal opinion not backed by good reasons, like evidence or unseen constraints or dependencies, etc.
This article started by the boss asking for "non-obvious advice", and then provided an example of advice that was pure opinion without any reason, and stated as a veiled command rather than offering an alternative option. It can be important to share actually non-obvious insights, even if it's just 2 cents worth, so I won't be asking my team to avoid sharing their 2 cents as a blanket rule, I will ask them to share any important insights they may have, and encourage them to have a good reason.
Huh... approaching this from the opposite side, when my boss has suggestions I always take it as an opportunity to let them feel some ownership of the work, even on occasions where the suggestions don't turn out to be that useful in practice ("I implemented your suggestion of X, which led me to come up with Y").
Trying to game professional relationships goes both ways I guess :)
It's tough to be prescriptive about this sort of thing in a general way. Every situation is different. It really depends on who you're working with, sort sort of context you're working in, what sort of expectations you're working with, etc.
I would say, "make sure you set expectations in advance about how feedback is to be interpreted and acted upon". My boss gives me his 2 cents all the time, and I enjoy it. And vice versa. Sometimes I preface my suggestion with "you don't have to do change anything, but FYI...", and sometimes I say "I feel quite strongly about this: XYZ" – and even then we have an understanding about whether or not something should or should not be changed. It works the other way too. I've shipped things without incorporating feedback, and all was well.
So I think it boils down to culture. Everyone's understanding of what the norms are, what is expected, etc. (Just for fun: Can you imagine telling Elon Musk or Steve Jobs not to add their 2 cents?)
> because it’s not just one person’s opinion anymore — it’s a command!
Spot on. Exactly the reason for quitting my last job. Boss(manager) comes and adds his 'suggestion' to every task.Even though, I tried to stick to my way to going about the task. He continued to insist that I should give this view a trail run first. After a week or so, When thing go wrong, I'll go back original method and finish the task.
Later, he will complain about I'm being slow to respond to task. When I point out the unnecessary time-wasted due to his suggestion. Now he will backtrack & put it as 'I was only giving suggestions, it was your baby anyway'. It happened 3 or 4 times & I had enough.
Funny thing - During my last day, I took this issue to CEO. To my surprise, he said, 'Yeah, employee has to take my suggestion, since I'm their boss'!
[to those bosses if you are reading this:] - I don't have any issue with trying out your ideas - but when thing go wrong, take the responsibility for your _stupid_ idea.
While I'm normally a fan of Derek's musings, this one is too pithy for me. He is painting with too broad of a brush. There are all kinds of reasons why you might tell an employee to make small changes: maybe one small change will have a big impact; maybe many small changes in aggregate will have a big impact; maybe the employee doesn't want to take ownership; maybe the employee is too junior to take ownership; maybe the employee wants to learn the nuances of the profession in greater detail; maybe the employee is an underperformer; I could go on like this indefinitely as could many other experienced managers.
Now maybe if you're employing a bunch of independent-thinking artistic, creative and intelligent types this generalization makes sense. But I'm sure the global workforce has substantially more than 1 billion members who don't fit this definition. In that light it seems a little irresponsible to put this thought out there like it's a zen koan.
If your team cannot take your feedback just like taking feedback from their colleagues, cannot argue with you or veto your idea easily with a legitimate response, take everything you said as a "command" then you have failed as a manager anyway.
I assume Derek's advice makes sense for Korean culture where manager and team dynamics are different.
I've seen this happen over and over again in American culture. One of my most common pieces of feedback to managers centers on this, in fact. Time and time again I see managers who _think_ they are able to give feedback as "one of the team" and that they aren't "the boss" or giving people orders... but when you speak to their reports, they are interpreting it as orders from the boss. Even if you produce documents declaring your workplace to have a "flat" structure, people tend to treat any feedback from the person who signs off on their paycheques as commands.
* It's about how make the suggestion. "How about making this blue darker?" vs. "Do you think making this blue darker would give us more engagement? Are there any studies, or have we done A/B testing on this? I think it fits on our branding better because..." etc. Derek's example is really bad one though. Why would a manager (unless an experienced designer) would make such a pointless suggestion?
* If everything you say is just done without any sort of questioning then it's obvious there is a problem.
I think it's a common delusion for managers to think that this kind of feedback is helpful, which is the kind of misconception this article addresses.
"They should work on fostering better employer - employee relationships" is non-advice, it's just a goal statement. Kind of like telling a runner that they should try going faster.
When a designer or developer shows you a version that is not nearly done, don't provide any _specific_ feedback. If you mention specifically that a button should be red instead of blue, for example, then you are communicating that they are almost done, and they simply need to make the minor changes you mention for you to be happy. If the work isn't nearly finished, it's better to instead say, "Great work so far. I don't want to rush you. I think you should spend some more time refining the UX. Do a few trial runs as a user and do the best job you can to make the most perfect UX possible."
As soon as you mention specific things, they mentally move on.
As soon as I read "_specific_ feedback", my eyes lit up.
Another issue with specific feedback is that "...should be red instead of blue" type feedback can derail a designers whole thought process, a thought process which usually doesn't end at the delivery of a draft, which is merely an optional stop along the way in the mind of the designer.
A designer might have ideas for how to address certain kinds of objections to a draft. For example, if boss says, "It doesn't match our brand well enough.", the designer might have some specific ideas that he/she came up with, in case that was a perceived issue. If, instead, the boss says, "It doesn't match our brand well enough, so add more blue.", then the designer's route can no longer be used, and an entirely new route has to be determined.
I use the railway analogy, because I think it actually maps exactly: Imagine you, as a train passenger, told the conductor (the person you've hired to be your railway professional) exactly where to go, and there wasn't a predefined switch for getting there OR the switch for getting to that exact location has already been passed. The only way to achieve this new route is to backtrack or build a new switch track, both of which are more expensive than continuing on the existing route to a location that also solves the passenger's problems.
As a follow up to this article, I need about 40 examples that illustrate the difference between manager opinions that are worth two cents, and useful manager feedback. Or about 10 years of experience, but I'm hopeful that someone will offer examples.
Sorry, but this is just lame. A manager has a job to do, too, and whether or not they do it well, it is within their prerogative to add comments or suggestions, even if small, if they think it will improve a product.
Put yourself in the manager's position (which ironically this article seems to attempt to do). Go further, suppose it is your company, not just your department. Are you going to let a product ship when something minor could be improved to make it even better? A sloppy manager might. Or one who doesn't care. This article almost seems to suggest that managers should care less.
Attention to detail is what often separates good from excellent.
I think the point is to avoid getting lost in the forest because you want to climb every tree.
As part of a leadership training program I once did, we had a Q&A with an executive where we could ask him anything. One of the questions was "What was the most surprising thing about going from an individual contributor to a manager to an executive?" His answer was, "I learned that as you get higher up in the organization, oftentimes you need to seek a good solution rather than the best solution."
Yes, this means that the product will be less excellent than it could be. Anyone who has used a big company's product can tell you that this is what actually happens. And yes, this leaves openings for big companies to get replaced by hungry little startups. But the alternative is for the big company to function like a startup that has a few thousand uncommitted people wandering around drawing a salary while providing input. Imagine working under those conditions as a founder; you won't get very much done, and people who work under those conditions in a big company don't get much done either.
If you want the product to be excellent, go quit and make an excellent (if minimal) product. If you want to work with a lot of other people, then let them do their jobs.
Maybe "Don't add your 2 cents" is not the best way to frame this, but he is correct that being the boss means your opinion is dangerous. More accurately, casually tossing out half-baked ideas is dangerous for anyone with real power or even social influence. When your words carry enormous weight merely because you said them, you need to be more careful about the things you say because it will have consequences. If it really is just a casual opinion, and not something you have really thought about, it is better to err on the side of not expressing it in such a situation.
Feeling ownership doesn't have to mean managers can't contribute at all, that's absurd.
Creative labor is unqiue - Depending on the employee, I know I have X changes I can suggest/propose per project before they start to get annoyed with me, for some it's more than others. Unsurprisingly when its promo time the guys who are easier to work with get brought up (even if the difficult divas work is marginally better) The big thing is trust and respect - earning that early on is key and once you do things are much easier going forward.
Your boss' opinion might not be better... but it often does have more authority.
In my case, I work directly for the president of the company. He owns the place, he founded it, he built it, it is his. Whether or not his opinion is better, it does hold complete authority, and it is his right to have his company run his way.
Now, if you are a low/mid-level manager, the advice from the article may be more applicable to your situation. But your own corporate structure and culture will have an impact on the validity of that advice.
Speaking as someone who has been "the technical guy" for 20-odd years, if the president of the company wants to pick nits like variable names and coding style, he's perfectly within his rights to do so. But he can do it without me.
There is probably a balance to be struck. Because I've also worked for milquetoasts whose teams walk all over them, doing whatever they want. The product suffers, the team suffers, and the company suffers.
This reminds me of that story about the bikeshed[1] colour:
"This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."
Wow, what a bad example. That is called constructive criticism and is a very valuable tool in a company's toolbox of culture.
What I observed to be actually harmful is criticism of how an employee works: Tools, practices and habits. If your boss tells you that the build tool of your choice sucks without naming a better alternative or any constructive advice, that feels really bad and destroys motivation for the job.
No it isn't. The example presented is the manager throwing in his two cents worth because they feel they ought to contribute something, which is what the article is arguing against.
My two cents: rather than tell someone to change a word here, a colour shade there, what you should do is give your reasons for WHY. Why is this shade of blue better than the one I chose? Why is a given call to action better than another? That way, your opinion becomes, if not data driven, at least reason or anecdote driven. And that shouldn't demoralize anyone, I should think.
The boss should not say, "it's perfect!", if the boss feels it is not....which is literally what this article is advocating.
In the hypothetical situation described, I get the impression that the boss didn't even look closely at the two weeks worth of work. To then get immediate flattery feels very disingenuous to me.
If your manager asks you to change a color or font or whatever that has 0 relevance to the actual task, you know then that your manager is an idiot and you should probably start searching for another job or a way to move up over him.
I had number of such situations. You are almost always better off without that in your life.
Emperor Joseph II from Amadaeus: "My dear, young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Cut a few and it will be perfect!"
The problem is the initial question, not the manager input. There's a significant difference between delivering something with facts than delivering something and asking for approval.
I like to get feedback from as many people as possible, and take action on MOST of the [actionable] feedback. In my experience, this always leads to a better final product.
The article draws an explicit line between giving feedback as a coworker and as a manager. If you didn't get that, rather than reproducing the arguments here I humbly suggest you re-read it.
Huge Sivers fan! With that said, I'd take this advice way further.
> The boss’s opinion is no better than anyone else’s.
All opinions are no better. Does not matter who. Throw out opinions altogether. In America we are obsessed with "our right to our opinion" and somehow have confabulated this to equal our individuality, our exceptionalism, and our success. We're unique to begin with, exceptional is only a hard earned reputation, and success is just a feeling. Case in point, unique is effortless because it takes effort to be identical to other people; no one has ever been exceptional without doing exceptional work; define success conveniently, and we're all successful.
> your opinion is dangerous
All opinions are dangerous. A doctor doesn't operate based on opinion. Engineers don't build rockets based on opinion. Programmers don't program based on opinion. Reality is fact based, not opinion based.
Don't add your 2 cents. Add something that's actually worth something. Faster, lighter, stronger, cheaper, smoother, more efficient, more succinct, more obvious, more fun... Better is measurable. If you need progress, you need facts. And if you start comparing "opinions" and find one is better, you're already seeking facts. Opinions about opinions is demonstratively far worse.
Of course, this is all professionally speaking. When consequences don't matter, we're free to indulge in our opinions because we all have them. They're automatic. But just because you thought something, it doesn't mean squat. If anything, opinions are funny. Off the clock, do and say whatever you want. But whenever you need to be real, share what you know, not what you think. The more you know the better. Never confuse this with the more you talk or the louder you voice your opinion. Bosses that authoritatively enforce their opinion are the worst.
And most importantly, know when you know. Because only then can you or anyone go gather facts before making that important decision. Talking and thinking is not gathering facts! Googling is.
If you're still wondering why Donald Trump is doing so well, it's because so many of us still live in an opinion based reality. He is the feel good candidate for his supporters. Hasan Minhaj just did an awesome piece on the Daily Show [0]. His supporters don't care what he says, and their opinions are hilarious. Not to mention they are all wonderful people. If not for politics, we'd all be holding hands in a circle.
For better or worse, democracy treats facts and opinions equally. But a good boss won't. They are not equal, and only one leads to true progress.
In terms of design, everything is an opinion. You can't prove one design is better than the other... unless you ask for multiple people's opinion. It boils down to opinion in the end.
Everyone having an opinion and there being opinions doesn't mean there isn't anything else. Design-wise any work can be broken down into all of its possible abstractions and inferences, just as a user interface can be measured by use cases. There is also technique, originality, coherence...These are factual and measurable, and any feedback regarding them would not be some opinion anyone could either take or reject based on their opinion. It would be stating a fact.
If you're an artist, the love for your work far outweighs anyone's opinion. You should be doing what would make you love your work even more. And it will resonate with those who love the work also. For this to work, you must have good taste. Love and taste are not opinions.
If something truly holds no empirical value or weight outside opinion, then you've just proved its worthlessness. If it only matters as much as opinions, it doesn't matter much. Do whatever you want.
Points of view, food for thought, and expert advice are not opinions. And none of this is my opinion either. I am stating what I know.
You can't prove a design is better than another but you can measure it. You can use beta releases or focus group and other methods. Abstract things like feelings and intuition tell you one design is better than another. Relying on intuition might be what works best if you are alone. But there are also concrete signs: user feedback, churn rate, etc. Although we can agree that the best design is not always the most successful. In the long run good design lasts.
Having good taste is the empirical skill for judging the aesthetics or experience of anything. If you have good taste, you know you can rely on your intuitions. If you don't, you need someone who has good taste.
> You can't prove a design is better than another but you can measure it.
If you can measure it, you can prove it. The missing key is priority. If you prioritize what your design needs to be better at, then you have a concrete reference for scientifically measuring one design against another.
A common conflict is having multiple priorities. If you want a page to look good, but also want to maximize your ad revenue, well, no matter what you do, you've lost freedom in both. But if someone accuses you for building an ugly page, you can show them the numbers, and their opinion will not matter. It will matter as little as yours. I mean, you probably agree with them.
Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't otherwise have. Finally, it inadvertently means that the rest of my code passed their “high” standards for quality, which is gratifying - especially for large commits in which I only need to change little.
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. That might explain why I have such a 180° reversal from this article's stance.