Golem and Pygmalion effects — traps to avoid as an Engineering Manager

You heard Stella was a “coding prodigy” during the interview. When Stella ships a bug in week two, you see it as a “learning opportunity.” You pair with her, offer encouraging feedback, and give her a high-visibility feature for the next sprint. Stella feels valued, takes ownership, and crushes the deadline. You think, “I knew they were a rockstar.”

You were lukewarm on Dave’s technical test, fearing they might be a “slow starter.” When Dave hits a similar bug in week two, you think, “Here we go.” You take the task away to “save time” and give them documentation updates instead. You check in three times a day, signaling a lack of trust. Dave feels stifled and anxious. They stop asking questions to avoid looking “stupid,” fall behind, and eventually disengage. You think, “I knew they weren’t a great fit.”

Both engineers had the same potential on day one. The only difference was the lens through which you viewed them. These two biases — the Golem and Pygmalion effect (high or low expectations influencing performance) — are two sides of the same self-fulfilling prophecy coin. They describe how a leader’s expectations — even the unspoken ones — directly dictate an individual’s performance.

Breaking the Curse: An EM’s Guide to High Expectations

The Golem Effect is the psychological phenomenon where lower expectations from a manager lead to lower performance from the employee. It’s the dark cousin of the Pygmalion Effect.

In the high-stakes world of engineering, this usually manifests as “The Death Spiral”: a manager thinks a dev is “junior,” gives them menial tasks, the dev loses motivation, and their performance actually drops.

Here are some scenarios you’ve likely heard about or encountered, and how to counteract them.

Episode 1: The “Label” Trap

The Scene: Manager “Mike” is looking at a Jira board. He points to “Dev Dave” and thinks, “Dave is just a tech-maintenance guy. He can’t handle the new API architecture.”

The Pitfall: Pre-judging capabilities based on past hiccups or narrow roles.

The Solution: Practice leadership philosophies like self-reflection and growth opportunities.

• Check Your Own Narrative: Instead of just “auditing biases,” take a quiet moment before you assign a task to look at your internal “story” for each person. Realize that every time you bypass Dave, you aren’t just saving time — you’re actively shrinking his future.
• The “Day One” Mindset: If you hold onto the version of Dave that struggled six months ago, you won’t notice the version of Dave that’s ready to lead today. Give him the space to surprise you; more often than not, people will rise to the level of the person you decide to see.

Episode 2: The Micromanagement Shadow

The Scene: Mike is hovering over Dave’s shoulder, commenting on every line of code in real-time. Dave looks like a deer in headlights.

The Pitfall: Low expectations lead to over-monitoring. This kills autonomy and signals a lack of trust, which crushes dev productivity.

The Solution: When I hover, I’m telling my engineer, “I don’t think you can do this without me.” That’s a heavy weight for them to carry.

• Trust the “Why,” Release the “How”: I need to be crystal clear on the goal, but I have to leave the path to them. I’ll measure success by the final product, not by whether they did it exactly the way I would have.
• The “Safety Net” Promise: Instead of watching them work, I’ll tell them: “I’m stepping back because I trust your judgment, but I’m right here if you hit a wall.” It changes my role from a “guard” to a “resource.”

Episode 3: The “Easy Task” Feedback Loop

The Scene: Dave is buried under a mountain of “Change Color of Button” tickets. He looks bored. Mike thinks, “See? He’s slow even on the easy stuff!”

The Pitfall: Giving “safe” tasks prevents growth. If an engineer isn’t challenged, they won’t innovate, confirming your low opinion of them.

The Solution: Instead of considering these a rigid formula and treat them as a personal commitment to your team’s growth; offer sponsorship and psychological safety.

• The “Growth Budget”: If an engineer spends 100% of their time doing things they already know how to do, they aren’t gaining a year of experience — they’re just repeating one month of experience twelve times. Allocate some flexible time where an engineer can explore unfamiliar territories, which will help her grow.
• Guided Bravery: Forget “scaffolding” — think of this as being the safety net, not the crutch. It’s about giving them challenging work but making sure they know they aren’t alone in the dark.

Episode 4: The One-on-One Pivot

The Scene: In a 1:1 meeting, Mike says, “Just get these bugs done” instead of saying “What part of the system do you want to own next quarter?”

