The Staff Engineer Who Said No to Microservices (And Saved the Company)

The Staff Engineer Who Said No to Microservices (And Saved the Company)

The Setup: A Classic Tech Industry Story

Marcus had been at the e-commerce startup for four years when the new VP of Engineering arrived with a mission: “We need to modernize our architecture. We’re going to migrate to microservices.”

The company had grown from 15 to 120 engineers. The Rails monolith that powered the business was creaking under the weight of growth. Deployment cycles took hours. Teams blocked each other. Test suites took 45 minutes to run. Everyone felt the pain.

The VP’s plan was straightforward: decompose the monolith into 50+ microservices organized by domain boundaries. Modern. Scalable. How all the big tech companies do it.

There was just one problem: it was the wrong solution for this company, at this time, with this team. And Marcus, recently promoted to Staff Engineer, was one of the few people who could see it—and had the standing to do something about it.

The Problem With the Plan

Marcus spent two weeks analyzing the proposal before saying anything. He wanted to be sure. He reviewed:

His conclusion: microservices would make everything worse.

Here’s what he found:

1. The Real Bottlenecks Weren’t Architectural

2. The Team Wasn’t Ready

3. The Business Couldn’t Afford It

4. The Risks Were Underestimated

Marcus faced a decision: stay quiet and execute the plan (it wasn’t his call to make), or escalate his concerns and potentially damage his relationship with the new VP.

The Moment of Truth: How to Say No

Marcus chose to speak up, but he did it strategically. This wasn’t just about being right—it was about influencing organizational direction without authority.

Step 1: Build a Coalition (Quietly)

Before talking to the VP, Marcus socialized his concerns with:

He wasn’t politicking—he was ensuring his concerns resonated across perspectives and that he had allies who could validate his analysis.

Step 2: Present Data, Not Opinions

Marcus requested a meeting with the VP and came with a 15-page analysis (TL;DR on page 1):

What He Didn’t Say:

What He Did Say:

Step 3: Offer an Alternative

Critically, Marcus didn’t just say “no.” He proposed a pragmatic path forward:

Alternative Architecture: Modular Monolith

Instead of microservices, Marcus recommended:

  1. Modularize within the monolith: Enforce domain boundaries via namespaces, explicit interfaces, and dependency rules
  2. Extract only what truly needs to scale independently: Background jobs, image processing, and search—three services, not fifty
  3. Fix the real bottlenecks: Parallel test execution, better CI infrastructure, service ownership model
  4. Build distributed systems capabilities incrementally: Start with observability, testing strategies, and operational excellence for the 3 extracted services before scaling the pattern

Projected outcomes:

Step 4: Frame It as De-Risking, Not Blocking

Marcus positioned his proposal not as “we shouldn’t do microservices” but as “let’s build the foundation to do microservices successfully, prove we can operate them with a few services, then expand if it makes sense.”

This gave the VP a path to achieve the vision without the career-limiting risk of a failed big-bang migration.

The Outcome: Influence Without Authority

The VP agreed to pilot Marcus’s approach—with one condition: Marcus would lead the effort and be accountable for results.

Six months later:

Eighteen months later:

Lessons for Staff Engineers

Marcus’s story illustrates critical aspects of Staff+ leadership:

1. Technical Judgment Means Knowing When NOT to Use the Shiny Tool

Microservices aren’t bad—they’re a tool with trade-offs. Staff Engineers must:

2. Influence Requires More Than Being Right

Marcus could have written a Slack message saying “this is a bad idea.” He’d have been ignored. Instead, he:

Key insight: Staff Engineers don’t have authority to veto decisions, but they can shape them through strategic influence.

3. Taking Responsibility Is How You Earn Trust

When the VP agreed to the pilot, Marcus didn’t delegate execution—he owned it. This demonstrated:

4. Data Beats Intuition in Organizational Decisions

Marcus’s analysis was compelling because it was:

5. Know When to Escalate and How

Staying quiet would have been safer for Marcus’s relationship with the VP. But Staff Engineers are hired to provide technical judgment, especially when it’s uncomfortable.

The art is how you escalate:

6. Pragmatism Over Purity

Marcus’s proposal wasn’t architecturally pure—modular monoliths are a compromise. But compromise is often the right answer when you balance:

Staff Engineers must be pragmatists, not ideologues.

The Broader Implications

This story highlights a pattern in Staff+ work: the most important contributions are often the disasters you prevent, not the systems you build.

Marcus didn’t get promoted for shipping a shiny new architecture. He got promoted for:

These are the invisible contributions that define senior technical leadership.

Action Items for Staff Engineers Facing Similar Situations

If you see a problematic technical decision being made:

  1. Verify your intuition with data: Don’t rely on gut feel alone—analyze timelines, risks, and alternatives
  2. Understand the “why”: What problem is the proposal trying to solve? Is there a better way?
  3. Build a coalition: Who else shares your concerns? Who has complementary perspectives?
  4. Prepare a compelling case: Data, case studies, risk analysis, and alternatives
  5. Frame it as de-risking, not blocking: Help leadership achieve their goals more safely
  6. Be willing to own the alternative: Don’t just criticize—take responsibility for a better path
  7. Know when to disagree and commit: If you make your case and leadership decides differently, commit to execution

Remember: Staff Engineer is not just a senior coding role. It’s a strategic leadership role where technical judgment, influence, and organizational savvy matter as much as implementation skill.

Marcus’s story proves that saying “no” to the wrong solution—at the right time, in the right way—is one of the most valuable things a Staff Engineer can do.

../