Bikeshedding - where people feel the need to give feedback even when none is needed, resulting in inane comments about things that don’t matter.
Pro tip, if you’re a software engineer, especially working on UIs - leave something annoying on your UI in the demo. Something small enough to not be a huge deal but big enough so that an exec or director would notice it. Make a button slightly too big, or the width of a divider too large. They’ll call that out, feel like they contributed, and likely the entire demo will be spent talking about the inane thing on the page. Then go fix the 2-ish lines of code and move on with your day.
I used to do a similar thing when I was in middle/high school. I do not consider myself to be a great writer, but when I was in school, I did very well for what my teachers expected at my grade level (I liked to read a lot). Most teachers I had wanted us to write essays or stories and then spend the next few classes fixing up our rough drafts into a final draft. I knew my first rough drafts were better than most other students’ final drafts so I would purposely put in spelling and grammar issues and maybe spend a few sentences off topic. Those would be the things I fixed to create my final draft. Doing that gave me more time to focus on subjects I had a harder time with.
Illustrators know this as the “hairy arm”: adding an undesirable minor detail to give the art director something with whose removal they can put their stamp on the project, without wrecking the rest of it or making too much work for the artist.
When designing, I try to provide options and typically one is a “throw away” simple option that took no effort. Like I change a color or a minor element. Just to provide the illusion of choice.
If I don’t provide multiple options on the initial drafts people lose their damn minds. They try to redesign something that shouldn’t have their input. This let’s them talk about which one they like better and not fixate on one design and tear into it.
Also I get the low effort feedback. Everyone has some opinion on visuals, because it’s easy to say “what if…”. Big part of the job is coming prepared knowing what people will start picking at with answers ready to why you did what you did. Or just bullshitting on the spot.
I use this a lot in presentations, and have taught this to colleagues I have mentored.
However I kind of understand the urge, when I’m on the other side and have to give feedback, saying “everything looks great” seems kind of lazy, or a cop-out. I have to fight the need to find something to nit-pick.
I think bikeshedding is more commonly that people will argue about the materials of the bike shed over more important points of discussion. ex a bad thing because it detracts from more important decisions, not because it requires unnecessary change
queens duck as mentioned below better fits the tip (which is valid)
I use it with customers, to hide something I haven’t quite figured out yet or know will result in a lengthy conversation that’s been had a dozen times before with no change in outcome
my team knows that there’s only so much time for review, so if they put dumb things to catch in reviews of their work, they can slip larger things by the quality review process. they also understand that that’s on them — if there’s so much wrong with something that it would simply take too long to point it all out, the problem is with their work, not with the reviewer.
only somewhat related, but shout out to the guy who would repeatedly make the same mistakes on drawings over and over again. he would put up a review package of 100 drawings, the common mistake would be noted explicitly on the first couple, and then on the 3rd the note would read “applies to all subsequent drawings”. that guy would then only fix the ones that were explicitly called out. either a complete dumbass or lack of giving a shit, I don’t know which. I’ve probably worked with both.
When I was a software pm I loved being able to tell someone “you nailed it that’s awesome can’t wait to show this to [person relevant to their review packet]!”
That’s the value that the engineers wanted me to add.
Been in contexts to give feedback and people pressure me when I say things like “I’m not a stakeholder, so no standing to give feedback” or “Ok, seems fine”. It’s evidently not “leadership” if I’m actually content with something or content to leave something alone I have no right to meddle with.
Actual leadership is, “This work looks good, let’s not waste any more time talking about it.”
Don’t be noncommittal, instead approve the work and push for moving forward. When someone suggests that more criticism is needed, indicate that they’re the one holding up progress.
Though you do run the risk that they love something you intended to be annoying. “The dart board value selector widget will make our product fun and exciting for gen Zs, I must report this to the board immediately so we can invest in converting all of our widgets to darts-based!”
Or make it too annoying and they might question your competence. “Yeah, he did quickly change the button that counted how many times you pressed it to a text box where you can enter a value but why would he have thought we’d have wanted that button in the first place!?”
Bikeshedding - where people feel the need to give feedback even when none is needed, resulting in inane comments about things that don’t matter.
Pro tip, if you’re a software engineer, especially working on UIs - leave something annoying on your UI in the demo. Something small enough to not be a huge deal but big enough so that an exec or director would notice it. Make a button slightly too big, or the width of a divider too large. They’ll call that out, feel like they contributed, and likely the entire demo will be spent talking about the inane thing on the page. Then go fix the 2-ish lines of code and move on with your day.
I used to do a similar thing when I was in middle/high school. I do not consider myself to be a great writer, but when I was in school, I did very well for what my teachers expected at my grade level (I liked to read a lot). Most teachers I had wanted us to write essays or stories and then spend the next few classes fixing up our rough drafts into a final draft. I knew my first rough drafts were better than most other students’ final drafts so I would purposely put in spelling and grammar issues and maybe spend a few sentences off topic. Those would be the things I fixed to create my final draft. Doing that gave me more time to focus on subjects I had a harder time with.
Your tip is also known as The Queen’s Duck.
Illustrators know this as the “hairy arm”: adding an undesirable minor detail to give the art director something with whose removal they can put their stamp on the project, without wrecking the rest of it or making too much work for the artist.
When designing, I try to provide options and typically one is a “throw away” simple option that took no effort. Like I change a color or a minor element. Just to provide the illusion of choice.
If I don’t provide multiple options on the initial drafts people lose their damn minds. They try to redesign something that shouldn’t have their input. This let’s them talk about which one they like better and not fixate on one design and tear into it.
Also I get the low effort feedback. Everyone has some opinion on visuals, because it’s easy to say “what if…”. Big part of the job is coming prepared knowing what people will start picking at with answers ready to why you did what you did. Or just bullshitting on the spot.
ah, so like pretty much every job ever. got it.
I use this a lot in presentations, and have taught this to colleagues I have mentored.
However I kind of understand the urge, when I’m on the other side and have to give feedback, saying “everything looks great” seems kind of lazy, or a cop-out. I have to fight the need to find something to nit-pick.
I think bikeshedding is more commonly that people will argue about the materials of the bike shed over more important points of discussion. ex a bad thing because it detracts from more important decisions, not because it requires unnecessary change
queens duck as mentioned below better fits the tip (which is valid)
This is valuable advice I wish I had known decades ago. You can’t always avoid shit managers.
or customers.
it works everywhere, even on me
I use it with customers, to hide something I haven’t quite figured out yet or know will result in a lengthy conversation that’s been had a dozen times before with no change in outcome
my team knows that there’s only so much time for review, so if they put dumb things to catch in reviews of their work, they can slip larger things by the quality review process. they also understand that that’s on them — if there’s so much wrong with something that it would simply take too long to point it all out, the problem is with their work, not with the reviewer.
only somewhat related, but shout out to the guy who would repeatedly make the same mistakes on drawings over and over again. he would put up a review package of 100 drawings, the common mistake would be noted explicitly on the first couple, and then on the 3rd the note would read “applies to all subsequent drawings”. that guy would then only fix the ones that were explicitly called out. either a complete dumbass or lack of giving a shit, I don’t know which. I’ve probably worked with both.
When I was a software pm I loved being able to tell someone “you nailed it that’s awesome can’t wait to show this to [person relevant to their review packet]!”
That’s the value that the engineers wanted me to add.
Been in contexts to give feedback and people pressure me when I say things like “I’m not a stakeholder, so no standing to give feedback” or “Ok, seems fine”. It’s evidently not “leadership” if I’m actually content with something or content to leave something alone I have no right to meddle with.
Actual leadership is, “This work looks good, let’s not waste any more time talking about it.”
Don’t be noncommittal, instead approve the work and push for moving forward. When someone suggests that more criticism is needed, indicate that they’re the one holding up progress.
Though you do run the risk that they love something you intended to be annoying. “The dart board value selector widget will make our product fun and exciting for gen Zs, I must report this to the board immediately so we can invest in converting all of our widgets to darts-based!”
Or make it too annoying and they might question your competence. “Yeah, he did quickly change the button that counted how many times you pressed it to a text box where you can enter a value but why would he have thought we’d have wanted that button in the first place!?”