When Architects Turn Into PMs: Risks and How to Stop It

Introduction: What Is Architect PMization

In large organizations, senior architects often end up performing the duties of a project manager (PM). This shift involves extensive coordination, resource alignment, and meeting overload, while technical contributions such as design, coding, and testing diminish.

The main reasons include:

The enterprise architecture is extremely complex, requiring massive coordination.

Severe resource mismatches across domains demand heavy effort to lock resources and drive schedules.

Project structures become overly complicated, leading to endless meetings and little actual code.

Many projects have low technical depth, resulting in superficial, “noodle‑style” architectures.

Characteristics of Architect PMization

Key signs that an architect is turning into a PM:

Hands‑on substantive work is decreasing

Spending more time in review meetings and progress‑pushing sessions, with little output in design, coding, or testing

Preferring to drive progress through meetings rather than technical solutions

Finding it harder to answer technical questions directly

Needing to involve many developers to locate and resolve issues

Loves formal processes and escalates schedule problems through them

Risks of Architect PMization

Project risk: With two PMs and no true architect, progress tracking becomes superficial, modules become isolated, and risks are hard to prioritize.

Organizational risk: Competition between PMs leads to friction, and the number of qualified architects declines, making architectural evolution difficult.

Personal risk for architects: The broader skill set of an architect (business understanding, design, implementation, governance) is neglected, turning the role into a pure PM.

Risk to developers: A hollowed‑out architect cannot guide developers effectively, focusing only on schedule rather than quality or cross‑domain architectural decisions, which hampers developers' growth.

How to Prevent Architect PMization

Prevention requires actions at the organization, individual, and cultural levels.

Organizational level: Shift assessment criteria toward tangible deliverables and technical achievements rather than abstract metrics.

Individual level: Ensure architects produce concrete architecture artifacts, record decisions, write code, and participate in testing.

Cultural level: Create an environment where developers can push back against architects who only chase meetings, and bypass architects who do not contribute architectural work.

Automation: Build pipelines that codify coordination, communication, and routine tasks (e.g., contract testing, functional testing, regression testing, deployment) so that progress can be driven automatically, reducing reliance on PM‑style oversight and encouraging architects to return to their core technical responsibilities.