Your Budget Is Not Permission to Spend: How to Build a Lean Organization Without Starving It

An approved budget is a prediction, not permission. Because budgeting assumptions are often outdated by the time money is spent, each request should be challenged by asking what problem it solves, whether existing teams can absorb the work, and whether the founder would spend their own money. This discipline creates underspend that becomes a strategic buffer, allowing capital to move toward what genuinely matters.

One of the easiest ways for a large organization to become bloated is to confuse an approved budget with an obligation to spend it. The pattern is familiar: someone arrives with a request for another person, another team, another vendor, or another piece of software and says, “It is already in the budget. The headcount was approved. I just need you to sign it off.” I almost never do, and my response is usually much simpler than people expect. You do not have headcount, and you do not have budget. You have a problem that somebody believed might require money to solve, and now I want you to show me the problem, because that distinction matters enormously.

1. Budget approval is not spend approval

Most corporate budgeting processes happen months before the money is actually spent, and they are based on assumptions about future demand, projects, organizational structures, technology, and priorities. By the time the spending decision actually arrives, many of those assumptions may already be wrong, yet organizations frequently behave as though the budget itself has become an entitlement. “We were approved for ten people” is not the question. The real questions are whether you still need ten people, what problem they are solving, what measurable value will be created, why the existing team cannot absorb the work, whether the process can be simplified or automated, and whether the work should exist at all.

Those questions create an important counter muscle inside an organization, and without that muscle, organizations tend to expand almost automatically.

2. Headcount is often the default solution to poor design

When teams become busy, the instinct is often to add people, but workload is not the same thing as value. Sometimes a team is overloaded because it is doing work that should never have existed in the first place, sometimes the process is badly designed, sometimes the technology is poor, and sometimes the organization has created layers of reporting, governance, coordination, or manual administration that consume enormous effort without improving the customer outcome. Adding people to that system does not fix it; it simply makes the inefficient system bigger.

Before approving additional headcount, I want to understand how the existing organization actually works, including the workload, the throughput, the automation, where the time goes, and where the real bottleneck sits. Only once that picture is clear can we decide whether the organization genuinely needs more capacity.

The same instinct shows up with platforms and systems, and I say no to it just as often. Someone builds a business case for a new piece of software to optimize a process that only exists inside one small pocket of the organization, and the case usually reads well on paper, with a clean return on investment and a plausible story about efficiency. But I am running a business, not funding every team’s preferred way of feeling optimized, and a business case built to justify a decision someone had already made is easy to spot once you start asking what problem is actually being solved. Very often the honest answer is that the activity the platform is meant to optimize should not exist in its current form at all, or that the volume of work involved is genuinely small enough that a spreadsheet and a capable school leaver would do the job perfectly well for a fraction of the licensing cost, the integration effort, and the years of maintenance that follow. Buying a system does not just spend the budget once. It creates a permanent piece of organizational furniture that someone has to support, secure, and eventually replace, so the bar for introducing one should be a great deal higher than whether a business case can be made to clear it.

3. The startup question

One of the most useful questions inside a large company is surprisingly simple: if this were your own money, would you still spend it? Large organizations create a psychological distance between decisions and consequences, because the money belongs to “the company,” the budget has already been approved, someone else requested it, finance signed it off, and the steering committee agreed, and that distance can produce extraordinary waste.

A startup cannot operate like this. Every additional hire shortens the runway, every subscription matters, every consultant matters, and every unnecessary platform matters, and that constraint forces a clarity that large organizations should deliberately recreate, not because they are poor, but because capital always has an opportunity cost. This is not meant literally, since a large enterprise is right to fund resilience, regulation, security, and long-dated research that an individual would never pay for out of their own pocket; it is a discipline test rather than a capital allocation rule, designed to close the psychological distance between the decision and its consequences. But once that distance is closed, the underlying point still holds. Every rand spent on something mediocre is a rand that cannot be spent on something transformative.

4. This is not about cutting costs

This philosophy is often misunderstood. Running lean does not mean relentlessly reducing spending; it means refusing to spend money without understanding the value, and there is a very important difference between the two. Halfway through a financial year, I often find that I have materially underspent my budget, and that is not because nothing happened. It is because throughout the first six months I have repeatedly challenged expenditure, deciding that we do not need something yet, that it can be delayed twelve months, that it can be automated instead, that the existing team can absorb it, that a piece of work should simply stop, that a product should not be bought, that a contract should be renegotiated, or that a requirement should be removed altogether.

Individually these decisions can look small, but collectively they create something extremely valuable, which is optionality.

5. Underspend creates strategic firepower

Imagine that halfway through the year the competitive environment suddenly changes, because a competitor launches something significant, customer expectations shift, a new technology creates an opportunity, a product suddenly needs to scale, or you realize your mobile application needs a major rewrite. At this point, many organizations begin the familiar ritual of requesting additional funding, and business cases are written, committees are convened, budgets are reopened, everyone competes for money, and months disappear in the process.

