To understand an architect's true function, analyze their calendar. If it's dominated by "reviewing and approving" meetings, they are a gatekeeper. If it's filled with "enabling and teaching" activities like participating in backlog refinements, they are a valuable enabler helping teams move faster.
Escalating a conflict by attacking an individual will likely backfire on your career. The correct approach is to escalate the systemic issue. Frame the problem as a broken or unclear decision-making process, and ask leadership for clarity on how such disagreements should be resolved.
A key test for an architect's effectiveness is the "vacation test." If their absence for a week or two brings progress to a halt, they are a bottleneck and a single point of failure. An enabling architect builds systems and shares knowledge so the team can function autonomously.
The need for a Solution Architect often signals a failure in organizational design. It's a workaround for teams not communicating effectively, a problem better solved by applying principles from frameworks like Team Topologies to foster cross-team collaboration directly.
A valuable architect enables teams by coaching them through decisions, providing self-serve documentation, and offering multiple solutions. A detrimental architect becomes a gatekeeper, creating a bottleneck where all decisions require their personal approval, stifling team autonomy and speed.
An architect's ultimate goal should be to work themselves out of a job. Success isn't being the indispensable decision-maker. It's creating systems, documentation, and team knowledge so robust that the teams no longer require their constant vigilance or approval.
PMs who complain about architect bottlenecks are often the cause. By failing to invite architects into the discovery phase and customer conversations, they prevent proactive collaboration. This forces architects to reactively gatekeep later, rather than co-creating solutions from the start.
To resolve conflicts, follow Marty Cagan's model: Product Managers are responsible for business outcomes, while engineering teams own the technical implementation. The architect's role is to enable both parties and facilitate the connection, not to override either domain.
Most conflicts between PMs and architects aren't truly technical. They stem from a lack of three crucial, vulnerability-based conversations: 1) What does success look like for you in your role? 2) What is your biggest fear? 3) How can we disagree productively?