The short version
- Every company is layered. The systems, naming and processes record the order decisions were made in, and that order explains most of the current mess.
- Failures follow the same channels repeatedly. Find the gullies and you can predict where the next problem arrives.
- The oldest layer is usually load-bearing and nobody remembers putting it there.
- Do this reading before proposing anything. A plan that ignores the strata gets rejected for reasons nobody can articulate.
Look at a mountain face like this one for long enough and it stops being scenery. The horizontal bands are layers that were laid down in order, so the sequence is readable. The pale streaks running down the gullies are the paths that things take when they fall, which means the face is also a record of how it fails. Companies are exactly the same, and reading a company this way is the fastest diagnostic I know when we take on a new account.
What does reading the layers look like in practice?
You look at the artefacts in the order they were created rather than as a flat set. A CMS with three generations of content model in it. A site with URL patterns from two rebuilds ago still live. A CRM with fields that only make sense if you know the sales process from four years back. Each layer was rational when it was laid down, and the confusion is almost always the boundary between two layers rather than either layer itself.
On one rebuild we migrated 42 routes and 387 content entries with 545 assets behind them. The routes were the visible part and the entries were where the history lived: several eras of taxonomy, stacked, each with its own assumptions about what a page was. You cannot plan that migration by counting pages. You have to read the layers.
Reading a company the way you read a rock face.
| What you are looking at | What it tells you | Where to find it |
|---|---|---|
| Layers, in order | The sequence decisions were made in | CMS models, URL patterns, CRM fields |
| Boundaries between layers | Where most confusion lives | Anything with two naming conventions |
| The oldest layer | What is load-bearing and undocumented | Conventions nobody can justify |
| Gullies | Where failures repeat | Incidents that have happened twice |
| Recent deposits | Current priorities | Whatever was built this quarter |
Why does the oldest layer matter most?
Because it is load-bearing and undocumented. The earliest decisions get built on top of, so by the time anyone questions them a great deal depends on them, and the person who made them has usually left. The result is a company full of conventions that everyone follows and nobody can justify.
This is where the real risk in any modernisation sits. Something that looks like an obvious cleanup turns out to be holding up three things nobody mapped. The correct response is not caution in general, it is specific archaeology on the pieces you intend to touch.
How do you find the gullies?
Ask what has gone wrong twice. Not what went wrong last, what has gone wrong repeatedly, because repetition means a channel exists. Failures in an organisation are not randomly distributed, they run down the same paths, and those paths are usually handoffs between two teams or two systems.
The common ones are consistent. A lead sync that breaks every time a form is swapped, because the integration is built on identifiers rather than an agreed process. A launch held by two separate gatekeepers, one on security and one on pricing, neither of whom appears in the plan. A blog that goes down and stays down because nobody’s name is on restoring it. Each of those is a gully, and each will carry the next failure too.
The useful part is that gullies are predictive. Once you have found one, you can say with reasonable confidence where the next incident will come from, which is a more valuable thing to hand a client than a list of what is currently broken.
What does this change about how you start an engagement?
It moves the first weeks from proposing to reading. Before anything is recommended, work out the order things were built in, which layer each current problem sits on, and where the repeated failures run. A plan that ignores the strata gets rejected for reasons the client cannot articulate, because it violates constraints they know exist and cannot name.
It also changes what you promise. Migration cost sits in the records rather than in the pages, so a quote based on route count is a guess. Counting entries before quoting routes is the difference between a scoped project and an argument in month three.
Failures in an organisation are not randomly distributed. They run down the same channels, and those channels are almost always handoffs.
How do you stop your own company from becoming unreadable?
Write down why, not just what. Almost every system captures the decision and almost none capture the reason, which is what makes the oldest layer dangerous. A single line of rationale attached to a convention costs nothing at the time and saves an excavation later.
Then remove layers deliberately rather than accumulating them. Every rebuild is an opportunity to delete a generation of assumptions, and most rebuilds instead preserve them out of caution and add a new one on top. That is how a company ends up with three eras of anything.
Related: auditing before adding traffic, where delivery failures originate and the limits nobody checks.
Frequently asked questions
How do you assess a new client's setup quickly?
Read it in chronological order rather than as a flat inventory. Work out which layer each artefact belongs to, because most confusion sits at the boundary between two layers rather than inside either one.
Why are old systems risky to change?
Because the earliest decisions get built on top of and are rarely documented, so by the time anyone questions them a lot depends on them and the person who made them has left. What looks like a simple cleanup often holds up three things nobody mapped.
How do you predict where the next problem will come from?
Find what has gone wrong twice. Repetition means a channel exists, and those channels are almost always handoffs between two teams or two systems. Naming them is more useful to a client than listing what is currently broken.
How should a migration be scoped?
By records rather than routes. On one rebuild, 42 routes sat on top of 387 content entries and 545 assets carrying several eras of taxonomy. Counting pages produces a quote that fails in month three.
What is the cheapest way to keep a company legible?
Record the reason alongside the decision. Most systems capture what was decided and almost none capture why, which is exactly what makes old layers dangerous to touch later.
Should rebuilds preserve existing conventions?
Only the ones you can justify. Most rebuilds preserve old assumptions out of caution and add a new layer on top, which is how organisations end up with three generations of the same thing running at once.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
