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

3–5 members. Simple scope, single workstream. Mentor-supervised.

1.8 – 2.4

PM2

Mid

6–12 members. One full sub-team run independently.

2.5 – 3.4

PM3

Senior

12–20 members. Multi-team or small ODC. Candidate for ODC Lead.

3.5 – 4.2

PM4

Principal

20–35 members. Multi-sub-team coordination. ODC Lead path.

4.3 – 5.0

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.

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).

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.

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.

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.

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.

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Sprint planning

L1: Attends; Tech Lead drives agenda

L2: Prepares and runs standard cadence

L3: Drives planning with rationale

L4: Plans 3-6 sprints with milestones

L5: Sets ODC planning playbook

Estimation & velocity

L1: Asks Tech Lead for sizing

L2: Tracks velocity as report number

L3: Uses velocity as planning baseline

L4: Rigorous calibration with seasonality

L5: Owns estimation reference library

Risk & deviation response

L1: Reports slippage upward

L2: Spots risks after they appear

L3: Spots risk 1-2 sprints out

L4: Detects failure 3+ sprints out

L5: Identifies systemic patterns across teams

Status & reporting

L1: Strict template, mechanical fill

L2: Standard reports, misses nuance

L3: Adapts reports to client preferences

L4: Engineering health metrics dashboard

L5: Cross-team executive dashboard

Process adaptation

L1: Follows existing process strictly

L2: Runs standard cadence reliably

L3: Adapts process when standard fails

L4: Tailors agile method without dogma

L5: Brings selective industry practices in

Anti-signal · auto-disqualifies the level

Rejects

L1: Becomes glorified scribe / note-taker

L2: 'Hoping' rather than planning for failure

L3: Process-worship; loses business outcome

L4: 'Hero mode' — solves all personally

L5: 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 — 3th value is your overall level. If the lowest drops more than 1 below, demote 1 level.

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

User story authoring

L1: Types up stories from BA notes

L2: Writes stories with BA's help

L3: Crisp AC; engineers don't interpret

L4: Stories tied to release outcomes

L5: Sets story standards across ODC

Change control discipline

L1: Tracks raw uncategorized log

L2: Categorizes but inconsistent enforcement

L3: Formal CR with impact assessment

L4: Complex changes; contract-aware

L5: Owns ODC change control playbook

Scope creep response

L1: Doesn't push back

L2: Spots obvious changes only

L3: Pushes back with data

L4: Detects creep 2-3 sprints out

L5: Shapes scope at SOW level

Backlog management

L1: Vague items; loose backlog

L2: Organized but has duplicates

L3: Clean, ranked, no zombies

L4: Release-level scope plan

L5: Cross-team scope dashboard

Client prioritization coaching

L1: Captures client requests verbatim

L2: Clarifies but doesn't think cost

L3: Offers trade-off options ('defer Y')

L4: Coaches must-have vs nice-to-have

L5: Mentors PMs on scope negotiation

Anti-signal · auto-disqualifies the level

Rejects

L1: Stenographer — captures words, not meaning

L2: Accepts client asks without impact check

L3: Procedural overload kills client goodwill

L4: 'Yes' person, or too rigid 'no'

L5: Over-standardizes; loses client nuance

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Risk identification horizon

L1: Reports today's blockers only

L2: Lists common risks; updates monthly

L3: Anticipates project-specific risks

L4: Anticipates strategic/client/regulatory risks

L5: Identifies systemic cross-team risks

Risk register discipline

L1: No register; daily issue log

L2: Basic log, vague 'monitor' mitigations

L3: Active register, owners, due dates

L4: Audits other PMs' registers

L5: Owns ODC risk framework

Quality gates & DoD

L1: Passes QA data through unread

L2: QA owns quality conversation

L3: Defines quality gates per release

L4: Engineering quality metrics (coverage, MTTR)

L5: Sets ODC-wide quality standards

Defect tracking & root cause

L1: No defect interpretation

L2: Defect summary in status report

L3: Tracks escape rate, root cause

L4: Crisis playbook; war-room ready

L5: Cross-team root-cause analysis

Crisis & incident response

L1: Reports issues upward

L2: Escalates when issue surfaces

L3: Holds team to Definition of Done

L4: Leads war-room, drafts client comms

L5: Handles board-level risk events

