Role Design Template

A role design should answer four questions before you hire: what problem does this role own, what outcome should improve, what decisions can the person make, and where does responsibility stop?

Use this template before turning a role into a public job description.

Role title: [Title candidates will recognize]

Why this role exists: [The business problem that requires this role]

Primary outcome: [What should be meaningfully better because this person exists?]

Reports to: [Name / role]

Works closely with: [Critical people or functions]

Company stage: [Pre-revenue / early revenue / growth / established]

Role type: [IC / manager / founding hire / functional lead / hybrid]

Current situation: [What is happening today?]

Cost of leaving it unresolved: [What becomes slower, more expensive, risky or unreliable?]

What has already been tried: [Process, owner, tool or workaround]

Why it is insufficient: [What remains unresolved?]

Core responsibility: [The durable problem this person is accountable for solving]

A role is easier to hire for when the founder can explain the problem without mentioning the job title.

Write 1–3 outcomes, not a list of activities.

Outcome: [Concrete result]

Evidence of success: [Observable evidence]

Time horizon: [30 days / quarter / ongoing]

What this person controls: [Decisions, resources and processes]

What this person influences: [Dependencies outside direct control]

Repeat for each major outcome.

Do not hold someone fully accountable for an outcome they cannot materially influence.

A role without decision rights can become coordination disguised as ownership.

Escalation rule: [What must be escalated?]

Escalate decisions that materially change company strategy, create unusual financial or legal risk, commit the company beyond the role's authority, or affect another team's core ownership.

"Everything needs founder approval" is not role design.

This role does not own:

• [Responsibility that belongs elsewhere]
• [Responsibility that belongs elsewhere]
• [Responsibility that belongs elsewhere]

Why: [Explain the boundary]

Clear boundaries prevent catch-all roles and make adjacent ownership explicit.

• Meet people closest to the problem.
• Review the existing process, data and constraints.
• Establish the baseline.
• Document the biggest unknowns.
• Confirm what the role actually owns.

Evidence by day 10: [What should be understood or documented?]

• Choose the highest-value problem within the role's authority.
• Make a small observable improvement.
• Establish the operating rhythm.
• Surface dependencies and risks.

Evidence by day 20: [What changed? What was learned?]

• Take responsibility for the recurring workflow.
• Set the first meaningful baseline.
• Agree on the next 60-day priorities.
• Clarify what should stop, continue or change.

Evidence by day 30: [What can now run without the founder?]

By day 30: [Understand + first improvement]

By day 60: [Own + stabilize]

By day 90: [Demonstrate a repeatable result]

A founding hire may need to create the process. A later specialist may need to improve an established one. Match the plan to company maturity.

Primary measure: [Measure tied to the outcome]

Secondary measures: [Measure] / [Measure]

Quality guardrail: [What must not deteriorate while the primary measure improves?]

Avoid activity counts unless activity is genuinely the desired outcome.

Receives from: [Inputs / decisions / information]

Provides to: [Outputs / decisions / information]

Critical dependency: [Person, team, customer, system or process]

When the dependency fails: [Escalation / fallback]

The purpose is to make handoffs explicit before they become interpersonal friction.

Do not begin with credentials. Begin with evidence.

Must demonstrate:

• [Capability]
• [Capability]
• [Capability]

Strong evidence looks like: [Specific result, work sample or demonstrated behavior]

Nice to have: [Useful but nonessential capability]

Do not overvalue: [Prestige signal that does not reliably predict the outcome]

The relevant question is whether the candidate's evidence matches the problem the role must solve.

Ask candidates what they owned, what they changed, what constraints existed, what they decided and what happened afterward.

The manager will provide:

• [Context]
• [Access]
• [Decision clarity]
• [Feedback cadence]
• [Resources]

The manager will not:

• [Constantly reclaim ownership]
• [Change priorities without explanation]
• [Hold the person accountable for decisions they cannot make]

If the founder wants ownership, the founder must give enough authority for ownership to exist.

Review after the first 30–60 days.

Is the problem still the right problem? [Yes / No / Changed]

Does the person have enough authority? [Yes / No]

Are the outcomes measurable? [Yes / No]

Are responsibilities duplicated elsewhere? [Yes / No]

Has the role become a catch-all? [Yes / No]

What should be removed? [Responsibility]

What should be added? [Responsibility]

What decision should move closer to the role? [Decision]

Role design is not finished when the job description is published. Early hires often reveal organizational assumptions that were invisible on hiring day.

[ROLE TITLE]

Why this role exists [Business problem and why the company needs this role now.]

What you will own

• [Outcome]
• [Outcome]
• [Outcome]

What success looks like [2–4 observable results]

What you can decide [Key decision rights]

What you will work with [Key interfaces]

What we are looking for [Evidence-based capabilities]

Your first 90 days [30 / 60 / 90-day outcomes]

What is not part of this role [Important boundaries]

How we will work together [Manager relationship, feedback cadence and operating rhythm]

Before publishing the job description:

1. Could a strong candidate explain what they would own after reading it once?
2. Could the manager explain what they are not allowed to delegate to this person?
3. Can the team distinguish this role from adjacent roles?
4. Can the hire be evaluated using evidence rather than charisma?
5. Can you tell after 90 days whether the role is working?
6. Does the role have enough authority to deliver its assigned outcomes?

If several answers are no, fix the role design first.

This is SOE editorial synthesis, not a copy of a single hiring framework.

Stripe Atlas separates preparation, sourcing, interviewing, decision-making and onboarding in its guidance for founders hiring early employees. Current Y Combinator startup role specifications also show concrete ownership and early outcome expectations, including 30/60/90-day framing in some roles.

SOE combines those observations into a reusable artifact: problem → outcomes → decision rights → boundaries → 30/60/90 days → measures → interfaces → candidate evidence → interview evidence → manager contract → role-health review.

No founder story, interview, quotation, statistic, personal testing or fabricated credential is claimed here.

Related reading: \2 · \2

Start with the business problem, then define the role outcome, responsibilities, decision rights, boundaries, dependencies and evidence of success. Review the role after the first 30, 60 and 90 days and change the design when the work changes.

1. Fill it with one real situation rather than hypothetical inputs.
2. Record the evidence behind each important field.
3. Make the smallest decision the tool is designed to support.
4. Set a review date and update the tool when the evidence changes.

Good output: another person should be able to understand what was decided, why, what remains uncertain, and what happens next without needing a separate founder explanation.