When your VP of Engineering keeps escalating decisions to you

You hired a VP of Engineering. They interviewed brilliantly. References were strong. The first 60 days were promising. And now, six months in, every meaningful decision is somehow back on your desk. The architecture choice. The hiring decision. The roadmap tradeoff. The deal with the customer who wants a custom thing. All of it. You hired someone senior so you could stop being the bottleneck, and you are more of a bottleneck than you were before.

The frame most CEOs reach for in this situation is "they lack confidence" or "they have too much on their plate." If you have a coach, they probably gave you some version of "they need more reps" or "you need to give them more rope." Both of those framings are wrong, or at least so incomplete that acting on them will waste the next quarter and probably the VP.

It's a system problem, not a person problem — and "delegate harder" isn't the fix.

Here is the actual diagnostic, the conversation you need to run, and the system change that makes it stick.

The misdiagnosis

When a senior hire escalates everything, three explanations get reached for, in roughly this order:

1. "They're not confident yet." Maybe true on day 30, almost never the real story by day 180. A VP-level person who can't make decisions after six months is not building confidence; something else is going on.
2. "They're overloaded." Sometimes real, often a symptom. The escalating VP is overloaded because they're routing decisions through you. Cause and effect get backwards here.
3. "They're just learning my context." This is the most seductive explanation because it lets everyone off the hook. The problem is that the "learning my context" period quietly becomes the steady state. Six months becomes eighteen.

The reason these misdiagnoses keep happening is that they put the work on the VP — they need more confidence, they need more reps, they need more context. Each one frames you as the patient teacher and them as the slow learner. None of which is what's actually going on.

The honest version: a senior hire who's been escalating for six months isn't building confidence. They're being trained out of decisions, one routed call at a time. Almost always because they're missing one or more of three things, none of which they control.

The actual diagnosis — three root causes

Root cause 1 · Decision rights are ambiguous. This is the most common. The org has a verbal "you own engineering," but no specific list of decisions the VP can make alone, decisions they should consult on, and decisions you reserve. So when the architecture call comes up, they don't know if making it without you is initiative or overstepping — and they route it to you to be safe. After it happens enough times, the safety move quietly becomes the operating model.

You'd be amazed how few companies have written this down. Most leaders run on inferred decision rights, and the inference fails any time the stakes feel non-trivial.

Root cause 2 · Strategic context is missing. A VP needs to know not just "what we're trying to do this quarter" but "what we're trying to do this year and why, and what tradeoffs we'd make to get there." When that context is in your head and only your head, every decision they touch eventually needs your input — because they can't tell which option is on-strategy and which is off-strategy without checking. They aren't escalating to be safe. They're escalating because they literally don't have enough information to make the call alone.

Most CEOs miss this one because the context feels obvious to them. It isn't — it's just invisible until someone writes it down.

Root cause 3 · There's fear of being wrong publicly. This is the political one, and it's the most uncomfortable. Some companies — usually small ones that have just hired a senior person — have a culture where mistakes by a new leader get audited in front of the rest of the team. The first time the VP makes a call that the founder publicly questions in a meeting, the VP stops making calls. They learn faster than you'd think. From then on, every decision goes through you, because every decision that goes through you is one they can't be blamed for.

If you're reading this and thinking "I don't do that," good. Most CEOs don't, intentionally. But you'd be surprised what gets read as that — a sharp question in a board meeting, a follow-up Slack DM, a public "wait, why are we doing X." Senior leaders read your micro-feedback signals harder than peers do. The senior hire who's been burned at a previous job is reading hardest.

The diagnostic question for you is: which of these three is it? It's almost always one of them. Sometimes two. Rarely all three. If you can't tell, the conversation to come will surface it.

Where to stage the conversation — and where most CEOs get it wrong

On The Accountability Dial™, there are two errors that show up here over and over. Most CEOs either reach for Boundary too early — "here's what needs to change or else" — or stay at Mention forever, dropping offhand "you don't need to run that by me" comments and treating those as if they were the conversation.

For a senior hire who's been escalating for several months, you are at Conversation: a named, scheduled exchange where you surface the impact and ask for ownership. The offhand comments you've made along the way were Mentions at most. Skipping straight to Boundary at six months — without a real Conversation first — is how you lose a senior hire who is genuinely fixable.

The Conversation — what to actually say

