In this essay 18 sections
A business can look busy while almost every useful decision is waiting for the same person. The team is working. Customers are asking questions. Suppliers want answers. The founder is moving between messages, calls and meetings, making decisions that should have been settled somewhere else.
That is not scale. It is a queue with a person at the end of it.
The answer is not to stop caring about the detail. Detail matters. The answer is to decide who owns it, what that person can decide, what standard they are working to and how the result will be checked. If those things are unclear, telling people to take ownership is just another instruction they have to interpret.
The structure has four parts: an agreed result, enough authority to deliver it, reliable information and a review of the finished work. I start with our published management roles. The worked examples later in the article are hypothetical, not accounts of particular employees, customers or projects.
How the work is divided at Williams Corporation
The business is not one person doing everything. Our published management profiles, checked in September 2026, describe different areas of responsibility. Mine include land acquisition, development design, resource consents, sales, marketing and finance. Blair Chappell’s include procurement, pricing, site management and building consents. Kathryn Marshall’s include cash flow, systems, processes, controls and oversight of legal and technical documents.
Those descriptions are a starting point, not a complete account of how every decision is made. They do not establish spending limits, individual approval rights or the result of a particular project. But they show why the idea of the founder personally running every part of a development is incomplete.
A design decision has consequences for procurement. A purchasing decision has consequences for cash flow. A customer needs an answer that is consistent with what the construction team can deliver. Dividing the work does not divide the finished home into separate promises.
That is the part of delegation I think deserves more attention. Naming a responsible person is useful, but the connections between their work and everyone else’s still have to function. Two people can each complete their own assignment and leave a gap between them. The customer should not have to discover that gap.
For a smaller business, the lesson is not to copy our titles or create three management jobs. It is to identify the different decisions already inside the work. Even if one person currently handles several areas, write down where the responsibility changes, what information needs to travel with it and who can settle a conflict. As the team grows, those distinctions give you something concrete to hand over.
Start by finding the queue
Before changing an organisation chart, look at what actually arrives in the founder’s inbox. Not the job descriptions. Not the process manual. The real requests from an ordinary week.
Some will genuinely belong there: a major commitment of capital, a material change in direction, an issue with consequences across several businesses. Others will be ordinary operating decisions that have travelled upwards because nobody is certain who can make them. A third group will be questions already answered, returning because the answer was never recorded where the next person could find it.
A strategic decision needs the owner’s judgement. An unassigned operating decision needs an owner. A repeated question needs a reliable source of information. If you treat all three as evidence that the team needs more supervision, you will make yourself busier without making the company more capable.
For a week, record the decisions that reach you. What was being decided? Who raised it? What information was missing? Why could it not be decided closer to the work? Do not turn this into a surveillance exercise. The purpose is to understand the design of the business, including the habits of the person at the top.
You may discover that you created the queue yourself. Perhaps you ask to approve every minor change. Perhaps you reverse sensible decisions because they differ from your preference. Perhaps people get criticised for acting but not for waiting. In that environment, waiting is a rational response. The organisation is doing what its incentives tell it to do.
Delegation begins with an honest answer to a difficult question: am I genuinely needed here, or have I made it difficult for anyone else to act?
Delegate a result, not a vague area of concern
“Look after customer service” is not a complete brief. Neither is “sort out purchasing”, “improve marketing” or “make sure the project runs well”. These phrases name an area. They do not explain the result a person is expected to deliver.
A usable brief makes completion visible. Who needs something? What must they receive? By when? What matters about quality? What resources are available? What would make an apparently successful result unacceptable?
Consider a hypothetical customer enquiry. Answering the message is an activity. Resolving the customer’s question, or clearly explaining the next step and when it will happen, is an outcome. A team measured only on replies can send a large number of messages while leaving customers no closer to an answer.
Write the result in ordinary language. Then ask the person taking responsibility to explain it back in their own words. This is not an examination designed to catch them out. It is a cheap way of finding differences in interpretation before those differences become expensive.
If two people can read the brief and reasonably imagine two different finished results, the work of delegation is not complete. The ambiguity is still yours to resolve.
What a useful decision brief looks like
Here is a hypothetical brief for a purchasing coordinator. It is a worked example, not a description of a Williams Corporation policy. The amounts, specifications and dates would need to be filled in for the actual job before anyone acted.
- The result: the receiving team gets the approved item, in the required quantity and condition, at the agreed location and time. The team can identify the item, check it and use it for the intended work.
- The owner: one named coordinator follows the order through to confirmed receipt. The supplier, carrier and receiving team each know who is coordinating the delivery.
- The authority: the coordinator may place the approved order and arrange delivery within the recorded budget and agreed terms. They do not need a fresh approval for every ordinary step already covered by that decision.
- The limits: a changed specification, an unapproved supplier, different payment terms or a commitment outside the budget goes to the authorised manager. A substitution is not accepted merely because it fits the available money.
- The evidence: the current specification, accepted quote, order confirmation, delivery information and receipt record are kept together. An estimate is labelled as an estimate until the relevant party confirms it.
- The exception route: a change that threatens the receiving team’s work is raised as soon as it becomes known. The coordinator states the impact, the available alternatives and who needs to decide. Serious concerns are raised immediately, even if all the answers are not yet available.
- The finish: the receiving team confirms what arrived and records any discrepancy. Someone is named to resolve outstanding items. A tracking notification on its own does not close the assignment.
Notice what this brief leaves open. It does not dictate the wording of every supplier email or require the owner to approve a routine delivery call. The coordinator has room to do the work. Notice what it does not leave open: the required result, the boundary of the commitment and the evidence of completion.
Before using it, the manager and coordinator should test one awkward case together. Suppose the supplier offers an apparently equivalent replacement that can arrive sooner. Can the coordinator accept it? Which person can judge equivalence? Who needs to know that the original item is unavailable? If the answers are unclear, the brief needs work before the order is placed.
Responsibility without authority is a setup
It is easy to say someone owns an outcome and then keep every decision required to produce it. That gives them the pressure of responsibility without the means to act. When the result disappoints, both sides feel let down.
Authority needs to be specific. What can this person commit? What can they change? Which people or resources can they coordinate? When can they say no? Which decisions require approval before action, and which require a report afterwards?
I would rather make those distinctions explicit than rely on an instruction to use common sense. Common sense is useful after people share the same facts and understand the same boundaries. Before that, it often means the manager expects somebody else to guess correctly.
There is also a difference between authority and access. A manager may be authorised to make a decision but unable to see the current information, contact the right supplier or access the system where the work happens. On paper, the task is delegated. In practice, it still returns to the founder.
Check the whole path. Permission, information, tools, budget and escalation support must fit together. Remove one and the person will either wait, improvise or repeatedly ask for assistance.
Not every decision deserves the same approval process
A decision that can be corrected tomorrow is different from one that commits the company for years. A small inconvenience is different from harm to a person. A preference about wording is different from a material representation made to a customer.
If every decision passes through the same approval process, you will either slow ordinary work unnecessarily or give serious decisions too little attention. Neither is good management.
One practical approach is to group decisions by their consequences. Routine work within an agreed standard can be handled and recorded by the person responsible. A departure from that standard may require a recommendation and a review. A material or irreversible commitment belongs with whoever has been explicitly authorised to make it.
The thresholds will differ between companies. They should be chosen for the actual business, not copied from an impressive-looking template. A spending limit that is sensible for one operation may be reckless or useless in another.
Do not measure significance by money alone. A relatively small purchase can create a major safety or compliance issue. An apparently free promise can create an obligation that is difficult to fulfil. A decision affecting personal information may need careful handling even when no payment is involved.
Make the exceptions easy to recognise. People should know that stopping to escalate a serious concern is part of competent work, not evidence that they failed to be decisive.
One accountable owner does not mean one person does everything
Work often crosses several teams. That does not remove the need for a named owner of the overall result. It makes that ownership more important.
Take a hypothetical property handover. Information may come from construction, administration, customer service and finance. Each team has a part to complete. If everyone owns only their part, nobody may notice that the customer is still missing something essential.
The accountable owner does not need to personally perform every task. Their job is to know whether the required parts fit together, identify what is missing and ensure it is resolved. They coordinate the outcome instead of assuming that several completed checklists automatically add up to a completed customer experience.
This distinction prevents two common mistakes. The first is giving responsibility to a committee and discovering that each member believed someone else was following up. The second is appointing an owner and then expecting them to absorb every task, even where another person has the relevant expertise.
At the boundary between teams, define what is being handed over and what counts as acceptance. Sending a file is not necessarily a handover. The next person needs to know what the file contains, whether it is current, what remains unresolved and what they are now expected to do.
A handover works when the receiving person can proceed without reconstructing the history from fragments of conversation.
Put information where the work happens
If the current answer lives only in the founder’s head, delegation will keep failing. People cannot make good decisions from information they do not have.
That does not mean everyone should receive every message. Copying the entire company into a conversation is often a substitute for deciding who needs what. It increases volume without creating clarity.
The useful question is narrower: what information must the responsible person have at the point of decision? For an ordinary task that may be the agreed specification, the current deadline, the budget remaining and the person to contact if something changes. For a more complex decision it may include assumptions, dependencies and the consequences of the available options.
There should be a recognisable current version. A document titled final, another titled final revised and a third sitting in a private message are not a system. Someone has to own the record, the update process and the place where others find it.
Keep the record proportionate. A small business does not need a large administration department to document a decision. A short entry stating the decision, its owner, its date and its effect may be enough. The test is whether another competent person can understand what is happening without asking the founder to narrate it.
Make assumptions visible too. A forecast based on an unconfirmed date should not quietly become an established fact because it has been repeated in several meetings. If the underlying assumption changes, the people relying on it need to know.
Review the result without taking the job back
Delegation is not disappearance. You still need to review what is happening. The question is whether the review improves the person’s ability to deliver or turns you back into the operator.
A useful review starts with the agreed result. What was due? What is complete? What is different from the plan? What decision is required? What will happen next? The conversation should be about evidence and consequences, not a performance in which the manager tries to appear busy and the founder tries to appear informed.
Sometimes the right response is a question. What alternatives did you consider? Which assumption matters most? What would make you change your recommendation? Who else is affected? A good question can reveal whether the problem has been understood without dictating every step of the answer.
Sometimes the right response is direct instruction. If the situation is urgent or the consequences are serious, clarity comes first. But distinguish intervention from normal operation. Explain why you stepped in, what changes and when ownership returns to the person responsible.
Otherwise an emergency can quietly become a permanent arrangement. The founder takes over once, remains involved in every detail afterwards and eventually complains that the team never acts independently.
Measure what the customer or next team actually receives
Activity measures are easy to collect. Calls made. Messages sent. Orders raised. Meetings attended. These can be useful indicators, but they do not establish that the work produced the intended result.
Connect the measures to that experience. If you track response time, also look at whether the response was useful. If you track completion, check whether the next person could use what was delivered. If you track sales activity, keep the quality and accuracy of the customer conversation in view rather than rewarding volume regardless of what was said.
Do not create twenty measures because the software makes twenty measures available. Choose a small set that tells you whether the operation is healthy and where attention is needed. Someone should be able to explain why each measure exists and what decision it supports.
Watch for measures that can be improved by moving the problem elsewhere. A team can close a ticket while leaving the underlying issue unresolved. It can meet a deadline by handing over incomplete work. It can reduce its own apparent cost by creating rework for another team.
These are not necessarily signs of bad people. Sometimes they are the predictable result of a badly designed target. If you reward a narrow number and ignore the wider consequence, do not be surprised when the number improves faster than the business.
Make the decision needed clear when you escalate
There is a difference between sharing information and escalating a problem. “Just keeping you in the loop” can be useful, but it should not conceal the fact that nobody has decided what happens next.
A clear escalation says what has changed, what the consequence may be, what action has already been taken and what decision is now needed. It identifies the time available. It separates what is known from what is still being checked.
Where possible, it includes a recommendation. Not because junior people must have every answer, but because making a recommendation forces the problem to become specific. The person receiving it can challenge the reasoning or choose another course. Both are more useful than inheriting a pile of unexplained messages.
There must also be permission to escalate without a complete recommendation when the risk demands immediate attention. A safety concern, suspected fraud, a serious privacy issue or a rapidly worsening customer problem should not wait for a tidy presentation.
The manager receiving an escalation has responsibilities too. Respond clearly. Name the decision-maker. Do not leave an urgent question sitting unanswered while assuming the team will somehow infer your preference. If more information is required, state what information and who will obtain it.
After the issue is resolved, examine why it travelled upwards. Was that the correct boundary? Was authority unclear? Was a recurring condition missing from the process? Each escalation is a chance to improve the next decision, not just survive the current one.
Three examples of a better hand-off
The following examples are deliberately ordinary. They are hypothetical operating situations, not descriptions of incidents at Williams Corporation or any other business. The point is to show how a clearer assignment changes the work.
A supplier changes the delivery date
The weak assignment is to chase the supplier. Someone sends emails, obtains a revised date and reports that they have followed up. Meanwhile, the person planning the next task continues using the old date.
The stronger assignment is to establish the reliable delivery position and protect the work that depends on it. The owner confirms the change, checks which activities are affected, identifies realistic alternatives and updates the relevant people. If choosing an alternative exceeds their authority, they escalate the decision with the options and consequences.
Completion is not the supplier’s reply. Completion is an agreed plan that the affected team can use. The responsible person need not control the supplier’s factory to own the quality of that response.
A customer asks for something outside the standard offer
The weak arrangement leaves a staff member choosing between an unauthorised promise and an indefinite wait for the founder. Either can damage the customer relationship.
The stronger arrangement gives the person an accurate description of the standard offer, the boundary of what they can agree and a route for exceptions. They can explain the position without guessing. If an exception is worth considering, the request reaches the authorised person with enough context to decide.
The customer receives a clear answer or a clear next step. They are not told yes merely to keep the conversation pleasant. They are not told that someone will get back to them with no owner or date attached. Good service includes being precise about what the business can and cannot do.
A recurring report arrives late
The weak response is another reminder. If the report is still late, the founder starts preparing it personally. The immediate problem disappears and the underlying dependence becomes stronger.
The stronger response examines the cause. Was the expected output clear? Were the inputs available in time? Did the person have capacity? Was the report used for an actual decision, or had it become administration that nobody read?
If the report matters, give its preparation a workable sequence and owner. If an input is late, make that dependency visible before the final deadline. If the report does not support a useful decision, change it or stop requiring it. Do not demand punctual production of information that has no purpose.
Separate a bad outcome from a bad decision
A decision can be reasonable on the information available and still produce an unwanted outcome. It can also be poorly reasoned and turn out well through luck. If you judge only the result, you will teach the wrong lessons in both cases.
Review the decision as it was made. What information was available? What was uncertain? Which alternatives were considered? Were the agreed limits followed? Was the risk recognised? What would a competent person reasonably have done at that point?
This is not an invitation to explain away every failure. It is a way to identify the actual cause. An unclear brief needs a clearer brief. Missing information needs a better information flow. A capability gap needs instruction, practice or a different assignment. Deliberately ignoring a clear standard needs a different response again.
Equally, do not allow the language of learning to remove consequences. A lesson should change something: a check, a threshold, a skill, an assumption or the person responsible for a particular decision. If the same error returns and nothing changes, the review has become a ritual.
People also watch what happens when they bring bad news. If early disclosure produces anger while silence buys time, information will arrive later. You cannot ask for an accurate view of the business while making accuracy personally expensive.
Capacity is part of the assignment
You cannot keep giving someone new responsibility while pretending their existing workload has disappeared. A capable person can become the company’s second inbox just as easily as the founder became the first.
Before handing over a result, ask what work it displaces. Which current obligations remain? Which deadlines compete? What support is available? Is there enough time to learn the work as well as perform it?
“They are our best person” is not a capacity plan. It can become a way of concentrating every difficult task on the same individual until the organisation depends on their memory, availability and willingness to absorb the pressure.
A resilient arrangement includes cover. Another person should know where the current work stands, which decisions are pending and how to find the important information. That does not require two people doing every task. It requires the company to avoid turning an ordinary absence into an operating crisis.
When responsibility grows, make time for the person to develop the judgement required. Exposure to a harder decision can be valuable. Being left alone with a harder decision and no support is a different thing.
Software should support ownership, not imitate it
A new system can make work visible. It cannot decide what the work should be. Before buying another tool, define the decision or handover that is failing.
If nobody owns the outcome, adding a task board gives you a more colourful view of unowned work. If the brief is vague, a notification sends the ambiguity faster. If the records are unreliable, a dashboard can present the wrong answer with impressive confidence.
Start with a process a person can explain. Then use the tool to make it easier to follow: one owner, an agreed result, a date, a current status, the relevant evidence and a clear exception route. The system should reduce the effort of maintaining that picture.
Automation deserves the same discipline. Decide what happens when an input is missing, a service fails or the result falls outside the ordinary range. Name the person who will notice and respond. An automated process without an exception owner is not independent; it is unattended.
The useful test is practical: does this tool help the responsible person complete better work with less avoidable effort? If the answer is mainly that it gives management another screen to watch, the operating problem may still be untouched.
The founder has to keep the agreement too
Delegation fails when the owner treats the agreed structure as optional. If you bypass a manager and give competing instructions directly to their team, you cannot then expect that manager to maintain a clear programme.
If priorities change, make the change explicit. State what has become more important and what is being delayed or stopped. Do not keep adding urgent work while insisting that every earlier commitment remains equally urgent.
Respect the difference between a requirement and a preference. A customer promise, a safety obligation or an agreed quality standard may be non-negotiable. Your preferred wording in an ordinary internal message probably is not. Capable people will not exercise judgement if every harmless difference is treated as an error.
Do not use delegation to avoid the work that remains yours. Strategy, capital allocation, leadership appointments and material trade-offs cannot be solved by telling everyone else to be more accountable. The team needs decisions from the owner just as the owner needs results from the team.
The discipline is to stay informed without making yourself the route through which everything must pass. That is harder than issuing instructions. It requires you to build a structure, let people use it and judge their work against the agreed outcome rather than their resemblance to you.
A practical first month
Do not try to redesign the whole company in a weekend. Choose one recurring area where decisions keep returning to the founder and where a better arrangement can be tested without taking an uncontrolled risk.
In the first week, map the actual work. Follow a request from arrival to completion. Record where it waits, which information is missing and who currently makes each decision. Include the steps that exist only because the founder expects to be consulted.
At the end of that week, choose the result you want to move. Make it specific enough to test. Identify one accountable person and speak with them about what the role requires. Check capability and capacity before assuming that a new label changes either.
In the second week, agree the brief, authority and limits. Identify the current record, the required inputs, the handovers and the exception route. Walk through an ordinary case and a difficult case together. Differences in interpretation are useful discoveries at this stage.
In the third week, let the arrangement operate. Keep the review rhythm short enough to catch problems, but do not intervene in every ordinary decision. Record exceptions. Notice whether questions have genuinely disappeared or simply moved into a different message channel.
In the fourth week, review evidence. Was the result delivered? Did the customer or next team receive usable work? Did decisions become faster without weakening the standard? Did the person responsible have the authority and information they needed? Which issues still depended on the founder, and why?
Keep what worked and repeat the process in the next suitable area. Progress should mean fewer avoidable dependencies and better completed work, not a larger document explaining how independent the organisation intends to become.
Build a company that can use the ability of its people
I do not see a contradiction between individual responsibility and a disciplined company. A good operating structure gives a capable person room to act and makes their contribution visible. A weak one turns initiative into a negotiation with whoever happens to hold the information.
This is consistent with the emphasis on professional judgement, clear values and development of people in Williams Corporation’s published culture. The practical test is whether those principles survive the ordinary work of a busy week. Can a person make the decision their role requires? Can they raise an issue early? Can they see whether the result was good enough?
I have also spoken publicly about giving younger people operating responsibility. The important point is not a slogan about youth or seniority. It is whether ability is recognised, supported and matched with real responsibility.
The founder remains responsible for the business they are building. That responsibility is not fulfilled by personally answering every question. It is fulfilled by creating the conditions in which good decisions can be made, poor decisions can be detected and useful work can be repeated.
Some decisions will always need you. Make sure they are the right ones.
For more on the relationship between standards and completed work, read The Work Is the Argument. The current ventures directory explains my roles across the businesses.