An architect must stay current across many technologies without spending all their time reading. What method works?

The method

• Learn principles deeply and technologies shallowly. Consistency models, queueing behaviour, failure modes, caching, partitioning and coordination are stable across decades; specific technologies are instances of them. An architect who understands the principles can evaluate a new technology in an afternoon; one who knows only products must learn each from scratch.
• Go deep on one thing at a time, deliberately, and stay broad on the rest. Breadth without any depth produces an inability to judge; depth in everything is impossible.
• Read primary sources for the things that matter: the paper, the documentation, the source. Secondary summaries are efficient and lossy, and the loss is concentrated in the caveats.
• Learn from incidents — yours and other organisations' published ones. A postmortem teaches more about a technology's real behaviour than its marketing does, and the failure modes are what you actually need.
• Build something small. Reading about a technology and using it produce different understandings, and the difference is exactly the operational reality that decides whether it fits.

What to deliberately not learn

Technologies you have no plausible use for, however interesting. The opportunity cost is real and the knowledge decays.

And detailed knowledge of things the team knows well — an architect does not need to be the best at any specific technology, and attempting it consumes the attention that the breadth requires.

The signal that learning is misallocated

Being surprised by a category of problem rather than by an instance. Being surprised by a specific database's behaviour is normal; being surprised that write-heavy workloads behave differently from read-heavy ones is a gap in principles, and it is the kind that generalises.

The organisational version

A team's learning is a shared asset and it is usually left to chance. Deliberate mechanisms — a rotation through unfamiliar areas, incident reviews attended by people outside the affected team, and pairing across specialisms — spread knowledge that otherwise concentrates in whoever happened to build something.

The concentration is a risk with a deadline set by that person's departure, which makes distributing it an architectural activity rather than a development one.