Key takeaways
- Early on, the founder decides everything. As the company grows, that habit slows it down.
- The aim is to show what waits on the founder, how long teams wait, and who could own it instead.
- Each handover would be a suggestion; the founder decides, and nothing changes without approval.
- In pilot today with design partners.
The problem
In a young company, the founder approves discounts, signs off vendor payments, answers key customers and reviews every hire. That works for ten people. At fifty, the same habits create a queue.
Teams wait for the founder's reply, the founder works late to clear it, and work stops whenever the founder travels. The founder rarely sees the full list, because it is spread across many threads: a refund question in support chat, a payment approval in email, a price change raised in a meeting, a contract waiting for a signature in a shared folder.
Picture the week a founder spends on fundraising. She is in investor meetings from morning to evening and checks messages in short gaps. The finance lead has two vendor payments ready and cannot release them. The support lead has four refund requests and has told each customer "we will confirm soon". The head of product wants to change a course price before a seasonal campaign. By Friday, a dozen people are waiting on one person, and nobody can see the whole picture, including her.
Most founders know they should delegate more. The hard part is knowing what to hand over first. Without a clear list of what waits on them, how often and for how long, the habit continues because each single request seems quick to answer.
What GeniOS is designed to surface
In pilot, the aim is for a founder to receive a clear view of what depends on them, drawn from email, calendar, chat and the business tools teams already use, read-only to start.
- Routine waits. Decisions and approvals that routinely wait on the founder.
- Founder-only processes. Processes where the founder is the only person who can act.
- Wait times by request type. How long teams wait for the founder's answer, grouped by type of request.
- Suggested owners. A suggested owner for each item the founder could hand over, based on who already does related work.
- Travel and leave risk. Requests likely to pile up when the founder's calendar shows a busy or absent week.
As with all GeniOS intelligence, a person stays in charge: nothing is sent or changed until someone approves it. The founder would answer each note with Delegate, Done, Later or Not relevant. If the founder hands an area over, later requests of that kind would go to the new owner. For the wider picture of where work waits across the company, see Company-Wide Bottleneck Detection; for unclear ownership in general, see Ownership & Accountability.
A worked example
Example at a generic company. Names, dates and numbers are made up to explain the idea.
At a 45-person education company, every refund request, every vendor payment above a set amount and every course price change waits for the founder. When the founder spends a week on fundraising, eleven requests pile up.
Four of them are refunds that support has already checked against the policy. Three are vendor payments where the finance lead has the invoice, the purchase approval and the bank details ready. Two are price changes for a campaign that starts next week. Two are contract questions that genuinely need the founder.
Here is how it would look in pilot: the founder receives one note listing the three request types that waited longest, and suggesting the finance lead own vendor payments from next week. The note shows that the finance lead already prepares every payment, and that the founder has approved each one unchanged for the past three months.
The founder agrees. She delegates vendor payments up to an amount she sets to the finance lead, asks the support lead to own refunds within the written policy, and keeps the price changes and contract questions. The following month, fewer requests wait on her, and the note shows which of the remaining ones still could move. She stays able to see every payment and refund; she just no longer has to approve each one.
How teams use it day to day
This is a monthly habit for the founder, plus a short handover for each new owner.
- Read the dependency view
Once a month, see which kinds of request waited on you and for how long.
- Pick one area to hand over
Start with the area where you approve almost everything unchanged.
- Set the rule with the new owner
Agree limits, such as an amount or a policy, and write them down where the team can see them.
- Approve the handover
Nothing changes until you approve it. The new owner gets later requests of that kind.
- Check the next month
See whether waits dropped, and choose the next area to hand over.
Where it applies
These are application areas where this use case can apply, not a list of current deployments. Our design partner work so far is in manufacturing, with Vaultex.
Founder dependency is common in growing companies of every kind: software and e-commerce, professional services firms where the founder still signs off pricing, education companies where the founder approves courses and refunds, and food and agriculture businesses where the founder still handles buyers and suppliers personally. It touches the executive office, operations, finance and sales.
- Domains: Executive Office, Operations, Finance, Sales
- Industries: SaaS & Technology, Professional Services & Consulting, E-commerce & Retail, Education & EdTech, Food & Agriculture
- Roles: Founders
Status
Pilot We are shaping this use case with design partners now, and it is not yet a finished part of the product. If this is a problem you have, talk to us about shaping it with us. Pilot work starts read-only, on a small set of sources the company chooses.