Brains in Jars Don't Have a Failover Plan

Fri, 06 Nov 2026 00:00:00 +0000

It was nearly midnight on a Friday, and I was the one person finishing the work behind a sales deal our rep had called huge for the company. My manager was a few feet away, scrolling something on his phone, a kind of show of solidarity, when it rang. He put it on speaker and set it down on the desk between us. The sales rep wanted to know if the work would be done by Monday morning, like he’d promised the client it would be. My manager didn’t check with me. He didn’t ask what was left, or what the weekend would cost me to get there. He just said it, loud enough that I heard every word from across the room: “I don’t care how long it takes, you will get it done for Monday morning.” I think he hung up proud of himself.

I didn’t have the word for it yet, but I knew exactly what had just happened. I wasn’t a person with a weekend, or an opinion about my own weekend. I was a brain in a jar that had just been told how hard to squeeze. I locked my computer, turned off the monitors, and went home anyway.

There’s a model of software engineering that most orgs run on without ever naming it. Psychologist Cat Hicks calls it Brains-in-Jars in her book The Psychology of Software Teams: developers treated as isolated, interchangeable cognitive units, not people with social needs, learning curves, context, or limits. Just brains, floating in jars, producing output when you apply the right pressure.

It shows up in more places than a Friday night phone call. It’s hiring for the unicorn, the superstar, the rock star, as if the right single hire fixes a team instead of just relocating the risk. It’s cramming Agile or Scrum onto a team because leadership wants to “better predict” the work, as if predictability is a process you bolt on instead of something a healthy team earns. It’s “call Joe,” because Joe’s the only one who really understands that system, and nobody ever got the chance to learn it alongside him. It’s the hard-to-see, easy-to-feel animosity between your team and mine, the kind that gets treated with a trust exercise, a sudden round of management training, or an offsite to “foster collaboration,” instead of whatever actually caused it. These days I think about team psychology about as much as I think about system reliability: the psychology of the org I’m in, how it fits inside the company around it, the things that come out of executive leadership, the good calls and the baffling ones. Reading Hicks’s breakdown, I kept hitting the same wall: every one of those is a reliability failure wearing a management costume. We just don’t call it that when it’s happening to people instead of servers.

Picture a Jenga tower. Each of those moments, the hiring call, the process mandate, the “call Joe,” the offsite, is one small move on one small block. None of them look like much on their own. But the blocks that were actually holding the tower up get pulled and stacked and rearranged, over and over, until one day the whole thing comes down, and nobody can point to the move that did it. And as long as we’re counting the blocks, their shape, their colour, how fast we can stack them, we miss the thing that actually mattered: the shape of the tower, and how little it would take to collapse it.

Cramming a process onto a team to make the work predictable is a Jenga move dressed up as a fix. It’s a system with no error budget: run a service hot, no margin, no slack, no room for anything to go wrong, and for a while the throughput looks great. Then one dependency hiccups, and because there was never any slack in the system, the hiccup becomes an outage. A team forced into that kind of brittle predictability is the same thing wearing a different badge: no slack for learning, no room for a bad sprint, no margin for the thing nobody planned for. It looks like a success story right up until the people who made it happen quietly start leaving, which is the human version of a cascading failure, and Hicks has her own name for it: black ice, dangerous precisely because the surface still looks fine. She points to research showing that the more a team fixates on being seen as high performers, the more they avoid anything that risks looking like a failure, which happens to be the exact behavior that produces learning and resilience in the first place. You don’t get a sustainable team by running it at 100% capacity forever, and you don’t get a reliable system that way either.

“Call Joe” is a single point of failure with a name attached. We’d never sign off on an architecture where one box, no replica, no failover, carries all production traffic, but we’ll happily build a team around the one person who really understands that system. It feels efficient the same way a SPOF feels efficient, right up until Joe goes on vacation, gets sick, or leaves, and the org finds out the hard way that nobody else ever got the chance to learn the thing, because knowledge-sharing was never worth the “cost” of slowing Joe down. Hicks has studied this directly: a strong learning culture predicted team effectiveness better than any individual trait did, and it’s backed by a wider research literature she cites, finding the same thing in study after study where anyone actually bothered to measure it.

Hicks gives this its own chapter, “More Bands and Fewer Rockstars,” tracing where the rockstar-developer myth actually came from and what the evidence says should replace it: not a lone genius, but something closer to a band, where each person’s output is shaped by who they’re playing with. Worth reading in full if the “call Joe” story above sounds familiar. Chapter summary and discussion guide here.

The animosity between teams, the one the trust exercise and the offsite were supposed to fix, is a team with no cross-training and no documentation, where asking a question gets you a look instead of an answer. In infrastructure terms, it’s the on-call rotation where nobody writes runbooks because admitting you needed one feels like admitting weakness, so every incident starts from zero knowledge, every time, with whoever drew the short straw that week. Hicks found this pattern strong enough that developers routinely hide the fact that they’re still learning something, from their own teammates, because visible learning reads as weakness instead of what it actually is: the thing that makes the whole system more resilient the next time something breaks. The trust exercise doesn’t fix that. It papers over the block that’s already missing.

None of this is all downside, and pretending otherwise would be dishonest. SREs build interchangeability on purpose, cattle, not pets, because a server that’s easy to swap is a server that’s easy to recover when it dies. Brains-in-Jars thinking is that same instinct pointed at people, and it’s not an unreasonable instinct on its own, it’s just aimed at the wrong unit. The catch is that redundancy in people doesn’t come free the way it does with a stateless server. You only get a second person who can cover for Joe by spending the exact thing the model treats as overhead: time, mentorship, the slow work of someone actually learning the system instead of being told to go faster. Measuring lines of code or ticket counts is cheap. Measuring whether anyone besides Joe could survive losing Joe is hard, slow, and never shows up on a quarterly chart, so the easy number wins by default, right up until the quarter it doesn’t.

Every reliability engineer already knows this trade. A system with no redundancy, no slack, and one person who understands it is cheaper to run and faster to ship, until the day it isn’t, and that day always costs more than the savings did. We just haven’t been willing to say the same thing about the people running the system, the ones we keep counting by the block instead of looking at the tower.

If you want to know whether your own team is built this way, you don’t need a framework. Ask yourself the uncomfortable version of two questions: if your best engineer disappeared for a month tomorrow, what actually breaks, and how many people could cover it without a two-week ramp? If the honest answer to either one is bad, that’s not a culture problem. That’s an architecture decision about people that nobody ever wrote down, sitting in exactly the spot where everyone assumed they were just counting blocks.

That Friday night didn’t cost the company anything it could see on the following Monday. The deal shipped out later than promised, same as it always does. It cost a block out of the tower instead, the kind nobody notices missing until years later, when they’re trying to figure out why the person who used to stay until midnight for them doesn’t work there anymore.

Management on Coffee or Blog

Brains in Jars Don't Have a Failover Plan