Don't add your 2 cents
sivers.org
sivers.org
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.
In a situation where your subordinates are unsure of what to do and they really don't have the skills to do it alone, you have to provide leadership and encouragement. Lead by example, show them how to do it, and let them iterate without too much micromanagement.
When your subordinates are competent but lacking confidence, it's often a better option to stand back and say nothing. The "ownership" piece is huge -- if this is the first big project you've "owned", you'll probably iron out the kinks even if I don't say anything to you. Also keep in mind is that there are many correct ways to solve a problem; while your solution may not be the one I would go with, you're more comfortable with your solution and can probably see things about it that I can't. I trust you to be the expert on the solution; I've got bigger things to worry about like how I'm going to continue servicing my same workload with a 10% cut in budget.
The goal is to move everyone up from "unconfident and incompetent" to "confident and competent". Some people also go through "incompetent and confident", which is also something where the best option is often to stand back and act as a safety net while letting the person learn whatever lesson they needed to learn.
The article is referring to things that are ostensibly subjective changes that don't make a tangible, measurable difference. The suggestions in question are often the boss putting their mark on something so demonstrate that they've made an impact.
Even if the suggestion actually improves the product, suggesting something that deflates team morale more than it brings to the design means the change isn't worth it. As a boss that's quite a hard lesson to learn because logic says you should be doing whatever you can to ship the best possible product. In reality, especially in the long term, the product is going to be better if you temper your suggestions in favour of the team.
Bosses must make sure that they're not all critic with no praise. No one wants to be critiqued all the time without kudos for the good portions and hard work. Tone, body languages, and timing all play into how an effective leader communicates positively or negatively to a team member.
On the flip side, staff need to be able to separate their personal worth from the work that they do. This can be especially tough in some fields and with some personality types such as art, design, and programming. When your work is highly subjective, when you're starting your career, or when their are a million methods to achieve the same goal (with some methods being better without obvious reason as to why), it can feel like critiques are attacking the person instead improving the work.
An anecdote from my personal life: I worked as a paralegal for a while. I started off mediocre at the job, but after a management change, my new boss had manuals that gave standardized instructions on how to do nearly everything. That's when I started to excel. There were many specific times when I would give my boss documents, but he never let them slide. Ever. He would say, "The language and structure of this document is perfect, but you know I can't let anything slide without having something to change." He'd mark something subjective such as substituting a synonym with the same meaning and tone or moving a sentence that didn't affect the language of the paragraph. It never bothered me, but I can see how that would definitely grate on others. In spite of this, he was always full of praise with nothing but positive remarks.
::Shakes fist:: lawyers! ;-)
When you get input you appreciate, you intrinsically appreciate it.
The challenge is that statistically, the more senior guy understands why changes are needed, while the more junior guy is less likely to understand the context, or probabilistic benefit of the offered change.
So, this has to be tempered, and like all things, has to be evaluated on a case by case basis.
No, no, no, a thousand times no!
The person most involved in the problem will almost always better understand the context of the problem, because they are spending far more time on it.
This is another important reason for the boss to refrain from suggesting changes, unless it's clear and important. As often as not, the boss's change will be worse, but there is a lot of pressure to not push back and just do what the boss says.
This whole topic is the punchline to many Dilbert pointy-haired-boss cartoons.
You're making a black and white rule. The black and white rule I'm advocating is that the boss should know when it's black (intercede) and when it's white (let their good v. subjectively interpreted better decision stand).
Of course, the counter-argument is that it's better to let the junior person make their own mistake and learn from them. And it is! Some/most of the time. But some some of the mistakes might cost too much and need to be avoided.
If you think my mentality is Dilbertesque, go ask your supervisor what kind of decisions they wouldn't let you make.
Maybe this is a little too personal for me.
Never been a manager, don't really want to be one. But I have been a developer for a long time, so I often have as much or more experience than my supervisor at this stage of my career.
The anecdotes that stick in my memory, is when I knew the right decision, explained the rationale for the right decision...and my boss made the wrong decision, without being able to explain why his decision was better. I distinctly remember one incident where, several months after going with my boss's decision, which turned into a bug generating maintenance nightmare, my boss ruefully smiling at me and saying "Yea, I think we should have done (jimbokun's original idea)."
Yea, thanks, now we're wasting who knows how many hours on the fallout of the original decision.
I appreciate those who are willing to take on the hard job of management, and OK with them potentially making more than I do. But good managers find and hire people who know how to do their job and let them do it. So if a manager has an inclination to change something, they should first assume they are wrong and their subordinate is right, ask the person doing the work to explain how they made their decision, ask for clarification if the manager still thinks a change should be made, and only then suggest the change if there is something clearly and obviously wrong with the reasoning behind the decision, making sure to explain the reason for the change.
I saw late2part situation happen a lot of times: A junior dev find a quick an elegant way to solve problem X. Senior dev comes and say: It's good but you should do it that way because it <will be more testable / require less maintenance / any advice only someone with more experience on the product's codebase can tell>
If the senior dev is bad / doesn't have time at the moment, he will skip explaining the "because" part, and the junior dev might be frustrated. With good communication a good faith from both parties, the junior would later understand.
The manager anecdote "my boss made the wrong decision, without being able to explain why his decision was better." would be a different situation, and in that case, that manager should definitely have kept his opinion for himself. At least he recognized his mistake later on.
So 2 stories: One where the junior dev is too "know-it-all", one where the supervisor didn't put enough trust in his subordinates.
There's a much longer post to be written on the ways to provide feedback and create a constructive conversation around solutions and seniority is almost never the reason someone is right but experience most often is.
"2 cents" is an opinion. Opinions are cheap, and as this demonstrates, they are noxious when coming from an authority figure.
But I know very well that when I put an incredible amount of thought and reason into picking every little detail, I DO NOT want some non-technical manager to come to me and say "the shade should be blue". His comments should not be so shallow to tell me he doesn't care, but neither should his comments be that decisive, when I cannot understand.
Your point of view comes from a person who is always looking for guidance, like someone fresh from college. The day you get lift off to the point where you are working for someone who has little expertise in your field or you have developed comprehensive depth where you can work independently, you will want ownership and you will feel annoyed at the "decisive" comments you receive.
To all others who are reading this: instead of being decisive or making shallow comments, learn to explore the work of your people, the great parts, and the weak parts. You will immediately hit upon the areas where the person is seeking guidance, and the areas where the person has resolved his mind with limited information.
He got everything setup how he wanted it and then added something that looked blatantly out of place, like a red border on one side of a div. Then they would say, "Looks great! If we can just lose that red line I think we're all set."
Worked every single time. He is somebody who's always been great at reading people and adapting to their behavior. If anything I'd say asking managers not to do the above costs people the opportunity to learn skills like this. It's a lesson that's served me well for my entire career.
The point is that when the difference is opinion (or close to), such as matters of color, font, position, etc., there is no reason to tweak things. If you're not going to make a big difference, don't make one at all.
I think the article is simply that if you are pushing for a very small change, one that would make not much difference, and is just a matter of opinion, then don't do it as it will impact negatively the original author.
Bosses shouldn't be bossy except in rare circumstances.
Most of aren't the creative director, so don't enforce your idiosyncratic aesthetic on your team members.
And I'm not only talking about issues where a non-technical manager critiques a technical project. If a non-technical manager has a comment about a UX choice, it should be valued not because it came from a "boss," but because it came from someone who did not make it. Something that seems really obvious to the implementer will not always be obvious to the general public and that is where non-technical feedback, even from your boss, is valuable.
This isn't about issues that can be right or wrong or technical expertise, it's about bike-shedding, except there's no argument about the color, there is simply someone changing the color to demonstrate that they can.
I agree with you in the open source situation that a more senior review adds valuable feedback.
Though I think that context is quite different from the employee-manager dynamic Derek describes in the article.
Boss sees a typo or brand color is wrong? Yeah, they say something. Boss just thinks their idea is slightly better on a hunch? Don't say something.
It's good advice.
The idea that "ownership" can be lost by 2 cent changes is absurd. What happened to wanting team input anyway? Weird piece.
It's likely that already the project has a combination of elements coming from more than one person anyway.
I think it's clear that this isn't suggesting withholding of all feedback when appropriate. It's saying that a casual, "I like blue" when the design being presented is purple isn't really helpful. If the boss has data that shows that actually blue increases conversion by 5% then it is not just this "two cents" that the article is talking about, it's an entirely different conversation that doesn't fall under the scope of this article.
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."
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
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.
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.
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.
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.
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.
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.
> It’s perfect. Great work! Let’s ship it.
Ditto!
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.
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.
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.
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.
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.
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.
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 motivational difference between it being a shade of blue I like vs. just being shipped right now because it's done is a gulf.
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!
Welcome to Silicon Valley!
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?"
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?
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.
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.
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.
This is where you need a decision from someone else.
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.
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.
https://en.wikipedia.org/wiki/Law_of_triviality
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.
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.
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.
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.
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.
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.
But the advice is something everyone must learn.
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.
> 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".
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.
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'.
These are extreme examples, but you get the idea.
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.
FTA:
"What if the work is all wrong? Obviously, if there’s more than “2 cents” worth of stuff that needs to change, then this rule does not apply."
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.
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.
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.
This empirically isn't true, as I am one counterexample (as the employee).
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.
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.
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.
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.
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.
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.
That is exactly what it says.
"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.
http://www.creativebloq.com/career/graphic-designers-price-l...
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.
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.
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.
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.
Trying to game professional relationships goes both ways I guess :)
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?)
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.
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.
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.
"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.
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.
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.
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.
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.
[1]: http://bikeshed.com/
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.
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.
I had number of such situations. You are almost always better off without that in your life.
I cringed. It's not perfect, it's at best excellent.
Is this kindergarten or grown-up life?
Especially in creative areas it pays to let other people look at your stuff and get feedback. It is simply too easy to just get stuck on a path.
Works with kids, too.
> 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...
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.
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.