An architect has no authority over the teams whose systems they are responsible for. What actually produces influence, and what destroys it?

The structural position

An architect is usually accountable for outcomes across systems they do not control, working with teams who do not report to them and who have their own priorities and deadlines. Authority is not available, and attempting to simulate it through process is the standard failure — it produces compliance, avoidance and worse architecture.

What produces influence

• Being useful before being right. An architect who has helped a team solve a problem is listened to when they raise a concern. One whose only interaction is review is a gate, and gates are routed around.
• Doing the work. Prototyping the risky part, writing the migration tool, taking a shift on-call, debugging the incident. Nothing establishes credibility with engineers faster than demonstrated competence in their domain, and nothing is more quickly discounted than architectural opinion from someone who does not build.
• Being right about the things you escalate, and deferring gracefully elsewhere. Credibility is the currency and it is spent on disagreements — an architect who objects to everything has none, and their genuine concerns are discounted with the rest.
• Reporting outcomes, including your own mistakes. An architect who says "I was wrong about that, here is what I learned" is trusted far more than one who is never wrong. This is the single most durable source of influence available, and it is the least used.
• Making the recommended path easier. A paved road that is faster than the alternative needs no advocacy; the strongest architectural influence is exercised through defaults rather than through decisions.
• Bringing information teams do not have — what another team learned, what the incident revealed, what the business intends. An architect's structural advantage is breadth, and trading that information is what makes the role valuable to a team rather than expensive.
• Framing decisions in the terms the audience uses: delivery speed for engineers, risk and cost for executives, capability for product.

What destroys it

• Review as the only interaction, which makes you an obstacle rather than a resource.
• Style preferences presented as findings, which destroys credibility for the findings that matter.
• Being wrong confidently, especially about the things you escalated.
• Escalating routinely, which teaches teams to route around you.
• Vague objections — "this will not scale" without a threshold and a mechanism.
• Not writing anything down, so the same conversation recurs with different people and nothing accumulates.
• Disappearing after the decision, so nobody knows whether the recommendation worked.
• Speaking about systems you have not read. Engineers can tell, immediately, and the recovery is slow.

The reframing that helps most

The objective is a good outcome, not a followed recommendation. An architect whose ideas are adopted and attributed to the team is succeeding; one who needs the credit is optimising for the wrong thing.

And a team that arrives at the right answer themselves, prompted by a good question, will implement it far better than one that was told — which makes the question the more effective instrument, and is the reason experienced architects ask more than they assert.