The Staff Engineer Who Saved the Company by Doing Less
The Staff Engineer Who Saved the Company by Doing Less
The Crisis
When Maria joined as a Staff Engineer at a 400-person SaaS company, the engineering organization was drowning. The platform team supported 47 internal services, maintained 12 shared libraries, and handled over 200 Slack messages daily asking for help. Deploy times had ballooned to 3 weeks. Feature velocity had dropped 60% year-over-year. Morale was in freefall.
The executive team’s solution? Hire more platform engineers. Build better tools. Automate everything.
Maria spent her first 30 days doing something different: she calculated the cost of every service, library, and tool the platform team owned.
Her findings shocked everyone.
The Hidden Tax
Maria created a simple spreadsheet that changed everything. For each platform service and library, she tracked:
- Development time: Hours spent on features, bugs, and maintenance
- Support burden: Time answering questions, debugging issues, helping teams integrate
- Operational overhead: Oncall incidents, deployment pipelines, monitoring
- Opportunity cost: What the team couldn’t build because of existing commitments
The results were brutal:
- 8 services had zero active users but required 15 hours/week of maintenance
- 3 internal libraries were used by only one team (who offered to own them)
- The most “popular” service generated 80% of platform team’s support tickets
- 60% of platform engineering time went to maintaining things, not building new capabilities
The insight: The platform team wasn’t understaffed—they were over-committed. Every service added was a permanent tax on future capacity.
The Radical Proposal
In her first major technical presentation as Staff Engineer, Maria didn’t propose building anything new. She proposed a “Subtraction Strategy”:
Phase 1: Deprecation (60 days)
- Sunset 8 unused services
- Donate 3 low-usage libraries to the teams using them
- Archive 12 “just in case” internal tools
Phase 2: Consolidation (90 days)
- Merge 6 overlapping services into 2
- Standardize on one observability stack (down from three)
- Unify authentication across services
Phase 3: Self-Service (120 days)
- Build platform abstractions that eliminated 80% of support requests
- Create decision trees replacing “ask platform team” with “follow this guide”
- Implement automated service templates reducing custom builds
The controversial part: Maria recommended the team commit to building nothing new for 6 months.
The Pushback
The initial reaction was intense resistance:
- Product leaders: “We need new features, not deletion!”
- Engineering managers: “My team depends on those services!”
- Platform engineers: “If we don’t build, what’s our value?”
- The CTO: “How does doing less save the company?”
Maria’s response was a single-slide financial model:
Current state: 12 platform engineers spending 60% of time on maintenance = 7.2 FTE maintaining existing systems, 4.8 FTE for new work.
Proposed state (after 6 months): 20% maintenance overhead = 2.4 FTE maintenance, 9.6 FTE for new work.
Net result: Doubling effective capacity without hiring anyone. Estimated savings: $2M/year in eng costs + immeasurable gains in velocity.
She ended with one sentence: “We can’t build our way out of complexity. We have to subtract our way to simplicity.”
The Execution
Maria was given a guarded green light with a 3-month checkpoint. She didn’t delegate—this was her technical bet. But she also didn’t do it alone. Her approach revealed a masterclass in Staff Engineer leadership:
1. Build a Coalition, Not an Empire
Maria identified engineers across teams who’d complained about platform complexity. She invited them to weekly “simplification reviews” where they’d identify candidates for deletion. She gave them credit for every service removed.
Key move: She positioned this as empowering other teams, not platform consolidating power.
2. Make Deprecation Celebratory
Instead of quiet deletions, Maria created “Deletion Fridays.” Each service removal was announced company-wide with:
- What we’re removing
- Why (data on unused features, maintenance cost)
- What it frees us to build instead
- Celebration in #general
Deletion became a feature, not a failure.
3. Metrics That Matter
Maria created a dashboard tracking:
- Complexity Score: Total services × avg maintenance hours
- Support Burden: Platform team Slack DMs/week
- Deployment Frequency: Company-wide (not just platform)
- Incident Rate: Platform-related production issues
She updated it weekly and shared it transparently. When complexity dropped 40% in month one, skeptics became believers.
4. Teach, Don’t Own
For services given to product teams, Maria didn’t just hand over code. She ran workshops on:
- How to operate a service in production
- When to ask for help vs. solve it yourself
- The true cost of adding dependencies
She turned platform consumers into platform thinkers.
The Results (6 Months Later)
The data was irrefutable:
- Services maintained: 47 → 18 (62% reduction)
- Support requests: 200/week → 35/week (82% reduction)
- Deploy time: 3 weeks → 2 days (93% improvement)
- Incident rate: Down 55%
- Platform team velocity: 2.5x increase
- Engineering satisfaction: +40 points (internal survey)
But the real victory was strategic:
With newfound capacity, the platform team shipped a self-service deployment pipeline that became the foundation for the company’s next growth phase. The project that “saved the company” (CEO’s words) was only possible because Maria freed up the capacity to build it.
The Staff Engineer Lessons
1. Addition by Subtraction is a Technical Skill
Senior engineers optimize algorithms. Staff engineers optimize systems and organizations. Sometimes the highest-leverage code is code you delete.
Tactical takeaway: Audit your team’s commitments quarterly. Calculate the maintenance burden of each one. Ruthlessly deprecate the bottom 20%.
2. Influence Requires Evidence
Maria didn’t lead with “trust me.” She led with data. Her cost analysis was irrefutable. Her metrics made progress visible. Her financial model spoke the language of executives.
Tactical takeaway: Before proposing major technical direction changes, build the quantitative case. Translate engineering problems into business impact.
3. Cultural Change Requires Ritual
“Deletion Fridays” wasn’t about code—it was about changing what the organization celebrated. Maria ritualized simplicity.
Tactical takeaway: If you want to change engineering culture, create visible, repeating ceremonies around the behavior you want to encourage.
4. Staff Engineers Multiply Others
Maria could have spent 6 months building a new platform feature herself. Instead, she multiplied the entire team’s capacity by 2x permanently. That’s the difference between senior and staff impact.
Tactical takeaway: Your goal isn’t to be the best engineer on the team. It’s to make the team’s ceiling higher.
5. Saying No is a Superpower
The hardest part of Maria’s strategy was committing to building nothing new for 6 months. That discipline created the space for transformation.
Tactical takeaway: Staff engineers say no to good ideas so they can say yes to great ones. Protect your team’s focus like you protect production.
The Career Insight
Maria’s promotion to Principal Engineer came 14 months later. In her promotion packet, the CTO wrote:
“Maria demonstrated what distinguishes Staff+ engineers: she solved the problem behind the problem. We thought we needed more people. She showed us we needed less complexity. That level of strategic thinking is what Principal Engineers do.”
This story reveals a truth about Staff Engineer impact: The most valuable technical contributions often don’t involve writing code. They involve removing obstacles, clarifying strategy, and multiplying the effectiveness of everyone around you.
Questions for Reflection
- What’s one service, library, or process your team maintains that costs more than it provides?
- How much of your team’s capacity is consumed by maintenance vs. new value?
- What would you build if you had 2x your current capacity?
- How could you measure and communicate the cost of complexity in your organization?
The Bottom Line: Staff Engineers don’t just build systems—they shape how systems are built. Sometimes the most important technical decision is deciding what not to build. Maria’s story is a reminder that in a world obsessed with addition, subtraction can be revolutionary.
Your move: What can you remove this quarter?