OLD SCRIPT DETECTED
“The new senior makes me redundant”
Try this response:
“They built a new endpoint; I'm rebuilding infrastructure. Different tasks, different time signatures.”SEE THE PRACTICE
Build a response for this thought—and one move to prove it.
THE THOUGHT
“The new senior makes me redundant”
YOUR RECORDED RESPONSE
“They built a new endpoint; I'm rebuilding infrastructure. Different tasks, different time signatures.”
ONE PRIVATE MOVE
List three tasks you've shipped in the past month. For each one, note what constraints or dependencies made it take the time it took. Do not compare it to any other person's work. Just name the constraint.
The Code Review That Landed Wrong
The Merge Lands at 9:47 AM
You're in the middle of your own branch—a refactor you've been threading through for two days, picking through old patterns, documenting as you go. Slack shows green: the new senior's PR just merged. Seven files. Approved in under an hour by someone you've never worked with. You click through. Clean. You click back to your own diff. Yours has comments. Not blocking comments, just—comments. The thought arrives unannounced: *This person made me look slow.*
By Friday, You're Measuring Everything
You start timing your own reviews. You note which tickets landed in their queue versus yours. Their task: fresh API endpoint, no legacy constraints. Your task: untangle a cache layer from 2019 that touches six services. You don't say this aloud. Instead, you find yourself scrolling their GitHub outside work hours. You skip the team lunch. When someone mentions their arrival, you nod and change the subject. The unspoken calculation hardens: if they stay and ship like that, what role is left for me? You don't ask for a project. You don't volunteer for the hard one. You wait to see what happens.
The Pattern Breaks When You Check the Ticket
Three weeks later, the new senior's big feature breaks in staging. Not a disaster, but real: the edge case they missed was the exact thing your 2019 cache layer was designed to catch. You see the fix go in. You see them learn something about the system you've been holding. That afternoon, your refactor ships—the one they asked about in standup last week, not to question it, but because they wanted to understand how you'd structured it. The question itself felt suspicious at the time. Replaying it now, it wasn't suspicion. It was curiosity about how you solve.
TRACE · 01/04
How this script runs you
- You scan their PRs for speed and assume faster means better, ignoring that they're on different code paths with different constraints.
- Each clean merge of theirs lands in your body as evidence that you're inefficient, even when your tickets involve legacy systems they've never touched.
- You begin measuring your own value against theirs instead of against the work you're actually doing, and the comparison makes you invisible to your own progress.
SOURCE_LOCATED · 02/04
The hidden rule underneath
The Velocity Scoreboard
Ship speed is the ranking, and every teammate is a row above me. The 10x-engineer myth came from studying toy tasks—most variance belongs to the task itself, not the person. But the scoreboard you're using measures neither the task complexity nor the actual outcome. It measures only the gap between their velocity and yours, and you assume that gap proves redundancy.
FORGING_REPLACEMENT · 03/04
Replacement lines (record these)
- They built a new endpoint; I'm rebuilding infrastructure. Different tasks, different time signatures.
- My refactor will save the team months of maintenance. Their merge was fast because the path was clear.
- A strong teammate raises what we can do next. They didn't lower what I'm needed for.
Generated per person in the app — these are the flavor, not your script. Yours is built from your exact words.
INSTALL · 04/04
The protocol, on one card
When I think
“The new senior makes me redundant”
I say
“They built a new endpoint; I'm rebuilding infrastructure. Different tasks, different time signatures.”
Then I do one thing
List three tasks you've shipped in the past month. For each one, note what constraints or dependencies made it take the time it took. Do not compare it to any other person's work. Just name the constraint.
STATUS: READY_TO_INSTALL
Wipe this thought4 minutes. Your voice. Free.
The wipe protocol
- Write the thought exactly as it plays: "The new senior makes me redundant". Word for word — the wipe targets the sentence, not the vibe.
- Trace the rule and the avoided action. What does this thought conveniently excuse you from doing?
- Record the replacement lines below in your own voice. Speak like you mean it — no recording, no install.
- Run the loop: play it every morning and night, log one proof action a day for 7 days.
Straight answers
If they can ship faster on the same codebase I work in, doesn't that prove I'm slower?
Not necessarily. Speed also depends on which exact files, which staging state, which prior context, which interruptions, which async blockers, and which reviews were in flight. Two people on the same codebase rarely have identical task conditions. Faster on one endpoint is not faster on cache layers. Watch whether they accelerate on *your* kinds of work, not on work chosen for them.
Why does their quick merge feel like personal evidence against me, even when I know logically it shouldn't?
Your brain is running a fast comparison because comparison is how you once learned what to improve. The problem isn't the comparison itself—it's comparing across different conditions. When the scoreboard only shows merge time, not task scope, you can't see that you're measuring different things. The feeling is real; the measurement is incomplete.
If I'm not being made redundant, why do I feel like I should leave before they push me out?
You're interpreting a threat that doesn't yet exist, and the interpretation is creating the behavior—pulling back, waiting, measuring yourself down. That's the cost: you stop raising your hand for work, stop showing what you know, stop building. The redundancy isn't coming from their hiring. It's coming from you shrinking in place.
Related old scripts
Related self-checks
Related science
Researchers to explore
Related mechanisms
The research behind this script
- Productivity Variations Among Software Developers and Teams: The Origin of 10x — McConnell, Construx, 2020
- The SPACE of Developer Productivity — Forsgren, Storey, Maddila, Zimmermann, Houck & Butler, ACM Queue, 2021
- Burnout in software engineering: A systematic mapping study — Tulili, Capiluppi & Rastogi, Information and Software Technology, 2022
- Two Sides of the Same Coin: Software Developers' Perceptions of Task Switching and Task Interruption — arXiv, 2018