How to reduce founder dependency before an IT company sale

Define dependency as an operating risk

Founder dependency is broader than a busy diary. It exists whenever a material event stops, slows or becomes unsafe because only one person can act. Typical points include approving prices, calming a major customer, releasing software, accessing banking, negotiating a cloud contract, hiring senior staff and directing an incident.

A buyer or successor will ask whether earnings and service quality can continue through a leadership change. The Swiss SME Portal connects documented processes, distributed know-how and clear responsibilities with successful succession financing. Its guidance also recommends consistent management information and scenario planning. These are practical signals that the organisation can be understood and led by someone else.

Separate three forms of risk: knowledge, what only the founder knows; authority, what only the founder may decide; and trust, relationships that customers, staff or suppliers attach personally to the founder. A procedure fixes only the first. The other two require delegated mandates and repeated contact with a credible second person.

Build a founder dependency map

List events, not job descriptions. Ask what happens if the founder is unavailable for ten working days during renewal season or a security incident. Map each event to frequency, financial or service impact, current owner, backup, evidence and next action.

Score impact and substitutability on a simple one-to-five scale. The score is a prioritisation prompt, not a valuation. Start with high-impact events that have no capable backup.

Transfer authority as well as information

A folder of procedures does not create autonomy if every exception still returns to the founder. Define decision rights: who recommends, who decides, who must be consulted and who is informed. Set explicit boundaries for discounts, hiring, expenditure, service credits and roadmap changes.

Use graduated delegation. First, the successor observes and records the reasoning. Next, they propose a decision. Then they decide within a stated limit while the founder reviews afterwards. Finally, they own the result and report through normal management information. Record exceptions, because those reveal where judgement has not yet transferred.

Access must follow responsibility. Review banking permissions, domain and cloud administration, source repositories, password vaults, signing authority and emergency contacts. Do not duplicate privileged access casually. Apply least privilege, named accounts and logged access. The Swiss Federal Office for Cyber Security describes information security as a combination of organisational and technical measures, which makes ownership and backup responsibility a management issue rather than an IT-only task.

Move customer and team trust deliberately

Relationship transfer is a sequence, not an announcement. For each material customer, name a primary and secondary relationship owner. Let the second owner join regular reviews, present decisions and resolve smaller issues. The founder should visibly support the new mandate without repeatedly taking the conversation back.

Do the same internally. A nominal managing director cannot lead if staff still seek private founder approval. Publish decision forums, escalation thresholds and objectives. Measure how often matters bypass them. Where the founder remains valuable in sales or product, define that future contribution by scope, time and end date.

A useful test is simple: can the customer name the person who will solve the next problem, and has that person already done so?

Avoid sudden withdrawal from sensitive accounts. Sequence introductions around business needs and confidentiality. A contemplated sale does not need to be disclosed merely to demonstrate that account ownership is shared.

Run a controlled ten-event absence test

Choose a two-week period and route ten recurring or plausible events away from the founder: a pricing exception, customer escalation, release approval, failed backup review, supplier renewal, cash forecast, hiring decision, overdue invoice, security alert and roadmap trade-off. Define safety limits before the test.

1. Name an owner and backup for every event.
2. Give them the required information and mandate.
3. Require the founder to stay out unless a preset threshold is crossed.
4. Log delays, escalations, missing access and reversed decisions.
5. Convert each failure into one owner, due date and retest.

The result is evidence, not theatre. A perfect test may mean the scenario was too easy. Buyers will learn more from a transparent exception log with completed improvements than from a claim that the company runs itself.

Avoid the common interpretation errors

• Documentation without adoption: a runbook that nobody uses does not reduce risk.
• Two names, one capability: a backup who always asks the founder is not independent.
• Delegation without information: authority fails when reporting arrives late or definitions change.
• Founder removal as the goal: the right transition may retain the founder for a defined period. The risk is ambiguity.
• Hiding the issue: unexplained dependency discovered in due diligence damages confidence. A measured remediation plan is more credible.

Link this work to your likely succession route. A family successor, management buyout and external buyer may need different timing, but each needs clear operating ownership.

A practical 30-day plan

Days 1 to 7: interview the leadership team and build the event map. Include sales, delivery, product, finance, people, suppliers, access and incidents. Days 8 to 14: select the five highest risks, appoint primary and backup owners, and write decision boundaries. Days 15 to 21: transfer access and relationship roles, then rehearse two high-impact events. Days 22 to 30: run the absence test, close urgent gaps and establish monthly reporting.

Keep a register with event, impact, primary owner, backup, authority limit, evidence link, last test date and next action. If your business provides managed services, extend it with the continuity controls in the MSP succession guide.

Continuum can help you form an independent first view of readiness and, if you ask, facilitate an introduction to a suitable adviser. Legal, tax and transaction-specific conclusions require qualified specialists.

Worked example: replace an invisible approval chain

An illustrative founder of a 20-person software company believes product decisions are delegated because a product lead runs the roadmap meeting. The event map tells a different story. Sales promises a feature to a major customer, the product lead prepares options, engineering estimates them, but everyone waits for the founder's private message before committing. The founder also holds the commercial history explaining why this customer receives exceptions.

The team first records the actual chain, including informal messages. It defines three decision classes. The product lead may reprioritise work within the quarterly capacity envelope. A small cross-functional forum decides customer exceptions using published criteria for revenue relevance, contractual duty, reusable product value, security and delivery cost. Only decisions above an agreed financial or strategic threshold go to the founder during a transition period.

For the next two monthly cycles, the founder attends as an observer and asks questions only after the forum records its decision. The decision log captures the options, evidence, owner and review date. Sales must enter proposed commitments before quoting them. Engineering records the capacity effect, and finance checks any unusual commercial concession. One decision is later reversed because its security impact was incomplete. That reversal is useful evidence: the process identified why it failed and changed the checklist.

After two cycles, the founder takes a planned ten-day absence. The forum resolves two priorities and declines one unsupported promise. No customer waits for private approval. The remaining dependency is not product knowledge but authority over the largest account, so the next test moves to the customer relationship rather than adding more roadmap documentation.

The example shows why counting documents or delegated titles is weak. A better measure is event performance: time to decision, number of founder escalations, exceptions outside the agreed forum, customer outcome and whether the second owner could explain the reasoning afterwards. Track these measures for several cycles and preserve the underlying decisions. They form practical evidence for a successor while improving the company even if no transaction follows.