The Consolidation That Nobody Wanted

The Consolidation That Nobody Wanted

Sarah had been at the company for six years, promoted to Staff Engineer eighteen months ago. She’d built and maintained the observability platform that powered monitoring for 200+ microservices across five product teams. The platform was reliable, well-documented, and had 99.97% uptime. Teams loved it.

Then the VP of Engineering dropped the bomb in the all-hands: “We’re consolidating our observability infrastructure with DataDog. Sarah’s platform will be deprecated over Q3 and Q4.”

The Initial Reaction

Sarah’s first instinct was defensive. The platform worked. Teams were happy. Why throw away years of work? She spent a weekend drafting a document arguing why they should keep the internal platform: lower costs, customization capabilities, no vendor lock-in.

Monday morning, her manager Lisa - also a former Staff Engineer - asked her for coffee. “I know this feels terrible,” Lisa said. “I saw the document you started. Don’t send it.”

“But the analysis is solid—”

“The decision isn’t about technical merit. It’s about organizational capacity. We’ve grown from 40 to 180 engineers in two years. Your platform needs a team of 4-5 people to evolve with the company. Right now, it’s you plus 20% of two other engineers. The math doesn’t work.”

The Fork in the Road

Sarah faced a choice that many Staff Engineers encounter: fight a losing battle on principle, or find a way to turn the situation into leverage.

She thought about what she’d seen other senior ICs do when their projects were killed:

• The Martyr: Vocally opposed the decision, became known as “difficult,” eventually left the company
• The Checked-Out: Phoned it in during the deprecation, did the minimum, looked for new roles
• The Architect: Used the opportunity to shape what came next

Sarah chose the third path, but not for the obvious reasons.

Reframing the Problem

Instead of asking “How do I save my platform?” she asked different questions:

1. What organizational problem is the consolidation solving?
2. What will teams lose in the transition that they actually care about?
3. How can I make this transition create more value than it destroys?

She scheduled 1-on-1s with every team lead who used her platform. Not to sell them on keeping it - but to understand their actual pain points.

The pattern became clear: teams didn’t love her platform specifically. They loved three things it provided:

• Custom metrics tailored to their domain (e-commerce, payments, ML inference)
• Self-service dashboards they could modify without tickets
• Instant feedback on deployments via Slack integrations

DataDog could do all of this - but none of it would happen automatically in the migration.

The Strategy Doc

Sarah wrote a 4-page document: “Observability Consolidation: Migration Strategy & Value Preservation”

The document didn’t argue against the decision. Instead, it proposed:

1. Migration Phases: Group services by team and criticality, not alphabetically
2. Value Preservation: Replicate the 15 most-used custom dashboards in DataDog before migrating each team
3. Improvement Opportunities: Use the migration to fix three long-standing pain points (cross-service tracing, cost attribution, alert fatigue)
4. Knowledge Transfer: Create a “DataDog Patterns” guide documenting common observability patterns

The insight: Migrations fail when teams end up worse off. Migrations succeed when teams end up better off, even if differently.

She shared the doc with her manager, the VP of Engineering, and the three other Staff Engineers. The VP responded in 20 minutes: “This is exactly what we needed. Can you lead the migration?”

Leading From the IC Track

Sarah became the technical lead for the consolidation - but she didn’t do it alone. She made three strategic moves:

1. Built a Tiger Team

She recruited one engineer from each product team (20% time) to be the “DataDog champion” for their domain. This served multiple purposes:

• Distributed the work (she couldn’t do it alone)
• Built buy-in (teams felt represented)
• Created expertise (champions became the go-to people post-migration)

2. Created Forcing Functions

Rather than a big-bang migration, she introduced a rule: any new service must launch with DataDog. This created dozens of proof-points and uncovered edge cases early.

She also made the old platform “read-only” for new dashboards three months before the full deprecation. This pushed teams to learn DataDog while they still had the safety net of the old system.

3. Documented Relentlessly

She created:

• Migration Playbook: Step-by-step guide for each service type
• Pattern Library: Common observability patterns (RED metrics, SLOs, deployment tracking) in DataDog
• Decision Log: Why certain approaches were chosen, alternatives considered, trade-offs made

The documentation had a hidden benefit: it demonstrated the strategic thinking behind the migration, making Sarah’s impact visible to leadership.

The Unexpected Outcome

The migration finished two weeks early. Teams reported higher satisfaction with observability post-migration than before. Three engineers from Sarah’s tiger team were promoted to senior engineer, citing the leadership experience.

And Sarah? Six months later, she was promoted to Principal Engineer.

Not because she built a great platform.

Not because she fought to save it.

But because she demonstrated something more valuable: the ability to turn organizational necessities into technical opportunities.

The Lessons

1. Organizational Decisions Aren’t Technical Arguments

Sarah initially tried to win a technical debate. But the decision was about organizational capacity, vendor consolidation strategy, and reducing cognitive load. Technical merit was necessary but not sufficient.

Key Insight: Staff+ engineers must understand the business and organizational context driving technical decisions. Fighting those decisions on technical grounds alone is a losing strategy.

2. Resistance vs. Redirection

Sarah could have resisted and been seen as difficult. Instead, she redirected her energy into making the inevitable decision successful.

Key Insight: Senior ICs build influence by making hard things easier for the organization. Sometimes that means gracefully sunsetting your own work.

3. Deprecation as Technical Leadership Opportunity

Most engineers see deprecation as failure. Sarah saw it as a different type of technical challenge: how do you migrate 200 services without breaking anything or losing critical capabilities?

Key Insight: Some of the highest-leverage Staff+ work is making migrations, consolidations, and deprecations successful. These projects have enormous risk and high visibility.

4. Documentation as Force Multiplier

Sarah’s documentation didn’t just help the migration - it made her thinking visible to leadership. The decision log showed strategic thinking. The pattern library showed she was thinking beyond the immediate project.

Key Insight: Documentation is how Staff engineers scale their impact and make their work visible to people who don’t read code.

5. Building Distributed Ownership

By creating the tiger team, Sarah distributed both the work and the credit. The team members learned and grew. Sarah multiplied her impact.

Key Insight: Staff+ engineers create more value by enabling others than by doing everything themselves. Building distributed ownership is a career-accelerating skill.

The Counterintuitive Truth

Sarah’s promotion to Principal Engineer came because she deprecated her own platform, not despite it.

The VP’s feedback in her promotion packet: “Sarah demonstrated Principal-level thinking by prioritizing organizational outcomes over personal attachment to her work. She turned a potential conflict into a model migration that raised the bar for how we sunset technology.”

Questions for Reflection

Have you encountered similar situations where your work was being deprecated or consolidated?

How did you respond: as the Martyr, the Checked-Out, or the Architect?

What organizational decisions are you currently fighting on technical grounds that might be about capacity, strategy, or business context?

Where could you turn deprecation, migration, or consolidation into a leadership opportunity?

Staff engineering isn’t about building systems that last forever. It’s about building systems that serve their purpose, recognizing when that purpose changes, and leading the transition with grace and strategic thinking.