But if you have disciplined spending throughout the year, you may already have the money, and the underspend becomes a strategic buffer. I prefer holding some of that flexibility centrally rather than allowing every budget line to automatically consume its allocation, because as the year unfolds and reality becomes clearer, capital can move toward the opportunities that matter most. Instead of spending money because we predicted twelve months ago that something might be useful, we can spend it because we now know something is important, and that is a much better allocation system.

6. Being under budget is not a license to relax

There is a trap hiding inside all of this underspend talk, and I want to be direct about it: a team that comes in under budget has not earned a pass, it has earned a harder question, though not the question it might sound like at first. Finding R5 million you did not need to spend is not proof that another R5 million is hiding somewhere else in the same budget, and I am careful not to treat it that way, because a leader who assumes every saving implies a further one teaches teams exactly the wrong lesson: stop finding savings, or at least stop reporting them. What an underspend should trigger instead is scrutiny of what remains, the same scrutiny every commitment already deserves, applied again rather than waived because a team has already shown good faith once. And a team should not walk away from finding R5 million with a smaller budget next cycle as its reward, because punishing efficiency with less funding recreates the exact spend it or lose it behaviour this whole approach is trying to remove, just arriving through a different door.

This is really a mindset distinction, and it matters more than any specific number. Entitlement says the budget is mine, I was approved, leave me alone, while stewardship says the capital was never really mine in the first place, that I am simply its current custodian, and that my job is to keep finding better uses for it, including uses nobody has thought to ask me about yet. So I keep leaning on teams that are already under budget, not despite the fact that they are ahead, but because of it, since they have already shown they can find savings once, and that is the strongest possible evidence that they can find more. Being lean is not a state a team arrives at and then gets to defend; it is a habit that either keeps compounding or quietly stops.

The way I make that habit stick is by running a periodic meeting where teams bring their own cost targets rather than waiting for a target to be handed down to them, and the effect on people is more interesting than the mechanism itself, because being asked to set your own number rather than defend someone else’s is what actually empowers a team to go looking for efficiency on your behalf, instead of treating the exercise as something being done to them. And when they come back with a target, I push them past the instinct to simply trim the margin on an existing line item, because shaving a percentage off something that should not exist at all is a much smaller win than removing the whole thing, so the real question is never how much cheaper can this get, it is whether this needs to exist in this form at all. Nothing gets to sit outside that conversation just because it has always been there or because a senior person championed it once, since a budget line does not earn permanence by surviving long enough to become familiar, and treating anything as a sacred cow is exactly how organizations end up carrying costs nobody can quite explain anymore. All of it, the targets, the trimming, the whole line items removed rather than shrunk, comes back to the same underlying test, which is that none of this is really about the cost at all, it is about whether the spend is creating value, and the moment it stops doing that, the size of the saving matters less than the fact that we finally noticed.

7. Some teams should exist to create capacity

There is another side to running lean that is just as important, which is that you should not only challenge new spending, but also deliberately assign some of your teams to removing existing spending. Every large technology estate contains systems that were once justified but no longer create enough value to warrant their cost, including vendor products with expensive licenses, legacy platforms carrying substantial infrastructure and support costs, duplicate capabilities created through acquisitions or organizational silos, and systems that survive largely because nobody has been given the explicit job of killing them.

I think that is a mistake, and some teams should have a mandate to exit systems, with that work itself coming from approved budgets. If I approve a technology budget, I do not expect every team to spend the year adding things; I expect some of that capacity to be used to simplify the estate, retire products, remove vendors, and permanently reduce the organization’s cost base. We frequently target high cost, low value vendor products where the product was useful five years ago but is now largely redundant, where functionality can be absorbed into an existing platform, where an expensive proprietary capability can be replaced with something simpler, or where a vendor relationship made sense when the organization was smaller but now represents an enormous recurring expense.

Whatever the reason, the important point is that the savings should not simply disappear into a generic cost cutting target; they should become reinvestment capacity. If a team removes R20 million of recurring vendor spend, I now have R20 million of strategic capacity that can be redirected into customer experience, engineering, security, AI, resilience, modernization, or another area where the return is substantially higher, and in capital-allocation terms that team has produced something every bit as valuable as a team that generated R20 million of incremental revenue elsewhere. That is the part people underrate: deletion is production. A line item removed from the estate is not a cost avoided, it is a fund created, and treating it that way changes the status of the work entirely, because system retirement stops being boring technical housekeeping and becomes capital creation instead.

8. Bottom-up budgets quietly cost more than top-down ones

Bottom-up budgeting has an obvious appeal, because it treats the people closest to the work as the best source of accurate estimates, and at the level of any single line item it usually is more accurate. The trouble is a habit it creates that compounds badly once you look at the whole organization rather than one team at a time, because when every team builds its own budget from the ground up, every team quite reasonably works a small buffer into its own numbers to protect against uncertainty. One team pads a project estimate a little in case scope grows. Another asks for a bit more contractor budget than it expects to use in case something slips. A third rounds a vendor renewal upward in case the negotiation goes badly, and none of it is dishonest, since each team is simply protecting itself against its own risk. But repeat that instinct across every team, every line item, every year, and the padding compounds into a very large number that has stopped bearing any real relationship to what the organization actually needs, and what you end up funding is a mosaic of small, unreconciled hedges rather than a small number of real ones held where somebody can actually see them.

