How do you stop every customer question reaching the founder?
Reduce founder dependency by making accepted commitments and decision responsibility available to the people who need to continue the work. Start with one repeated customer question and identify the information or authority missing from the current handoff. Test a colleague’s next action, then define the genuine exceptions that still need the owner.
Keep these in mind
- Identify which questions need information and which genuinely need the founder’s decision.
- Give each repeated handoff a record, owner and escalation condition.
- Test the handoff with a colleague who did not hear the original conversation.
Sort the questions that reach your phone
For one ordinary workday, record the questions employees bring to you. “What did the customer choose?” is a retrieval question.
“Can we accept a lower price?” is a decision question. “Who should collect the drawing?”
is an ownership question. They should not all produce the same answer: ask the founder.
Atlassian’s roles-and-responsibilities practice provides one way to clarify ownership. Use the questions interrupting your day to find the missing information. Each repeated question points to a record or decision rule worth improving.
Create a handoff the next person can use
In an illustrative design agency, a customer approves the concept but asks to delay production until legal review. The designer needs the approval source and the coordinator needs the condition.
The account lead owns the legal follow-up. A vague “approved” status will send all three people back to the founder.
Write a short record with the customer, affected work, current decision, unresolved condition and next owner. Include a source that explains the commitment. The record should be understandable without the founder narrating the history.
| Repeated question | Missing piece | Practical change |
|---|---|---|
| What did we promise? | Current commitment and source | Save the approved scope or date |
| Can I decide this? | Decision authority | Define the decision and escalation limit |
| Who does the next step? | Accepted ownership | Name a responsible person |
| Why is this blocked? | Unresolved condition | Record what is missing and who resolves it |
Keep a small number of useful escalation rules
An escalation rule should describe a situation staff can recognize. For example, a scope change after acceptance goes to the account lead; an unclear payment allocation goes to accounts. The founder can remain the approver for unusual commitments without being the only person who can locate everyday information.
Do not turn delegation into a collection of rigid rules for every possible case. Start with recurring decisions and leave genuine exceptions visible. Staff need a way to ask for help when the available context does not support a confident answer.
Run a founder-free handoff test
Choose a familiar job and let a colleague continue it using only the shared records. Stay available for safety or genuine exceptions, but avoid volunteering the missing story.
Record each question they cannot answer. That list becomes the next improvement, whether it involves a clearer approval source, access or ownership.
- Collect a day’s repeated questions and sort them into information, decision and ownership gaps.
- Choose one recurring customer handoff with a clear current commitment.
- Record the evidence, unresolved conditions and next responsible person.
- Define when that person should escalate rather than guess.
- Have another employee complete the handoff without a verbal recap.
- Revise the process from the questions the test exposes.
Common questions
Which questions should stop depending on the founder?
Start with ordinary questions about accepted commitments, current work and responsibility. Make that information available to the team while keeping a clear route for decisions outside their authority.
How do I delegate without losing control?
Define what a colleague can decide, the conditions that require escalation and where outcomes are recorded. Test one repeatable handoff and improve the missing information before delegating a wider set of decisions.
Sources & further reading
Primary references for the facts and frameworks discussed. Worked examples and recommendations are Daltn’s own analysis.
- Roles and Responsibilities | Atlassian Team Playbook ↗
A primary practice for clarifying responsibilities; no research percentages reproduced.
- Manage your business | U.S. Small Business Administration ↗
General bookkeeping, business continuity and marketing guidance; no jurisdiction-specific legal advice derived.
Published by the team building Daltn. Comparisons are first-party analysis, not independent reviews. Our editorial approach.