You are a new architect and every team tells you a different story about what is wrong. How do you decide where to start?

Separate complaints from evidence

Every team has a narrative and each is partly true. Rank by what you can measure rather than by who was most persuasive:

Frequency — how often does this actually happen? Incident records and ticket volumes answer it.

Cost when it happens — engineering time, customer impact, revenue.

Breadth — one team or many.

Tractability — materially improvable in weeks, or a year of work.

Start where all four are favourable

A frequent, expensive, broad problem you can improve in weeks is where a new architect earns the standing to tackle the year-long one. Starting with the hardest problem is admirable and it means six months of no visible result from someone with no credibility yet.

Look for the problem that appears in several stories

When three teams complain about different things and all three trace to the same environment queue or the same shared database, that is the one. It is also the strongest evidence that you have understood the estate, which matters for how the proposal is received.

Say what you are not doing

Publishing the shortlist with the reasoning — including what you are deliberately deferring and why — prevents the perception that you ignored anyone. Most people accept not being first if they can see the ranking.

Re-rank in public, periodically

Priorities change and the ranking should be revisited openly rather than quietly. It keeps the list credible, and it is how you find out when something has become urgent that was not before.