Anti-signal · auto-disqualifies the level

Rejects

L1: Lives in present — no risk horizon

L2: Log exists but doesn't update

L3: Long risk log, items unactioned

L4: Quality becomes religion; team micromanaged

L5: Theoretical modeling loses ground truth

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Client meeting presence

L1: Listens; speaks only when asked

L2: Runs standup; confident on facts

L3: Runs client meetings solo

L4: Manages C-level steering committees

L5: Trusted advisor across executives

Written communication

L1: Strict template emails

L2: Template populated, sometimes robotic

L3: Matches client format and depth

L4: Executive 1-pagers, decision-focused

L5: Sets ODC client comms standards

Hard conversations

L1: Defers complex talks to senior

L2: Defers escalations to senior PM

L3: Handles delay/defect calls directly

L4: Resolves escalations independently

L5: Coaches PMs through tough calls

Expectation management

L1: Sends status only when asked

L2: Over-promises to please client

L3: Raises concerns before client does

L4: Brokers between conflicting stakeholders

L5: Opens new account opportunities

Reading the room / subtext

L1: Misses sarcasm, indirect dissatisfaction

L2: Sticks to script; doesn't dig

L3: Adjusts tone (formal/casual, tech/biz)

L4: Personal relationships with client leaders

L5: Clients call for unrelated advice

Anti-signal · auto-disqualifies the level

Rejects

L1: Becomes 'ghost PM'; avoids interaction

L2: Over-promises under pressure

L3: Over- or under-communicates bad news

L4: Gets too close to client; advocates against own co.

L5: Over-relied-on; becomes bottleneck

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Morale & engagement

L1: Doesn't notice morale dips

L2: Notices fatigue but doesn't act

L3: Owns morale; acts on dips

L4: Maintains morale under pressure

L5: Sets ODC behavioral norms

1:1s & coaching

L1: No 1:1s; relays direction only

L2: Informal, inconsistent 1:1s

L3: Regular cadence; weekly feedback

L4: Coaches mid-PMs on leadership

L5: Mentors senior PMs on leadership

Conflict resolution

L1: Doesn't intervene in conflict

L2: Mediates surface, not root cause

L3: Structured conflict handling (NVC)

L4: Leads team through major change

L5: Consulted on hard team dynamics

Psychological safety

L1: Standup is mechanical, transactional

L2: Standup efficient but not candid

L3: Retros produce real candor

L4: Builds adaptability into culture

L5: Shapes culture across teams

Developing the team

L1: Task tracker; no development

L2: Avoids hard feedback

L3: Knows each motivator; recognizes wins

L4: Spots and develops emerging leaders

L5: Owns leadership curriculum

Anti-signal · auto-disqualifies the level

Rejects

L1: Becomes a task manager, not leader

L2: Avoids hard feedback to keep comfort

L3: 'Everyone's friend' instead of leader

L4: Hero leader; team dependent on PM

L5: Imposes personal style as universal

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Stack & system knowledge

L1: Knows stack at name level only

L2: Understands high-level architecture

L3: Reads architecture diagrams

L4: Spots architecture trade-offs

L5: Co-leads architecture reviews

Design discussion engagement

L1: Listens; doesn't contribute

L2: Asks clarifying timeline questions

L3: Engages meaningfully in design

L4: Bridges client CTO and our TL

L5: Second opinion on hard decisions

Challenging estimates technically

L1: Trusts every Tech Lead estimate

L2: Discusses feasibility at high level

L3: Challenges with technical rationale

L4: Detects technical risk early

L5: Advises on tech-strategy decisions

NFR & quality concerns

L1: Unaware of NFRs

L2: Names common patterns

L3: Understands NFRs conceptually

L4: Holds tech-debt conversations

L5: Understands modern delivery deeply

Tech-client translation

L1: Defers all tech questions

L2: Reads tech docs unaided

L3: Translates tech-client bidirectionally

L4: Client-facing technical briefings

L5: Influences ODC tech hiring profile

Anti-signal · auto-disqualifies the level

Rejects

L1: Bluffs understanding; engineers detect

L2: Asks too many basic questions

L3: Steps on Tech Lead's design turf

L4: Becomes de-facto architect by default

L5: Forgets they're a PM, not CTO

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Timesheet hygiene

