He had the title of architect, and he was very good at diagrams.
Boxes, arrows, layers. He could explain any system in terms of components and their relationships. He'd been doing this for years, and his diagrams were genuinely beautiful — clear, logical, easy to follow.
The problem was that he hadn't written production code in a decade.
This wasn't a secret. It was understood. His role was to think at a higher level, to make decisions that would guide the teams doing the actual building. He was strategic. He was senior. He was above the code.
But the systems he designed kept running into trouble.
Not immediately. The diagrams made sense. The architecture reviews went smoothly. Everyone would nod and agree that yes, this was the right approach. Then the teams would start building, and the problems would begin.
The abstractions that looked clean on a whiteboard turned out to be awkward in practice. The boundaries between services created friction that nobody had anticipated. The "simple" integrations required weeks of work to get right.
The architect would be puzzled. The design was sound. The teams must be implementing it wrong.
But the teams weren't implementing it wrong. They were discovering things that only become visible when you try to make something real. The gap between a diagram and working software is vast, and it's filled with details that don't fit in boxes.
I've seen this pattern repeat across companies. The further an architect gets from the code, the more their designs drift from reality. Not because they're incompetent, but because architecture is a contact sport. You have to feel the friction to know where it is.
The best architects I've worked with still write code. Not all the time, but enough to stay calibrated. They know what's easy and what's hard, not from memory, but from recent experience. Their designs account for the messy realities because they've recently been in the mess.
The worst architects treat code as beneath them. They've graduated to a higher plane where implementation details don't matter. They design systems that would work perfectly if only the engineers were better.
Architecture isn't a phase that happens before building. It's something that emerges from building, gets refined by building, and stays honest only through continued contact with building.
The diagram is not the system. And the person who draws the diagram should probably still remember what it feels like to make the system work.