Why We Killed the 'Staff Engineer' Title. The Glue Trap.

We followed the standard tech career ladder that every scaling startup adopts. It seemed like obvious best practice: Junior Engineer → Senior Engineer → Staff Engineer → Principal Engineer. The model came from Google, Facebook, and every other company we admired. Who were we to question it?

When we hit 60 engineers, we felt the "need" for Staff Engineers. Our best Senior Engineers were hitting the ceiling. They'd been Senior for three years. They were restless. We needed to give them somewhere to go that wasn't management. The Staff Engineer track seemed like the perfect solution—"technical leadership without people management."

We promoted our four best Senior Engineers to Staff. We gave them raises, new titles, and updated their job descriptions to focus on "technical strategy," "architecture," and "cross-team coordination." We expected them to become force multipliers—super-coders who would elevate the entire engineering organization.

Six months later, we had a problem. Our four most talented engineers had stopped writing code. They spent their days in back-to-back meetings. They produced design documents that nobody read. They "aligned stakeholders" and "unblocked teams" and "drove technical vision." They were everywhere—except in the codebase.

Our most productive builders had become our most expensive meeting sitters.

We ran a time audit. Our Staff Engineers were spending 70% of their time in meetings, 20% writing documents (RFCs, design docs, architecture proposals), and 10% coding. That 10% was usually reviewing other people's PRs, not writing their own.

Meanwhile, the rest of the team was struggling. Without our senior technical experts actually in the code, quality was slipping. Architectural decisions were being made by people who hadn't touched the codebase in months. The "technical leaders" were leading from the sideline.

After nine months, we killed the Staff Engineer title entirely. We flattened the IC track. We required every engineer—regardless of seniority—to ship code to production weekly. Two of our former Staff Engineers quit. The other two started coding again and became genuinely valuable.

Here's what we learned about why the "Staff Engineer" concept, as commonly implemented, is an organizational anti-pattern.

Section 1: The "Staff" Archetype and Why It Doesn't Translate

The Staff Engineer concept was codified by Will Larson in his book Staff Engineer: Leadership beyond the management track. It's a thoughtful exploration of how senior ICs can have impact without managing people. The book describes archetypes like the "Tech Lead," the "Architect," the "Solver," and the "Right Hand."

This model makes sense at Google, where a single "Area" might have 500 engineers and coordination costs are massive. When you have 50 teams working on interconnected systems, having full-time technical coordinators is valuable. The scale justifies the specialization.

At a 60-person company with 8 teams, this model is poison.

The Coordination Creep

When you create a role whose job description says "cross-team coordination" and "technical alignment," the person in that role will find coordination to do. It's human nature—you justify your existence by doing your job description.

Our Staff Engineers started scheduling "sync meetings" between teams that didn't really need syncing. They began requiring "architectural reviews" for changes that didn't need review. They created "Technical Steering Committees" that met weekly to discuss... not much of substance.

The more "coordination" work they created, the more they could point to their calendars and say "I'm busy and important." But the actual output was negative—they were creating process overhead that slowed everyone else down.

The IDE Closes, Google Docs Opens

We observed a predictable pattern within weeks of each Staff promotion:

Week 1-2: Still coding, but attending more meetings to "get the lay of the land."

Week 3-4: Starts writing a "Technical Vision" document. Coding drops to 50%.

Week 5-8: Deep in "Architecture Reviews." Coding drops to 20%.

Week 9+: The IDE is closed. The calendar is full. Coding is "when I have time," which is never.

The Staff Engineers didn't choose to stop coding maliciously. The role incentivized it. If your job is "technical strategy" and your calendar is full of meetings, when exactly are you supposed to code? Deep work requires 4-hour blocks. A Staff Engineer's calendar is sliced into 30-minute meetings.

The title effectively said: "You've been promoted beyond coding."

Section 2: The Ivory Tower Architect—When Strategy Becomes Theology

The most dangerous failure mode we saw was the "Ivory Tower Architect"—a Staff Engineer who had opinions about architecture but no skin in the game of implementation.

The GraphQL Federation Disaster

One of our Staff Engineers attended a conference and became convinced that GraphQL Federation was the future. He wrote a 40-page RFC explaining why we should migrate our REST APIs to a federated GraphQL gateway. He cited Netflix. He cited Airbnb. He drew impressive diagrams.

The Senior Engineers who would actually have to implement it pushed back. "This is complex. We don't have the use case for federation. Our services are simple CRUD. This is over-engineering."

But the Staff Engineer had the title. He had "architectural authority." Leadership sided with the "expert."

We spent four months building the federated GraphQL gateway. It was a disaster. Schema conflicts between services. Performance issues from the extra network hop. Debugging became a nightmare because errors could originate in any of three layers. The team was demoralized.

The Staff Engineer who mandated it didn't feel the pain. He wasn't on call when the gateway crashed at 3 AM. He wasn't debugging the resolver chain when a query timed out. He wasn't the one refactoring business logic to fit the GraphQL paradigm.

He had moved on to his next "strategic initiative."

