How to Design a First Hire Role From Scratch

Why role design happens before the job advert, not during it

Many first hires go wrong not because the wrong person was chosen, but because the role itself was never properly designed. A founder under pressure lists everything that is currently overwhelming them, bundles it into a job title, and advertises it. The person who takes the job then discovers that the 'role' is really three or four unrelated jobs stitched together, with no clear sense of what success looks like or which decisions they are trusted to make on their own.

Good role design happens on paper, before a single candidate is contacted. It starts from an honest audit of what you actually need to stop doing, works out what a single coherent job looks like once that work is grouped sensibly, and only then becomes a job advert. Skipping this step does not save time; it moves the cost of doing it properly into the first few months of someone's employment, when it is far more expensive to fix.

Step one: audit what you are actually doing

Before you can design a role, you need an honest picture of where your time currently goes. For one to two weeks, keep a simple running list of every task you do, however small, noting roughly how long it takes and how often it recurs. This is tedious, but it reveals patterns that a memory-based guess almost never does: the admin task that eats four hours a week without you noticing, the customer emails that pile up every afternoon, the invoicing that always slips to the end of the month.

Once you have the list, mark each task with three things: how often it recurs, how much skill or judgement it requires, and how comfortable you would be handing it to someone else entirely. Tasks that recur often, require a describable skill rather than pure founder judgement, and that you would be genuinely willing to hand over are your raw material for the new role.

• Log every task for one to two weeks, including frequency and rough time spent.
• Mark each task by recurrence, skill level required, and your willingness to hand it over.
• Separate tasks that are genuinely repeatable from one-off projects that happened to land recently.
• Note which tasks depend entirely on knowledge that currently exists only in your head.

Step two: group tasks into a coherent role, not a pile

The most common role-design mistake is grouping tasks by how much they currently annoy you rather than by what they have in common. Bookkeeping, customer email and diary management might all feel like 'admin' from where you sit, but they are three different skill sets with three different rhythms of work, and asking one person to be excellent at all three from day one is a recipe for mediocre performance across the board rather than strong performance in one area.

A better approach is to group tasks by the skill they require and the person they primarily serve. Customer-facing tasks (support emails, order queries) form one coherent cluster. Financial admin (invoicing, expense tracking, basic bookkeeping) forms another. Operational tasks (scheduling, supplier coordination, stock) form a third. If your leftover work spans two or three of these clusters, you likely have the outline of two or three future roles, not one role today. Decide which cluster represents the most valuable, most recurring block of work, and design your first hire around that one, deliberately leaving the others for later.

1. List every task from your audit and note which broad function it belongs to.
2. Group tasks into two or three candidate clusters based on shared skill or shared customer.
3. Identify which single cluster represents the most consistent, valuable block of recurring work.
4. Build the first role around that cluster alone, resisting the urge to add 'a bit of everything else'.
5. Note the other clusters as future roles or ongoing freelance work, rather than folding them in now.

Step three: write success in observable terms

Once the role is defined, write down what success looks like at 30, 90 and 180 days, in plain, observable language rather than vague aspirations. '30 days: has processed all supplier invoices accurately and on time, with no more than one query per week needing your input' is a usable standard. 'Settling in well' is not, because it cannot be checked against and gives the new hire nothing concrete to aim for.

This exercise does double duty. It forces you to be precise about what the role is actually for, which often reveals gaps or overlaps you had not noticed, and it becomes the backbone of your job advert, your interview questions, and your first probation review. A role with no written success measures cannot be fairly assessed, which means both you and the new hire are guessing at how things are going, usually until something goes wrong enough to be undeniable.

If you cannot describe what 'doing this job well' looks like in a sentence, you are not ready to advertise it yet.

Step four: decide the decision rights

A role is not fully designed until you have decided which decisions the person can make on their own, which they should make and then tell you about, and which need your sign-off before they act. Skipping this step is one of the most common causes of frustration on both sides: the founder feels like everything still comes back to them, and the employee feels like they cannot move without permission, because nobody ever wrote down where the line actually sits.

A simple three-column approach works well here: decisions the role owns outright (for example, replying to routine customer queries within agreed guidelines), decisions the role makes but reports (for example, ordering standard stock up to an agreed value), and decisions that always need your approval first (for example, anything involving a new supplier contract or a refund above a set threshold). Writing this down before day one gives the new hire real authority to act, rather than authority that only exists in theory.

Step five: pressure-test the role before you advertise

Before writing the job advert, read the role description back and ask two honest questions. First, does this role still make sense if you removed everything that only feels urgent this month? A role built entirely from this week's crisis rarely survives contact with a normal, less chaotic month, and you risk hiring someone into a job that quietly disappears. Second, could a stranger, with no access to your memory, actually perform this role using only what is written down? If the answer relies on unwritten knowledge that lives in your head, that knowledge needs to be captured, even roughly, before the person starts.

It is also worth checking the role against realistic hours. If the genuinely recurring work only fills three days a week, resist inflating it to a full-time role by adding vague extra duties. A well-defined part-time role that matches real demand is a far stronger foundation than a full-time role padded out with tasks that will not consistently exist.

Turning the design into a one-page brief

The end product of this process should be a single page: the recurring problem the role solves, the core tasks grouped by cluster, the 30/90/180-day success measures, the decision rights, and the hours and reporting line. This page becomes your job advert, your interview scorecard, and your first probation review document, all drawn from the same source. Founders who skip straight to writing a job advert without this groundwork tend to end up hiring a personality they liked rather than a role they had actually defined, which is a much harder outcome to manage fairly once someone is in post.