When Your VP of Engineering Should Actually Be Three People

The Impossible Job Description

We see this VP of Engineering job posting every week: "Lead a team of 30 engineers. Set technical direction. Own the architecture. Manage hiring and retention. Report to the CEO. Drive process improvements. Ensure quality and delivery timelines."

That's three full-time jobs stapled together. And companies wonder why their VP of Engineering burns out in 18 months.

The problem isn't the people — it's the role definition. As engineering organizations grow past 15-20 engineers, the VP of Engineering role naturally splits into three distinct functions that require fundamentally different skills.

The Three Roles Hidden in One Title

Role 1: The People Leader (Head of Engineering Management)

This person's job is humans. They own:

• Hiring and retention — Building the pipeline, closing candidates, preventing attrition
• Career development — Growth frameworks, promotion criteria, 1:1s
• Team health — Resolving conflicts, maintaining culture, managing performance
• Organizational design — Team structure, reporting lines, cross-team collaboration

The skills: Empathy, communication, coaching, conflict resolution, organizational psychology. This person should spend 70%+ of their time in conversations with people, not looking at code.

Role 2: The Technical Leader (Chief Architect / Principal Engineer)

This person's job is systems. They own:

• Technical strategy — Which technologies, frameworks, patterns to adopt
• Architecture decisions — System design, API contracts, data models
• Technical debt management — Prioritizing what to fix, when, and why
• Quality standards — Code review culture, testing strategies, reliability targets

The skills: Deep technical expertise, systems thinking, pattern recognition, ability to simplify complexity. This person should be reading code, drawing architecture diagrams, and making build-vs-buy decisions.

Role 3: The Delivery Leader (Director of Engineering / Program Management)

This person's job is output. They own:

• Delivery cadence — Sprint planning, release management, roadmap execution
• Process optimization — CI/CD pipelines, developer experience, tooling
• Cross-functional coordination — Working with product, design, and stakeholders
• Metrics and visibility — Cycle time, deployment frequency, incident response

The skills: Project management, process design, stakeholder communication, data-driven decision making. This person should be running standups, unblocking teams, and reporting progress to leadership.

Why One Person Can't Do All Three

The People Leader:
  Calendar: 80% meetings, 1:1s, interviews
  Energy: Emotionally intensive, requires deep listening
  Failure mode: When overwhelmed, stops having 1:1s → attrition spikes

The Technical Leader:
  Calendar: 60% deep work, design reviews, code
  Energy: Cognitively intensive, requires focus blocks
  Failure mode: When overwhelmed, makes hasty architecture decisions → tech debt

The Delivery Leader:
  Calendar: 70% coordination, planning, reporting
  Energy: Context-switching intensive, requires breadth
  Failure mode: When overwhelmed, stops tracking metrics → missed deadlines

When you combine these into one role, you get a person who does all three poorly. They have 1:1s during their architecture thinking time. They skip design reviews to attend planning meetings. They don't track metrics because they're too busy interviewing candidates.

The Transition Points

Not every company needs all three roles from day one:

5-10 engineers:   One VP/Head of Engineering does everything (it's manageable)
10-20 engineers:  Split out a Principal Engineer / Architect (most critical)
20-40 engineers:  Add a Director of Engineering for delivery (second split)
40+ engineers:    All three roles are full-time positions (non-negotiable)

The most common mistake is waiting too long for the first split. If your VP of Engineering hasn't written code or reviewed an architecture document in three months because they're buried in people management, you're already past the point where you need a dedicated technical leader.

How to Make the Split

Option A: Hire Laterally

Promote or hire into the two supporting roles while keeping your VP of Engineering focused on their strongest area:

Option B: The Fractional Approach

Not ready for three full-time hires? Use fractional leaders to fill the gaps:

• Fractional CTO/Architect: 2-3 days/week for technical strategy and architecture decisions
• Fractional VP of Engineering: 2-3 days/week for people management and org design
• Part-time Delivery Coach: Agile coach or program manager for process optimization

This is exactly where a fractional engagement works well. You get senior-level expertise in the gaps without the full-time cost, and as the organization grows, you can transition to full-time hires with a clear job description based on what actually works.

The Warning Signs You've Waited Too Long

• Your VP of Engineering hasn't had a 1:1 with a direct report in three weeks
• Architecture decisions are being made by default (whoever touches it first)
• Nobody knows the actual deployment frequency or cycle time
• Senior engineers are leaving because they "don't have a technical leader"
• Product is frustrated because delivery is unpredictable
• The VP is working 70+ hour weeks and still dropping balls

If three or more of these are true, you don't have a VP of Engineering problem. You have a role design problem. Fix the structure, and the performance follows.

Stop asking one person to do three jobs. Either split the role, bring in fractional support, or accept that you're burning out your best leader for no good reason.