Avoid the Maintenance Trap
How high performers get stuck in "maintenance mode" — and the ROI framing that gets you back to building
Hi, it’s Ethan & Jason from Level Up: Make career breakthroughs with AI-proof leadership skills. If you like to learn through cohorts, here’s what we have coming up:
(May 29 & June 12) Claude Cowork Certification for Business Professionals
(July 11) High Quality Decision Making for Senior Leaders & Executives
This edition of Level Up is a guest post from Marcel Tella Amo, Scientist, Engineer, and High Performance Coach. He helps engineers overcome performance friction, the invisible bottleneck behind stalled output and promotion plateaus.
His background includes a Ph.D. in medical imaging from University College London, training in neuroscience for business at Massachusetts Institute of Technology, and coaching certification from the International Coaching Federation. Find more of his work on debugging tech careers in his newsletter.
In this article, Marcel breaks down why so many high-performing engineers get quietly trapped in “maintenance mode” — then shows you how to escape by auditing your week, quantifying the invisible drain, and reframing systemic fixes in plain ROI terms (that resonate with senior leadership) so you can buy back creation time.
Keep this in your back pocket the next time you realize you spend more time maintaining than building what matters.
Performance Friction
On paper, your career is working.
Inside your brain, the system is crashing.
You studied hard, built technical expertise, and earned the senior title. You did everything “right”.
But internally, everything feels wrong.
You open your side project repo on Sunday night, stare at the architecture for 10 minutes, close your laptop, and just watch YouTube. You wake up dreading Monday morning. You see former colleagues launching AI startups while you feel like your brain is running at 60% capacity.
The worst part isn’t that you’re stuck. It’s that you know exactly what you should build next... and you still don’t open the repo.
This isn’t just burnout.
It is Performance Friction, the invisible resistance that accumulates inside high-performing careers when you shift from creation to maintenance.
To understand Performance Friction, we have to look at the numbers. In a comprehensive developer coefficient report by Stripe, it was found that the average software engineer spends up to 42% of their workweek dealing with technical debt and maintenance.
Let that sink in.
Nearly half of your highly compensated, deeply trained cognitive capacity is spent acting as a digital janitor.
You might ask, does this still hold in a world with AI and powerful productivity tools?
AI acts as an amplifier.
It accelerates whatever system is already in place. If your execution is clean, it compounds output. If your system is fragmented, it compounds distraction, context switching, and unfinished work.
In practice, many engineers are not blocked by lack of tools, but by unresolved cognitive and emotional friction. Adding AI often increases the surface area of work, more ideas, more branches, more partially completed tasks, without resolving the underlying bottleneck.
This is why performance friction does not disappear with better tools.
In some cases, it intensifies.
When you are a junior engineer, friction comes from lack of knowledge. You don’t know how the system works, so you have to learn. That friction is productive; it builds muscle.
But when you are a senior engineer, friction comes from systemic drag. You know exactly how the system works, and you know exactly how broken it is. The friction shifts from learning to merely enduring. Over time, enduring becomes your primary skill, and your “creation” muscle atrophies.
Here is exactly what this looks like in the wild, and how to debug it.
A) The Anatomy of a Maintenance Trap
Let me share the exact logs of David, a Staff Engineer I worked with recently.
He was among the top performers at his level, consistently receiving strong ratings and compensation, and yet utterly miserable.
We audited his actual weekly inputs.
Here is what a “successful” week looked like for him:
Monday: 4 hours reviewing PRs on a legacy auth service no one wanted to touch. 2 hours fixing a broken deployment pipeline caused by a deprecated package.
Tuesday: 5 hours in cross-functional alignment meetings explaining why Q3 velocity was down.
Wednesday: 3 hours rewriting documentation for an API that was about to be replaced anyway.
David had become the ultimate maintainer.
He kept systems running, so managers kept giving him maintenance. His intellectual curiosity, the spark that originally drove his rapid career ascent, had slowly starved.
He was not building anymore. He was just keeping the lights on.
The psychological toll of this is insidious because it looks like success from the outside. David’s breaking point wasn’t a massive system outage; it was a Tuesday morning standup. His manager praised him for “holding down the fort” on a particularly nasty legacy migration.
The rest of the team clapped.
But internally, David realized something terrifying: If I am the only one who can hold down this fort, I am never going to be allowed to leave it.
He had become a victim of his own competence.
By being the most reliable person to fix the broken deployment pipeline, he accidentally signaled to leadership that his highest value was maintenance.
This is the core of the Maintenance Trap: companies will happily let you stagnate as long as your stagnation keeps their legacy systems profitable.
The burden of breaking this cycle rests entirely on you.
The problem was not his work.
The problem was how that work was framed.
The invisible work of engineering.
Most engineers describe maintenance in a way that traps them in it.
We have to change the framing.
❌ Instead of: “I led the Q3 legacy system cleanup and kept the platform stable”.
✅ Say: “I identified operational inefficiencies costing the engineering team 15 hours a week, and automated a fix that reclaimed that time for feature development”.
Actionable Advice:
Audit your calendar ruthlessly: Open your calendar for the last 14 days, label each 30-minute block as “Maintenance” (fixing, aligning, reviewing) or “Creation” (building, architecting, deep work), then total the hours in each category. If Maintenance exceeds 50%, you are in a maintenance trap.
Quantify the invisible drain: Calculate the exact hours your team wastes on a recurring legacy issue. Use this simple formula: (Incidents per month) x (Average time to resolve) x (Number of engineers involved) = Total Wasted Engineering Hours. For example, if a recurring issue happens 10 times per month, takes 2 hours to resolve, and involves 2 engineers, that’s 40 hours lost per month. At an average cost of $100/hour, that’s $4,000 per month, or nearly $50,000 per year, spent on a single recurring problem.
Draft a systemic fix, framed in terms of ROI: Do not just fix the bug again. Write a one-page technical proposal to solve the root cause, and present it as your next high-leverage initiative. Structure your one-pager into three sections: 1. The Bleed (the data you just calculated), 2. The Tourniquet (the immediate automated fix), and 3. The ROI (hours reclaimed for feature work). Managers rarely approve “refactoring for the sake of clean code,” but they will almost always approve high-leverage ROI.
B) The Paralysis of AI Acceleration
For David, when AI arrived, the panic began.
He felt the intense pressure of AI acceleration closing in on him.
Every week, a new model is launched. He felt his skills becoming irrelevant.
So, he planned to build an AI wrapper on the side. But his internal logs were brutal:
“I spent three weeks researching vector databases, watched 10 hours of tutorials, planned a massive microservices architecture, and didn’t write a single line of code.
It just felt too heavy”.
This is fear disguised as preparation.
High performers are terrified of building the “wrong” thing or writing “bad” code, so they build nothing. The friction is paralysis by analysis.
Why does this happen to the smartest people in the room?
Because being a Senior or Staff Engineer means you are used to being the expert. You are paid for your judgment, your flawless architectures, and your ability to foresee edge cases.
When a massive paradigm shift like AI acceleration hits, it forces you back to the beginner’s mind. But high-performers hate being beginners. The cognitive dissonance between your senior title and your junior-level understanding of Large Language Models creates immense psychological friction.
Watching 10 hours of tutorials feels productive.
It feels safe.
It protects your ego from the reality that your first AI script is going to look like it was written by an intern. But preparation without execution is just sophisticated procrastination. You cannot read your way out of Performance Friction; you have to code your way out, and you have to be willing to write bad code to do it.
To debug this, David forced a severe constraint. No architecture. No tutorials. Just raw momentum. He realized the real trap was not the difficulty of the project. It was the expectation that he needed the perfect plan before starting.
The Analysis Paralysis Curve
That mindset sounds like this: “I’ll start the AI project when I have a clear weekend to map out the perfect tech stack”.
But momentum begins much smaller.
“Tonight, I will spend exactly 20 minutes writing terrible, unoptimized code using a new API just to break the seal. If it fails, I have only lost 20 minutes”.
Actionable Advice:
Lower the execution barrier to near zero: Commit to a 20-minute, zero-stakes exploration block. The goal is not a product; the goal is compiling. Set a physical timer. Close all tabs except your IDE and one API documentation page. If you catch yourself opening Figma to design a UI, or opening YouTube to watch “just one more tutorial,” stop. The rule is: no architecture, no scalability concerns, just raw momentum. Write everything in a single file if you have to.
Ship microscopic prototypes: Build a script that automates one tiny personal task. Ignore scale. Do not try to build “a revolutionary RAG pipeline for enterprise data”. Build a Python script that reads your last five unread emails and summarizes them in your terminal. That is it. By lowering the stakes to a microscopic personal task, you bypass the inner critic that demands architectural perfection.
Measure velocity, not output: Track how fast you can implement a new concept, rather than whether the architecture is flawless. Keep a “momentum log” instead of a project tracker. Write down: “Started using new vector DB API at 8:00 PM. First successful query at 8:45 PM”. Celebrate the 45-minute loop, not the final product. Rewire your brain’s reward system to dopamine-hit on the speed of implementation rather than the perfection of design.
C) The System Restart (The “After”)
David didn’t fix his career by taking a vacation or trying to “find his passion”.
He fixed it by engineering his environment.
 | A guest post by
|