Growth
Five signs your systems are about to become the bottleneck
Growth rarely breaks technology all at once. It shows up first as small frictions a capable team has quietly learned to work around.
Systems seldom fail on the day they become inadequate. They degrade quietly, and a capable team absorbs the degradation — with a spreadsheet here, a workaround there, a person who knows the trick. By the time anyone calls it a technology problem, it has usually been a staffing problem for a year.
The signs below are early. None of them look like an outage. All of them mean the same thing: the business has outgrown the way its systems were assumed to be used.
1. The real work finishes in a spreadsheet
Someone exports from the system, does the actual thinking in a spreadsheet, and types the result back in. The export is not the problem. The problem is that the judgement now lives in a file on somebody's desktop, where it cannot be audited, inherited or improved — and where it leaves when they do.
2. Onboarding a new starter takes a week of shadowing
If a competent hire cannot become useful without sitting next to someone, the process is not written down anywhere the system can enforce it. That cost is invisible while you are hiring one person a quarter, and painful the moment you are hiring three a month.
3. Your reporting is a person
There is someone who assembles the monthly numbers. They are good at it, everyone trusts the output, and nobody else can produce it. That is not a reporting capability — it is a single point of failure with a calendar reminder attached.
4. Nobody can say what the system of record is
Ask three people where the authoritative customer list lives and get three answers. Duplicate data is survivable; ambiguity about which copy is true is not, because every downstream decision inherits the ambiguity, and reconciliation quietly becomes a job.
5. Changes are avoided rather than scheduled
The clearest sign of all. When a small change is treated as risky — when people would rather live with a known irritation than touch the system — the organisation has stopped believing it can change its own tools safely. Every subsequent problem then gets solved with headcount, because headcount feels reversible and the system does not.
“By the time it looks like a technology problem, it has usually been a staffing problem for a year.”
What to do about it
The instinct is to replace something. Resist it for a fortnight. A replacement decided in the first flush of frustration tends to reproduce the same assumptions in newer software, and the same workarounds reappear within a year.
Do the cheaper thing first: find the workarounds and write them down. Every spreadsheet, every manual step, every piece of knowledge that lives in one head. That list is the actual requirements document, and it was assembled by the people doing the work rather than by anyone guessing on their behalf.
Be wary of any recommendation that arrives before that list exists. A supplier who can scope a replacement without knowing what your team currently works around is scoping the system they already build.
Then fix in order of how often the friction occurs, not how annoying it feels. Daily beats dramatic. Most of what looks like a platform problem turns out to be three or four specific frictions, and clearing them buys the years of runway a rebuild would have consumed.
Have a Question About This?
If this raised something you are unsure about in your own setup, bring us the actual situation.