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.
Related Insights
To avoid stifling teams with bureaucracy, leaders should provide slightly less structure than seems necessary. This approach, described as "give ground grudgingly," forces teams to think actively and prevents the feeling of "walking in the muck" that comes from excessive process. It's a sign of a healthy system when people feel they need a bit more structure, not less.
The facilitator's role is to create "productive serendipity." This means carefully architecting the context—agenda, environment, opening questions—but then stepping back to allow the group's interactions to unfold organically, rather than micromanaging the process.
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.
Many leaders, particularly in technical fields, mistakenly believe their role is to provide all the answers. This approach disempowers teams and creates a bottleneck. Shifting from advising to coaching unlocks a team's problem-solving potential and allows leaders to scale their impact.
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.
Productive teams need to schedule three distinct types of time. Beyond solo deep work and structured meetings, they must carve out 'fluid collaboration' blocks. These are for unstructured, creative work like brainstorming or pair programming, which are distinct from formal, agenda-led meetings and crucial for innovation.
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.
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?
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.