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.
Related Insights
To create a cohesive product across multiple teams, GitHub uses a framework that forces alignment upfront. By ensuring all teams first deeply understand the problem and collectively identify solutions, the final execution is naturally integrated, preventing a disjointed experience that mirrors the org structure.
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.
Instead of siloing roles, encourage engineers to design and designers to code. This cross-functional approach breaks down artificial barriers and helps the entire team think more holistically about the end-to-end user experience, as a real user does not see these internal divisions.
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.
Brad Jacobs designs org charts based on the optimal structure for achieving goals, defining necessary roles first. He resists shaping the chart around existing employees and their "fiefdoms." This role-first approach means leaving a seat empty is preferable to filling it with a poor fit, ensuring the structure dictates personnel, not the other way around.
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?
The traditional "assembly line" model of product development (PM -> Design -> Eng) fails with AI. Instead, teams must operate like a "jazz band," where roles are fluid, members "riff" off each other's work, and territorialism is a failure mode. PMs might code and designers might write specs.
Organizing by function (e.g., all sales together) seems efficient but incentivizes teams to optimize their individual metrics, not the company's success. This sub-optimization prevents cross-functional learning and leads to blame games, ultimately harming the entire customer value stream and creating a non-learning organization.
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.