Sources of insights for an architect

An architect doesn’t just design solutions. They also spot systemic problems long before they blow up.
People rarely talk about this because many either don’t notice it or don’t fully understand it.
It’s messy, behind-the-scenes work.

To uncover these problems, architects look for signals in how systems actually behave.
So where do those insights come from?

1. Code reviews
Architects can spot patterns that hint at future issues just by looking at the code. For example:
– Running an app as root inside a Docker container → high risk of executing malicious code with elevated privileges
– Treating RPC calls like local functions, especially inside loops → serious performance degradation

2. Incident retrospectives

3. Customer feedback
Both are already “post-failure” signals. Something has gone wrong.
But if the architect doesn’t act on them, the same issue will hit again, usually harder.
You can’t foresee everything, so this is a goldmine of insight.

4. Team communication
Breakdowns in communication between dev, QA, DevOps, and product often point to deeper architectural issues:
– Poor system decomposition that impacts performance
– Bad naming that leads to duplicated functionality

5. How adjacent teams actually work
You can often spot architectural flaws by looking at the workarounds teams are forced to use. For example:
– Infrastructure defined only imperatively (scripts, docs, or just in someone’s head) → high risk of manual errors and insecure setups (like a DB exposed to the internet)
– QA needing a full week to run tests because the environment is too heavy to spin up per PR → low solution quality

6. Business feedback about engineers
“Developers have gotten slow” usually means technical debt has piled up and was missed at the architectural level.
“Developers ask dumb questions and don’t get obvious things” often means the architecture wasn’t thought through well enough for the team to execute.

Where do you personally find your insights?