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.
Related Insights
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.
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.
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.
Product managers frequently receive solutions, not problems, from stakeholders. Instead of saying no, the effective approach is to reframe the solution as a set of assumptions and build a discovery backlog to systematically test them. This builds alignment and leads to better outcomes.
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.
When pursuing a long-term strategic solution, dedicate product management time to high-level discovery and partner alignment first. This doesn't consume engineering resources, allowing the dev team to remain focused on mitigating the immediate, more visceral aspects of the problem.
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?
While intended to improve efficiency, the rise of Agile ceremonies and specialized roles like Product Managers has created layers of abstraction. This often "hides" engineers from direct customer interaction, reducing their understanding of the "why" behind their work.
The number one reason design-led product visions fail is the exclusion of product management. Since design doesn't typically own the roadmap, involving product partners from the very beginning is critical for buy-in and ensuring the vision doesn't become a useless artifact.
The misconception that discovery slows down delivery is dangerous. Like stretching before a race prevents injury, proper, time-boxed discovery prevents building the wrong thing. This avoids costly code rewrites and iterative launches that miss the mark, ultimately speeding up the delivery of a successful product.
