Scaling Without Losing Focus

Small companies have a quality that is easy to take for granted. When there are ten or fifteen of you, everybody knows roughly what is going on. You overhear conversations. You know what customers are saying. When something goes wrong, people notice, and when priorities change, everyone can be brought up to speed in an afternoon. There is an enormous amount of shared context, and nobody had to design it.

Then the company grows. Twenty people become fifty, fifty become a hundred. Functions emerge, specialists are hired, teams acquire their own responsibilities and priorities, and layers of management appear. All of this is necessary; the organisation is building capabilities that didn't exist when everyone fitted around one table. But something else is happening at the same time, and it is less visible. The mechanisms that kept the organisation coherent when it was small are quietly breaking down.

Alignment stops being free

Communication gets more expensive as organisations grow, and not simply because there are more people. There are more relationships, more dependencies and more information being generated than anyone can hold in their head. That includes the people running the business.

Growth also brings specialisation. Increasingly, the people closest to a problem know more about it than their managers do. That is the point of hiring specialists, but it changes the leadership problem. A founder who once understood nearly every important issue in the business no longer can. Senior leaders drift further from the detail of the work, while the people doing the work drift further from the context in which strategic decisions are made.

You can see this in the language used at different levels. At the top, conversations are about strategic outcomes: entering a market, improving retention, increasing profitability, reducing risk. One level down, those outcomes have become programmes, projects and initiatives. A level below that, they are deliverables and tasks. Eventually you reach someone who can give an excellent answer to "what are you working on?" and a much weaker one to "why does it matter?"

Leaders lose sight of the work; workers lose sight of the strategy. This is one of the fundamental problems of scale.

Leadership becomes a system-design problem

The obvious response is for leaders to stay involved, and up to a point that works. Beyond that point the leader becomes the bottleneck. If every significant decision has to travel upwards to someone who supposedly holds the complete picture, the organisation hasn't scaled its decision-making capacity at all. It has just increased the volume of information being funnelled towards a shrinking proportion of the people in it. Eventually there is simply too much to know.

The alternative is to accept that work previously done by proximity now has to be done by the management system. That system needs to provide at least three things:

• Direction. People need to understand what matters, where the organisation is going and what it is currently trying to achieve.
• Visibility. People need reliable information about what is happening, rather than assumptions, anecdotes or an increasingly distant impression of reality.
• Responsiveness. The organisation needs to act on that information and change course without every decision working its way through the hierarchy.

None of this is about centralising control. A good management system does the opposite: it makes distributed decision-making possible without losing coherence. As a business scales, leadership becomes less about personally knowing everything and more about building a system through which the organisation can know what it needs to know.

What Andy Grove understood about scale

This was the problem Andy Grove faced at Intel. He couldn't personally direct the decisions of thousands of increasingly specialised employees, and Intel couldn't afford to have all of them pursuing whatever looked most important from where they happened to be standing. The organisation needed autonomy and alignment at the same time.

Grove's approach rested on a handful of principles. There had to be focus: an organisation can't meaningfully have dozens of top priorities, so attention has to be concentrated on the few things that matter most. There had to be clarity about outcomes, so management could say what needed to be achieved without prescribing how. There had to be evidence, so progress didn't rest on somebody's feeling that things seemed to be going well. There had to be transparency, so people could see what other parts of the organisation were trying to do and where their own contribution fitted. And there had to be frequent feedback, because an annual planning cycle is a very slow way to discover that assumptions made months earlier were wrong.

One of the mechanisms that came out of this approach is the one we now call Objectives and Key Results. The acronym is far less interesting than the management problem it was designed to address.

OKRs are an instrument, not the point

Most of an OKR's value sits in the key results: the observable evidence that would tell you the objective has actually been achieved, not just worked on.

Take an early-stage software company trying to establish commercial momentum. It might set an objective around that momentum and use recurring revenue, paying customers or conversion rate as evidence of progress. A team contributing to that objective then sets its own objective and measures, appropriate to its part of the system. The result is a chain from strategy to company objectives to team objectives to work, and it gives people a sharp question to ask of any new initiative: which outcome do we expect this to move?

If there isn't a convincing answer, that doesn't automatically mean the work shouldn't happen. Businesses have operational work, maintenance, regulatory obligations and plenty else that simply needs doing. But it should at least provoke a conversation about priority.

The point is not that every company should adopt OKRs. It is that growing organisations need some mechanism for maintaining focus, alignment, visibility and feedback. OKRs are one way of doing that; they are not the goal.

Measure outcomes, not just activity

