So you need to start worrying about scaling your organisation. Congratulations!

You've got plenty of other things to worry about, of course, so this is the last thing you need. But take a moment to enjoy the fact that you've got this far - it means that you've been successful enough to grow, and that's positive by any measure.

Organisations and teams need to scale because of customer growth. And that growth - from a tech perspective at least - is going to have two dimensions:

• Bigger systems - you need to handle more traffic, or more data, or more records, or more - you get the idea. Whatever you have today, it isn't enough, and you need more.
• More people - your teams are stretched and struggling to keep up, or need new or different skills sets. Maybe you need to cover extended operational hours, or a new product line requires different tech. Either way, it means more headcount.

Those problems rarely come separately, of course - and to some extent they're even circular.

First, some good news

Scaling your systems is usually the easier problem. Scaling solutions are often built-in - it's a strange vendor that doesn't make extravagant claims about how their tech will handle 10x of today's load without blinking.

Scaling infrastructure also has lots of established patterns that you can exploit. The solution is often some variation on "spin up another container". Cloud vendors make it almost trivially easy to bring new infrastructure online. And the inherent traffic capacities of tech such as queues offer performance in the millions-of-events-per-hour class out of the box.

In fact, you could almost argue that when it comes to the difficulties of scaling up infrastructure, the problem is actually the opposite. Lots of us have got stories about unexpectedly-large bills from cloud providers because we accidentally spun-up a T2-large instead of a T2-medium...

Scaling people, on the other hand - this is the hard problem.

Firstly, people don't behave linearly. A team of 4 behaves very differently than a team of 2, and a team of 40 - well, that's not really a team, as we'll see later.

Behaviour patterns, social relationships, coordination of the tasks to be done - none of these emerge in easily-predictable patterns. We're social animals, but we don't behave in ways that are obvious.

The temptation is to approach people problems as you would technology. That would be fine if people exhibited consistent behaviour in similar situations. But they don't.

People problems are often the perfect example of "slowly, then all at once". Everything was working well last week, but by Wednesday something has changed, and what were once a finely-honed processes run by a high-performant team is now a smoking shambles.

A smoking shambles that you're responsible for.

So why is it so hard to scale people, at least compared to tech?

One of the principle reasons is the concept of coordination costs.

Doing some mental math makes this clear - coordination costs increase as the team enlarges. Before the organisation grew, you usually knew who was responsible for what, assuming that it wasn't actually you in the first place. When you needed to talk to them, you could get up and walk over to have the conversation.

These days, the first problem is figuring out who looks after the problem area. Chances are in this Covid world, they're not physically adjacent - maybe even in different cities or timezones. You may never have spoken to them before, so now you have the problem of getting them to buy into your needs.

What before was a simple conversation has expanded into a detective task followed by diplomacy. And as teams enlarge, those coordination costs can increase exponentially.

Organisation and process lags behind the growth of the business in most organisations. At first, problems are subtle, and may not even show as being size-related. You only recognise problems when things go wrong, and before you know it, you're always playing catch-up. At best this is sub-optimal, but if it's severe enough it can be fatal to the success of teams, products or even entire businesses.

So, how can you avoid these problems? How can you scale in a way that is ahead of the game for once?

Scaling before you have to scale

The ideal situation, at least from the point of view of problem mitigation, is to scale before you need to scale. Get ahead of the problem and anticipate the issues before they arrive.

This doesn't necessarily mean hiring people and building teams before you need them, though. By anticipating where the likely problems are going to come from, you can be ready to react ahead of the curve rather than behind it.

Three areas where it's possible to be ready before the scaling problems land.

Set your structure limits. In organisational theory, there's a concept known as span of control - it's the maximum number of people that you can sensibly have reporting to you before you can't give people the attention that they need from a management point of view.

What this number actually is varies from team to team and context to context. But the good news is that you can figure it out, at least roughly, by looking at what you currently do today.

