When Every Decision Still Needs the Founder

A founder can remain involved in nearly every commercial decision when a business is small. That involvement provides context, protects quality and allows unusual requests to be handled quickly.

As demand grows, the same arrangement can become a queue. More work reaches the person whose judgement made the earlier process effective, but their available attention has not grown with it.

The first response is often to add coordination: another meeting, a status report or a colleague who chases decisions. Those measures may help temporarily. They do not necessarily change the point at which work must wait.

The operating question is whether each decision still needs the same person, the same information and the same level of review. Some decisions should remain central. Others can be delegated within explicit boundaries or built into a clearer process.

This is a more precise starting point than asking whether the business needs a new management platform. Software can expose a queue and route work through it. It cannot decide how much authority the founder is willing to delegate or which risks the organisation is prepared to accept.

Examine the decisions attached to growing demand. The business may need more capacity, but it may also need a different distribution of responsibility. Those possibilities should be separated before the next hire or system purchase.

Select work that the business expects to do more of: a customer project, an order, a service appointment or a recurring operational request. Trace it through the people and systems required to finish it.

Record where someone performs work and where the request waits. A long elapsed time can arise from a difficult task, a missing input or a delay in permission. Improving the wrong part of the sequence may have little effect on completion.

Microsoft's overview of business process management recommends examining the activities and bottlenecks before changing the process. For a growing SME, the important detail is often the dependency between decisions.

Ask why each handoff exists. Does it provide expertise, protect a material control or establish a commercial commitment? Does it merely move information to someone who will forward it again? Are staff waiting because the next person lacks context or because they lack authority?

Include rework. A request that returns to an earlier team may consume capacity without appearing as new demand. Repeated clarification can make staffing needs look larger than the underlying task requires.

Use this evidence to distinguish three responses: increase capacity where necessary work exceeds available time, improve information where staff cannot decide, or change authority where routine work waits for avoidable approval.

These responses may be combined. The useful distinction is that they solve different constraints and require different evidence.

“Use your judgement” can be a difficult instruction for someone who does not know which consequences the business is willing to accept. Effective delegation needs a defined area in which a person can act.

Describe the decision, the information required and the conditions that require escalation. A service team might be permitted to rearrange appointments within agreed capacity, while changes that affect another customer's commitment need a wider decision. A project lead might approve a limited adjustment that preserves the agreed outcome but escalate a material scope change.

These are illustrative arrangements. The boundary should reflect the business's actual obligations and the consequences of an error.

The UK Government's guidance on service-team roles connects ownership with decision authority. Smaller organisations can combine roles, but assigning responsibility without authority leaves the original queue intact.

Make the escalation route usable. Staff need to know whom to approach, what evidence to provide and what happens while a decision is pending. An exception should not require them to stop every other part of the work if some activity can continue safely.

Retain visibility without insisting on prior approval for everything. Depending on the decision, a review of completed actions may be more proportionate than a mandatory sign-off before each one. Other actions will still require advance approval.

The design should make that choice deliberate. Reducing a queue is useful only if the business can support the responsibility it transfers.

Specialisation brings depth, but it can also divide a simple customer outcome into many internal transfers. A request may cross several teams before anyone has enough authority and information to complete it.

Look for work that could be handled by a stable group with the necessary skills. That does not require every team to become self-sufficient or every specialist to be duplicated. It requires clarity about which dependencies are essential and how they are managed.

DORA's guidance on loosely coupled teams emphasises autonomy supported by clear interfaces and manageable coordination. The practical implication is to examine the dependencies that prevent a team from completing its responsibilities.

For a small business, this may involve a shared planning session between existing colleagues rather than a formal reorganisation. A specialist could contribute at a predictable point in the work instead of receiving urgent requests whenever another team becomes blocked.

Specify the output expected at each remaining boundary. A handoff should transfer usable work, relevant context and a clear next action. If the receiving team must repeatedly reconstruct the request, the boundary is not functioning well.

Some central services should remain shared. Security review, financial control or scarce specialist expertise may be better organised that way. The aim is to make their involvement proportionate and predictable.

A team chart is less important than whether a real request can move through the business without unnecessary waiting or contradictory decisions.

Once responsibilities are clear, software can help maintain them. It can route work, preserve context, show capacity and make pending decisions visible. Automation can handle routine conditions that the team has agreed.

Avoid encoding an unresolved argument into a workflow. If sales and delivery disagree about what makes a request ready, a required field will not settle the disagreement. If nobody owns an exception, an automated notification will not create that ownership.

A practical implementation brief should describe the accepted work, the authority boundaries, the exception routes and the evidence needed to show progress. That gives software development and automation a specific operating purpose.

Pilot the revised process where its effects can be observed. Follow waiting time, work returned for clarification, unresolved exceptions and the quality of the completed outcome. Include the effort required to operate the new process itself.

Check the effect on the next stage as well. Clearing an approval queue may release work faster than delivery can absorb it. The improvement then needs a capacity decision or an explicit limit on work in progress. Otherwise, the business has moved the waiting rather than reduced it. Customers should receive commitments based on the whole path to completion, including the constraints that remain.

Keep the change reversible where possible. A delegated decision may need a narrower boundary; a newly combined team may still depend on expertise it does not have. Treat those findings as information about the design.

Growth should leave the business able to complete more of the right work with a process people understand. The most useful improvement may be the decision that no longer needs to travel through three other people before someone can act.