An architect with eight years of experience has only ever worked on systems in their first three years of life - four greenfield builds and two rewrites. Which gap in that record most limits their architectural judgement?

The deciding property

Architectural decisions are made in weeks and paid for over years, and this record contains only the weeks. Build cost is visible immediately; carrying cost is not. A long-lived internal system commonly spends 5 to 10 years in operation after a build measured in months, so the build is often under 20% of what the organisation will spend on it, and an architect who has only built has issued invoices and never received one.

The bill looks like this: the event schema that cannot change because 40 consumers read it; the framework version nobody can move off because the upgrade needs a test suite that was never written; the service costing real money to serve 11 requests a day that nobody will turn off because nobody can prove who calls it; the dataset nobody may delete and nobody may read. Each of those is the second-order consequence of a decision that looked clean on the day it was made, and the only way to learn which decisions produce them is to still be present when they arrive.

Why that is the gap

Judgement is a calibration loop, and a greenfield-only record gives feedback on exactly one variable: did it ship. Someone who has run a system through decline has watched their own abstractions decay, has tried to remove something and found out what was coupled to it, and has learned the single most useful habit the experience teaches — designing the removal path at the same time as the thing.

What to do about it deliberately: prefer the next role where you will still be there when your decision's third year arrives; failing that, take ownership of one system you did not build and carry it through a deprecation end to end, including telling its users. One decommission teaches more about coupling than three builds: at a 300-engineer enterprise software vendor with a dozen products older than its current architects, the people who can say which abstractions will not survive contact with year five are the ones who have switched something off in production.

Why the other options fail

• A second cloud provider. Portability knowledge is cheap to acquire and rarely decisive; the concepts transfer and the differences are documented. It would be the answer if the role required a migration, which is a project gap, not a judgement gap.
• Conference talks. Visibility, not judgement. Plenty of strong architects have never given one, and the activity feeds back on how well you explain decisions, not on whether they were right.
• A regulated industry. Genuinely valuable, and narrower: it teaches one constraint class, and that class is written down and can be read. The decline experience cannot be read, because the information exists only in a particular estate's history.

When this is the wrong answer

For an architect whose actual job is greenfield product discovery at a company that may not exist in three years, the decline gap is not binding — nothing they build will reach year three, and the binding gap is commercial: can they tell which of six plausible products the company can afford to run. The question is always which gap limits the next decision, not which experience is most prestigious.