The Staff Engineer Who Deleted Half the Codebase - And Got Promoted

The Staff Engineer Who Deleted Half the Codebase - And Got Promoted

The Problem That Nobody Wanted to Admit

Sarah Chen had been a Senior Engineer at a fast-growing fintech startup for three years when she was promoted to Staff Engineer. Her first major project in the new role wasn’t building something new - it was understanding why everything took so long to build.

The company had grown from 20 to 200 engineers in 18 months. What used to take days now took weeks. Simple feature requests disappeared into a black hole of dependencies, test failures, and integration headaches. Engineering velocity was in free fall, and leadership’s solution was to hire more engineers.

Sarah spent her first month as Staff Engineer doing something unusual: she read code. Not to fix bugs or add features, but to understand the system as a whole. What she discovered was shocking.

The Archaeology of Good Intentions

The codebase told a story of well-intentioned decisions that had ossified into architectural cement:

• 14 different authentication mechanisms across services (each team had solved the problem their own way)
• 6 feature flag systems (experiments that became permanent)
• An “internal framework” wrapping Spring Boot that added 40,000 lines of code and saved approximately 200
• Custom serialization library because “JSON was too slow” (narrator: it wasn’t)
• Three different state machines for the same business process (onboarding), all slightly incompatible
• 47 microservices, 23 of which received fewer than 10 requests per day

The codebase had grown to 2.3 million lines of code. But here’s what Sarah realized: most of it didn’t need to exist.

The One-Pager That Changed Everything

Sarah wrote a one-page document titled “The Complexity Tax.” It didn’t propose a solution - it quantified the problem in terms executives could understand:

Finding:

• Average feature development time: 6 weeks
• Average time spent writing new code: 3 days
• Average time spent on integration, testing, deployment: 39 days
• Engineer satisfaction score: 4.2/10 (down from 8.1/10 18 months ago)

Root Cause: Unintentional complexity. We have built abstractions on top of abstractions, each solving a point-in-time problem, none ever removed.

Business Impact:

• Lost opportunity cost: ~$2M/month in delayed features
• Recruitment/retention risk: engineers are frustrated and leaving
• Onboarding time: 4 months for new engineers to be productive (industry average: 6 weeks)

Recommendation: Before we add more engineers, we need to subtract unnecessary code.

The document landed with executive leadership on a Monday. By Wednesday, Sarah had approval for a six-month “subtraction initiative.”

The Deletion Strategy

Sarah knew that proposing to “delete half the codebase” would create panic. Instead, she framed it as surgical removal of complexity, using a clear methodology:

Phase 1: Catalog and Classify (Month 1)

Working with three senior engineers, Sarah created a comprehensive map:

• Green: Core business logic, actively used, well-tested
• Yellow: Used but could be simplified or replaced with standard tools
• Red: Legacy, low usage, or duplicative functionality

The results:

• Green: 600K lines (26%)
• Yellow: 500K lines (22%)
• Red: 1.2M lines (52%)

Phase 2: Build Coalition (Month 2)

Sarah didn’t dictate what to delete. Instead, she:

• Shared the complexity map with all engineering teams
• Asked each team to identify their top 3 “pain points”
• Ran workshops where teams proposed what to remove

Critical insight: Teams were eager to delete code - they just needed permission and a clear process.

Phase 3: Execute in Waves (Months 3-6)

Sarah organized deletion into themed sprints:

Wave 1: Consolidate Auth (Month 3)

• Migrated all services to single SSO provider
• Deleted 13 authentication systems
• Result: -120K lines, auth bugs dropped 80%

Wave 2: Kill the Framework (Month 4)

• Migrated services from custom framework to vanilla Spring Boot
• Deleted internal framework and all its complexity
• Result: -40K lines, build times reduced 60%

Wave 3: Microservice Consolidation (Month 5)

• Merged 23 low-traffic services into 4 domain-bounded services
• Applied “reverse Conway maneuver” - reorganized teams around consolidated services
• Result: -200K lines, deployment complexity reduced dramatically

Wave 4: Feature Flag & Experiment Cleanup (Month 6)

• Removed flags for features shipped >6 months ago
• Consolidated to single feature flag system
• Result: -80K lines, eliminated entire class of production bugs

The Results That Mattered

By the end of six months:

Code Metrics:

• Total codebase: 1.2M lines (down from 2.3M) - 48% reduction
• Services: 24 (down from 47)
• Build time: 8 minutes (down from 22 minutes)

