The Golem Effect
How nice managers ruin careers
It was 2015. I was at Yahoo in Sunnyvale, newly appointed to an engineering manager role, and the purple badge still felt strange on my belt. My calendar had quietly replaced “fix the cache” and “write design doc” with “staff sync,” “perf calibration,” and “headcount review.”
And I had just hired a new engineer who would quietly change the way I challenged people.
It was her first day, and you can probably picture her: clean laptop, no stickers yet, and a Yahoo hoodie one size too big. Her orientation packet was half-folded in her backpack, and her notebook was open to the first page with the pen uncapped, ready to prove this wasn’t a mistake. She was fresh out of a bootcamp that promised to turn her into a Software Engineer in twelve weeks.
In my head, she became a system diagram, a brand new production service with no legacy and no scars, not yet tested by real traffic. She had lots of potential, but unknown failure modes. Somewhere in that mental diagram, I made a decision I didn’t say out loud. I decided to keep her safe.
I decided to be the “good boss,” the benevolent manager. I kept her off the on-call rotation to let her sleep. I kept her off incident bridges because she “didn’t need that stress yet.” I avoided scary deploys to keep her in the sandbox for a while. I gave her a safe tour of duty: small tickets, copy tweaks, and low-risk refactors. Every time a high-stakes piece of work landed, the kind that can go gloriously right or painfully wrong, I mentally moved it away from her.
It was too risky. Too visible. Too much. It all felt reasonable, even kind. But six months later, the results were not kind.
In standups, the space around her had a weight to it. She spoke last, if she spoke at all, and her updates sounded like someone afraid of stepping over a line she couldn’t see. “Still working on the settings page,” she would say. “Made some progress. Should be ready soon.”
She triple-checked work that didn’t need it. When a bug report mentioned a part of the system she had touched, she didn’t open the logs. She looked at me first, like a tenant checking with the landlord. She waited for reviews, for sign-off, for permission.
I told myself she was being thoughtful, careful, and risk-aware. I was wrong.
The One-on-One That Broke The Spell
Picture a small conference room that has seen too many performance reviews and not enough sunlight. One wall is glass, smudged with fingerprints and old tape marks where sticky notes used to be. Another is a whiteboard no one has ever quite managed to clean. The overhead light buzzes just enough to annoy you, but not enough to justify a ticket.
She sat across from me with her laptop closed. Both hands were wrapped around a paper cup that only held lukewarm coffee now but gave her something to hold on to.
I opened my usual script. “How are you feeling about the work?”
“It’s good,” she said. “I’m learning a lot.” Her voice was calm and practiced.
“Your work on the internal tools has been solid,” I said. “The team appreciates it.”
She looked down at her hands. The silence that followed stayed in the room a second too long. It felt less like reflection and more like waiting for a verdict.
“I was wondering about something,” she said at last. “When do I get to do the real stuff?”
I tried to gain a few seconds. “What do you mean by ‘real stuff’?”
“I mean the on-call. The incidents. The migrations.”
I laughed out of reflex. “This is real stuff,” I said.
She didn’t laugh. She met my eyes. “It feels like practice,” she said. “Dave gets the database. I get the button colors. If I mess up a button color, nobody cares. If I mess up the database, it matters.”
“Dave has been here three years,” I argued. “I’m trying not to overwhelm you. On-call is a nightmare. I’m doing you a favor.”
She didn’t argue or get dramatic. She just spoke in a flat, quiet voice. “But if you never give me the things that matter, how am I supposed to prove I matter?”
The buzzing light suddenly seemed loud. Inside my head, six months of decisions lined up: keeping her off the on-call rotation “for now,” reassigning a gnarly integration to Dave because “the deadline was tight,” saying “let’s not overwhelm you yet” and watching her nod because what else was she going to do?
All of it had felt like protection, responsible and reasonable. But from her side of the table, the story was different. I hadn’t been protecting her from failure. I had been quietly signaling that I expected it.
The realization landed like a weight in my chest. These decisions weren’t rooted in her capacity. They were rooted in my fear. Fear that she would fail and the questions would land on my desk. Fear that leadership would ask why I gave a big lever to someone “so new.” Fear that she would crack under pressure and I would be the one sweeping up.
I simply didn’t believe in her.
I didn’t say that sentence out loud. I just sat in that buzzing room while she held an empty paper cup and waited for an answer I didn’t have. She had walked in wondering when she would finally count as “real.” I walked out knowing I had quietly decided she wasn’t.
The Golem Effect: When Low Expectations Build The Box
Psychologists have a name for this pattern: The Golem Effect.
The name comes from Jewish folklore. A golem is a creature made of clay, brought to life to protect its creator, but which eventually turns clumsy and dangerous. It has strength but no soul; it does exactly what it is told and nothing more. In the same way, the Golem Effect describes what happens when leaders shape people with low expectations. You think you are protecting them. In reality, you are creating a smaller, more brittle version of who they could have been.
Most leaders have at least heard of its friendlier twin, the Pygmalion Effect. The story goes like this: In a school study, teachers were told that certain students were “late bloomers” who were expected to make big academic gains. Those students were picked at random, yet by the end of the year, the “late bloomers” had in fact pulled ahead. The teachers didn’t give them special textbooks or announce who was chosen. They just behaved a little differently around them. They waited a bit longer for answers, asked slightly harder questions, gave more detailed feedback, and smiled more.
Small shifts, repeated often, became meaningful distance.
The Golem Effect is the same machine running in reverse. Low expectations don’t stay safely inside your head. They leak into your calendar, your tone, and your assignments. You don’t need to dislike someone. You just need to quietly decide they are fragile, slow, or “not quite ready.” After that, your behavior tilts.
You explain a little less. You choose slightly safer work for them. You step in sooner when they hesitate. You sand the edges off your feedback so it never quite stretches them. It feels like risk management, but what you are really doing is quietly loosening the bolts on the track and then pointing to the wreck as proof you were right.
The person feels this. Not in one meeting, but in the season. The emotional temperature around them drops, the work they get shrinks, and the chances to prove themselves drift to other people. Soon, their performance fits the cramped outline you drew.
From your side, it looks like you predicted reality. You expected less, you gave less, and you got less. From theirs, you built the box and then blamed them for not filling more of the room.
Four Channels Where Belief Leaks Out
This leakage isn’t random. It follows a few reliable pipes, primarily through four channels: Climate, Input, Output, and Feedback. You can swear up and down that you are “treating everyone the same,” but these four will testify otherwise.
Climate: The Temperature Around Each Person
Climate is the emotional weather you bring into the interaction.
Who gets your full attention?
Who gets you half-present, half-scrolling Slack?
With someone you quietly see as a star, you lean in. You ask, “What do you think?” and wait for an answer. Confusion becomes a puzzle you are curious about.
But with someone you think of as junior or struggling, the air is thinner. You keep the meetings shorter. You steer the conversation. Silences feel like tests they are failing rather than space to think. You never say, “I don’t believe in you.” Your body already did.
Input: Who Gets The Map
Input is information and context.
Who gets the “why,” not just the “what”?
Who do you invite to the meeting where the real tradeoffs get discussed?
Two engineers can sit eight feet apart in the same pod and work in different universes. One has a map. The other has Jira.
The one with the map can anticipate. They raise risks before they explode and suggest alternatives that make sense. Later, you call them “strategic.”
The one with tickets waits for instructions. When they try to look ahead, they trip over constraints no one told them about. Later, you say they “don’t think at the right level.”
You denied them the map, then judged them for not navigating.
Output: Who Gets The Stage
Output is the work that leaves a story behind.
Who owns the scary migration?
Who presents at the org review?
These decisions rarely feel biased. They feel like prudence. “We can’t risk this demo going badly,” you think. “Give it to the safe pair of hands.”
Each choice is defensible on its own, but over time, a pattern sets like concrete. One person gets a chain of visible, story-rich assignments while another becomes the reliable background executor, always helping, never seen. Then promo season arrives and someone says, “I’m not sure we’ve seen her lead at that scope.” It sounds objective, but it is missing the part where you never let her near the microphone.
You cripple them, then blame them for limping.
Feedback: Pillow Or Ladder
Feedback is where your belief shows most clearly.
One engineer hears, “You handled that incident well. Next time, page SRE sooner so you are not alone at two in the morning. Also, I want you to lead the next review. I will be there as backup.”
Another hears, “Nice work. Keep it up.”
Both are compliments. Only one is a path. Specific feedback with a next rep and explicit support says, “I see you on a longer arc and I am willing to invest in it.”
Vague praise says, “Stay right here, please.”
Put climate, input, output, and feedback together, and you get something uncomfortable. You aren’t only watching performance. You are building the room performance is allowed to occupy.
What I Changed
I walked out of that one-on-one feeling like I had kicked a puppy, then forwarded the incident summary to myself as “good coaching.” But guilt alone does nothing. It just sits there and curdles. So we changed the playbook to break the spell.
1. Engineer The First Win
We redesigned onboarding around a single question:
How fast can this person do something real?
Up to that point, our version of onboarding looked like a museum tour of legacy monoliths and wiki pages. Weeks could pass before a new engineer shipped anything that touched an actual user. With her, we picked something else. We found a small but real bug in a flow that people complained about often enough to be annoying.
“It’s yours,” I said. “Fix it. Ship it by Friday.” She looked scared. “What if I break payments?” “Then we roll back,” I said. “And you fix it… again.”
We stripped unnecessary approvals and paired her with a senior who had actual bandwidth. She fixed it, she deployed it, and the world didn’t end. On Monday, someone dropped a comment in chat:
