Design so every developer delivers a little better
You can't always assemble a team of star developers. You can almost always change the structure they work inside — and that is the leverage that compounds.
Most advice about building software assumes a team you do not have. Hire exceptional people; give them autonomy; get out of the way. It is good advice and it is rarely actionable. Real teams are assembled from who was available, at the rate the budget allowed, in the town the office is in.
The structure those people work inside, though, is something you can change. And it determines a surprising amount of what they are able to produce.
Structure as leverage
A system with clear boundaries means a developer can be productive in one part without holding the whole thing in their head. Explicit contracts between components mean a mistake surfaces at the boundary instead of three layers away. Decisions written down mean the same argument isn’t relitigated every quarter by people who weren’t there the first time.
None of that makes anyone smarter. It lowers the amount of brilliance the work requires in order to come out well — which is the only kind of improvement that works on a team of ordinary, capable people. That is most teams, including good ones.
Why this is the architect’s job
This is what architecture is for. Not drawing the boxes, and not being the person who makes the hard calls — but shaping the thing so that fewer calls are hard, and so the ones that remain are made where the information actually is.
Judged this way, an architecture is good when the team around it delivers steadily without heroics. Elegance that only its author can maintain has failed the test, however pleasing the diagram.