Business Metrics:

• Average feature delivery: 2 weeks (down from 6 weeks)
• Engineer satisfaction: 7.8/10 (up from 4.2/10)
• Production incidents: -45%
• New engineer onboarding: 4 weeks (down from 4 months)

Financial Impact:

• Estimated value of increased velocity: $8M in first year
• Infrastructure cost savings: $400K/year (fewer services to run)
• Avoided hiring: 15 engineers (at $200K each = $3M/year)

The Lessons for Staff Engineers

1. Subtraction Is a Skill

Sarah’s promotion to Principal Engineer cited her “ability to see the system holistically and make bold architectural decisions.” But the real skill wasn’t technical - it was recognizing that the best solution was removal, not addition.

Takeaway: As a Staff Engineer, your job isn’t always to build. Sometimes it’s to unbuild.

2. Quantify in Business Terms

The one-pager that got executive buy-in didn’t talk about cyclomatic complexity or coupling metrics. It talked about money, time, and people.

Takeaway: Translate technical problems into business impact. Executives can’t approve what they don’t understand.

3. Build Coalition, Not Consensus

Sarah didn’t wait for everyone to agree. She:

• Got executive sponsorship first (top-down)
• Empowered teams to identify deletions (bottom-up)
• Created a clear process that teams could opt into

Takeaway: You don’t need unanimous agreement. You need executive air cover and team champions.

4. Make Deletion Safe

Sarah’s deletion process included:

• Feature flags for reversibility
• Gradual rollouts with monitoring
• Clear rollback plans
• “Deletion retrospectives” to learn from mistakes

Takeaway: Teams fear deletion because it feels risky. Make it safe, and they’ll embrace it.

5. Organizational Design Follows Code

The microservice consolidation required reorganizing teams. Sarah worked with engineering leadership to:

• Align team boundaries with service boundaries
• Give teams full ownership of consolidated services
• Reduce cross-team dependencies

Takeaway: You can’t fix architecture without addressing org structure (Conway’s Law is real).

The Broader Pattern: Technical Leadership as Constraint Removal

Sarah’s story illustrates a critical Staff Engineer skill that’s rarely discussed: constraint removal.

Most engineers are taught to solve problems by adding:

• More features
• More services
• More abstraction
• More process

Staff Engineers solve problems by removing constraints:

• Delete unnecessary code
• Simplify architecture
• Remove dependencies
• Eliminate process overhead

This requires a different mindset:

• Strategic thinking: What are we optimizing for?
• Systems thinking: How do the pieces interact?
• Negative space: What can we remove to make the system better?

How to Apply This in Your Context

If you’re a Staff Engineer (or aspiring to be), here’s how to identify subtraction opportunities:

Run a Complexity Audit

• Map all services, frameworks, libraries, internal tools
• Identify usage patterns (what’s actually being used?)
• Flag duplication and low-value complexity

Quantify the Cost

• How much time is spent maintaining this?
• How often does this cause production issues?
• What’s the opportunity cost of this complexity?

Build Your Case

• One-pager format: Problem, Impact, Recommendation
• Use business metrics: time, money, people, risk
• Show quick wins to build momentum

Execute Strategically

• Start with high-impact, low-risk deletions
• Build trust through successful removals
• Scale to bigger architectural changes

Change the Culture

• Celebrate deletions as much as additions
• Make “lines of code removed” a positive metric
• Teach engineers to ask “what can we remove?” not just “what should we add?”

The Counterintuitive Promotion Path

Sarah’s promotion to Principal Engineer came from deleting code, not writing it. This is counterintuitive to many engineers who equate impact with creation.

But at the Staff+ level, impact is measured differently:

• Did you make the team more effective?
• Did you reduce drag on the organization?
• Did you improve the system’s ability to evolve?

Sometimes the answer is building something new. But often, it’s removing what shouldn’t be there.

Final Thought: The Courage to Subtract

It takes courage to propose deletion at scale. You’re implicitly saying “previous work was wrong” (even if it was right at the time). You’re risking breaking things. You’re going against the engineering instinct to build.

But as Sarah proved, the highest leverage work is often subtractive, not additive.

The codebase doesn’t need more features. It needs less complexity. The system doesn’t need more services. It needs clearer boundaries. The team doesn’t need more process. It needs fewer obstacles.

As a Staff Engineer, your job is to see what others miss - including what needs to be removed.

Discussion Question: What’s one thing in your codebase or organization that should be deleted? What’s stopping you from proposing it?