Lesson: You cannot direct technical strategy if you do not feel the pain of implementation. Decisions made from whiteboards are different from decisions made while staring at a stack trace at midnight.

The Document That Nobody Read

Our Staff Engineers produced a lot of documents. RFCs. ADRs. Technical Visions. Platform Strategies.

We surveyed the rest of the engineering team. 85% of them had never read a single RFC written by a Staff Engineer. Not because they were lazy—because the documents weren't relevant to their work. The RFCs were written at such a high level of abstraction that they didn't translate to actionable guidance.

"We should adopt event-driven architecture" sounds strategic, but it doesn't tell the engineer implementing a feature which message queue to use, how to handle retries, or what the error semantics should be.

The documents became a form of organizational theater—proof that "strategy" was happening, without any practical impact.

Section 3: The Glue Trap—When Helping Becomes a Full-Time Job

Tanya Reilly coined the term "Glue Work" in her famous talk—the invisible work that keeps teams running. Onboarding new hires. Facilitating meetings. Writing documentation. Unblocking other teams. This work is valuable and necessary.

The problem is when you make glue work a role.

Parkinson's Law for Glue

When you create a Staff Engineer whose job is to "facilitate" and "unblock," they will find things to facilitate and unblock—whether those things need it or not.

Our Staff Engineers started "unblocking" by attending meetings on behalf of teams. "I'll handle the cross-functional sync so you can focus on coding." Sounds helpful! But it created a dependency where the team could no longer communicate directly with stakeholders. The Staff Engineer became a telephone game intermediary.

They started "facilitating" by creating more meetings. "We need a weekly architecture sync to stay aligned." No we don't. We have Slack. We have PRs.

They started "documenting" by writing process guides that created busywork. "All major changes need an RFC approved by the architecture board." Now every change is "major" (who decides?) and the architecture board (three Staff Engineers) becomes a bottleneck.

The Alignment Fetish

Our Staff Engineers became obsessed with "alignment." Every decision had to be "aligned across teams." Every change needed "buy-in from stakeholders."

Alignment is good. Performative alignment is waste.

We watched a Staff Engineer hold five meetings to build "consensus" on a database schema change. Five meetings! Twelve hours of combined engineer time! The change affected one service and one team. The decision could have been made by the tech lead in 10 minutes.

But the Staff Engineer needed to demonstrate value. Facilitating "alignment" was something visible. Staying out of the way was not.

Section 4: The Replacement—Engineers Who Ship

We eliminated the Staff and Principal titles. We collapsed the IC track to a simpler ladder: Engineer L1 through L6. L1-L2 are junior/mid. L3 is senior. L4-L6 are what we used to call "Staff" but with a crucial difference:

Every engineer, L1 through L6, must ship code to production every week.

No exceptions. Not "write a document about code." Not "review someone else's code." Ship your own code. Merged to main. Deployed to production.

Architects Must Build Their Designs

If you're an L5 "Architect," you architect by writing the skeleton code. You architect by implementing the hardest 20% of the new pattern and letting others fill in the rest. You architect by doing the scary refactor that everyone else is afraid to touch.

This isn't radical. It's how architecture worked for centuries in other fields. A chief architect designs the building and oversees construction—but they also know how to lay bricks. They earned their position by actually building things, not just drawing pictures of things.

What We Measured Changed What People Did

We started tracking "commits to production" for every engineer, visible on a team dashboard. Not to micromanage—but to make visible what was previously invisible.

Suddenly, it was noticeable when someone hadn't shipped in two weeks. Not as a punishment—as a conversation starter. "Hey Sarah, I noticed you've been in a lot of meetings. Is there anything we can do to give you coding time back?"

The cultural message shifted from "senior people are too important to code" to "everyone ships, together."

What Happened to Our Staff Engineers

Two of our four Staff Engineers quit within three months. They explicitly said they didn't want to code anymore—they wanted to be "strategic." We wished them well. They now work at big companies where full-time strategy coordinators make more sense.

The other two adapted. They started coding again. One admitted he actually missed it—he'd drifted into meetings because it felt like "advancement," but he was happier when building. The other became our best technical mentor, pairing with junior engineers and teaching through shared implementation.

Team velocity went up. Code quality improved. Architectural decisions got simpler—because the people making decisions were living with the consequences.

Conclusion: Leadership Is Demonstrated Through Code

The tech industry sends a perverse message to individual contributors: "If you want to get promoted, stop coding." This is insane.

We pay surgeons to do surgery. We don't promote the best surgeon to "Staff Surgeon" and tell them to stop operating and start writing essays about scalpels. The value of the surgeon is their skill in the operating room. Leadership means taking the hardest cases, training residents, and pushing the state of the art—while still operating.

Software engineering should be the same. Leadership is demonstrated through:

• Writing the code that others are afraid to write
• Reviewing code thoroughly and teaching through comments
• Mentoring by pairing, not by lecturing
• Making architectural decisions and then implementing them—proving they work

It is not demonstrated by escaping to a calendar full of meetings while the "junior" engineers do the "real" work.

If you aren't shipping, you aren't leading. You're just talking about leading.