Project Manager Track

Project Manager

Runs sub-team delivery end-to-end. Owns the plan, surfaces the risks, keeps the client confident.

4levels · 9competencies · Total weight 13.5 · Hire bar PM2

The 4 PM levels

PM1

Junior

You ship: Run 1 sub-team · 3–5 members

📋Mentor-supervised cadence + standup

📚Single workstream, simple scope

🎯Learns escalation timing

1.8 – 2.4

PM2

Mid

You ship: 1 sub-team end-to-end · 6–12 members

🛠Runs standard cadence solo

📊Owns metrics + client reports

🤝Direct client meetings

2.5 – 3.4

PM3

Senior

You ship: Multi-team / small ODC · 12–20 members

🧭Leads 2+ teams or small ODC

🌉Coaches PM1/PM2 daily

🎯ODC Lead candidate

3.5 – 4.2

PM4

Principal

You ship: Multi-sub-team coordination · 20–35 members

🌍Coordinates across sub-teams

📜Defines ODC playbooks

🎯ODC Lead path

4.3 – 5.0

Your journey:

PM1 PM2 PM3 PM4

Behaviors, not tenure. See the detail below.

Competency matrix — at a glance

Competency

PM1

PM2

PM3

PM4

Delivery Planning & Execution

×2

Requirements & Scope Mgmt

×1

Risk & Quality Mgmt

×1.5

Client & Stakeholder Comm

×2

Team Leadership

×1.5

Technical Literacy

×1

Effort Efficiency (EE)

×1

People Management

×1.5

Account Health

×2

1 Aware 2 Developing 3 Proficient · hire bar 4 Senior 5 Expert

Competency deep-dive

Delivery Planning & Execution

Weight ×2

L3 · hire bar

Aware

Fresh PM hire (0–1 year), or BA/Scrum Master transitioning into PM, or a coordinator role re-titled.

"The plan exists; my job is to keep things on it."

The PM knows what planning artifacts look like (sprint plan, burndown, release plan) and can populate them when given inputs. They cannot independently create a plan from scratch. They are learning by doing, not yet contributing.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Attends daily standups led by senior PM/TL	≥90% attendance/month	Calendar + standup notes
Updates Jira tickets per assigned scope	≥95% tickets current within 24h	Jira ticket update logs
Files reflection / learning notes to mentor PM	≥1/week	Confluence mentor log or Slack DM
Slippage reported upward within same day detected	100% same-day reporting	Slack / email timestamp vs Jira flag
Completes assigned sub-team tasks following sprint template	Manages 1 sub-team of 3-5 members	Jira team config + HR org chart

Observable behaviors

1Attends sprint planning, but Tech Lead or senior PM drives the agenda and pace.
2Asks the Tech Lead "should this be a 5 or 8?" rather than estimating themselves.
3Updates Jira when team members report status — does not chase status proactively.
4Sprint board exists but they don't restructure it for the team's needs.
5Status reports follow a strict template; off-template situations cause confusion.
6Standups feel like a roll-call rather than a working session.
7When something slips, the response is to report it up rather than act on it.
8Limited use of dashboards beyond default Jira views.

Expected outputs

Updated Jira tickets reflecting yesterday's status.
Meeting notes from ceremonies attended.
A sprint plan populated with team-provided estimates (PM did not estimate).
Standard weekly status report, template filled in mechanically.
Auto-generated burndown chart (no commentary).
Risk log, mostly empty or recording only obvious risks after they appear.

What you would see

The Tech Lead facilitates the sprint planning. The L1 PM updates Jira live during the meeting, captures decisions, occasionally asks clarifying questions, doesn't push back on estimates, and the meeting can comfortably run without them present.

Common traps

Becomes a glorified scribe — the team treats them as a note-taker.
Defers all planning judgment to Tech Lead and stays passive too long (over 6 months in a comfortable team).

Developing

PM with 1–3 years of sub-team experience. Comfortable on small, simple projects.

"I can follow the playbook reliably. When reality deviates, I react."

The PM can run the standard cadence on a small team (3–6 people, mostly known scope) without supervision — they prep meetings, run them, drive Jira, write status reports. They struggle when reality diverges from the standard pattern (scope changes, late ramps, integration issues).

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Runs standup solo without senior PM	≥4/week solo	Calendar host + meeting notes
Sprint planning session duration kept tight	≤60 min per planning	Calendar meeting duration
Routine escalations to senior PM	=0 routine escalations/sprint	Slack escalation log / email
Sprint completion vs commitment ratio	≥80% committed scope shipped	Jira sprint reports
Status reports delivered on schedule	≥95% on time	Email/Confluence status report timestamps

Observable behaviors

1Prepares for sprint planning (pre-groomed stories, capacity check).
2Runs standup; team participates.
3Owns the sprint plan, but estimates still lean on the Tech Lead.
4Tracks velocity but treats it as a number to report, not a planning input.
5Identifies risks after they appear, not before.
6Status reports get written but might miss nuances the client actually cares about.
7Burndown is used but not interpreted ("here's the chart").
8Slippage triggers a "we'll catch up next sprint" response rather than a re-plan.
9Comfortable with Jira day-to-day but doesn't customize the board for the team's needs.

Expected outputs

Sprint plan, 1–2 sprints out, with team-provided estimates.
Daily-updated sprint board.
Weekly status report (template, populated).
Risk log — known risks listed, often without mitigations.
Burndown with one-line commentary.
Velocity tracking spreadsheet (numbers captured, not analyzed).
Sprint retro notes with action items, many unimplemented.

What you would see

PM opens the meeting, walks through capacity, asks the Tech Lead for top-priority items, team estimates, PM commits sprint scope based on velocity. Meeting runs 90–120 minutes and ends with a populated sprint. The PM doesn't always question whether the right items got prioritized, or whether dependencies are real.

Common traps

"Hoping" — assumes things will go well rather than planning for what could go wrong.
Doesn't push back on team estimates ("if Tech Lead says 8, it's 8").
Misses second-order effects of scope changes (dependencies, testing, deployment).
Burndown drifts 2–3 days before any intervention.

ProficientHIRE BAR

Independent sub-team PM. Can run one team end-to-end without supervision.

"I own the plan. The plan is a hypothesis. My job is to make reality match the plan, or replan when reality wins."

The PM can pick up a sub-team, kick it off, build the backlog and release plan, run sprints, and deliver on commitments — without anyone holding their hand. Their estimates are within ±20% on a typical sprint. They spot deviation early and act before it becomes a status-report problem.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Runs entire sprint solo without senior PM backup	100% sprints PM-owned end-to-end	Jira sprint ownership + retro notes
Sprint completion vs commitment sustained	≥85% committed scope shipped over 4 sprints	Jira sprint reports trend
Manages team size at the hire bar	8-12 members managed directly	HR org chart + Jira team assignments
Sprint ceremonies (planning, review, retro) facilitated solo	100% ceremonies hosted by PM	Calendar host + ceremony notes
Status reporting horizon and accuracy	2 sprints visible, ≥90% forecast accuracy	Status report archive vs actual outcomes

Observable behaviors

1Drives sprint planning meetings (not just facilitates).
2Challenges team estimates with rationale, not just "are you sure?"
3Tracks velocity actively and uses it as the planning baseline.
4Spots schedule risk 1–2 sprints out and intervenes (replan, descope, or escalate).
5Adapts process when the standard isn't working (e.g., adds a mid-sprint sync if scope shifts often).
6Pushes back on client scope changes through formal change control.
7Status reports adapt to the client's preferences (frequency, format, focus areas).
8Knows when to handle locally vs escalate.
9Standups are short, focused, and end with actionable next steps.
10Sprint retros produce concrete improvements that get implemented over 3+ sprints.
11Risk register is living — items added and closed regularly.

Expected outputs