So I tell teams directly not to over budget. If a team pads its numbers to create comfort at the line item level, I do not treat that as prudence, I treat it as capital being taken out of circulation, and every rand sitting in an unnecessary local buffer is a rand that is not available for something else the organization needs in order to grow. Over budgeting does not feel like it costs anything to the team holding it, because the money mostly just sits there quietly, but at the organization level it is a very real cost, since money reserved defensively across hundreds of line items is money that cannot be redirected quickly toward the one opportunity that actually needs it, and I am direct with teams that this is exactly how it will be viewed: not as caution, but as something standing in the way of the growth the organization is trying to fund elsewhere.

The alternative is to keep every line item lean and hold the real buffer centrally instead, sized once against the organization’s genuine uncertainty rather than duplicated dozens of times inside numbers nobody is comparing to each other. This is not only more efficient, it is more intentional. Money spent from a deliberate, visible, centrally held buffer tends to be spent well, because someone has to make the case for it at the moment the need becomes real. Money sitting quietly inside a padded line item tends to simply get spent anyway by the end of the year, largely because it exists and because an unspent line invites questions nobody wants to answer, and spent that way it rarely returns anything like the value the same rand would have produced if it had been held centrally and released with real intent.

9. Budgets should be reservoirs, not pipelines

Traditional corporate budgeting often behaves like plumbing, where money is allocated into a pipe and the expectation is that it flows through that pipe, with technology getting its allocation, marketing getting its allocation, operations getting its allocation, and headcount getting its allocation. Then each function tries to ensure that it consumes the money before the year ends, partly because underspending can perversely result in a smaller allocation the following year, and this creates the famous year end spending rush, where the organization accidentally rewards expenditure instead of outcomes.

A better mental model is a reservoir, where capital sits available until there is sufficient evidence that releasing it will create value. Some gets used, some gets redirected, some is created by retiring existing costs, some remains unused, and sometimes large amounts move rapidly toward an unexpected opportunity, which is far closer to how capital should actually work. This is not just a personal preference either. McKinsey’s own work on capital allocation suggests holding somewhere between five and twenty percent of the budget back as a strategic reserve, with the higher end suited to faster moving industries, precisely so that an investment committee can redirect it quickly when the year throws up something the annual plan never saw coming.

None of this should be mistaken for constantly reopening commitments or making teams afraid that sensible investment will be withdrawn partway through. Teams need confidence in their strategic priorities, and a reservoir model only works if that confidence is real. What they should not have is an entitlement to the particular resources originally estimated to achieve them, because the outcome the organization is committed to and the specific budget line assumed to deliver it are two different things, and only one of them deserves to be treated as fixed.

10. Complexity compounds, and it does so quietly

Every new employee, vendor, platform, process, committee, or system adds organizational weight, because people require management, systems require maintenance, vendors require contracts, processes require governance, and teams create dependencies, so what looks like a small decision today often becomes permanent organizational architecture. That means complexity should have to justify itself, and before adding something we should ask whether the organization can solve the problem by removing something instead, whether we can stop doing it, and whether exiting it today would create the capacity to build something better tomorrow.

This is also why large organizations become too large without anyone deciding to make them that way. I have worked in organizations where the number of people seemed completely disconnected from the amount of value being produced, where a company that appeared capable of operating with ten thousand people might employ fifty thousand, and it never happens because somebody deliberately sets out to build a bloated company. It happens one approved role at a time, one project team at a time, one vendor contract at a time, and one system that nobody is ever given the job of retiring, and because nobody challenges any single decision in isolation, the accumulation goes largely unquestioned until the weight of it becomes the story.

11. Efficiency as a habit, and the freedom it buys

Lean organizations are not created by annual cost cutting programs; they are created by thousands of ordinary decisions, and the habit is simply asking what problem we are solving, what outcome changes, whether the current organization can absorb the work, whether we can simplify or automate it, what we can stop doing, and whether I would spend this money if it were mine. Those questions should not feel hostile; they should feel normal, because the purpose is not to prevent investment, but to make sure the organization can invest aggressively when it matters.

The payoff for building that habit is not really lower cost, it is strategic freedom. Organizations carrying less structural weight can move people, move capital, respond to competitors, fund new technology, retire old technology, and abandon bad ideas without defending sunk costs, and they do it by continuously manufacturing investment capacity rather than waiting for it to be granted, through challenging unnecessary headcount, refusing low value expenditure, automating work, retiring systems, and exiting vendors whose value no longer justifies their cost.

That is why I challenge budget and headcount even after they have been approved. I am not trying to save the money; I am trying to protect capital from mediocre uses, recover it from yesterday’s decisions, and make sure it is available for tomorrow’s opportunities, because the goal of a budget should never be to spend it. The goal is to continuously move capital toward its highest value use.