Managing Senior Engineers: Mistakes Every New VP Makes

When I became a VP of Engineering for the first time, I had six senior and staff engineers reporting up through my managers. Within eight months, I'd lost two of them. One to a competitor. One to "I just don't feel challenged anymore."

Both exits were my fault.

Senior engineers are a different species. The management instincts that work well with mid-level engineers will actively backfire with senior and staff-level people. I learned this the hard way, and I've since watched a dozen new VPs make the same mistakes.

Here are the seven mistakes, why they happen, and what to do instead.

# Mistake 1: Micromanaging the How

When a senior engineer tells you they can solve a problem, your instinct might be to ask about their approach, suggest alternatives, and request regular progress updates.

With a mid-level engineer, this is responsible management. With a senior engineer, it's an insult.

Senior engineers were hired for their judgment. When you micromanage their approach, you're communicating that you don't trust their judgment. They won't tell you this directly. They'll just start looking for a job where their judgment is respected.

What to do instead: Define the outcome clearly. "We need the search latency under 200ms at p95 for our expected Q3 traffic. You own the approach." Then get out of the way. Check in on progress, not process. Ask "how's it going?" not "why did you choose Elasticsearch over Typesense?"

If you genuinely think their approach is wrong, share your concern once, as a peer, not as a directive. "I've seen this pattern cause issues at scale. Have you considered X?" If they've considered it and disagree, let them disagree. They'll learn from the outcome either way, and your trust will be intact.

# Mistake 2: Treating Them Like Individual Contributors Who Just Write Better Code

A senior engineer isn't just a better coder. They're a force multiplier. Their impact should extend far beyond the code they personally write.

I had a staff engineer who wrote beautiful code, reviewed PRs thoughtfully, and kept to herself. On paper, she looked productive. In reality, she was underperforming for her level because her influence wasn't reaching the broader team.

The mistake was mine: I hadn't set expectations for impact beyond individual output.

What to do instead: Set explicit expectations for scope of influence. At my current company:

• Senior engineers are expected to influence their team (5-8 people). They set technical direction, mentor mid-level engineers, and make design decisions for their team's domain.
• Staff engineers are expected to influence their area (2-3 teams). They drive cross-team technical initiatives, create standards that others follow, and identify strategic technical risks.
• Principal engineers are expected to influence the org (all of engineering). They shape company-wide technical direction and represent engineering in executive decisions.

Make this explicit during onboarding, reinforce it in 1:1s, and evaluate against it in reviews.

# Mistake 3: Not Giving Them Hard Enough Problems

This is the mistake that cost me my first staff engineer. She was solving problems that were challenging for a senior engineer but routine for someone at her level. She wasn't growing. She wasn't engaged. She was coasting.

I thought I was being kind by not piling on pressure. In reality, I was boring her to death.

What to do instead: Senior engineers need problems that stretch them. Not busywork. Not feature tickets. Problems that require them to think deeply, make tradeoffs under uncertainty, and produce work that they're genuinely proud of.

My rule: at least 30% of a senior engineer's time should be spent on work that makes them slightly uncomfortable. Not overwhelmed. Uncomfortable. That's the growth zone.

Examples of appropriately challenging work:

• Design a system that needs to handle 100x current scale
• Create the technical strategy for a domain nobody has expertise in
• Fix a production reliability problem that's been unsolved for 6 months
• Evaluate and recommend a technology bet that the company will commit to for 3+ years

# Mistake 4: Shielding Them from Business Context

New VPs often filter information. They attend the executive meetings, hear about business strategy, financial pressures, and organizational politics, and then sanitize it for the engineering team. "Just focus on the tech. I'll handle the business stuff."

With mid-level engineers, some filtering is appropriate. With senior engineers, it's crippling.

Senior engineers make better technical decisions when they understand the business context. The engineer who knows you're planning an acquisition in Q3 will make different architectural choices than the engineer who doesn't. The engineer who knows the company is cash-constrained will propose different solutions than one who assumes unlimited budget.

What to do instead: Share business context freely with senior engineers. Not gossip. Context. Revenue numbers. Competitive threats. Strategic priorities. Hiring plans. Financial constraints.

I include my staff engineers in monthly business reviews. They hear the same numbers the C-suite hears. Their technical decisions got measurably better after I started doing this.

# Mistake 5: Avoiding Disagreements

Senior engineers have strong opinions. They'll push back on your decisions. They'll disagree publicly. They'll tell you when they think a strategy is wrong.

New VPs often interpret this as insubordination or negativity. So they avoid the disagreement, make decisions without consulting the senior engineers, or pull rank to end debates.

All three responses erode trust and eventually drive senior engineers away.

What to do instead: Welcome disagreement. Actively seek it out. In every major decision, ask your senior engineers: "What am I missing? Where could this go wrong? Why might this be the wrong approach?"

The best senior engineers I've worked with were the ones who told me I was wrong more often. Not because they were contrarian, but because they were honest. That's worth more than agreement.

When you do disagree, explain your reasoning fully. "I hear your concern about X, and you might be right. Here's why I'm going a different direction: [specific reasoning]. If Y happens, we'll revisit." That's respecting their opinion while making a decision.

# Mistake 6: Not Sponsoring Their Career

Senior engineers often hit a career plateau. They've mastered the technical skills. The next level requires visibility, influence, and organizational navigation that they may not know how to develop.

Your job as their VP is to sponsor them. Not just mentor. Sponsor.

Mentoring is giving advice. Sponsoring is creating opportunities.

What to do instead:

• Put them in rooms they wouldn't normally be in. Invite them to executive discussions. Let them present to the board.
• Give them visible, high-impact projects. Not just technically interesting ones.
• Advocate for them in calibration and promotion discussions when they're not in the room.
• Connect them with leaders in other companies who can broaden their perspective.

The difference between a senior engineer who stays 5 years and one who leaves after 2 is usually sponsorship.

# Mistake 7: One-Size-Fits-All Management

I once managed three staff engineers simultaneously. One wanted weekly 1:1s with a structured agenda. One wanted biweekly casual conversations. One wanted monthly check-ins and otherwise to be left alone.

I gave them all the same weekly 1:1 because "consistency is fair."

The first engineer was happy. The second was mildly annoyed. The third started skipping meetings and eventually told me the meetings felt like surveillance.

What to do instead: Ask each senior engineer how they want to be managed. Literally ask. "What cadence of 1:1s works for you? How do you prefer to get feedback? What does effective support from me look like?"

Then do what they say. Fairness doesn't mean identical treatment. Fairness means each person gets what they need to do their best work.

# The Stealable Framework: The TRUST Model

T - Trust their judgment. Define outcomes, not approaches.

R - Raise the bar. Give them problems that stretch them. 30% of their time should be uncomfortable.

U - Unfiler the context. Share business context freely. Better information produces better decisions.

S - Sponsor their growth. Create opportunities for visibility and influence. Advocate for them when they're not in the room.

T - Tailor your management. Ask how each person wants to be managed. Then do that.

Senior engineers don't leave companies. They leave managers who treat them like interchangeable resources. If you manage them as the unique, opinionated, high-judgment individuals they are, they'll build things you couldn't have imagined.