Trending topics
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
If this flavor text works for your org, wonderful, but find some equivalent flavor text which works for your org.

Mar 13, 11:08
“WTBU” is one of the most useful communication technologies I know of. It stands for “Watch Team Back-Up”, I believe it originated to reduce mistakes on nuclear submarines.
You prepend it to a message to someone where you’re pointing out something that might be obvious, but you want to check/confirm that they’re on top of it. For example, you might say “WTBU: you checked that we’re cleared to share this info with XYZ person?”
It takes the pressure/ego out of the message, by letting you communicate something to the effect of “I’m not saying this because I think you’re incompetent/dumb, so ignore this if it isn’t relevant/useful—I just really want to make sure we don’t mess up/make silly mistakes, and smart/competent people can make silly mistakes!”—except once you’ve coordinated on using the letters WTBU to communicate that, you can just say “WTBU:”.
This lets you now check basic/obvious things with coworkers much more easily and with less ego/emotion, which makes it much easier to catch mistakes in advance.
Worth considering adopting into your org as a standard communication practice!
(Japanese salarymen engineers are steeped in a culture of confirm confirm confirm the confirming and while it takes a bit of getting used to you'll really appreciate it during all the incidents you don't have.)
(The other bit of organizational technology you can steal there: if a junior engineer asks a "dumb question" the most senior engineer present should repeat the dumb question. It's not a dumb question if the senior engineer has it, after all.)
(25 year old: "... Is that prod?" Senior engineer, quickly: "IS THAT PROD.")
(You should generally make tooling robust to this mistake, but since many orgs don't or use vendors that don't make it easy, the issue here is that sometimes commands intended to be run against development or test environments are run against the production environment.)
(Bites more than a few orgs every year, for want of a 25 year old seeing the word "production" in a terminal and thinking "That's odd, didn't expect to touch prod in this procedure.")
"You could also just not have a hierarchical culture."
Best of luck/skill to everyone with regards to org cultural design, but if one is not in denial that one factually has a hierarchical culture, one can design processes which take notice of that fact and use it positively.
Incidentally in early 2026 we have synthetic 25 year olds an API call away but our terminals do not yet constantly have passive anomaly detection, which _seems like an opportunity_ (and/or a mistake).
Terminals are far from the only site of operator error which we could catch constantly. Another trivial one is email service providers. It should be 95% less likely to send a mistaken blast email given the ability of an LLM to review every request with a tweet-sized prompt.
"bob at just attempted to send a 400 byte message to All Customers Revised Revised Final [500,000 addresses] with subject line 'TEST: New privacy policy.' In one word, assess Intended or Mistake, considered from this user's perspective."
(If one doesn’t have at least five places in mind where this is trivially implementable ask your synthetic 25 year old to read last N years of after action reports and suggest a ranked list.
Or a real 25 year old! Also a good use of time.)
(If you’re worried about accuracy put it in advisory/canary mode and start putting in after action reports whether the canary chirped or not. Six months from now you should have overwhelming confidence on whether it is useful enough to block a human momentarily.)
(Alert fatigue is a real thing but that is because most of our alerting tools are *stupid* because we did not require them to be smart.)
91
Top
Ranking
Favorites
