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.
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 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.
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'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.
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).
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.
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.
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.
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.
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 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.
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.
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 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'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 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 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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
> 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.
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!
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
247 comments
[ 6.0 ms ] story [ 260 ms ] thread"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.
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.
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.
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.
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.
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.
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.
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.
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.
This empirically isn't true, as I am one counterexample (as the employee).
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.
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.
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.
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.
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.
[1] See point 5 https://blog.codinghorror.com/new-programming-jargon/
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 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.
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.
Right, there's no reason the designer/software engineer shouldn't take the initiative
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.
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."
[0] https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s
[1] https://en.wikipedia.org/wiki/Battle_Chess#Development
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.
> 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).
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.
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.
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-agressiveness exists but reading everything into that context just makes for poor workplace performance IMO.
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 hate being slow rolled to idea or opinion..
If you have criticism about my work come out with it, I am not some delicate little snowflake, if there is better way I want to know.
Guidance (or "slow rolling") helps with strong/deep learning and enables opportunities for conversation.
If you trust your boss/coworker, considering letting them continue when they start such discussions.
If you don't trust them or feel frustrated/patronised while they're talking, then you have other issues...
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
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.
I assume Derek's advice makes sense for Korean culture where manager and team dynamics are different.
* 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.
So I think any decent manager would notice it.
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?"
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.
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.
^^^ Here's your comment without the pointless condescending remarks. Notice the difference?
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.
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?
Solve it yourself, guys. Perfect.
http://www.joelonsoftware.com/articles/fog0000000072.html
This is where you need a decision from someone else.
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.
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.
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.
But the advice is something everyone must learn.
I had number of such situations. You are almost always better off without that in your life.
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.
Which included incredibly detailed nuances like pixel-level critiques of icons and UIs, which is literally what the author defines as "your 2 cents".
> demonstrably the worst manager one could have so I wouldn't draw too many conclusions from him
Except how to build one of the most valuable companies in the world? Seems like a fair criterion for good management.
> 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.
> It’s perfect. Great work! Let’s ship it.
Ditto!
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!
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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.
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.
> resentment and feelings of not being appreciated
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.
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.
Welcome to Silicon Valley!
The motivational difference between it being a shade of blue I like vs. just being shipped right now because it's done is a gulf.
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?"
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.
> 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.
----
[0] http://www.cc.com/video-clips/ukn1y5/the-daily-show-with-tre...
> 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.
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.