This post first ran as a two-part series in the summer of 2021. The advice has held up, and the AI-tools era has made it more urgent, so it is back in one piece.
Scaling up versus scaling out
When a server ran out of room, you used to buy a bigger server: more memory, more processors, more disk. That is scaling up, and it has a ceiling, because one machine is still one machine. The cloud made the other option practical: scaling out, adding more ordinary machines and spreading the work across them. Systems designed to scale out can grow as far as the budget allows.
Development teams have the same two options, and most growing companies pick the wrong one without noticing. As the business grows, the software has to do more, and the answer is to ask more of the same developer. That is scaling up. It works until it does not, and when it stops working it stops all at once.
The indispensable developer problem
Every company that runs on custom software has met this person. They built the system, or they inherited it and are the only one who understands it. They are talented, overworked, and impossible to replace. I call the risk the meteor eventuality: what happens to your business if this person is hit by a meteor, or, more realistically, takes another job?
The obvious answer is to hire more developers. It rarely works on its own, for a reason the indispensable developer knows better than anyone. The shortcuts, workarounds, and postponed fixes that accumulated while they kept the business running are technical debt, and technical debt is what makes a codebase hard for anyone new to enter. You cannot spread the work across more people if only one person can read it.
So scaling out a team has two parts. Design the codebase so new people can join it, then bring them on in a way that actually makes them productive.
Designing a codebase people can join
The fundamentals are the same ones every experienced engineer would name: low coupling, high cohesion, automated tests, and the object-oriented design principles that go by the acronym SOLID. Four less obvious habits matter as much.
Use abstraction to cut the required reading. A new developer has to understand the code they are working in. If the system is tangled, understanding one module means reading the whole thing. Good abstractions act as summaries: a developer can understand what a piece does without knowing how every part of it works.
Finish your refactors. Systems change over time, especially in iterative work. Too often a developer makes the change the business needs without cleaning up the code around it, and the next person inherits assumptions that stopped being true a year ago. Half-finished refactors are history lessons nobody wanted.
Design for extension through new code. From the first day, the likely changes should be possible by adding new implementations of well-defined interfaces rather than by editing what exists. Document what an implementation is expected to do, and write the tests against the abstraction so any implementation that passes them is acceptable.
Write code as if the next reader knows nothing. Because they will not, and in three months the next reader may be you. Do not assume anyone knows why you made a choice. Say it.
Bringing new developers on
Once the codebase can take them, the onboarding is what decides whether new people slow the team down or speed it up.
Assign the what, not the how. “Build a new implementation of abstraction A that does B. Modules P and Q will help. Implementations X and Y are similar.” Then point them at the tests their work has to pass and let them work out the how. It is the same discipline a good business analyst uses in writing requirements: express the need, not the mechanism. People who own the how take ownership of the result.
Make sure the system matches the picture before they start. The first trip into an unfamiliar system is disorienting enough. If your description of the architecture does not match what they find, they lose a week and some trust. This is the last chance to finish the refactors that would otherwise become their problem.
Keep the briefing short. Give the thirty-thousand-foot view of the system, the vocabulary they will run into, and a reading list of the code that matters. Then stop. Most developers learn by working things out, and forcing more into their heads before they start does not help.
Check in before they build. After they have read the code, ask them to explain what they plan to do and how. This is where you catch someone who is far off course. If they are only slightly off, let it go and catch it in review. Correcting a plan before the work starts protects their confidence; correcting a small choice afterward teaches more.
Review in detail. Walk through the finished work together. Ask about every place they touched the system. Look for copy-and-paste, and look for the shortcuts that will cost more later than they saved. Have them refactor where needed. The standard you hold on the first review is the standard they will hold for the next person.
Why this matters more now
AI coding tools have made it possible for one person to produce more code than a team could five years ago, which means the indispensable developer can now build an entire company’s system alone. That makes every point above sharper. The codebase grows faster, the technical debt accumulates faster, and the meteor eventuality arrives sooner. If you are wondering whether your own system has this problem, Before an AI-Built System Runs Your Business is the checklist, and a System Evaluation is how you find out for certain.
Engineering a team that scales out is slower at the start and far cheaper over the life of the system. It is also how we build every project we take on, because a system only one person can run is not finished.