The 1:1 where you run this needs the three-beat shape from the Dial. Open in under sixty seconds. Don't pad it.

Beat 1 — what I'm seeing. Name the pattern. Three specific instances, recent.

"I want to talk about something I've been noticing for a while. In the last few weeks, three decisions have come back to me that I think should have stayed with you — the call on whether to backport the auth refactor, the eng-hiring loop for the staff role, and the conversation with the customer about the custom integration. I don't think any of those needed me. I want to understand what's making them come up."

Three specifics. Stated cleanly. No softening. No "you're doing great but" framing. You're not doing great in this specific way, and naming it directly is the work.

Beat 2 — what the impact is. Speak in terms of the company, not your own irritation.

"The impact is two things. One: every decision routed through me is a decision that's been delayed by my schedule, which means the engineering org is slower than it would be if you were calling it. Two: the team is reading my involvement as the operating model. They're starting to escalate to you, who then escalates to me, which is exactly the bottleneck we hired you to break."

The second one usually lands hard. The CEO escalation problem becomes the team escalation problem one layer down, and senior hires often haven't seen it from the cascading angle.

Beat 3 — what I want. This is the stage most CEOs flinch on. The ask isn't "delegate more." It's a structural request.

"From here, I want us to do three things. First, I want to be clear with each other about which decisions are yours alone, which we consult on, and which I reserve — and I'll send you a first cut by end of week. Second, I want to spend an hour walking you through the strategy in more detail than I have, including the tradeoffs I'd actually make. Third, I want to know if there's something I'm doing that's making this harder — a tone in meetings, a kind of question I'm asking, anything. I want a real answer."

That last one is what makes the conversation real. You are explicitly opening the door to the third root cause — fear of being wrong publicly — and letting them tell you, if it's there.

After Beat 3, stop talking. The next move is theirs. They'll either name a system gap (decision rights or strategic context) or a political signal (something you're doing). Either is useful. The bad outcome is a long deflection that lets the conversation end without naming anything — and that's what happens when you keep talking past Beat 3.

What ownership looks like — and what to do if it doesn't show up

A Conversation succeeds or fails on whether ownership shows up. In this specific situation, ownership looks like one of these:

• "Honestly, I haven't been sure which calls were mine to make. The auth refactor felt like a call I should run by you because of the customer impact. Let's get the decision rights doc done — that'll fix a lot of it."
• "I think I've been over-cautious. Last gig I made a call on hiring that got walked back publicly, and I think I'm flinching here. Let me work on it. Push me back when I escalate something that should be mine."
• "The strategy piece is real. I keep hitting situations where I don't know which way you'd want me to lean — like the custom integration thing. That session you offered would help."

Each of those is a working answer. The pattern: they name the specific system gap, propose a concrete change, and don't get defensive. That's ownership.

If ownership doesn't show up — the response is a long explanation of why each escalation was actually necessary, or a vague "I'll work on it" with no specific naming — you are now at Boundary, not Conversation.

A Boundary in this situation sounds like:

"I hear that. Here's where I am. In six weeks, I need to see a real shift. Specifically: the major decisions in engineering coming from you, with the explanation, not the question. I'll do my part on the decision rights doc and the strategy session. If the pattern hasn't shifted by then, we'll need to have a different conversation about whether this is the right shape of the role for you."

That is the conversation no one wants to have. It is also the conversation the company needs, if you've done your part of the work and the change hasn't come.

The system fix — what changes in how you run the company

The Conversation is half the work. The other half is the system change that makes the change stick. Without this part, the VP nods, agrees, and the same pattern returns in three weeks because nothing about the operating model has changed.

Three things to do in the 30 days after the Conversation:

1. Write the decision rights doc. A one-page document. Three columns: "VP decides alone," "VP and CEO consult before deciding," "CEO reserves." Specific decisions, not categories. "Architecture calls under $50K in compute spend and 1 quarter of eng time" not "technical decisions." Send your first cut. Iterate together. Sign it. Put it where both of you can refer to it. This single artifact resolves Root Cause 1 for most teams.

2. Run the strategy session, in writing. A 60-minute live session is good. The artifact that comes out of it is better. Write down: what we're trying to do this year. What the three tradeoffs are that we'd make to get there. What we'd cut if we had to cut something. What we'd add if we had a free quarter. Send it to the VP. Update it quarterly. This resolves Root Cause 2.