Sprint plan with rationale (why these items, why this size).
Release plan covering 2–3 sprints with milestones.
Active risk register (typically 5–15 items, weekly updated, with owner and mitigation).
Velocity report with one-line trend analysis.
Customized client status report (matches client's preferred format/focus).
Sprint retros with tracked actions sprint-over-sprint.
Capacity model factoring in vacations, training, and ramp time.
Dependency map for known cross-team dependencies.
Sprint kickoff doc for the team (goal, scope, team composition).

What you would see

PM has pre-groomed the backlog with the BA, knows the capacity, and has a draft sprint goal ready. Meeting starts with goal discussion, then team estimates with PM challenging when numbers feel off. Sprint scope is set in 60–90 minutes. PM confirms commitments aloud. Sprint kickoff doc goes to stakeholders within the day.

Common traps

Process-worship — measures sprint mechanics but loses sight of the business outcome.
Velocity worship — chases sprint completion at the expense of quality or learning.
Comfort zone — keeps the team in steady-state too long; doesn't push for stretch.

Senior / Lead

Senior PM running a large sub-team (15–20 people), 2 sub-teams, or a recovery project.

"I plan multiple horizons simultaneously. I detect failure 3+ sprints out. I am the project's brain, not its calendar."

Beyond running steady-state, the L4 PM plans releases (multi-sprint, with milestones and dependencies), recognizes patterns of failure early, and can recover a project in trouble. They also start to influence how other PMs work.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Forward planning horizon with milestones	3-6 sprints visible in roadmap	Jira roadmap / Confluence release plan
Failure / slip prediction lead time	Detects ≥3 sprints out, ≥80% accuracy	Risk register vs actual slip outcome
Engineering health dashboard maintained	≥1 live dashboard with ≥5 metrics	Confluence / Jira dashboard URL
Coaches mid-PMs on planning rigor	≥2 mid-PMs via documented 1:1s/quarter	Confluence 1:1 log
Manages cross-team member count	12-20 members across 2+ teams	HR org chart + Jira team assignments

Observable behaviors

1Plans 3–6 sprints out with milestone-based release planning.
2Manages dependencies across multiple sub-teams (within the ODC and across ODCs).
3Velocity calibration is rigorous — uses historical data with seasonality, not gut.
4Recognizes "project in trouble" patterns weeks before they bite (velocity declining, retro items repeating, defect rate creeping).
5Knows how to run a project recovery — descope, reshuffle, re-baseline, communicate.
6Coaches mid-PMs informally; reviews their plans before client checkpoints.
7Adapts agile method to the project (Scrum, Kanban, hybrid) without dogma.
8Establishes and revisits team working agreements quarterly.
9Drives improvement cycles end-to-end (action items actually close).
10Pushes back on senior client stakeholders on scope or timeline with evidence.
11Tracks engineering health metrics (deploy frequency, MTTR, defect escape rate), not just velocity.

Expected outputs

Multi-sprint release plan with milestones and dependency map.
Velocity calibration model with statistical baseline and outlier handling.
Project recovery plan (when needed) with re-baselined dates and client communications.
Engineering health dashboard alongside delivery dashboard.
Capacity model accounting for skills, ramp, and attrition probability.
Coaching notes or written guidance for junior PMs.
Continuous improvement backlog with metrics on the improvements themselves.
Cross-team dependency tracker with named owners and dates.
Risk mitigation playbook specific to this client/domain.

What you would see

Sprint planning is fast (45 minutes) because release planning happened separately. The sprint goal ties to a release milestone. The PM has already checked in with each team member individually before the meeting — the meeting is execution, not discovery. Dependencies are flagged with named owners and dates.

Common traps

"Hero mode" — solves all problems personally, doesn't develop the team or other PMs.
Over-engineers planning artifacts (too many dashboards, nobody reads them).
Recovery becomes the default mode rather than prevention.

Expert / Principal

Senior-most PM in the ODC. Shapes how every PM plans and executes.

"My job is no longer to deliver this project — it is to make all projects deliver better. I work on the system, not in it."

The PM designs the standards, templates, and tooling used across the ODC. Other PMs come to them with hard problems. They influence sales (delivery expectations in SOWs) and the ODC's strategic planning.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Authors ODC planning playbook adopted by other PMs	≥1 playbook adopted by ≥2 PMs/year	Confluence playbook + adoption record
Cross-team executive dashboard owned	Covers ≥3 teams, updated weekly	Confluence/BI dashboard URL
Identifies systemic delivery patterns across teams	≥4 documented systemic findings/year	ODC retro / leadership memo
Manages ODC-level member count across sub-teams	20-35 members across multiple sub-teams	HR org chart + ODC structure doc
Mentors L4 PMs on multi-team delivery	≥2 L4 PMs mentored sustained 2+ quarters	Confluence mentorship log

Observable behaviors

1Writes and maintains the ODC planning playbook (versioned, updated quarterly).
2Sets estimation standards — reference stories, planning poker conventions, story-point definitions.
3Owns or co-owns the Jira configuration, dashboards, and automation.
4Brings industry practices in (SAFe, Spotify, Scrum-at-Scale) — selectively adopts, doesn't copy-paste.
5Trains and certifies new PMs through structured onboarding.
6Audits other PMs' release plans and gives written feedback.
7Influences how the ODC sells to clients — sets realistic delivery expectations in proposals.
8Identifies systemic planning issues across multiple sub-teams.
9Co-creates ODC-level OKRs with the ODC Lead.

Expected outputs

ODC planning playbook (the canonical reference).
Estimation reference library — reference stories, calibration tools.
PM onboarding and training material (multi-week curriculum).
Process improvement RFCs (proposed changes with rationale and pilot results).
Industry benchmarking reports — how do we compare on velocity, predictability, defect escape.
Cross-team planning dashboard (executive view).
Standard templates library (sprint kickoff, release plan, retro, capacity plan, recovery plan).

What you would see

Rarely in sprint planning meetings — they observe occasionally to coach. When they do attend, they ask second-order questions: "What does our last 6 months of velocity look like? Are we still calibrating against the right baseline? Why is this team's retro producing the same action item we saw in another team three months ago?"

Common traps

Loses touch with day-to-day execution; becomes too theoretical.
Over-standardizes — kills team-specific innovation.
Becomes a bottleneck if too many PMs need their input.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Becomes glorified scribe / note-taker

'Hoping' rather than planning for failure

Process-worship; loses business outcome

'Hero mode' — solves all personally

Loses touch with day-to-day execution

Scoring rule: You are at Level N if you hit Level N in at least 3 of 5 dimensions, AND no dimension is below Level (N−1). Sort levels descending — the 3rd value is your overall level. If the lowest drops more than 1 below, demote 1 level.

Requirements & Scope Management

Weight ×1

L3 · hire bar

Aware

Junior PM who hasn't yet driven requirements work; relies on the BA for everything.

"Requirements come from the client; my job is to capture them."

The PM captures words but not yet meaning. They type up what the BA discovers and what the client says, without questioning either.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
User stories typed up from BA notes within SLA	≥90% within 1 business day of BA handoff	Jira story timestamps vs BA notes
Raw change log maintained (uncategorized acceptable)	100% changes logged within 24h	Confluence CR log / Jira
Backlog reviewed with mentor PM	≥1/week	Calendar + mentor sign-off
Client requests captured verbatim	100% client asks logged within 24h	Email/Slack vs Jira backlog entries
Asks clarifying questions in BA/PO sessions	≥3 questions logged per refinement session	Meeting notes / Confluence

Observable behaviors

1Captures meeting notes when the client requests features.
2Types up user stories from the BA's discovery sessions.
3Doesn't write acceptance criteria independently.
4Asks "what does the client want?" rather than "what is the underlying need?"
5Tracks change requests but doesn't categorize or assess them.
6Doesn't push back on scope creep.
7Backlog items are vague (e.g., "add reporting").

Expected outputs

Story tickets with text copied from notes.
Raw change request log (uncategorized, no impact assessment).
Loose backlog with many vague items.

What you would see

In requirements meetings, the PM is the scribe. The Tech Lead and BA do the questioning. The PM only contributes when asked.

Common traps

Becomes a stenographer — captures words but not meaning.
Lets the BA own the entire scope conversation.

Developing

PM with some project experience, working closely alongside a BA.

"I write stories from the BA's discovery. AC are checklists."

Can produce reasonable user stories with the BA's input. Recognizes obvious scope changes but misses the subtle ones (e.g., "a filter" that requires three new endpoints).

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Writes stories independently (BA reviews only)	≥70% stories authored by PM	Jira author field
Change requests categorized at intake	≥90% CRs categorized within 48h	Confluence CR log
Backlog duplication rate	≤10% duplicate or zombie items	Jira backlog audit
Identifies obvious scope changes before sprint end	≥80% scope changes flagged same sprint	Jira change log vs sprint dates
Clarifies client asks before commit	≥80% asks have clarification record	Email/Confluence clarification thread

Observable behaviors

1Writes user stories with clear acceptance criteria (with BA's help).
2Tracks the change log with high-level categories.
3Recognizes obvious scope changes ("client added a new screen").
4Misses subtle scope creep (small asks with big downstream impact).
5Backlog is organized but with some duplicates or outdated items.
6Doesn't enforce formal change control consistently.

Expected outputs

User stories with acceptance criteria (mostly clear, some ambiguity).
Categorized change log (defect / new scope / clarification).
1–2 sprints of refined backlog.
Basic story map.

What you would see

BA leads the grooming session; PM facilitates and captures decisions. When the client floats a new idea, PM asks clarifying questions but doesn't immediately think about cost.

Common traps

Accepts client requests as commitments without checking impact.
Treats acceptance criteria as a checklist of features rather than testable behaviors.

ProficientHIRE BAR

Independent PM owning the sub-team backlog end-to-end.

"Backlog is product strategy in flight. Every change has a cost and I own that cost conversation."

The PM drives backlog and scope discussions. Enforces formal change control with impact data. Pushes back on scope creep without damaging the client relationship.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
PM authors stories independently end-to-end	100% stories authored by PM	Jira author field
CR categorized at intake with full taxonomy	100% CRs categorized within 24h	Confluence CR log + intake form
Owns backlog grooming cadence	Weekly grooming led by PM, ≥95% attendance	Calendar host + grooming notes
AC quality and DoD compliance	≥95% stories pass AC review first time	Jira AC review log + QA rework rate
Scope change detection horizon	≥90% scope changes flagged ≥1 sprint ahead	Risk register vs change log

Observable behaviors

1Runs backlog refinement; drives prioritization conversations with client and BA.
2Writes user stories with crisp acceptance criteria that engineers don't need to interpret.
3Enforces formal change control — every change request gets assessed for time, cost, and risk impact.
4Categorizes changes (defect, new scope, clarification, missed requirement).
5Pushes back on scope creep with data ("this requires X more sprints").
6Maintains a clean backlog (ranked by value, no zombies).
7Uses story-mapping or release-mapping to help the client see priority trade-offs.

Expected outputs

Refined backlog (1–2 sprints deep, ranked).
User stories with AC and Definition of Done.
Change Control Register with impact assessment per item.
Story map or release roadmap (visual).
Scope baseline document (what was in the original SOW vs what has changed).

What you would see

PM runs the backlog meeting with ranked priorities. When the client wants to add scope, PM responds with "to add X, we'd need to defer Y or extend by N sprints — which do you prefer?" rather than "yes, we can add that."

Common traps

Procedural overload — every conversation becomes a change request, client loses goodwill.
Treats the SOW as gospel rather than a starting baseline.

Senior / Lead

Senior PM managing complex scope, multiple sub-teams, or a recovery.

"Scope is a negotiation. I shape it; I don't just receive it."

Negotiates scope trade-offs at release-planning level. Coaches the client on must-have-vs-nice-to-have thinking. Handles complex changes that ripple through dependencies, NFRs, and contracts.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Release-level scope plan maintained	≥1 release plan per release, kept current	Confluence release plan
Detects scope creep horizon	≥2-3 sprints out, ≥80% accuracy	Risk register vs actual creep events
Coaches client on must-have vs nice-to-have	≥1 coaching artifact per release	Client meeting notes / email
Handles contract-aware complex changes	100% contract-impacting CRs have legal/PMO sign-off	CR log + contract review trail
Mentors mid-PMs on scope discipline	≥2 mid-PMs/quarter via documented sessions	Confluence mentorship log

Observable behaviors

1Negotiates scope trade-offs with the client at release-planning level.
2Aligns scope to release plan and commercial constraints (margin, headcount).
3Detects scope creep 2–3 sprints out through pattern recognition.
4Coaches the client on prioritization ("if we do all of this, here's what gets sacrificed").
5Handles complex changes that affect dependencies, NFRs, or contract structure.
6Builds reusable scope-management artifacts (templates, prioritization frameworks).

Expected outputs

Release-level scope plan with named trade-offs.
Scope dashboard (commitments, changes, impact, cumulative drift).
Negotiation outcomes documented.
Lessons-learned register for scope-related issues.

What you would see

In a client meeting where new requirements emerge, the PM proposes prioritization options ("if you want X, we drop Y, or we extend by N sprints, or we add headcount with a change order — which fits your goals?") rather than escalating.

Common traps

"Yes" person under client pressure — accepts scope to keep peace.
Or, conversely, too rigid — kills the client relationship by always saying no.

Expert / Principal

Senior-most PM, shaping ODC-wide scope discipline.

"Scope discipline is a system, not a heroic act per project."

Sets ODC-wide change control standards. Influences how proposals and SOWs are scoped. Mentors other PMs on scope negotiation.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Owns ODC change control playbook	≥1 playbook, adopted by ≥2 PMs	Confluence playbook + adoption record
Cross-team scope dashboard maintained	Covers ≥3 teams, weekly refresh	Confluence/BI dashboard
Shapes scope at SOW level for new engagements	Contributes to ≥2 SOWs/year	Sales/PMO SOW records
Mentors PMs on scope negotiation	≥3 PMs mentored over 2+ quarters	Confluence mentorship log
Sets story authoring standards across ODC	Standards doc adopted by ≥80% PMs	Confluence + Jira template usage

Observable behaviors

1Shapes scope at SOW level — influences how proposals are written.
2Sets ODC-wide change control standard (templates, governance).
3Mentors other PMs on scope negotiation and prioritization.
4Tracks scope-related metrics across teams (scope-change rate, approval cycle time).

Expected outputs

ODC change control playbook.
SOW scope-input templates.
Cross-team scope dashboard.

What you would see

Reviews and improves how the ODC scopes proposals; consulted on contentious scope battles across accounts.

Common traps

Over-standardizes — client-specific nuance gets lost in templates.
Disconnects from current project realities.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Stenographer — captures words, not meaning

Accepts client asks without impact check

Procedural overload kills client goodwill

'Yes' person, or too rigid 'no'

Over-standardizes; loses client nuance

Risk & Quality Management

Weight ×1.5

L3 · hire bar

Aware

Junior PM new to risk-management practice.

"Risks are what's blocking us today."

Treats risk as reactive triage. Lives in the present. QA-supplied defect data passes through them without interpretation.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Daily blockers reported in standup	100% blockers raised same day	Standup notes / Jira blocker flag
Issues escalated to senior PM with context	≥95% within 24h of detection	Slack escalation thread
Passes QA reports to senior PM/team	100% QA reports forwarded within 1 day	QA report distribution log
Attends risk review sessions led by senior PM	≥90% attendance	Calendar + session notes
Maintains daily issue log per team requirement	≥95% days updated	Jira / Confluence issue log

Observable behaviors

1Reports issues as they appear in standups.
2Follows the QA checklist when given one.
3Doesn't anticipate failure modes.
4Defect data is captured by QA, not interpreted by the PM.

Expected outputs

Daily issue log.
QA-supplied defect report passed through to status.

What you would see

In standup, the PM reports today's blockers. Doesn't proactively ask "what could go wrong this sprint?"

Common traps

Lives in the present — no risk horizon.
Treats risk as reactive triage.

Developing

PM with basic risk-management training.

"I keep a risk log."

Maintains a basic risk log with common risks (timeline, dependency, key person). Updates infrequently. Mitigations are wishful ("monitor").

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Risk register maintained with common risks	≥10 items, monthly review	Confluence/Jira risk register
Defect summary in sprint status report	≥95% sprints include defect section	Status report archive
Escalates surfacing issues within SLA	100% within 1 business day	Slack/email escalation timestamps
QA gate sign-off before release	100% releases have QA sign-off recorded	Release log / QA sign-off doc
Risk register update cadence	Updated ≥1/month	Confluence version history

Observable behaviors

1Identifies common risks (timeline slippage, dependency, key-person dependency).
2Runs a basic risk log (10–15 items).
3Updates monthly or less often.
4Quality conversation comes from QA, not from the PM.
5Mitigations are vague ("monitor", "escalate if needed").

Expected outputs

Risk log with status field.
Defect summary in weekly status report.

What you would see

PM adds risks after they appear in standup; risks rarely have concrete mitigations or owners.

Common traps

Log exists but doesn't update.
Mitigations are wishful ("monitor") rather than actionable.

ProficientHIRE BAR

Independent PM running a sub-team's risk and quality discipline.

"Risk is an active discipline. Quality is a contract with the client."

Maintains a proactive risk register with named mitigations and owners. Defines quality gates per release. Tracks defect escape rate and acts on trends.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Risk register maintained live (continuous update)	Updated within 24h of any new risk	Confluence/Jira risk register version history
Pre-mitigation rate of identified risks	≥80% risks have mitigation plan before impact	Risk register mitigation column vs outcome
Active risks tracked per sprint	≥3 risks tracked actively per sprint	Risk register sprint slice
Risk review meeting led by PM	≥1 risk review/sprint led by PM	Calendar host + risk review notes
RCA documented for materialized risks	100% materialized risks have RCA within 1 week	Confluence RCA archive

Observable behaviors

1Maintains a proactive risk register with named mitigations and owners.
2Defines quality gates per release (entry and exit criteria).
3Reviews the risk register weekly with the Tech Lead.
4Tracks defect escape rate and root-cause categories.
5Anticipates risks specific to this project (integration, NFR, third-party SLA).
6Holds the team accountable to Definition of Done.

Expected outputs

Active risk register (\~15–20 items, weekly updated, with mitigation, owner, and due date).
Quality gates documented per release.
Defect dashboard (escape rate, root cause, trend).
Release readiness checklist.

What you would see

In sprint planning, the PM raises 1–2 risks for this sprint. In standup, the PM asks "anything that could derail this?" Quality is part of every status report, not just a footnote.

Common traps

Risk log becomes long but unactioned (10+ items with no movement).
Quality treated as "did QA sign off?" rather than "what's our actual defect trend?"

Senior / Lead

Senior PM responsible for strategic risk and quality culture.

"I anticipate strategic risks. Quality culture is my responsibility."

Anticipates strategic risks (client politics, regulatory shifts, technology changes). Leads crisis recovery when defects hit production. Drives a quality-first culture in the team.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Audits other PMs' risk registers	≥2 PMs/quarter with documented audit notes	Confluence audit log
Engineering quality metrics tracked	≥3 metrics live (coverage, MTTR, escape rate)	Engineering dashboard / Jira
Crisis playbook ready and rehearsed	≥1 playbook + ≥1 drill/year	Confluence playbook + drill log
Leads war-room on major incidents	≥80% major incidents led by PM	Incident log / war-room records
Anticipates strategic/regulatory risks	≥3 strategic risks logged + mitigated/year	Risk register strategic section

Observable behaviors

1Anticipates strategic risks (client politics, regulatory shifts, technology changes).
2Leads crisis recovery — declares incident, runs war room, drafts client comms.
3Drives quality-first culture in the team (TDD adoption, code review depth, NFR sign-off).
4Audits other PMs' risk registers and gives feedback.
5Establishes engineering quality metrics (cyclomatic complexity, test coverage, MTTR).

Expected outputs

Strategic risk briefings to the ODC Lead.
Crisis playbook (steps to follow when production breaks).
Engineering quality dashboard broader than defect rate.
Quality improvement RFCs.

What you would see

When a critical defect hits production, the PM has a war-room running within 2 hours with named owners, blast-radius assessment, and client comms drafted before the client asks.

Common traps

Quality becomes religion; team feels micromanaged.
Risk register becomes a "scary list" without action.

Expert / Principal

Senior-most PM, shaping ODC risk and quality systems.

"Risk and quality are systems we engineer, not events we react to."

Builds the ODC's risk framework — categories, escalation paths, governance. Defines ODC-wide quality standards. Handles client-board-level risks.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Owns ODC risk framework	Framework adopted by ≥80% PMs	Confluence framework + adoption record
Cross-team root-cause analyses authored	≥2 cross-team RCAs/year	Confluence RCA repository
Sets ODC-wide quality standards	Standards doc adopted, ≥2 PMs cite	Confluence quality standards
Handles board / executive-level risk events	≥2 board-level risk briefings/year	Executive briefing log
Mentors PMs on risk maturity	≥3 PMs mentored sustained 2+ quarters	Confluence mentorship log

Observable behaviors

1Builds the ODC risk framework — categories, escalation paths, governance.
2Defines ODC-wide quality standards (entry/exit criteria, code review norms, NFR baselines).
3Handles client-board-level risks (contract risk, security risk, reputational).
4Sets ODC quality metrics with the Head of Delivery.

Expected outputs

ODC risk framework documentation.
ODC quality standards.
Quarterly risk and quality report to the Head of Delivery.
Cross-team root-cause analysis.

What you would see

Reviews systemic risks across teams; intervenes when patterns appear across multiple sub-teams.

Common traps

Theoretical risk modeling that loses ground truth.
Standards become so heavy they slow teams down.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Lives in present — no risk horizon

Log exists but doesn't update

Long risk log, items unactioned

Quality becomes religion; team micromanaged

Theoretical modeling loses ground truth

Client & Stakeholder Communication

Weight ×2

L3 · hire bar

Aware

PM with limited client exposure, or non-native English speaker still building fluency. CEFR B1.

"I send status when asked; I escalate when stuck."

Limited client interaction. Defers complex conversations to senior PM. Misses subtext.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Attends client meetings as observer/note-taker	≥90% attendance	Calendar + meeting notes archive
Sends client emails using approved templates	100% template-compliant	Email archive review
Status updates sent on schedule	≥95% on time	Email/Confluence timestamps
Defers complex client conversations to senior PM	100% complex conversations handed off appropriately	Slack handoff log / mentor notes
Asks senior PM for review before sending client comms	100% external comms reviewed before send	Email draft review trail

Observable behaviors

1Participates in client calls but rarely speaks unprompted.
2Writes basic status emails using strict templates.
3Defers complex conversations to senior PM or ODC Lead.
4Misses subtext in client messages (sarcasm, indirect dissatisfaction, urgency cues).
5Doesn't proactively ping client.

Expected outputs

Template-based status emails.
Factual meeting notes.

What you would see

In client calls, the PM listens. If asked a question, they give a short factual answer. They don't initiate conversation.

Common traps

Avoids client interaction; becomes a "ghost PM".
Takes everything literally — misses the real concern.

Developing

PM with regular client exposure. CEFR B2.

"I run the standup with the client. I write weekly status."

Comfortable in routine client interactions. Status reports are complete. Struggles with non-routine situations.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Runs client standups confident on facts	≥4 standups/week solo	Calendar host + client meeting notes
Email response time to client	≤4 business hours median	Email response time analytics
Escalations to senior PM on client comms	≤1/sprint for non-strategic asks	Slack escalation log
Client status meetings hosted independently	≥3/week	Calendar host field
Client CSAT baseline	≥3.5/5	Quarterly CSAT survey

Observable behaviors

1Runs client standup; speaks confidently on factual topics.
2Writes weekly status report from template, well-populated.
3Handles routine clarifications.
4Defers escalations to senior PM.
5Can lose nuance in writing (sounds robotic or overly hedged).
6Sometimes over-promises to please the client.

Expected outputs

Weekly status reports (template, complete).
Meeting agendas for client calls.
Routine email responses.

What you would see

Client standup runs smoothly; PM keeps to the agenda. "Any blockers?" is the most challenging question they handle confidently.

Common traps

Sticks to script; doesn't dig when client says something subtle.
Over-promises under pressure to keep things smooth.

ProficientHIRE BAR

Independent client-facing PM. CEFR B2+ to C1.

"I own the client relationship at the project level. I handle hard conversations."

Runs client meetings solo. Handles delays and defect conversations. Manages expectations proactively.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Handles client escalations solo	≥90% client escalations resolved without senior PM	Escalation log resolution column
Weekly client cadence owned	≥1 weekly client meeting hosted by PM	Calendar host + meeting notes
Sustained client CSAT at hire bar	≥90% CSAT (≥4.5/5) over 2+ quarters	Quarterly CSAT survey trend
Client comms authored without review	≥95% external comms sent without senior review	Email send log + review trail
Client tough conversations handled directly	100% sprint-level tough conversations led by PM	Meeting notes + retro reflection

Observable behaviors

1Runs client meetings independently (planning, status, escalations).
2Handles delay and defect conversations directly with the client.
3Manages client expectations proactively (raises concerns before the client does).
4Writes status reports that match the client's preferred format and depth.
5Reads the room and adjusts tone (formal vs casual, technical vs business).
6Knows when to escalate to senior PM or ODC Lead.
7Builds personal relationships beyond email (informal check-ins, follow-ups on personal mentions).

Expected outputs

Customized client status reports.
Escalation memos with proposed options.
Meeting agendas and structured follow-ups.
Client communications log.

What you would see

In a tough call (e.g., announcing a 2-week delay), the PM frames the issue, proposes options, takes the heat without deflecting. Client trusts them.

Common traps

Over-communicates — drowns client in updates.
Or under-communicates when uncomfortable about bad news.

Senior / Lead

Senior PM managing C-level client stakeholders. CEFR C1.

"I'm a senior peer to client leaders. I solve things at their level."

Manages C-level stakeholders. Brokers between conflicting client voices. Writes executive-level summaries. Negotiates without escalating.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Manages C-level steering committees	≥1 committee/quarter solo	Calendar + steering committee minutes
Executive 1-pagers authored	≥1/month with decision focus	Confluence/email exec brief archive
Resolves escalations independently	≥90% escalations closed without senior PM	Escalation log resolution column
Sustained client CSAT	≥4.5/5 over 4 quarters	Quarterly CSAT survey trend
Personal relationships with client leaders	≥2 named client leaders with 1:1 cadence	Calendar 1:1 series + CRM notes

Observable behaviors

1Manages C-level client stakeholders (VP and Director level).
2Resolves escalations independently.
3Brokers between conflicting client stakeholders (Product vs Engineering, etc.).
4Writes executive-level summaries (1-page, decision-focused).
5Has personal relationships with key client leaders.
6Negotiates dates, scope, or terms without escalating to ODC Lead.

Expected outputs

Executive briefings (1-pagers).
Documented escalation resolutions.
Senior stakeholder map with relationship status.

What you would see

In a steering committee, the PM speaks confidently to the client CTO, proposes options, and the CTO trusts the PM's framing of the trade-offs.

Common traps

Gets too close to the client — becomes their advocate against own company.
Or becomes too "company person" — client feels unheard.

Expert / Principal

Senior-most PM. CEFR C1+.

"I'm a trusted advisor. Clients ask me strategic questions, not project status."

Trusted advisor to client executives. Opens new account opportunities. Coaches other PMs.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Sets ODC client communication standards	Standards adopted by ≥80% PMs	Confluence standards + audit
Trusted advisor across client executives	≥3 unprompted client outreaches/quarter	Email/Slack inbound from client execs
Coaches PMs through tough client calls	≥3 PMs/quarter with documented coaching	Confluence coaching log
Opens new account expansion opportunities	Contributes to ≥2 expansion wins/year	Sales CRM / account expansion record
Clients seek advice on unrelated matters	≥2 unrelated advisory requests/quarter	Email/meeting notes flagged advisory

Observable behaviors

1Trusted advisor to client executives across multiple stakeholder levels.
2Opens new account opportunities through credibility.
3Coaches other PMs on client communication.
4Influences the ODC's communication standards (templates, escalation paths).

Expected outputs

Strategic client briefings.
PM client-communication coaching material.
Client comms standards for the ODC.

What you would see

Clients call this PM directly even when they're no longer on the account — to ask for advice on unrelated topics.

Common traps

Over-relied-on; becomes a bottleneck if every client wants to talk to them.
Identity wrapped in being the trusted person — struggles to step back.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Becomes 'ghost PM'; avoids interaction

Over-promises under pressure

Over- or under-communicates bad news

Gets too close to client; advocates against own co.

Over-relied-on; becomes bottleneck

Team Leadership (Daily Dynamics)

Weight ×1.5

L3 · hire bar

Aware

New PM treating leadership as task tracking.

"I track tasks and relay direction."

Reminds team of deadlines, captures action items, relays direction from above. Doesn't intervene in team dynamics.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Holds informal check-ins with sub-team members	≥1 check-in/member/2 weeks	Calendar / Confluence notes
Attends mentor PM 1:1s for leadership coaching	≥2/month	Calendar + mentor notes
Standup attendance and facilitation as observer	≥90% attendance	Calendar + standup logs
Recognizes team milestones in Slack/standup	≥1 recognition/week	Slack #team-channel review
Reflection notes filed with mentor on team dynamics	≥1/week	Confluence mentor log

Observable behaviors

1Reminds the team of deadlines.
2Captures action items.
3Relays direction from above.
4Doesn't intervene in team conflict.
5Doesn't notice morale dips.

Expected outputs

Task tracker.
Meeting follow-ups.

What you would see

Standup is mechanical. Team participates because they have to, not because the PM is leading.

Common traps

Becomes a task manager, not a leader.
Misses early signs of disengagement.

Developing

PM running small teams with reasonable mechanics.

"I run good standups and surface blockers."

Effective at meeting mechanics. Recognizes problems but doesn't always act on root causes.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
1:1s with each team member	≥1/2 weeks per member	Calendar series + 1:1 notes
Retro participation by team members	≥90% retro attendance	Retro meeting attendance log
Standup efficiency	≤15 min median duration	Calendar/standup duration logs
Surface-level conflicts mediated by PM	≥80% sub-team conflicts resolved without senior PM	Slack escalation log / retro notes
Team morale pulse tracked	≥1 pulse check/month	Pulse survey or HR tool

Observable behaviors

1Runs effective standups (focused, time-boxed).
2Surfaces team blockers and escalates.
3Handles minor conflicts ad-hoc when they boil over.
4Recognizes when the team is tired but doesn't act on it.
5Has informal 1:1s but inconsistently.

Expected outputs

Standup notes with blockers and owners.
Ad-hoc 1:1 notes (sparse).

What you would see

Standup is efficient. When a real conflict happens, the PM looks uncomfortable and tries to mediate but doesn't address root causes.

Common traps

Mediates surface conflict but doesn't address root cause.
Avoids hard feedback to keep the team comfortable.

ProficientHIRE BAR

Independent PM owning a team's daily dynamics.

"I own team morale day-to-day. I coach individuals. I create psychological safety."

Notices and acts on morale dips. Coaches juniors. Handles conflict with structure. Holds regular 1:1s.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
1:1 cadence with each direct report	≥1/2 weeks per member sustained	Calendar series + 1:1 notes archive
Mid-PMs coached per quarter	≥1 mid-PM coached/quarter with documented sessions	Confluence coaching log
Team conflicts resolved at PM level	≥90% conflicts resolved without escalation	Retro notes + escalation log
Team pulse / morale tracked monthly	≥1 pulse check/month with action items	Pulse survey + Confluence action log
Team eNPS sustained	≥40 sustained over 2+ quarters	HR engagement survey

Observable behaviors

1Owns team morale day-to-day; notices and acts on dips.
2Coaches juniors actively (gives constructive feedback weekly).
3Builds psychological safety — team raises hard things in retros.
4Handles conflict directly with structure (mediated 1:1, NVC framing).
5Holds regular 1:1s (weekly or bi-weekly) with each team member.
6Celebrates wins and recognizes effort.
7Knows each team member's motivators.
8Protects the team from external chaos (scope thrash, exec drive-bys).

Expected outputs

1:1 notes per team member on a regular cadence.
Recognition log.
Conflict resolution notes.
Team morale check-ins (formal pulse or informal).

What you would see

Retro produces real candor — the team raises hard things, the PM holds the space, and concrete actions emerge that actually get implemented.

Common traps

Avoids hard feedback to be liked.
Becomes "everyone's friend" instead of leader.

Senior / Lead

Senior PM with a high-performing team or running a recovery.

"I build culture. The team consistently outperforms peers."

Builds team culture, norms, and rituals. Leads through change. Spots and develops emerging leaders. Maintains morale under pressure.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Coaches mid-PMs on leadership behaviors	≥2 mid-PMs/quarter with documented coaching	Confluence coaching log
Team eNPS / engagement score	≥45 sustained over 4 quarters	HR engagement survey
Emerging leaders identified and developed	≥2 IDPs naming emerging leaders/year	HR IDP records
Leads team through major change (re-org, tech shift)	≥1 documented change initiative/year	Confluence change log + retro
Maintains morale during high-pressure releases	eNPS drop ≤5 points during crunch	Pulse survey before/after release

Observable behaviors

1Builds high-performing team culture (team identity, norms, rituals).
2Team consistently outperforms peers on velocity, quality, satisfaction.
3Leads through change (re-orgs, technology shifts, client changes).
4Coaches mid-PMs on leadership.
5Spots and develops emerging leaders within the team.
6Maintains morale under pressure (during recovery, scope changes).

Expected outputs

Team charter / working agreements.
Leadership coaching notes for junior PMs.
Team-of-team dashboards (if managing multiple).

What you would see

When a major change hits (client changes scope, key engineer leaves), the team adapts quickly and stays motivated — because the PM has built that adaptability into the culture.

Common traps

Hero leader — team is dependent on PM, PM doesn't develop replacements.
Culture becomes inward-looking; team feels exclusive.

Expert / Principal

Senior-most PM, shaping culture beyond their own team.

"I shape culture across multiple teams."

Sets behavioral standards for the ODC. Mentors senior PMs on leadership. Co-creates people strategy with ODC Lead and HR.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Sets ODC behavioral norms / culture playbook	≥1 norms doc adopted by ≥2 teams	Confluence norms + adoption
Mentors senior PMs on leadership	≥2 L4 PMs/quarter via documented sessions	Confluence mentorship log
Consulted on hard team dynamics across ODC	≥4 consultation requests/quarter from other PMs	Slack/email consultation log
Owns leadership curriculum / development program	≥1 curriculum, ≥5 PMs trained/year	Confluence curriculum + training log
ODC-level eNPS / engagement	≥50 sustained 4+ quarters across teams	HR engagement survey ODC level

Observable behaviors

1Shapes culture across multiple teams in the ODC.
2Sets behavioral standards for the ODC.
3Mentors other senior PMs on leadership.
4Co-creates ODC people-strategy with the ODC Lead and HR.

Expected outputs

ODC behavioral norms document.
Leadership development curriculum.

What you would see

Other senior PMs come to this person when they have a hard team-dynamics situation.

Common traps

Becomes too theoretical; loses touch with team realities.
Imposes their personal style as the universal standard.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Becomes a task manager, not leader

Avoids hard feedback to keep comfort

'Everyone's friend' instead of leader

Hero leader; team dependent on PM

Imposes personal style as universal

Technical Literacy

Weight ×1

L3 · hire bar

Aware

PM new to the technical domain.

"Tech is the team's job. I track tasks."

Knows the stack at name level. Can describe what the system does at a high level. Can't follow most technical discussions.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Can name the tech stack components in use	100% recall of project stack in mentor review	Mentor verbal check / Confluence project overview
Attends design / architecture reviews	≥80% attendance	Calendar + meeting attendance
Defers tech questions to TL with context	100% with context handoff (not blind forward)	Slack handoff review
Files learning notes after each tech session	≥1 note/week	Confluence learning log
Completes onboarding tech glossary / training	100% within 60 days of join	HR training tracker

Observable behaviors

1Knows the project tech stack at name level (React, Java, AWS).
2Can describe what the system does at high level.
3Can't follow most technical discussions in detail.
4Trusts every estimate from the Tech Lead without question.

Expected outputs

High-level project description.

What you would see

In design reviews, the PM listens but doesn't contribute. When asked a technical question by the client, they defer to the Tech Lead.

Common traps

Disengaged in technical discussions; team loses respect.
Bluffs technical understanding — engineers detect it quickly.

Developing

PM actively building technical literacy.

"I can discuss feasibility at high level."

Understands high-level architecture. Can discuss feasibility with the Tech Lead. Reads tech docs without translation.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Asks meaningful timeline / feasibility questions in design	≥3 substantive questions per design session	Meeting notes / Confluence design discussion
Reads architecture diagrams and tech docs unaided	≥90% PR/design docs reviewed without TL walkthrough	GitHub PR review log / Confluence
Knows common patterns and named NFRs	≥10 common patterns recalled in mentor review	Mentor knowledge check
Discusses feasibility at high level with client	≥80% client tech questions answered without TL	Client meeting notes
Tech reading / learning cadence	≥2 tech articles/blogs logged per month	Confluence learning log

Observable behaviors

1Understands high-level architecture (components and interactions).
2Discusses feasibility with the Tech Lead ("can we add this feature?").
3Reads tech documentation without translation help.
4Can name common patterns (REST, microservices, event-driven).

Expected outputs

Project architecture summary (1-page).

What you would see

In design review, the PM asks clarifying questions about timeline impact of decisions but doesn't yet challenge the technical reasoning.

Common traps

Bluffs deeper understanding than they have.
Asks too many basic questions in technical meetings.

ProficientHIRE BAR

Independent PM who engages credibly with engineers.

"I challenge estimates with reasons. I think about NFRs."

Challenges estimates with technical rationale. Engages meaningfully in design discussions. Understands NFRs conceptually.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Reads PR descriptions in sprint	≥90% PR descriptions reviewed within sprint	GitHub PR view log
Understands tech decisions made in sprint	≥80% tech decisions articulated in retro	Retro notes + ADR review
Can articulate the project stack end-to-end	100% stack components explained without TL aid	Mentor/Tech Lead verification
Engages in design reviews with informed input	≥2 substantive inputs per design review	Design review notes / Confluence
Tracks tech-debt items raised by team	100% tech-debt items logged within sprint	Jira tech-debt backlog

Observable behaviors

1Challenges estimates with technical rationale ("that's 8 because of integration, right?").
2Engages meaningfully in design discussions.
3Understands NFRs (performance, security, scalability) at a conceptual level.
4Can read a simple architecture diagram.
5Knows when to involve the Security or Cloud practice.
6Translates tech-to-client and client-to-tech bidirectionally.

Expected outputs

Architecture decision log (co-owned with Tech Lead).
NFR checklist for releases.
Technical risk callouts in status reports.

What you would see

In a tech review, the PM asks "what's our test strategy for the API layer? What's our fallback if the third-party SLA dips?" Engineers respect their input.

Common traps

Plays technical detective when not needed; slows decisions.
Tries to make design decisions (steps on Tech Lead's turf).

Senior / Lead

Senior PM who detects tech risk early and bridges client and ODC tech leaders.

"I bridge the client's tech leaders and our TL on trade-offs."

Detects technical risk early. Bridges client tech leaders and ODC Technical Leader on trade-offs. Holds informed conversations about tech debt.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Spots architecture trade-offs in reviews	≥1 documented trade-off insight per release	Confluence architecture review notes
Bridges client CTO and internal TL	≥1 tech alignment session/month facilitated	Calendar + meeting notes
Detects technical risk early	≥3 sprints ahead, ≥75% accuracy	Risk register vs actual
Tech-debt conversations with engineering	≥1 tech-debt review/quarter documented	Confluence tech-debt log
Client-facing technical briefings delivered	≥2/quarter solo	Calendar + client meeting notes

Observable behaviors

1Detects technical risk early (scaling issues, security gaps, scaling unknowns).
2Bridges client tech leaders and the ODC Technical Leader on trade-offs.
3Holds informed conversations about tech debt and refactoring.
4Spots architecture/quality trade-offs (e.g., monolith vs microservices for this project).

Expected outputs

Tech-debt register.
Client-facing technical briefings.

What you would see

In a 3-way conversation between client CTO and our Tech Lead, the PM mediates and proposes options that respect both sides' concerns.

Common traps

Tries to make architecture decisions (steps on Tech Lead's turf).
Becomes the de-facto architect by default — engineers stop owning architecture.

Expert / Principal

Senior-most PM with near-Tech-Lead-level technical understanding.

"I could pass as a hands-off tech lead."

Advises on tech-strategy decisions. Understands modern delivery deeply. Co-leads architecture reviews.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Co-leads architecture reviews across ODC	≥4 reviews/year as co-lead	Confluence architecture review records
Second opinion sought on hard tech decisions	≥3 consultations/quarter from PMs/TLs	Slack consultation log
Influences ODC tech hiring profile	Contributes to ≥1 hiring rubric/year	HR hiring rubric + sign-off
Advises on tech-strategy decisions to ODC Lead	≥2 strategy memos/year	Confluence strategy memo archive
Modern delivery practices adopted from PM advocacy	≥1 practice (e.g. trunk-based, observability) adopted/year	Confluence practice adoption record

Observable behaviors

1Advises on tech-strategy decisions.
2Understands modern delivery deeply (cloud, AI, DevOps).
3Co-leads architecture reviews with the Tech Lead.
4Influences tech-hiring profile for the ODC.

Expected outputs

Tech-strategy input to ODC plans.
Architecture review feedback.

What you would see

Acts as a second opinion to the Tech Lead on hard architecture decisions; consulted on tech hires.

Common traps

Forgets they're a PM, not a CTO.
Engineers feel second-guessed.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Bluffs understanding; engineers detect

Asks too many basic questions

Steps on Tech Lead's design turf

Becomes de-facto architect by default

Forgets they're a PM, not CTO

Effort Efficiency (EE)

Weight ×1

L3 · hire bar

Aware

New PM treating EE as an HR/finance concern.

"Timesheets are HR's thing."

Tracks own and team timesheets accurately. Knows what EE means. Doesn't yet monitor it.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Own timesheet accuracy	≥95% days logged on time	HR timesheet system
Team timesheet compliance tracked	≥90% team members on time weekly	HR timesheet compliance report
Asks mentor about EE concept and team baseline	≥1 EE coaching session/month	Mentor 1:1 notes
Reports actual hours vs planned at sprint end	100% sprints have actual-vs-planned recap	Sprint report / Jira
Attends EE review sessions led by senior PM	≥90% attendance	Calendar + EE session notes

Observable behaviors

1Tracks own and team timesheets accurately.
2Knows what EE means and how it is calculated.
3Doesn't monitor EE actively during the sprint.
4Sees EE as a backward-looking metric.

Expected outputs

Accurate timesheets for self and team.

What you would see

EE doesn't appear in their status reports or sprint reviews unless someone asks for it.

Common traps

Doesn't see EE as their responsibility.
Pushes timesheet discipline to HR.

Developing

PM beginning to track EE.

"I report EE weekly; I flag overruns."

Monitors EE weekly and reports actual vs planned. Raises overruns after they happen. EE typically 80–90%.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Weekly EE monitoring report	≥1/week	Confluence/email EE report
EE attainment	80-90% sustained	HR EE dashboard
Flags overrun within 1 week of occurrence	100% overruns flagged within 7 days	Slack/email vs timesheet date
Standard EE template used in status reports	≥95% reports include EE section	Status report archive
Sprint actual vs planned variance reported	Variance ≤15% reported per sprint	Jira sprint report + timesheet

Observable behaviors

1Monitors EE weekly.
2Reports actual vs planned in status.
3Raises overruns after they happen.
4EE typically lands at 80–90%.
5Doesn't yet diagnose root causes.

Expected outputs

Weekly EE report.

What you would see

PM flags an overrun at the end of the sprint and asks the team to be more efficient next sprint, without changing anything structural.

Common traps

Reactive — flags after the fact rather than acting in-sprint.
EE becomes a finger-pointing exercise.

ProficientHIRE BAR

Independent PM actively managing EE.

"I manage EE in-sprint. 90%+ consistently."

Proactively manages EE during the sprint. Anticipates overruns and acts (replan, reshuffle, descope). Consistently 90%+.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Gross margin maintained on project	Gross margin ≥35%	Finance project P&L
Team utilization rate	Utilization ≥85%	HR utilization dashboard
EE attainment sustained at hire bar	EE ≥95% sustained across last 4 sprints	HR EE dashboard trend
EE root-cause analysis on variance	100% sprints with variance >5% have RCA	Confluence EE RCA log
EE forecast vs actual accuracy	≥90% forecast accuracy across last 4 sprints	EE forecast log vs HR dashboard

Observable behaviors

1Proactively manages EE during sprint (replan, reshuffle, descope).
2Anticipates man-month overruns and acts mid-sprint.
3Consistently lands at 90%+ EE.
4Identifies root causes when EE dips (estimation accuracy, dependency, rework).

Expected outputs

Sprint EE forecast.
Mid-sprint replan when needed.
Root-cause notes when EE dips.

What you would see

At sprint midpoint, the PM has already noticed that one workstream is trending toward an overrun and has redirected a person or descoped an item.

Common traps

Optimizes for EE at the cost of quality (rushes the team, skips testing).
EE chasing — pushes team into overtime to hit the number.

Senior / Lead

Senior PM driving systemic EE improvement.

"I drive EE improvement through process. 95%+."

Drives EE improvement through process changes (better estimation, fewer dependencies, less rework). Sustains 95%+. Cross-checks against quality and morale.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
EE attainment sustained	≥97% over 4+ quarters	HR EE dashboard trend
Cross-sprint EE trend with commentary	≥1 trend analysis/release with root causes	Confluence EE analysis
Process changes driven by EE root cause	≥2 process changes (e.g. AC quality, rework reduction)/year	Confluence process change log
Cross-checks EE against quality and morale	≥1 holistic review/quarter (EE + defects + eNPS)	Confluence holistic review
Coaches mid-PMs on EE techniques	≥2 mid-PMs/quarter via documented sessions	Confluence coaching log

Observable behaviors

1Drives EE improvement through process (better estimation, fewer dependencies, less rework).
2Sustains 95%+ over multiple releases.
3Cross-checks EE against quality and morale — doesn't sacrifice either.
4Mentors juniors on EE management.

Expected outputs

EE improvement initiatives (with measured impact).
Cross-sprint EE trend with commentary.

What you would see

Quarterly review shows EE trending up by structural improvements (e.g., reduced rework via better AC), not by squeezing the team harder.

Common traps

Over-optimizes; team feels squeezed.
EE becomes the headline metric, displacing more important outcomes.

Expert / Principal

Senior-most PM setting ODC-wide EE standards.

"I set ODC EE benchmarks."

Sets EE benchmarks for the ODC. Coaches other PMs on efficiency techniques. Shapes estimation standards.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Sets ODC EE benchmarks	Benchmarks adopted by ≥80% PMs	Confluence benchmark doc + adoption
Benchmarks all teams; EE leaderboard maintained	Updated monthly, covers all ODC teams	BI/Confluence EE leaderboard
ODC EE attainment	≥95% ODC-wide sustained 4+ quarters	HR EE dashboard ODC view
Shapes estimation standards across ODC	Standards adopted, ≥2 PMs cite	Confluence estimation standards
Sets ODC timesheet hygiene standards	≥98% ODC-wide timesheet compliance	HR timesheet compliance ODC level

Observable behaviors

1Sets EE benchmarks for the ODC.
2Coaches other PMs on efficiency techniques.
3Shapes estimation standards across teams.

Expected outputs

ODC EE standards document.
Efficiency coaching material.

What you would see

Consulted when a project's EE is consistently below the ODC benchmark.

Common traps

Pushes EE as the headline metric, displacing quality and morale.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Doesn't see EE as their responsibility

Reactive; flags after the fact

EE chasing — pushes team into overtime

EE displaces more important outcomes

EE as headline metric, kills quality

People Management (Hire · Develop · Retain)

Weight ×1.5

L3 · hire bar

Aware

New PM who treats people work as HR's role.

"HR handles people."

Knows team headcount. Submits HR paperwork. Relies on ODC Lead and HR for hiring decisions.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Participates in hiring panels as observer	≥2 panels/quarter	HR interview panel log
Onboards new joiner using template	100% new joiners receive welcome doc within day 1	Confluence onboarding doc + HR record
Attends performance review prep with senior PM	100% reviews shadowed	HR review log + mentor notes
Escalates people concerns to senior PM within SLA	100% within 2 business days	Slack/email escalation timestamps
Files team observation notes with mentor	≥1/week	Confluence mentor log

Observable behaviors

1Knows team headcount.
2Submits HR paperwork.
3Relies on ODC Lead and HR for hiring.
4Doesn't yet own onboarding.

Expected outputs

Completed HR paperwork.

What you would see

When a team member is unhappy, the PM finds out from HR or the ODC Lead, not directly.

Common traps

Defers entirely to HR and ODC Lead.
Misses early signs of attrition risk.

Developing

PM with some panel and review experience.

"I join interviews and do onboarding."

Joins interview panels (fit screens). Runs basic onboarding. Runs scheduled performance reviews from template.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Joins hiring panels as fit/culture screener	≥3 panels/quarter with documented feedback	HR interview feedback record
Onboarding plan customized per joiner	≥80% joiners have personalized week-1 plan	Confluence onboarding plans
Performance review forms completed on time	100% on schedule	HR review cycle compliance
1:1 cadence with team	≥1/2 weeks per direct report	Calendar series + notes
Early-attrition flag rate	Catches ≥50% flight risks before resignation	HR attrition cause-of-leaving analysis

Observable behaviors

1Joins interview panels (fit screens, not technical).
2Does basic onboarding (welcome doc, first-week plan).
3Runs scheduled performance reviews from template.
4Doesn't yet write Individual Development Plans.

Expected outputs

Onboarding plans.
Performance review forms (completed).

What you would see

Performance review is form-filling — boxes checked, ratings assigned, but no deep conversation.

Common traps

Treats reviews as form-filling exercises.
Onboarding is template-driven, not personalized.

ProficientHIRE BAR

Independent PM owning their team's people work.

"I own my sub-team's people. Hire well. Develop them. Notice flight risks early."

Owns sub-team hiring. Runs structured monthly 1:1s. Writes IDPs. Identifies flight risks proactively.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Team retention sustained	Retention ≥90% over 4 quarters	HR retention report
Promotions supported per year	≥1 promotion supported/year with documented case	HR promotion record + IDP
Performance reviews delivered on time	100% performance reviews on schedule	HR review cycle compliance
IDPs maintained for direct reports	100% direct reports have current IDP	HR IDP records
Flight risk detection accuracy	≥75% flight risks identified before resignation	HR attrition cause-of-leaving analysis

Observable behaviors

1Owns sub-team hiring (defines profile, interviews, recommends offers).
2Runs structured monthly 1:1s with every team member.
3Writes Individual Development Plans (IDPs) for each.
4Identifies and manages flight risks proactively.
5Recognizes good performance through a structured recognition log.
6Handles underperformance directly, not by avoidance.

Expected outputs

Hiring scorecards.
Monthly 1:1 notes per team member.
Individual Development Plans.
Flight-risk log.
Recognition log.

What you would see

A team member feels demotivated — the PM has already noticed (from the weekly 1:1 cadence) and had a structured conversation before the issue becomes attrition.

Common traps

Treats 1:1 as status update; doesn't dig.
IDPs become wishlists without follow-through.

Senior / Lead

Senior PM driving calibration and succession.

"I drive calibration. I develop successors. I attract senior talent."

Drives team performance calibration. Develops succession. Attracts senior talent via network. Keeps regrettable attrition under 10%.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Attracts senior talent via personal network	≥2 senior hires sourced/year	HR sourcing channel record
Develops successors / second-in-command	≥1 named successor per role with IDP	HR succession plan
Team regrettable attrition	<10% over 4 quarters	HR attrition report
Mentors mid-PMs on people management	≥2 mid-PMs/quarter via documented coaching	Confluence coaching log
Drives team performance calibration sessions	≥1/cycle as lead	HR calibration meeting record

Observable behaviors

1Drives team performance calibration with peer PMs.
2Develops succession — the next PM or Tech Lead from within.
3Attracts senior talent through personal network.
4Keeps regrettable attrition under 10%.
5Mentors mid-PMs on people management.

Expected outputs

Performance calibration outcomes.
Succession plan.
Attrition and flight-risk dashboard.
Talent pipeline (personal network).

What you would see

When a key engineer leaves, there is already a successor in waiting because the PM had been developing that person for 12 months.

Common traps

Plays favorites; calibration becomes biased.
Develops successors but doesn't actually delegate to them.

Expert / Principal

Senior-most PM shaping ODC-wide talent.

"I shape ODC talent strategy."

Shapes ODC talent strategy. Designs career frameworks. Builds talent pipeline through community and branding.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Shapes ODC hiring brand and employer profile	≥1 brand initiative/year (talks, content, referrals)	Marketing/HR brand record
Designs career framework / leveling guides	≥1 framework adopted ODC-wide	Confluence framework + HR adoption
Key voice in promotion and re-org decisions	Consulted on ≥80% L3+ promotions	HR promotion committee record
Builds inbound talent pipeline	≥30% of senior hires via inbound/referral/year	HR sourcing channel breakdown
Consulted on contentious promotion calls	≥3 consultations/cycle from other PMs/HR	HR / Slack consultation log

Observable behaviors

1Shapes ODC talent strategy with the Head of Delivery.
2Designs career frameworks (this kind of document).
3Builds talent pipeline through community involvement and personal branding.
4Key voice in offers, promotions, and re-orgs.

Expected outputs

Career framework documents.
Hiring brand materials.
ODC people-strategy inputs.

What you would see

Speaks at industry events, attracts inbound applicants, and is the person ODC Lead consults on a contentious promotion call.

Common traps

Becomes more HR than PM; loses delivery edge.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Defers entirely to HR and ODC Lead

Reviews are form-filling exercises

1:1 as status update; IDP wishlist

Plays favorites; calibration biased

Becomes more HR than PM

Account Health (Project Level)

Weight ×2

L3 · hire bar

Aware

New PM treating client feedback as inbound.

"Feedback comes when the client gives it."

Receives feedback when given. Doesn't actively ask. Knows what CSAT and NPS are but doesn't track them.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Logs unsolicited client feedback	100% feedback logged within 1 business day	CRM/Confluence feedback log
Attends account review with senior PM	≥90% attendance	Calendar + review notes
Files account observation notes for mentor PM	≥1/week	Confluence mentor log
Forwards client comms to senior PM with context	100% sensitive comms shared same day	Slack/email forwarding trail
Completes account-context onboarding (client domain, history)	100% within 30 days of joining account	Confluence account brief + mentor sign-off

Observable behaviors

1Receives client feedback when it comes.
2Does not actively ask for feedback.
3Knows what CSAT and NPS are but does not track them.

Expected outputs

Records of unsolicited feedback.

What you would see

The PM doesn't know whether the client is happy or unhappy until something escalates.

Common traps

Treats feedback as the client's job.
Mistakes "no complaints" for "happy client".

Developing

PM with some account exposure who asks at milestones.

"I ask for feedback at milestones."

Asks for feedback at release milestones. Reports satisfaction up to ODC Lead. Recognizes obvious expansion signals.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Solicits feedback at sprint/milestone	≥1 feedback ask per milestone	Email/Confluence feedback ask record
Recognizes obvious expansion asks from client	≥80% obvious asks logged within 1 week	CRM/Confluence expansion log
Maintains informal expansion / opportunity log	Updated ≥1/month	Confluence expansion log
Reports satisfaction status to ODC Lead	≥1 satisfaction summary/month	Email/Confluence ODC report
Client CSAT baseline	≥3.5/5 (or 7/10)	Quarterly CSAT survey

Observable behaviors

1Asks for feedback at milestones.
2Reports satisfaction to the ODC Lead.
3Recognizes obvious expansion signals ("we should also add reporting...").
4Doesn't yet measure systematically.

Expected outputs

Milestone feedback summaries.
Informal expansion-signals log.

What you would see

After a release, PM sends a feedback email to the client. Response or no response, the PM moves on.

Common traps

Feedback is qualitative only — no measurement.
Doesn't follow up when feedback is ignored.

ProficientHIRE BAR

Independent PM actively managing project-level account health.

"I measure satisfaction. I spot growth. I build trust."

Measures client satisfaction at least quarterly. Builds personal trust with client product owner and dev lead. Surfaces 2–3 project-level expansion opportunities per year.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Account scope expansion per year	≥1 scope expansion closed/year on owned account	Sales/CRM expansion record
Account renewal rate	Renewal rate 100% on owned accounts	Sales renewal log
Client NPS sustained	NPS ≥40 over 2+ quarters	Quarterly NPS survey
Expansion opportunity log owned	Updated weekly, ≥3 active opportunities tracked	CRM/Confluence opportunity log
Account health report to ODC Lead	≥1 health report/month per owned account	Confluence account health archive

Observable behaviors

1Measures client satisfaction at least quarterly (CSAT or structured feedback).
2Builds personal trust with the client Product Owner / dev lead.
3Surfaces 2–3 project-level expansion opportunities per year to ODC Lead.
4Acts on negative feedback within the same cycle.

Expected outputs

Quarterly CSAT or structured feedback survey results.
Expansion-opportunity log.
Trust-building cadence (informal check-ins with key client contacts).

What you would see

Client product owner mentions wanting to add reporting features in a status call. PM logs it, follows up with ODC Lead within the day, and the ODC Lead pursues a change order.

Common traps

Treats CSAT as a metric to chase rather than a signal to act on.
Builds trust with one client contact only (single point of dependence).

Senior / Lead

Senior PM driving sustained satisfaction and project growth.

"CSAT ≥ 8/10. Client requests me by name. I co-pitch growth."

Sustains CSAT ≥ 8/10. Client requests this PM specifically. Co-pitches expansions with ODC Lead. Senses churn risk early.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Sustained CSAT high mark	≥8/10 over 4 consecutive quarters	Quarterly CSAT trend
Client requests PM by name on new work	≥2 named-request instances/year	Sales/CRM record
Co-pitches and closes expansion	≥1 expansion closed/year with PM involvement	Sales pipeline + expansion record
Senses churn risk early and escalates	≥3 sprints lead time before formal churn signal, ≥75% accuracy	Risk register vs actual churn outcome
Provides client references and case study material	≥1 reference call or case study/year	Marketing/Sales reference log

Observable behaviors

1Sustains CSAT ≥ 8/10 (or NPS ≥ 50) over multiple quarters.
2Client requests this PM specifically for new work or new phases.
3Co-pitches expansions with the ODC Lead and closes some independently.
4Provides references on request.
5Senses churn risk early — escalates before the issue becomes contract-level.

Expected outputs

Quarterly CSAT trend report.
Expansion pipeline shared with ODC Lead.
Reference and case-study materials.

What you would see

When a new SOW is being pitched, the client asks "is \[PM Name\] going to be on it?" before signing.

Common traps

Becomes the client's PM more than the company's PM (advocates for client against own org).
Over-invests in one account — bench versatility drops.

Expert / Principal

Senior-most PM, trusted partner to client execs.

"Client treats me as a trusted partner."

Trusted partner to client executives. Contributes to renewal and expansion strategy. Volunteered case studies and testimonials.

Measurable indicators(pQA verification checklist)

Indicator	Threshold	pQA source
Client volunteers unprompted testimonials	≥2 unprompted testimonials/year	Marketing/Sales testimonial log
Trusted partner to client executives	≥3 executive-initiated strategic discussions/quarter	Calendar + executive meeting notes
Contributes to renewal strategy	Authors / co-authors ≥80% renewal strategies on owned accounts	Sales renewal strategy doc
Strategic account input documented to ODC Lead	≥1 strategic memo/quarter per major account	Confluence account strategy archive
Other PMs learn this PM's client style as case study	≥2 PMs cite via training/playbook adoption/year	Confluence playbook citation + training log

Observable behaviors

1Trusted partner to client executives — consulted on broader topics.
2Contributes meaningfully to renewal and expansion strategy.
3Client volunteers case studies and testimonials unprompted.
4Other PMs in the ODC learn from this PM's client style.

Expected outputs

Volunteered case studies and testimonials.
Mentoring artifacts on client relationship.
Strategic account input to ODC Lead.

What you would see

Client invites this PM to internal client strategy sessions; references them in public talks or case studies without being asked.

Common traps

Over-investment in a single account locks the PM in place.
Identity gets wrapped in the client relationship.

Anti-signal & scoring rule3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Anti-signal · auto-disqualifies the level

Rejects

Mistakes 'no complaints' for happy client

Feedback qualitative only; no measurement

Single point of dependence with one contact

Becomes client's PM, not company's PM

Identity wrapped in client relationship

How to advance — promotion criteria

PM1PM2

Typical 18–24 months

What to demonstrate

L3 in Delivery, Client Comm, Team Leadership
L2+ in all other competencies including Account Health
Run a 6+ member sub-team for 2 consecutive sprints
Sustain EE ≥ 90% for 3 consecutive sprints

Portfolio (CORE)

3 recent weekly status reports
1 sprint plan with rationale
Mentor's written endorsement (1 page)
+ pick 2 supporting items

Verification path

1Self-assessment using the worksheet

2Submit portfolio + manager calibration

3Annual review passes with no "below expectation"

PM2PM3

Typical 24–36 months

What to demonstrate

L3 in all 9 competencies
L4 in Client Comm AND Team Leadership
L3+ in People Management
EE ≥ 92% for 6 consecutive sprints
Recovered or stabilized ≥ 1 troubled sub-team

Portfolio (CORE)

Multi-sprint release plan with milestones
1 client reference letter or testimonial
1 sprint recovery example (caught and resolved)
Self-assessment + manager calibration
+ pick 2 of 5 supporting items

Verification path

1Self-assess + manager calibration

2Submit portfolio

3ODC Lead + Head of D3 calibration review

PM3PM4

Typical 24–36 months

What to demonstrate

L4 in all 9 competencies (including Account Health)
L5 in Client Comm OR Team Leadership
Lead multi-sub-team or small ODC for 12+ months
Develop a successor (next PM3) from within team
Regrettable attrition < 10% for 12 months

Portfolio (CORE)

1 full project recovery case write-up
1 successor development plan with PM3-readiness evidence
2 client reference letters from senior stakeholders
1 expansion converted or co-pitched

Verification path

1Self-assess + multi-reviewer calibration

2Submit portfolio

3Manager + ODC Lead + Head of D3 sign-off

PM4ODC Lead

When opportunity arises

What to demonstrate

Demonstrated client trust at C-level
Track record of account growth during PM4 tenure
Successful hand-off of previous team to a successor

Portfolio (CORE)

Client C-level reference
Account growth data (revenue, headcount, scope)
Successor in role for 3+ months with stable metrics

Verification path

1ODC Lead opening or new account matched

2Pass ODC Lead assessment (separate framework)

3Head of D3 + Delivery Director sign-off

Alternative tracks — when the PM path isn't the best fit

Delivery Manager

Internal-facing. Run the inside of the engagement so a client-facing PM runs the outside.

When to consider

You freeze in front of clients but run a tight team
English is a hard ceiling, execution is strong
Your account has a separate Account Manager

Profile fit

Strong: Delivery, Risk, Team Leadership, People Mgmt (L4+)
Relaxed: Client Comm, Account Health (L2–L3 OK)

Comp parity

Same band

Reversible

Yes, 1×/18mo

Solution Architect

Technical-facing. For PMs with engineering background who prefer architecture depth over client work.

When to consider

You're drawn into design discussions and add value
Background is engineering, energized by tech
Client Comm gap is preference, not skill

Profile fit

Strong: Tech Literacy (L4+), Risk technical (L4+)
Relaxed: Client Comm, Team Leadership, People Mgmt

Comp parity

Engineering ladder

Reversible

Yes, level resets

How to move between tracks

1. Declare interest 2. 1-on-1 with supervisor 3. 1-sprint shadow + 1-sprint contribute 4. Decide within 30 days

FAQ for PM role

FAQ items will be added as questions surface from the team.

Self-assessment

Self-assess your PM level

Score yourself on each dimension and get a live radar chart of your competency profile. Scores stay in your browser — never saved or shared.