Role purpose
What business drag is the role supposed to relieve, and what is outside the role?
Field Note
Hiring before the role is clear creates a management problem
A hire can add capacity. It can also inherit unclear ownership, vague decision rights, and founder context that never left the founder’s head.
Founder overload can be real. But the next hire should not become a container for every unresolved decision. The fix may be right. The sequence may be wrong.
Visible symptom
Too much work still routes through the founder.
The founder is overloaded. The team asks repeated questions. Projects slip. Approvals bottleneck. Delivery depends on founder memory. Everyone can see that the business needs more capacity or more structure, but the exact role is hard to define.
That creates a reasonable hiring instinct. If the founder is the constraint, add a delivery lead, ops manager, project manager, sales support role, or fractional operator. A person can help. But a person also needs clear work to own.
Fix founders usually consider
Hire the person who will take work off the founder.
The usual fix is to define a broad role around founder relief: own delivery, manage projects, clean up operations, follow up with leads, coordinate the team, handle clients, or keep tools updated. The job description can become a list of pressure points rather than a focused role.
That is where the sequence matters. If the role is supposed to own decisions, those decision rights need to be named. If the role receives handoffs, those handoffs need to be visible. If success depends on founder context, that context needs to be converted into rules, review points, or boundaries before the hire is expected to carry it.
Sequence risk
A vague role adds supervision instead of removing drag.
A hire can inherit every unclear input: unclear project readiness, unclear handoffs from sales, unclear client promises, unclear approval authority, unclear tools, and unclear definitions of done. When that happens, the founder does not get relief. The founder gets a new person to supervise through the same unresolved decisions.
The risk is not that hiring is wrong. The risk is hiring before the operating surface shows what the role should own, what it should not own, and which founder decisions need to change. The role should be designed around the pressure point, not around the founder’s exhaustion alone.
Fictional example
A delivery lead request hides decision-rights drag.
Fictional example: A founder wants to hire a delivery lead. Projects keep slipping, clients ask for updates, and team members wait for founder direction. The founder believes a delivery lead would absorb coordination and keep work moving.
In this fictional sample review, there may be a capacity issue later. But the immediate drag is unclear decision rights after sale and no handoff rule from sales to delivery. The new delivery lead would receive work without a clear scope confirmation, authority to push back, or rule for when the founder has to approve changes. The hire could help only after the role surface is clearer.
What to inspect first
Before hiring, define the work the role will actually own.
Decision ownership
Which decisions will the role make without waiting for founder approval?
Handoffs into the role
What information, scope, status, and timing must be clear before work reaches the role?
Founder approvals
What does the founder still approve, and what should stop routing through the founder?
30/60/90 clarity
What does success mean after 30, 60, and 90 days?
Management load
What support, review rhythm, and rules would the founder need to provide at first?
How a Bottleneck Audit maps it
The audit maps whether the next move is a role or role clarity.
A Bottleneck Audit would map founder bottlenecks, handoffs, recurring decisions, project readiness, approval points, and the work that seems to need a person. It would test whether the pressure is capacity, ownership, sequence, tooling, delivery design, or decision rights.
The output can clarify whether hiring belongs now, what the role should own, what needs to change first, and what implementation or documentation should be scoped separately before the role becomes realistic.
Manual route review