3. Audit your own micro-signals for a month. This is the hardest one and the most important. For 30 days, watch yourself in meetings where the VP makes a call. Notice the sharp question, the follow-up DM, the public "wait, why X." Most of those are reasonable individually. The aggregate, week after week, is what creates Root Cause 3. You don't need to stop asking sharp questions — you need to redirect them. "I'd love to understand the reasoning on that one — DM me after?" lands differently than "wait, why are we doing it that way" in front of six people.

The 30-day check-in is where you measure whether it worked. Specific question: did the major engineering decisions in the last 30 days come from the VP, with explanation, or from you? It's a binary read. If yes, the system change is taking. If no, you are at Boundary, and the harder conversation is the one to have next.

When this is the wrong role for them — and when it isn't

Sometimes, after you do all of this — the Conversation, the decision rights doc, the strategy session, the 30 days of clean signals — the VP still doesn't take ownership. That's worth naming clearly: it usually means the role isn't the right shape for them. Not that they're a bad leader. The shape of a VP role in a 200-person engineering org with this kind of CEO is highly specific. It doesn't fit everyone who'd be brilliant in a different shape. A senior IC role, a director role inside a bigger company, or a different stage of company might be the right next move.

That's not a failure of the hire. It's information that took six months and one structured conversation to surface. Most of the time, though, what you actually find is the opposite: the system change unlocks the VP, decisions start flowing from them, and the bottleneck moves where it should be — to the actual hard problems of the business, not to your calendar.

The thing worth remembering is that neither outcome happens without the Conversation. Most CEOs avoid it for months, telling themselves it's a confidence issue or a workload issue. Both outcomes — fixing the role or releasing it — are good outcomes for the company. Drifting in the middle for another quarter is the only bad one.

The math on doing nothing

The reason this is worth a structured Conversation now rather than another quarter of "let's see how it goes" is that the cost of drift is bigger than the cost of either outcome on the other side of the Conversation.

A VP-level replacement runs in the range of 30–50% of first-year cash comp for search and ramp, plus six to twelve months before the new hire is operating at the level you needed last quarter. In dollars, that's typically $150–400K and at least one quarter of leadership-team velocity. Real cost, paid in one bucket.

The cost of not having the Conversation is harder to see, paid in smaller buckets, larger in total. Every week of decisions routed through your calendar is a week the engineering org runs at CEO bandwidth, not VP bandwidth. The senior ICs reading the cascade start updating their LinkedIn — not because they're unhappy, but because they can tell the leadership layer above them isn't operating. The next senior hire is harder to make because the role is a known bottleneck. None of that shows up as a line item. All of it compounds.

The Conversation is cheap. The system fix is a week of work. The downside, if the role is wrong, is the same VP transition you'd eventually need anyway — caught at six months instead of fifteen.

How Ren makes this easier

Ren reads the context from your Slack and Teams threads, recognizes the escalation pattern before it's been the operating norm for six months, and helps you locate where it actually sits on The Accountability Dial™ — most CEOs mis-stage it as Mention or jump to Boundary, both of which lose the VP.

When you're ready to have the Conversation, Ren drafts the three-beat opening in your voice, not template language — naming the specific decisions that came back, the cascading-bottleneck framing, the structural ask. You edit. You send. The drafting that used to take an hour of agonizing takes five minutes of editing.

After the meeting, Ren prompts you to send the recap inside an hour, captures the what happened layer of the record (the conversation initiated, the change requested, the cadence agreed), and quietly schedules the 30-day check-in. The decision rights doc you committed to writing? Ren drafts it from the patterns it's already seen in your Slack — your real decisions over the last quarter — so you're editing, not staring at a blank page.

The drafts and prep stay between you and Ren — Tier 1, never visible to HR or the leadership team. Only the outcomes — did the conversation happen, did the pattern shift — roll up as the Tier 2 layer that becomes the company's record.

The CEOs who run Ren average 8–9 voluntary coaching sessions per manager per week, sustained for six-plus months, without mandates. The VP-keeps-escalating-to-me pattern is one of the most common reasons they reach for it the first time, and one of the most common patterns it resolves inside 60 days.

Take the three-minute product tour to see Ren draft a Conversation like the one above in real time, or talk with us about a deployment for your leadership team.