It’s happened enough that I don’t think it’s a coincidence: people tend to like new ideas better the second time they hear them. Remember how you felt when you heard Ben Affleck would be playing Batman? Seemed pretty dumb, right? But then you remembered the others actors in the role and that Micheal Keaton succeeded where George Clooney failed. So, you know, maybe Mr. Affleck will do just fine. Some ideas need to be acquired incrementally.
Unfortunately, there’s no way to know beforehand if these complaints are valid or not. They represent a natural knee jerk reflex to any abrupt change. Truthfully, we often sympathize because we all went through the very same shock treatment when we first heard the new idea internally. But we also know that after a week or so the surprise won’t be so troublesome. Like the change Facebook or Twitter recently made that prompted waves of protests and petitions, changes on Stack Overflow quickly become the new normal.
Unless they just don’t work out of course. Critical feedback works best when it includes specific problems caused by the change:
Hmm . . . When I do X, I expect to see Y. Now I’m going to get Z instead and that will break my workflow.
We can work with the developers and designers to accommodate the workflow or provide a workaround. Or failing that, there’s a chance to address shortfall. We pitch ideas to our communities for the very purpose of getting feedback we hadn’t considered yet. Our casual handicapping of voting on meta leaves plenty of arbitrage opportunities. Features we think will be met with popular approval hit strong headwinds. Features we are certain will be unpopular get wide acceptance. It’s uncanny.
I just let slip a major cause for the second post is often better scored than the first: we don’t often follow up when the first post is well-received or when we are convinced to change course. Let me break out a logic table to illustrate:
|Positive reaction||Negative reaction|
|We agree||No followup||No followup|
|We disagree||???||Second post|
So the only time we really publish a response to meta is when we think we have a good idea that folks didn’t understand the first time around. There’s a story in Thinking, Fast and Slow about how criticism often looks more effective than praise. Daniel Kahneman looked a the performance of IDF pilots after receiving a commendation or reprimand. Statistically speaking, future performance could be explained simply by reversion to the mean. In other words, commanders tend to praise pilot doing exceptionally well and, after praising that achievement, notice they had “lost their edge”. Meanwhile, pilots who had a random string of bad luck would start to look more average not because the commander yelled at them, but rather as a result of statistical phenomenon.
While it can seem like we consistently screw up initial communication, it’s probably better to say we don’t often restate meta posts when we get the communication right. We only ever write second posts when we don’t get the feedback we want or aren’t swayed by it. And that’s a bit of shame now that I think about it. We don’t think of our goal as browbeating our users into submission, but rather as building the best products we can with our user’s help.
It bugged me to put
??? in the table above. Here’s how the chart
really should look:
|Positive reaction||Negative reaction|
|Good idea||Do it!||Address concerns|
The hard part—the bottom line—is being self-critical enough to recognize when our ideas aren’t a good idea. The next hardest part is admitting publicly that we screwed up, not with the way we communicated, but in the idea itself. Far too often, we don’t complete the loop on bad ideas even when we recognize them.
I wrote in my review of Stack Exchange’s 2015 accomplishments:
At “Stack Exchange, Inc doing business as Stack Overflow”, we think of our communities as our partners. The company’s responsibility is to provide our users with the very best platform for helping each other and creating lasting artifacts.
The challenge as our company grows and becomes more specialized is to continue letting our partners peer over our shoulders as we work. There’s no such thing as too much communication among friends.
Send feedback by creating a GitHub issue.