The Pitfall: Transactional management, a style that relies on a clear structure of rewards for high performers and punishments for failure.

The Solution: Spread the intentional belief; be the person who sees their potential before they even see it themselves.

• Casting the vision: If you only interact with the “Current Dave,” he stays stuck. If you interact with the “Future Senior Dave,” he starts to unconsciously reach for that standard.
• Active Encouragement: Use “I’m giving you this because I know you can handle the complexity,” even if they seem hesitant.

The Pedestal Peril: Balancing the Pygmalion Effect

The Pygmalion effect, aka the “Golden child” trap, it’s the phenomenon where high expectations lead to improved performance — which sounds great until you realize it can lead to burnout, favoritism, and “Star Player” silos. In engineering, this usually looks like a manager giving the “Rockstar” all the cool projects while everyone else gets the leftovers.

Here are some scenarios you’ve likely heard about or encountered, and how to counteract them.

Episode 1: The “Hero” Bottleneck

The Scene: Manager “Mike” hands a critical, high-visibility project to “Star Player Stella” for the fifth time this month. In the background, the rest of the team is playing Minesweeper because they have nothing impactful to do.

The Pitfall: Over-relying on your top performers because you “know they’ll crush it.” This creates a single point of failure and builds resentment.

The Solution: It’s the mental shift from protecting the project to building the people

• Investing in future talent: It’s a conscious choice to stop taking the easy path of least resistance (giving it to the person who already knows how) and start taking the path of most growth.
• Turning Heroes into Multipliers: Redefine what it means to be a ‘Senior’ on this team; instead of just doing the work themself, by becoming a Multiplier, they use their intelligence to amplify the capabilities of everyone around them.

Episode 2: The “Halo” Blind Spot

The Scene: Stella pushes code that breaks the build. Mike laughs it off, saying, “Classic Stella, she’s just moving fast!” Meanwhile, another dev gets a formal warning for a smaller mistake.

The Pitfall: High expectations can blind you to a top performer’s actual flaws or toxic behaviors (the “Brilliant Jerk” syndrome).

The Solution: Real leadership isn’t about protecting your best player; it’s about protecting the integrity of the whole team.

• Equal Standards: High expectations must apply to process, not just output. Use the same automated linting and PR review standards for everyone.
• 360 Feedback: Don’t just rely on your own view; ask the team how working with the “star” actually feels.

Episode 3: The Burnout Pedestal

The Scene: Stella is at her desk at 10 PM. She looks exhausted. Mike sends her a Slack: “I know only you can solve this by tomorrow morning! You’re a legend!”

The Pitfall: Using high expectations as a psychological whip. Your belief in their “superhuman” ability can make them feel they aren’t allowed to struggle or rest.

The Solution: Protect the Person, Not Just the “Asset”

• De-clutter the Ego: Remind your stars that their value isn’t tied to being “the best” every single day.
• Predictable Stress: Don’t use “You’re the only one who can do this” as a management tactic for poor planning.

Episode 4: The Inclusion Gap

The Scene: A brainstorming session. Mike only looks at Stella for the “right” answer. The other three engineers have stopped trying to speak.

The Pitfall: Creating a “Two-Tier” team. If only one person is expected to be brilliant, the others stop trying to contribute.

The Solution: Shift from being a fan of an individual to being a facilitator of a collective.

• The “Round Robin” Expectation: Start meetings by asking for input from the person with the least tenure first.
• Assume Collective Intelligence: Move from “Stella is the expert” to “This team is an expert unit.”

EM Desk Reference: Navigating the Golem and Pygmalion Effects

💡 Quick Audit for Your Next 1:1

If you aren’t sure where a team member is positioned, ask yourself these three questions:

1. For Golem Check: “What is one complex task I am currently withholding from this person because I’m afraid they’ll fail?”
2. For Pygmalion Check: “If this person left tomorrow, would the team collapse because I haven’t let anyone else learn their ‘special’ domain?”
3. The Neutralizer: “Am I holding this person to a standard of excellence, or am I holding them to my personal opinion of them?”

Credits:

1. Image — Google Nano Banana
2. Blogpost Structure — Google Gemini PRO

P.S: This blogpost is part of the same series where I discuss the common pitfalls to avoid as an engineering manager. If you are interested in reading further, discover this blogpost on Doctolib Medium account where I talked about Growth Debt.