L1: Tracks own/team timesheets accurately

L2: Reports actual vs planned

L3: Sprint EE forecast

L4: Cross-sprint trend with commentary

L5: Sets ODC timesheet standards

EE monitoring cadence

L1: Doesn't monitor during sprint

L2: Monitors weekly; reactive

L3: Mid-sprint forecasting

L4: Sustains 95%+ over releases

L5: Sets ODC EE benchmarks

EE attainment

L1: No EE awareness

L2: Lands 80-90%

L3: Consistently 90%+

L4: Sustains 95%+

L5: Benchmarks all teams

Root-cause diagnosis

L1: Sees EE as backward-looking

L2: Doesn't diagnose causes

L3: Identifies dependency/rework causes

L4: Process changes (better AC, less rework)

L5: Shapes estimation standards

In-sprint intervention

L1: No intervention

L2: Flags overruns after the fact

L3: Replan/reshuffle/descope mid-sprint

L4: Cross-checks quality and morale

L5: Coaches PMs on efficiency techniques

Anti-signal · auto-disqualifies the level

Rejects

L1: Doesn't see EE as their responsibility

L2: Reactive; flags after the fact

L3: EE chasing — pushes team into overtime

L4: EE displaces more important outcomes

L5: EE as headline metric, kills quality

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Hiring & interviewing

L1: Relies on HR/ODC Lead

L2: Joins panels as fit screener

L3: Owns hiring; recommends offers

L4: Attracts senior talent via network

L5: Shapes ODC hiring brand

Onboarding

L1: Doesn't own onboarding

L2: Template welcome doc

L3: Personalized first-week plan

L4: Develops successors from day one

L5: Designs career frameworks

Development & IDPs

L1: No development conversations

L2: Performance review form-filling

L3: Writes IDPs; structured 1:1s

L4: Drives team performance calibration

L5: Key voice in promotions, re-orgs

Flight risk & retention

L1: Hears about issues via HR

L2: Misses early attrition signs

L3: Manages flight risks proactively

L4: Regrettable attrition under 10%

L5: Builds inbound talent pipeline

Performance management

L1: Doesn't address performance

L2: Templated review only

L3: Handles underperformance directly

L4: Mentors mid-PMs on people mgmt

L5: Consulted on contentious promo calls

Anti-signal · auto-disqualifies the level

Rejects

L1: Defers entirely to HR and ODC Lead

L2: Reviews are form-filling exercises

L3: 1:1 as status update; IDP wishlist

L4: Plays favorites; calibration biased

L5: Becomes more HR than PM

Measurement matrix 3-of-5 majority

Dimension

L1 · Aware

L2 · Familiar

L3 · Proficient

L4 · Advanced

L5 · Expert

Feedback collection

L1: Receives only unsolicited feedback

L2: Asks at milestones

L3: Quarterly CSAT or structured

L4: Sustained CSAT >=8/10 over quarters

L5: Client volunteers testimonials unprompted

Trust & relationships

L1: No proactive relationship work

L2: Reports satisfaction up to ODC Lead

L3: Personal trust with PO and dev lead

L4: Client requests PM by name

L5: Trusted partner to client executives

Expansion / growth opportunities

L1: Doesn't notice expansion signals

L2: Recognizes obvious expansion asks

L3: Surfaces 2-3 opportunities/year

L4: Co-pitches expansions; closes some

L5: Contributes to renewal strategy

Churn / risk sensing

L1: Finds out only via escalation

L2: Doesn't follow up when feedback ignored

L3: Acts on negative feedback same cycle

L4: Senses churn risk early; escalates

L5: Strategic account input to ODC Lead

References & advocacy assets

L1: No reference work

L2: Informal expansion log

L3: Trust cadence with key contacts

L4: Provides references; case studies

L5: Other PMs learn this PM's client style

Anti-signal · auto-disqualifies the level

Rejects

L1: Mistakes 'no complaints' for happy client

L2: Feedback qualitative only; no measurement

L3: Single point of dependence with one contact

L4: Becomes client's PM, not company's PM

L5: Identity wrapped in client relationship

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.

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).

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.

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.

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.

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.

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.

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").

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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%.

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%+.

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.

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.

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.

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.

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.

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.

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%.

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.

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.

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.

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.

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.

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.

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.

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.

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.