Some Hires Fill a Role. Some Hires Are Hired to Build One.

Most hiring decisions are replacements or additions to an existing structure. A role is defined, a budget is approved, a brief is written. The recruiter sources candidates who can do the described work, the hiring manager selects the best fit, and the new person joins a team and a function that existed before they arrived. Their job is to perform the role. They are not expected to build it.

A function-driver hire is different in a way that matters from the first day of the search. This person is not joining an existing structure. They are being hired to create one. The US staffing function did not fully exist before the person brought in to drive it arrived. The e-learning vertical's sales infrastructure did not exist before the person who built it joined with that mandate. In each case, the hire was not filling a vacancy. They were being given a brief to build something that would not exist without them.

This distinction changes the profile of the right candidate, the structure of the brief, the expectations of the onboarding period, and the criteria by which success is measured in the first 90 days. Running a function-driver search the same way as a standard operational hire produces the wrong candidate, and the mismatch becomes apparent quickly because the wrong person for a role that does not yet exist is immediately visible in a way that the wrong person for a well-defined existing role sometimes is not.

The Difference Between Hiring for a Role and Hiring to Build a Function

A hire for an existing role is being evaluated against a defined set of requirements. The job description describes what the person will do. The interview process tests whether the candidate can do it. The onboarding provides the context and tools they need to begin doing it. The success criteria in the first 90 days reflect whether the person is performing the role as defined.

A function-driver hire is being evaluated against something harder to articulate: the judgment, initiative, and domain expertise required to take a business direction and translate it into an operational reality that did not previously exist. The job description for this hire describes an outcome, not a set of tasks. The interview process tests not whether the candidate can do the described work, but whether they can figure out what the work is and build the infrastructure to do it. The onboarding for this hire is not contextualisation for an existing process. It is the beginning of the process of building the context.

The candidates who excel in standard operational roles are not always the candidates who excel in function-driver roles. The skills overlap significantly: domain knowledge, operational capability, communication, judgment. The distinguishing factor is the tolerance for building without a template. A strong operational hire in a mature function thrives on clarity: clear expectations, clear processes, clear success metrics. A strong function-driver hire thrives on the absence of clarity and the mandate to create it. This is a genuinely different disposition, and it is more important than any specific domain credential in determining whether the hire succeeds.

What the Brief Looks Like When the Function Does Not Yet Fully Exist

Writing a brief for a function-driver hire is one of the more honest challenges in early-stage company building. The role is defined by its outcome, which the founder has a clear vision of, and its method, which is the person being hired to figure out. The brief needs to communicate both the vision and the latitude clearly enough that candidates can evaluate whether they are the right person for it, without being so vague that it attracts the wrong type of candidate who reads openness as the absence of direction.

The most effective briefs for this type of hire describe the market opportunity and strategic context clearly, name the specific outcomes the function needs to produce in its first year, and are honest about what does not yet exist: the processes, the client pipeline, the team, the playbook. They describe the infrastructure the person will be building and why that is the opportunity rather than framing it as a temporary gap. The wrong candidate reads a brief like this and sees risk. The right candidate reads it and sees exactly what they were looking for.

The brief should also describe what support exists. Not a detailed org chart for a team that does not yet exist, but an honest account of what the founder will provide, what resources are available, and what the expected relationship between the function-driver hire and the rest of the organisation looks like during the building phase. Function-driver hires who receive inadequate support in the early months fail not because they were the wrong person but because the context they needed to succeed was not built around them.

How the Onboarding and Ramp Period Works Differently

Standard onboarding for an operational hire has a well-understood shape: learn the processes, meet the team, understand the tools, begin delivering within a defined ramp period. The new person is being integrated into an existing system, and the onboarding is the transfer of knowledge about how that system works.

Onboarding a function-driver hire has a different shape because the system they are joining is the one they are being asked to build. The first weeks are not primarily about learning how things are done. They are about establishing what needs to be done and in what sequence, which requires a different kind of collaboration between the new hire and the founder.

The most productive onboarding for a function-driver hire is built around intensive initial access to the founder's knowledge about the market, the clients, the competitive context, and the strategic rationale for the function being built. The new hire needs to understand not just what the function should produce but why the company is investing in building it now, what the expected sequence of development looks like, and where the founder's instincts are strong and where they are genuinely open to the new hire's judgment about the right approach.

This conversation requires the founder to be explicit about something that founders are often reluctant to articulate: where their own knowledge ends and where the new hire's knowledge is expected to begin. A function-driver hire who is expected to build the US staffing function needs to know that the founder's US market knowledge has specific limits, and that the new hire's job is not to implement the founder's US strategy but to develop one that the founder will support. This clarity, given early, is what allows the function-driver hire to operate with genuine autonomy rather than spending the first months trying to reverse-engineer what the founder actually wants.

What Success Looks Like at 30, 60, and 90 Days for a Function-Driver Hire

The 30-60-90 day framework for evaluating new hires is useful for operational roles and misleading for function-driver roles if applied without adjustment. For an operational hire in a mature function, the framework asks whether the person is performing the defined role at increasing levels of independence and quality. For a function-driver hire, the relevant question at each stage is different.

At 30 days, the relevant question is whether the hire has developed a clear picture of what needs to be built and in what sequence. Not whether they have begun building it, but whether they have done the diagnostic work required to build it in the right direction. A function-driver hire who is executing enthusiastically at day 30 without having done this diagnostic work is probably building the wrong thing, and discovering this at month six is significantly more expensive than discovering it at month one.

At 60 days, the relevant question is whether the first version of the function's infrastructure, however minimal, is operational and producing early evidence about whether the strategic direction is correct. The function does not need to be mature at 60 days. It needs to have produced enough real-world feedback to validate or challenge the initial assumptions the hire brought into the role.

At 90 days, the relevant question is whether the hire has built something that is genuinely operational and has a clear path to the first meaningful result. Not the result itself, but the visible path to it. A function-driver hire who reaches 90 days with a functioning infrastructure and a credible plan for the first client or the first significant output has succeeded in the first phase. One who reaches 90 days with an extensive plan but no operational reality has a problem that needs to be addressed before the second phase begins.

How to Know When the Company Is Ready for This Type of Hire

A company is ready for a function-driver hire when three conditions are simultaneously true. The strategic direction for the new function is clear enough to communicate to a candidate who will be building it. The resources to support the building phase, financial, relational, and operational, are committed rather than conditional on the function producing results first. And the founder is genuinely prepared to give the hire the autonomy their mandate requires, rather than maintaining control over the key decisions while delegating the execution.

The third condition is the most commonly underestimated. A founder who hires a function-driver and then second-guesses the major decisions, requires approval for steps that should be within the hire's authority, or resets direction based on their own instincts before the hire's approach has had time to produce evidence, is not actually running a function-driver model. They are running a founder-led model with an execution layer, which is a different thing and requires a different type of hire.

The function-driver hire is not a harder version of a standard senior hire. It is a different type of hire that attracts a different type of person, runs through a different type of process, and produces a different type of outcome. Companies that treat it as a standard hire and apply the same criteria at each stage will consistently choose the wrong candidate and set unrealistic expectations for the first 90 days. Companies that understand the distinction build the functions they need, with the people who can build them.