Your VP of Engineering Is a Project Manager in Disguise
The $350K Project Manager
Last quarter, a Series C startup asked us to evaluate why their engineering velocity had cratered despite growing the team from 15 to 45 engineers. We sat in on meetings for a week. The diagnosis took about two days.
Their VP of Engineering spent 80% of their time on sprint planning, ticket grooming, and status updates. They couldn't explain the system architecture. They hadn't reviewed a pull request in months. They had no opinion on the database migration strategy that was causing weekly outages.
They were a project manager earning a VP of Engineering salary. The company was paying $350K for someone to move tickets around in Jira.
And look — this isn't a knock on the person. They were working hard and genuinely cared about the team. But the role had been defined wrong from the start, and nobody had corrected it. This is way more common than you'd think.
What a VP of Engineering Actually Does
So what should the role look like? It has three pillars that most companies either conflate or ignore entirely:
1. Technical Strategy
A VP of Engineering should be able to answer these questions with specificity:
- What is our system architecture, and why did we choose it?
- What are the top 3 technical risks to the business in the next 12 months?
- Where are we accumulating technical debt, and what's the payoff timeline for addressing it?
- What technology decisions do we need to make in the next quarter, and what are the tradeoffs?
If your engineering leader can't answer these without checking with someone else, you have a problem.
VP of Engineering time allocation (healthy):
Technical strategy & architecture: 30%
People management & development: 25%
Cross-functional alignment: 20%
Process & delivery optimization: 15%
Hands-on technical work: 10%
VP of Engineering time allocation (broken):
Sprint ceremonies & status updates: 40%
Ticket management & grooming: 25%
Firefighting production issues: 20%
Hiring (reactive, not strategic): 10%
Technical strategy: 5% ← This is the problem
2. Engineering Culture
Let's talk about culture — and no, we don't mean ping pong tables and beer fridges. Culture is the set of defaults that determine how your team makes decisions when nobody's watching:
- Code review standards: Does the team ship quality by default, or does every PR need a gatekeeper?
- Incident response: When things break at 2am, does the team know what to do without being told?
- Technical decision-making: Are engineers empowered to make technology choices, or does everything need VP approval?
- Knowledge sharing: Does institutional knowledge live in people's heads or in documentation and code?
A strong VP of Engineering builds systems and habits, not dependencies.
3. People Development
This is the hardest part of the job — and the one most "project manager VPs" completely neglect because sprint planning eats all their time:
- Career frameworks: Engineers need to know what growth looks like beyond "senior" and "staff."
- Performance management: Not annual reviews. Continuous, specific feedback loops.
- Team structure: Organizing teams around domains, not projects. Conway's Law is real.
- Hiring strategy: Building a pipeline, not posting jobs when someone quits.
The Five Warning Signs
Alright, let's get practical. How do you know if your engineering leader is actually a project manager in disguise? Here are the patterns we see over and over:
Sign 1: They Can't Draw the Architecture
Ask your VP of Engineering to whiteboard the system architecture. Not from memory — that's unreasonable for large systems. But they should be able to explain:
- The major components and how they communicate
- Where the data lives and how it flows
- What breaks when load increases 10x
- Which parts of the system are most fragile
If they defer to "the senior engineers" for this, they're not leading the technical organization. They're managing the schedule.
Sign 2: Every Meeting Is a Status Update
Pull up their calendar. Go ahead, look at it right now. If more than 50% of their meetings are status updates, standups, or sprint ceremonies, the role has been reduced to information routing. They've become a very expensive telephone.
Healthy VP calendar:
Mon: Architecture review, 1:1 with tech lead
Tue: Cross-functional planning (product, design)
Wed: Technical deep-dive on migration project
Thu: 1:1s with direct reports, hiring debrief
Fri: Strategy work block, team retro
Broken VP calendar:
Mon: Standup, Sprint planning, Status sync
Tue: Standup, Grooming, PM sync, Status report
Wed: Standup, Sprint review, Exec status update
Thu: Standup, Grooming, Status sync, Sprint planning
Fri: Standup, Retrospective, Status report, More grooming
Sign 3: Technical Debt Has No Strategy
Every codebase has technical debt. The question is whether there's a strategy for managing it. A project-manager VP sees tech debt as "stuff engineers complain about." A real VP of Engineering has a prioritized list with business justifications:
Tech Debt Register (what it should look like):
| Item | Business Impact | Effort | Priority |
|------|----------------|--------|----------|
| Monolithic deploy pipeline | 2-hour deploys block features | 3 sprints | P1 |
| No database connection pooling | Outages above 500 req/s | 1 sprint | P1 |
| Inconsistent API error handling | 15% of support tickets | 2 sprints | P2 |
| No automated testing for payments | Manual QA adds 3 days/release | 4 sprints | P2 |
| Legacy jQuery in admin panel | Slow feature development | 6 sprints | P3 |
Sign 4: Firefighting Is the Default
We've all been there — it's 2am, the site is down, and someone pings the VP in Slack. But if your VP of Engineering is in every production incident channel personally fixing things, that's not dedication — it's a failure to build systems and processes. Incident response should be a well-oiled machine:
- On-call rotations with clear escalation paths
- Runbooks for known failure modes
- Blameless post-mortems that produce systemic fixes
- Monitoring and alerting that catches issues before customers do
The VP should be reviewing incident trends and improving the system, not personally restarting servers.
Sign 5: They Have No Engineering Strategy Document
Ask to see the engineering strategy. Not the product roadmap — the engineering strategy. A living document covering:
- Technical vision for the next 12-18 months
- Key architectural decisions and their rationale
- Hiring plan tied to technical needs
- Technical debt reduction plan with business justifications
- Platform and tooling investments
If this document doesn't exist, nobody is doing the strategic work of engineering leadership.
How to Fix It
Okay, so you've read the warning signs and you're nodding along uncomfortably. Now what? You've got a few options, and the right one depends on the person and the situation.
Option 1: Coach Your Current VP
This is always our first recommendation. Some project-manager VPs can absolutely grow into the full role — they just need the right support and, frankly, permission to stop attending every meeting:
- A fractional CTO or technical advisor to handle strategy while they learn
- Clear expectations: "Spend 30% of your time on technical strategy"
- Concrete deliverables: architecture reviews, tech debt register, engineering strategy doc
- Permission to stop attending every sprint ceremony
Give them 90 days with clear milestones.
Option 2: Split the Role
Sometimes — and this requires some honest reflection — the answer is that you need two people:
- Engineering Manager / Director: Owns delivery, process, sprint mechanics, team coordination
- VP of Engineering / CTO: Owns technical strategy, architecture, engineering culture
This is expensive but honest. It acknowledges that project management and technical leadership are different skill sets.
Option 3: Bring in Fractional Leadership
When companies need technical leadership but can't justify (or find) a full-time VP of Engineering, a fractional CTO can establish the technical strategy, set up engineering processes that don't require constant oversight, build the culture for scale, and mentor internal leaders who can eventually take over.
The goal isn't to be a permanent fixture. It's to build the systems and develop the people so the organization can run itself.
The Test
Before we wrap up, try this. Walk up to your engineering leader tomorrow and ask them these five questions. No prep, no warning:
- What are the top 3 technical risks to the business right now?
- What's our architecture, and why did we choose it?
- If we needed to handle 10x our current load, what breaks first?
- What are we building in the next 6 months that requires technical investment ahead of product work?
- What should our team structure look like in 12 months?
If they can answer all five with specificity and confidence, you've got the real deal. If they reach for Jira... well, now you know.
The difference between a project manager and a VP of Engineering isn't the title or the salary. It's whether they're building a delivery machine or just tracking the delivery schedule. One scales with your company. The other becomes the bottleneck that holds it back.