VP Engineering (vice president of engineering)

The VP Engineering, or vice president of engineering, leads the organisation responsible for designing, delivering and operating software products. They connect the company’s priorities with the capabilities of its technical teams. Their role combines team leadership, delivery coordination and judgement on the technical investments needed over time.

Their scope depends on the organisation. It may cover several engineering domains and involve working through team managers or directors. The titles Head of Engineering and director of engineering often cover the same scope. The title alone therefore does not establish their responsibilities: specify the teams involved, the decisions they make and the matters they share with other executives. Their reporting line and budget authority must also be explicit.

VP Engineering, CTO and Engineering Manager: who does what?

To allocate responsibilities, you can start with the following questions and then adapt them to your organisation:

• VP Engineering: who organises the teams, supports their managers and coordinates delivery commitments?
• CTO: which decisions on technological direction fall to them, and which do they share with the VP Engineering?
• Engineering Manager: which decisions remain at team level and which require trade-offs between teams?

This allocation should give team managers a clear scope for decision-making. If every difficulty is escalated to the VP Engineering, examine the responsibilities delegated and the resources available to managers. Conversely, a matter involving several teams needs a clearly identified owner.

The roles described in the GitLab, Sourcegraph and AEG frameworks converge on organisational leadership and technical execution, with different scopes. To define a position, therefore, start with the decisions to be made and the teams to be led, then choose the title that describes that need.

The challenge is to reconcile the company’s commitments with its engineering resources. A product priority involves development time, technical choices and sometimes several teams. The VP Engineering must be able to connect these dimensions so that leadership understands what it can expect from the organisation.

Quality and reliability are part of this responsibility. A trade-off favouring immediate delivery may postpone an investment that would benefit the systems. To make a decision, make the anticipated consequences visible: deferred work, dependencies between teams and risks to product operation. The useful question is which compromises the company accepts and how it will monitor them.

The management structure also matters. Developing managers and teams supports the ability to make decisions at the right level. During an organisational change, specify what each manager will be able to decide, the matters on which they will need to coordinate and the support available to them. A new allocation of teams should be linked to a concrete problem.

Fictional example: two teams commit to features that depend on the same platform work. The schedule looks achievable when each team considers its work separately. Ask the VP Engineering to explain the dependency, the available resources and the sequencing options. Leadership can then choose a shared commitment while understanding what will be deferred.

Finally, to assess a candidate’s suitability, distinguish between the difficulties they have already faced. Supporting managers, coordinating several teams and adjusting technical investments draw on different experiences. A hire should be linked to your company’s priority problem. Without this clarity, you risk assessing a general ability to lead when the position calls for very specific trade-offs.

• Organise teams and their responsibilities to support engineering priorities.
• Support managers in developing their own skills and those of their teams.
• Coordinate delivery plans with product leadership and technical managers.
• Lead the recruitment needed to develop the organisation within the assigned scope.
• Make trade-offs on technical investments that support quality and delivery capacity over time.
• Monitor product quality and reliability and improve the associated practices.
• Allocate engineering resources to agreed priorities in line with the position’s budget responsibilities.

A useful background combines an understanding of software development with experience of leading teams. Education in computing can contribute to the technical foundation. Professional experience can also provide this knowledge: AEG explicitly accepts experience equivalent to the computing degree cited in its vacancy. This example does not establish a general entry requirement for the profession.

On the technical side, look for the ability to understand an architectural decision, its constraints and its effects on product operation. The candidate must be able to connect a technical investment with the organisation’s needs. Proficiency in a specific environment should be assessed in relation to your scope, without treating a tool as a substitute for technical judgement.

Their management background should allow you to assess the responsibilities they have actually held. Leading managers involves helping them develop their teams and make their own decisions. Distinguish this experience from directly managing developers alone. Also examine their role in coordination with product teams and in organisational development.

To compare career backgrounds, put the knowledge and skills acquired into context: the variety of teams led, technical problems encountered, decisions entrusted to them and changes they supported. The same title can cover different responsibilities. Prioritise the match with the difficulties your future VP Engineering will need to address. The assessment section then allows you to examine how the candidate applies this knowledge and experience in a situation similar to yours.

To assess a VP Engineering, you can structure discussions around the following stages, adapting them to the responsibilities you want to entrust to the role.

1. Define criteria based on the position

Choose the situations the candidate will need to handle: team coordination, manager development, technical trade-offs or reliability improvements. For each, describe an expected decision and the people involved.

Use these criteria to compare candidates. Distinguish the knowledge and skills needed from the outset from those that can develop with experience of the context. Give explicit consideration to technical judgement and the management of managers.

2. Examine past decisions

Ask the candidate to describe an organisational change for which they were responsible. Ask them to clarify the initial problem, the options considered, their decision and the consequences observed.

Explore a difficult delivery commitment in more depth: “What did you change when the available resources were no longer sufficient to deliver the plan?” Look for an explanation that connects the constraints with the choices made.

A positive signal is their ability to distinguish their contribution from that of the teams. Pay attention to accounts that remain general or attribute every difficulty to other functions. Ask what they would do differently.

3. Propose a case close to the scope of the role

Fictional example: a product priority depends on a team already working on reliability problems. Ask the candidate how they would prepare the decision with product teams and technical managers.

Provide the relevant context, then observe the information they request. Ask them to compare several options and explain which work they would defer. Assess their reasoning, their consideration of the systems and the coordination they propose.

A convincing answer makes the compromises understandable. An immediate conclusion without examining the constraints warrants further exploration. Involve a technical manager who can discuss the candidate’s assumptions.

4. Explore management and communication in depth

Ask how the candidate helped a manager develop. Ask them to specify the responsibilities left to that person, the feedback provided and the changes observed.

Also explore a disagreement with product leadership. Ask them to restate the other person’s constraints and explain how the decision was made. Assess their ability to listen and make a trade-off understandable.

A candidate who describes the limits of their involvement helps you understand their approach. If every decision seems to depend on them, question the role they give their managers.

5. Cross-check the evidence and decide

With the candidate’s consent, seek references from people who have observed the responsibilities being examined. Ask questions about specific situations and distinguish reported facts from general assessments.

Then compare the interview observations with the initial criteria. Record the points established and those that remain uncertain. Avoid allowing strong interpersonal confidence to obscure an unresolved technical or managerial question.

If your company lacks the technical expertise to assess this level of responsibility, involve a qualified person in this part of the assessment. Keep the decision on suitability for the position and your organisation a shared one.