How do you influence technical decisions when you do not have direct authority over the teams involved?

Question

Accepted Answer

Influencing without authority is perhaps the most important skill for a solutions architect because the role inherently involves guiding decisions across teams that report to other managers. The architect cannot mandate; they must persuade. Effective influence is built on credibility, relationships, and the ability to articulate the value of the recommended approach in terms that resonate with each stakeholder.

Credibility is the foundation. Teams listen to architects who demonstrate deep technical competence, who have a track record of good judgment, and who understand the practical constraints of delivery. Building credibility requires staying hands-on, participating in design discussions with genuine technical contributions rather than abstract guidance, reviewing code and architecture documents with specific feedback, and occasionally rolling up your sleeves to help solve a hard problem. An architect who has never worked in a codebase or deployed a service loses credibility quickly.

Relationship building creates the trust that makes influence possible. Investing time in understanding each team's priorities, challenges, and concerns shows that you are there to help rather than to impose. Regular one-on-one conversations with tech leads, attending team standups occasionally, and being available for ad hoc consultations build the personal connections that make people receptive to your input.

Framing recommendations in terms of the audience's priorities is critical. A development team cares about development velocity and maintainability. A product manager cares about time to market and customer impact. An engineering director cares about operational costs and team capacity. The same technical recommendation needs different framing for each audience.

Providing data and evidence rather than opinions makes recommendations compelling. Instead of saying we should use event-driven architecture, present the analysis: synchronous calls between these three services create a coupling that has caused cascading failures twice in the last quarter. Event-driven communication would eliminate this coupling and reduce the blast radius of failures.

Offering options rather than mandates respects team autonomy. Present two or three viable approaches with their trade-offs and your recommendation. Teams are more receptive when they feel they have a choice and when the reasoning behind the recommendation is transparent.

Listening and incorporating feedback demonstrates humility and builds collaborative relationships. When teams push back on a recommendation, understand their concerns before defending your position. Their practical experience may reveal constraints that your higher-level view missed. Sometimes the right response is to adjust the recommendation based on their input.

Building coalitions with other influential engineers amplifies your impact. When a respected tech lead agrees with your recommendation and advocates for it within their team, the message carries more weight than if it came only from the architect. Socializing ideas informally before formal presentations allows you to build support and address objections proactively.

Documenting decisions in ADRs gives your influence persistence. A recommendation that exists only in a conversation fades. An ADR with clear rationale remains as a reference that guides future decisions, even after you have moved on to other initiatives.