Do you work at a company with hit and run style management? Joel Spolsky wrote a great article on this a long time ago. "Nobody at Juno owned anything, they just worked on it, and different layers of management happily stuck their finger into every pie, giving orders left and right in a style which I started calling hit and run management because managers tended to pop up unannounced, give some silly order for exactly how they wanted something done, dammit, without giving any thought to the matter, and leave the room for everyone else to pick up the pieces. The most egregious example was the CEO and president of the company, who would regularly demand printouts of every screen, take them home, and edit them using a red pen. His edits were sometimes helpful (spelling and grammar corrections), but usually, they demonstrated a complete lack of understanding as to what went into the screens and why they said what they said. For months later, we would have meetings where people would say things like “Charles [the CEO] doesn’t like dropdown list boxes,” because of something he had edited without any thought, and that was supposed to end the discussion. You couldn’t argue against this fictional Charles because he wasn’t there; he didn’t participate in the design except for hit and run purposes. Ouch." https://www.joelonsoftware.com/2000/03/23/command-and-conquer-and-the-herd-of-coconuts/
Yes, definitely see that here. A lot of feedback involves "CEO/EVP/SVP doesn't like x". Producing good work is hard.
Look up how the thing in question is currently performing. Do a simple cost and projected revenue comparison of making, user testing, or A/B testing the change. Compare that to what your current priorities are and see if it merits any immediate focus. Whether it does or doesn’t, validate the request by asking to meet briefly about it and explain why. Ask to understand why the change is being asked for if you don’t understand. Make it clear that the brief meeting is so that you can understand the request before moving forward and if at all possible, simply sit on the request until the meeting happens unless it’s clearly valid and more impactful than what you’re currently working on. Your excuse is “I wasn’t sure if it was more important than X to you” and/or “I wanted to better understand the impact you believed it would generate.” If you’re still at odds at the end of the meeting, ask to prove it out with some basic user testing or A/B testing. If they’re still unreasonable, just make the change, track the cost, and measure the impact positive or negative. Publish the results to them politely. Take the first request that generates a negative impact and use it to clearly make the point that testing whether something will work or not is important. If they’re still unreasonable after that, update your resume.
You know what really grinds my gears? That these forkers are the ones who push taking feedback while they themselves don’t take any feedback.
Does this happen at Twitch?
One of Twitch’s value is Take Feedback Well. Guess who don’t take feedback well?