Titles are useful shorthand for the market, but they are poor substitutes for role design. In one company a Head of Engineering may manage several managers, own architecture direction and sit with the executive team. In another, the same title may describe the most senior hands-on engineer in a team of eight. If you choose the title before defining the work, you risk attracting the wrong people and creating the wrong expectations.
Define the operating problem
Start with the problem the business needs this person to solve. Is delivery unreliable? Has the team grown faster than its management structure? Does architecture need stronger direction? Is the founder or CTO carrying too much day-to-day engineering leadership? Is the organisation preparing for a new product, acquisition or scale event?
Those situations imply different jobs. A strong Engineering Manager may be exactly right when the need is to coach engineers, improve delivery and create healthy team practices within an established technical direction. A Head of Engineering becomes more likely when the person must shape organisation design, set engineering standards across multiple teams, work across product and business leadership, and carry broader accountability for the engineering system.
Make the span of ownership visible
Team size is only one signal. Ask how many teams and management layers exist, who owns hiring and performance decisions, whether the role manages managers, and how product ownership is structured. Then define what sits outside the role. If a CTO owns architecture and strategy, what decisions remain with the Head of Engineering? If Product owns delivery priorities, where does engineering planning begin and end?
Ambiguity here creates expensive mismatches. Senior candidates may assume executive-level scope because of the title, while the business expects hands-on delivery management. Alternatively, a company may advertise an Engineering Manager role but expect someone to redesign the organisation and influence board-level technology decisions. The market can work with either model when it is explained clearly.
Decide how technical the role must remain
“Technical” is not a binary requirement. A leader may need to review architecture, challenge design decisions and understand production risk without writing code every day. Another role may genuinely require significant hands-on contribution because the team is small or the platform is at an early stage. Be specific about the decisions the person must be able to make and the level of detail they need to enter.
This also changes the candidate pool. Someone who has spent several years leading a large engineering organisation may not want — or be best suited to — a role requiring daily implementation. A highly capable hands-on manager may not yet have experience leading managers, shaping budgets or handling the organisational consequences of rapid growth. Neither gap is a criticism; it is a fit question.
Choose the title after the work is clear
Once ownership, team shape, technical depth and business expectations are clear, choose the title that best helps the market understand the opportunity. Then make the first paragraph of the brief even clearer than the title. Explain why the role exists, what the person will inherit, what they need to change and how success will be recognised.
This approach also improves interviews. Instead of asking generic leadership questions, you can test examples that resemble the actual work: reorganising a team, improving reliability, managing a delivery reset, making architecture trade-offs or developing managers. The result is a hiring process focused on what the person needs to do next rather than whether their previous company used the same title.
A practical role-design test
Write down the five decisions this person must be able to make without escalating them. Then write down the five outcomes you expect them to influence in the first year. If most of the list concerns team coaching, delivery health and execution within an established technical direction, an Engineering Manager title may be clearer. If the list includes organisation design, cross-team engineering standards, senior hiring, architecture direction and executive trade-offs, the role is probably broader.
Share that list with the CTO, product leader and anyone else involved in the appointment. If each person describes a different job, resolve that before going to market. Candidate disagreement later in the process is often a symptom of internal role ambiguity rather than a candidate-quality problem.