Well, in this case it mostly didn't happen in the future - most of it happened last May. Our failure to catch it recently was a mistake, but the root error was building it that way in the first place. Still, I take your point.
After last year's snafu, we had a company-wide retro to discuss what had happened. It lasted a couple of hours, during which several people (including myself) were pretty blunt about what we thought. I don't want to get into a complete postmortem here, if only because it would make this post require ten paragraphs of niche internal culture context, but the biggest problem was that we had an internal communication breakdown. Many people who were uncomfortable with what we were doing, and who could have predicted the public response, did not feel empowered to speak up about it. Not in the sense that they'd face backlash for doing so, but in the sense that they felt they'd be ignored. This was less true than they thought - had they all spoken up at once, it probably would have made a difference - but more true than it should have been.
Since then, a number of people within Triplebyte (including Ammon, but also myself and various others) have made an effort to create space for those kinds of concerns.
One of our defining traits as an organization is that we're very good at creating coherent internal narratives. Everyone knows what we're doing and why. But the flip side of that is that in the effort to create clarity, we sometimes run over inconvenient details like "wait isn't that a terrible idea". That means that to avoid problems like last year's, we need to be explicit and deliberate in actively seeking out dissent about what we're doing, especially from people who are not the very assertive strong personalities that tend to show up in leadership. That doesn't mean that dissent is always right - strategic decisions are difficult and complicated, people do sometimes lack the visibility to see why they're made, and in a room of fifty people there's always going to be some disagreement - but it costs us very little to listen to it and (as we learned last year) can cost us dearly when we don't.
(Actually, as I was preparing to submit this post, one of our engineering leads pinged me on Slack to suggest ways we could avoid mistakes of the kind that spawned this thread - TLDR, build less automated shit that we can forget about until it bites us.)
I realize this reply is a little bit nonspecific ("make space for"? what does that even mean?), but that's the nature of solving a culture problem. You're necessarily wrestling with subtle cues and unspoken assumptions rather than with a thing where you can go "ah, yes, we just need to change step 2a of our product development process". But for what it's worth, I think we've gotten better about making sure we consider how people feel about what we're doing, and we've avoided some potential bad decisions in the year since then as a result.
This post is really, really refreshing to read. As a startup founder I empathize deeply with how difficult it is to "actively seek out dissent." Product pipelines move quickly, teams need to feel they can have initiative to deploy things independently from the rest of the org, as a cross-team leader it's unhealthy to squash that initiative... but at the same time you need to set boundaries about when something needs consensus.
IMO this is why it's vital to have Core Principles at a company (in this case, "user trust" might be a reasonable wording), both at a product level and a meta level, about how the world needs to see the company and the company needs to see itself. And when any employee, no matter where, feels something might breach Core Principles, it should be a five alarm fire that the C suite should know about and react to (or delegate said reaction), and if it turns out to be a misunderstanding, that employee should not feel they expended any political capital in escalating their concerns - at worst they might just require more context about why something is either a non-issue or necessary (which in this specific case doesn't apply), and leadership should be excited to see them growing by asking those questions. Ideally, it's as easy and low-risk as submitting an internal bug report.
Of course, I can imagine this stops scaling at some point. FAANG need very different approaches to this problem, and that's probably an entire business school class to answer. But I feel any smaller organization with a focused product can move in this direction!
After last year's snafu, we had a company-wide retro to discuss what had happened. It lasted a couple of hours, during which several people (including myself) were pretty blunt about what we thought. I don't want to get into a complete postmortem here, if only because it would make this post require ten paragraphs of niche internal culture context, but the biggest problem was that we had an internal communication breakdown. Many people who were uncomfortable with what we were doing, and who could have predicted the public response, did not feel empowered to speak up about it. Not in the sense that they'd face backlash for doing so, but in the sense that they felt they'd be ignored. This was less true than they thought - had they all spoken up at once, it probably would have made a difference - but more true than it should have been.
Since then, a number of people within Triplebyte (including Ammon, but also myself and various others) have made an effort to create space for those kinds of concerns.
One of our defining traits as an organization is that we're very good at creating coherent internal narratives. Everyone knows what we're doing and why. But the flip side of that is that in the effort to create clarity, we sometimes run over inconvenient details like "wait isn't that a terrible idea". That means that to avoid problems like last year's, we need to be explicit and deliberate in actively seeking out dissent about what we're doing, especially from people who are not the very assertive strong personalities that tend to show up in leadership. That doesn't mean that dissent is always right - strategic decisions are difficult and complicated, people do sometimes lack the visibility to see why they're made, and in a room of fifty people there's always going to be some disagreement - but it costs us very little to listen to it and (as we learned last year) can cost us dearly when we don't.
(Actually, as I was preparing to submit this post, one of our engineering leads pinged me on Slack to suggest ways we could avoid mistakes of the kind that spawned this thread - TLDR, build less automated shit that we can forget about until it bites us.)
I realize this reply is a little bit nonspecific ("make space for"? what does that even mean?), but that's the nature of solving a culture problem. You're necessarily wrestling with subtle cues and unspoken assumptions rather than with a thing where you can go "ah, yes, we just need to change step 2a of our product development process". But for what it's worth, I think we've gotten better about making sure we consider how people feel about what we're doing, and we've avoided some potential bad decisions in the year since then as a result.