There is a related trap. As strategy travels through an organisation, outcomes have a habit of turning into activities. "Increase customer retention" becomes "launch the customer portal". "Improve sales effectiveness" becomes "implement the CRM". "Improve the product" becomes "release version 2.0".

These may all be sensible things to do, but completing them tells you nothing about whether the outcome happened. The portal can launch without changing customer behaviour. The CRM can go live without improving sales. Version 2.0 can ship without making the product more valuable. Activity tells you what you did. Outcome measures tell you whether anything got better as a result.

So the useful question when choosing a measure is: what should be observably different if this works? It might be revenue, retention, conversion, defect rate, customer satisfaction, lead time or repeat purchase. The right measure depends on the outcome. What matters is that it gives you information about the change you were trying to create.

Don't drive using only the rear-view mirror

Not all useful measures tell you the same kind of thing. Revenue, profitability and retention matter, but they are largely records of things that have already happened — useful for knowing whether you succeeded, less useful for changing course before you fail. Getting the balance right between these lagging indicators and the earlier, more actionable leading indicators is its own subject; I've covered it properly in Leading and Lagging Indicators.

The short version: a working management system needs both. Outcome measures keep you honest about whether anything actually improved; earlier signals give you enough warning to do something before the outcome is decided.

Measurement changes behaviour

There is a danger in all of this. As soon as you measure something, and particularly once you attach consequences to it, people start responding to the measure rather than to the thing it was meant to represent. Sometimes that is exactly what you want. Often it isn't.

This is the trap covered in more depth in Goal Setting — Careful What You Measure: attach a number to something and behaviour bends toward the number, not necessarily toward whatever it was meant to represent. None of this requires dishonesty. People are very good at adapting to the systems around them.

Measure a support team purely on calls handled per hour and calls will get shorter without customers getting happier. Reward a software team for features delivered and you will get more features. Set a sales target without considering the quality of the customers it attracts and you may get exactly the revenue you asked for, along with problems you didn't.

Metrics create incentives, so choosing them requires thinking about the behaviour they will encourage as well as the thing they measure. Sometimes measures need pairing: if speed matters, quality probably needs to sit beside it; if acquisition matters, so does retention. And more is not better. A dashboard with fifty metrics often carries less useful information than one with ten. The aim is not to measure everything measurable, but to find the signals that help you understand what is happening and decide what to do about it.

A dashboard isn't a feedback loop

This is where many measurement systems, and a great many OKR implementations, fall down.

An organisation decides to introduce OKRs. Everyone writes some objectives and key results and enters them into a tool. People go back to work. Management meetings carry on exactly as before, discussing projects, deadlines and operational issues. Three months later somebody remembers to update the OKRs. Technically the organisation has implemented them. In practice, nothing has changed.

Dashboards suffer the same fate. Collecting data isn't a feedback loop. Displaying it isn't a feedback loop. Reporting it to management isn't necessarily one either. The loop only closes when the information changes what happens next.

That means strategic outcomes and their measures have to become part of the operating rhythm. When a leadership team reviews performance, the conversation should cover what has changed, what is on track, what is drifting and why, what has been learned, and, crucially, what will be done differently as a result. The purpose is not reporting. It is course correction.

The progression runs: data, reporting, insight, decision, action. Stop before decision and action and you have a reporting process, not a feedback loop.

The value of short feedback loops

A ship doesn't stay on course because somebody calculated the correct route before it left port. Wind changes, currents change, new information arrives. Navigation is a continuous process of observing where you are, comparing it with where you intended to be, and correcting.

Running an organisation isn't fundamentally different. Strategy, plans and targets all contain assumptions, and some of them are wrong. The longer the gap between acting and learning the consequences, the further reality can drift from intent before anyone responds, and the bigger the eventual intervention needs to be. Short feedback loops allow small corrections while they are still cheap.

This is one of the real advantages of an early-stage company. Large organisations have resources, expertise and market power, but their size slows information down and slows decisions further. A smaller organisation can learn much faster. That advantage is worth protecting deliberately, because it will not protect itself.

Don't recreate the ten-person company

None of this is an argument for preserving startup informality indefinitely. As organisations grow they need more structure: clearer responsibilities, channels for information, mechanisms for decisions, process for coordination. The formality of the management system has to evolve with the organisation.

The mistake is to assume the choice is between startup informality and corporate bureaucracy. It isn't. The job is to introduce enough structure to replace what scale has taken away, and no more. Clarity without centralising every decision; visibility without micromanagement; measurement without metric obsession; autonomy without fragmentation.

The goal isn't to recreate the ten-person company. It is to preserve what made it effective, the clarity, ownership, shared context and rapid learning, once proximity can no longer provide them. That is what scaling without losing focus means.