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.