Say you aim for a 1-hour 1:1 meeting with each of your direct reports every week. On average, it takes you an hour beforehand to prepare, and an hour afterwards to follow-up.

That means 3 hours per direct report - and those three hours need to come from your weekly budget of 40 hours or so, assuming you're trying to keep to a reasonable work-life balance. If you've got a team of 5 direct reports, you're looking at between 5 and 15 hours a week just on management tasks - or something fast-approaching two whole days.

By the time you've reached double figures of team size, something has to give. Either you're compromising on giving direct reports the attention they deserve; or other things need to handed off.

While thinking about team structures, know what you wants the limits to be. If you think 5 to 7 direct reports is the maximum, then if the team currently is 3-strong and it's an area that seems likely to grow, that’s a heads-up to start thinking about splitting off a new team.

Know how you'll split your domains. Splitting larger teams into multiple smaller ones isn't a free lunch, though. Just as coordination costs between people increase, so does the coordination costs between domains.

If you're lucky enough to have completely autonomous teams, that's less of an issue - but this is a highly unusual situation, as most teams don't operate in vacuums. Application frontends depend on backends, which in turn run on platforms. For all of these areas to run in sync, coordination is a necessity.

There are many theories about the optimum way of structuring an organisation - Conway's law is possibly the most well-known, but important as structure is, it's nothing if it's not clearly understood.

The enemy of successful scaling is ambiguity - so whatever structure you have or are going to make, make sure the responsibilities are clear. Write them down and publicise them. Make the information available and easy to find, and make it clear that this is the way things are organized.

Make your coordination processes explicit. Just you need to think deliberately about team sizes, so you need to think about coordination processes.

There are many schools of thought about how this should be done, but a simple trick is to think of coordination in two dimensions - formality and frequency

Formality can range from regular steering groups with defined memberships, formal minutes and official communiques. At the other extreme is ad-hoc coordination by pinging someone else on Slack. Which works best is a function of your business area and domain and culture - international air traffic control needs something very formal than a laidback startup.

By thinking explicitly about this - and being explicit about how and who the coordination processes involve - you're reducing the scope for confusion where things fall down the cracks between teams, or key people are out of loops they needed to be included in.

Frequency of coordination is also context-dependent; and here you can get a clue from the velocity of your product. If it’s relatively slow-moving, then a correspondingly-relaxed frequency of meetings or check-ins can work. In more dynamic situations, on the other hand, you may find that you need to coordinate on even a daily basis.

There's a tradeoff with coordination frequency, though. If your daily standups are a meandering discussions about not much, be prepared to be ruthless with them. If the signal-to-noise ratio of a daily isn't what it needs to be, make it weekly. If there's never any actions after a recurring meeting, cancel it.

Scaling people

Scaling people means hiring, and in this almost-post-Covid world that's never been harder. Fixing your hiring pipelines and processes is beyond the scope this post - it's a book at least - but here's some factors to consider in the specific context of scaling.

Be clear about what you want. There's a temptation when hiring to use your current teams as the template for the new people that you need. But being in scaling situation implies that your business is changing - the skills you needed may no longer be what you need. Be prepared to think beyond simply hiring more of the same - this is an opportunity to anticipate the challenges coming down the line.

It’s also a mistake to relax your hiring standards if you're really struggling to find people. You have to consider the long-term impact of diluting your technical standards, and the effect on morale if you're bringing in people who don't share your values.

Fix your recruiting processes. Building teams and maintaining standards means you're going to be doing a lot of recruitment activity. You need processes that will allow you to do this at scale. If you don't have slick recruitment processes you're making life way more difficult for yourselves

Assuming that you don't have a kickass talent acquisition team to do the hard work for you, what does this mean in practice?

Firstly, don't rule out the use of external recruiters. Yes, they will cost you more - but 30% of the first year salary of a successful hire might actually cost less than your time, if you can outsource the volume repetitive work of talent sourcing. You'll need to find a good recruiter who don't grow on trees - but building a long-term relationship with a reliable partner can pay dividends over years.

