PM archetype
The Architect
Builds programs that hold at scale.
You see the whole system: workstreams, dependencies, governance. You design the structure so a large program does not collapse under its own weight.
Top strengths
- Program structure and governance
- Dependency and risk thinking
- Scaling delivery across teams
Blind spot
You can over-design for problems that never arrive, and small quick wins may wait too long.
How The Architect works in each role
Project manager.
A small project can end up carrying gates and templates built for a much larger one, and that is where the Architect most often slips. At best, the Architect plans beyond the next milestone: dependencies mapped early, a clear critical path, governance that is light but exact. The habit worth building is fitting the structure to the work. Cutting a gate is a decision worth writing down.
Program manager.
This is home ground. The Architect sets workstreams, decision rights and the cadence that lets many teams move without a meeting for every question. The strength here is a structure designed before it is needed. The risk is design that runs ahead of delivery: an elegant operating model and a first release that arrives late. The test is plain: what did the structure change in the first quarter? A resume line for this work should answer the same question.
Product manager.
In product work, the Architect thinks in platforms, cross-team dependencies and a roadmap that survives a change of mind. That helps most in large products with many integrations. It slips when the roadmap becomes a diagram of options while customers wait for something small. Pair the big picture with one visible, quick improvement each quarter, so the plan earns trust as it goes. Name the platform, the dependency and the first thing that shipped.
The typical resume mistake
Your resume describes structures, not results: "Established a governance framework".
Examples are illustrative, not from a real client.
Example 1
Before: Established a governance framework for the program.
Why Reed flags it: Rule family: structure named, result missing. A framework is something you built, not something it changed. Reed would ask which decision got faster or which milestone stopped slipping.
After: Set up a [cadence, such as a monthly gate review] across [number of] workstreams; [what changed, such as late scope changes ending or approvals coming sooner], shown in [your decision log or milestone history].
Example 2
Before: Created standard templates and a delivery methodology for all teams.
Why Reed flags it: Rule family: output counted as outcome. Templates are deliverables. Reed asks whether teams used them and what moved as a result.
After: Introduced a [named artifact] that [number of] teams adopted; [the measurable shift you can source] since [month and year]. Source: [where the adoption or result is recorded].
How to fix it
Say what the structure changed: fewer slipped milestones, faster decisions, a go-live that held. Keep only the numbers you can back up.
Interview questions to prepare
Where did a structure you designed turn out to be too heavy, and what did you remove?
How to prepare: Find one process, gate or report you cut or simplified, and write down why it stopped earning its place and what happened after.
How did you know the governance was working?
How to prepare: Choose the two or three signals you actually watched, such as slipped milestones, decision turnaround or open dependencies, and note where each one is recorded.
Common questions
My programs are confidential. How do I describe the structure without naming it?
Describe the shape, not the client: how many workstreams, what kind of change, what governance you set up and the outcome in words. A phrase like "multi-vendor ERP program across several regions" shows scale without a name. Leave out any figure you cannot source.
Does an Architect resume need a framework name?
Not necessarily. Reed asks for a result next to every framework name, so a name alone gives little to work with. One line that says what the structure changed is more useful than a list of methods. Put the methods in a skills section and keep the results inside each role.
For fun and self-reflection only. This quiz has not been scientifically validated. It is not a psychometric, personality or hiring assessment, and should not be used to evaluate anyone for a job.