Secondly, ensure that you have clear and repeatable processes for managing the pipeline. Keep meticulous records so you know where in the process a candidate is; who they've talked to, and who needs to speak to them. Use templates and canned snippets to automate the process of candidate communication as much as possible. You don't need a flashy ATS - spreadsheets might be good enough if you're diligent.

Building these kinds of process has at least three benefits. Firstly, you're reducing the amount of mental bandwidth you need to devote to the tasks. Secondly, you're ensuring that no matter how many candidates you're dealing with, all of them will get a consistent experience in dealing with you - you never know how a shitty interaction can come back to bite you in the future. Finally, you're minimising the chances of the right person slipping past you because you couldn't respond fast enough. It's a seller's market at the moment, and it's easy to miss the perfect candidate.

Scaling process

The third challenge when scaling is that in most organisations, processes lag the state of the business. They’re always playing catch-up.

Process is sometimes seen as a dirty word, but it doesn’t have to turn you into Deutsche Bank. It’s possible to go overboard with process for process's sake - but the absence of process is anarchy. I'm not aware of any successful businesses run on with an anarchistic organisational style, and while flying by the seat of your pants can be exhilarating, it's also exhausting.

All this means that you need to start considering how your processes operate well before the cracks begin to show.

Some factors to consider when looking at process change:

Align it with your desired culture. Don't go all-in on ITIL-style bureacracy if you aspire to remain Agile. Some aspects of your culture must be right if you've got to the stage of needing to worry about scaling, so you don't need to change everything.

But at the same time, be prepared to admit that the culture that got you here might not get you there. Consider the hidden aspects - when you all fitted around a single table, communication was easy and probably mostly verbal. Expanding teams will need that to change - but if verbal comms has always worked in the past, it might not be immediately obvious that there are now people out of the loop.

Culture can't be completely controlled - but you can steer in the right direction if you're clear on what "right" is.

Aim for 80/20. Unless you're dealing with a situation where pinpoint accuracy is essential, knowing roughly what to do is often enough when it comes to process.

Most business processes are sufficiently variable that there's a law of diminishing returns in covering all eventualities

Don't be afraid to leave gaps and rely on the judgement of your people - you've hired them because you trust them, after all.

Statements like "treat your expenses as if it was your own money" can be more effective in the long run than attempting to micromanage every upcoming possible combination of circumstances.

Be prepared not to shoot for perfection. Maybe you could solve a problem by implementing new systems, but sometimes quick hacks are actually good enough.

As a wise boss once said to me, "never underestimate how much you can save on an ERP system with a room full of students punching numbers into a simple spreadsheet". You probably don't want to be running your entire business on Excel by the time of your IPO, but it can take you a long way.

Document the shit out of it. The enemy of process is ignorance - if your people don't know what they should do, they'll fill the vacuum with best-endeavours if you're lucky, and chaos if you're not. This is especially true taking into account the changes in communication patterns that happen as teams grow. Decide what to do, then write it down.

In the past I’ve used a quick heuristic for figuring out the chaos levels in a business by asking what the process is for making a trivial change (say fixing a type) to the company's website. If processes are well-designed and well-documented, the answer will be a link to a process. In a really sophisticated place, you might be able to ask questions like this of a Slack bot, or at least run a search on the company wiki. If the answer is more like a treasure hunt - "oh, I think you need to talk to X. Or maybe Y", then that's a sign that there's process rot going on.

Make it visible and available, and make it updatable. Process documentation is only ever a snapshot in time, and the older and out-of-sync with reality that process becomes, the harder it becomes to stick to. Anyone should be able to suggest changes or flag up errors, even if the publishing process has some checks and balances built-in.

This a good problem to have!

Scaling a business doesn't need to be chaos, and it doesn't need to be an energy-sapping uphill struggle either. Keep it as detailed as necessary and as simple as possible - and above all, think ahead. And while you're doing it, remember - you only need to scale when you're successful, so this is definitely a good problem to have!