The minimum roles.
This chapter names the roles a Cadence org needs to function. It’s not a complete org chart. Specialist roles, area owners, COE leads, and program-specific positions all live above this baseline.
What’s below is the floor. Without these five roles operating well, the lanes don’t connect, the pods don’t get fed, and the maturity model has no one watching it.
The five
- 01Chief Product Owner
- 02Engineering Manager
- 03Engineers
- 04Product Owners
- 05Flow Leads
Role Nº 01
Chief Product Owner
The final decider of strategy and priority for the organization. Sits in the Align lane. Owns the question every other role eventually asks: “is this what we’re actually doing?”
What the Chief Product Owner owns
- Final say on strategy. When the org has to choose between competing directions, the Chief PO is the one who chooses.
- Final say on priority. When two pieces of work want the same time, the same pod, or the same money, the Chief PO breaks the tie.
- Subordinate role design. The Chief PO can add subordinate Product Owners (area POs, value-stream POs, scaled POs) as the org needs them. That structure is a strategic and operational call; the framework doesn’t prescribe it.
Why one role, not a committee
The Chief PO exists to prevent priority fragmentation. Committees stall. A single accountable role keeps the whole system moving even when the answer is uncomfortable. The Chief PO is supported by the rest of Align, but the buck stops at one person.
Role Nº 02
Engineering Manager
The process owner. The Chief PO owns what the org does; the Engineering Manager owns how. They’re responsible for the health of the delivery system itself, continuously inspecting and adapting it and growing the organization’s process maturity.
What the Engineering Manager owns
- Process maturity. The framework includes a maturity model for the SDLC itself (next section). The Engineering Manager tracks where the org sits on each dimension and decides where to invest.
- Cross-pod inspect & adapt. Pod-level retros surface local problems. Many of those are actually system problems. The Engineering Manager is the one spotting patterns and pulling them up to a process change.
- Coaching the Flow Leads. Flow Leads at the pod and multi-pod level need a coach. That’s the Engineering Manager’s job too.
Process maturity model.
Process maturity, sometimes called SDLC maturity, is what the Engineering Manager tracks across five dimensions. It mirrors the AI maturity model in shape: continuous tracking, no single score, and one goal, which is to know which dimension is the constraint right now.
Dimension · Nº 01
Planning & Flow
- Single-source backlog
- Prioritization discipline
- Dependency management
- Lead time, cycle time, WIP
Dimension · Nº 02
Engineering Practice
- Version control hygiene
- CI/CD maturity
- Code review standards
- Testing discipline
Dimension · Nº 03
Quality & Feedback
- Defect tracking
- DORA-style metrics
- Customer signal loops
- Escape-rate accountability
Dimension · Nº 04
Operations & Observability
- Production monitoring
- On-call discipline
- Incident response & post-mortems
- SLO / error-budget practice
Dimension · Nº 05
Learning & Adaptation
- Retro discipline
- Knowledge sharing
- Process change ownership
- Cross-pod learning channels
Dimension Nº 01
Planning & Flow
Does work enter through one ranked list? Are dependencies surfaced before they bite? Are pods finishing what they start, or piling up WIP? This dimension is about the discipline of work moving through the system, measured by lead time, cycle time, and WIP rather than velocity points.
Dimension Nº 02
Engineering Practice
Branching strategy, CI gates, code review norms, test pyramid. This is the dimension every engineering team assumes it has already maxed out, and almost none actually have. The Engineering Manager's job is to be honest about where it really sits.
Dimension Nº 03
Quality & Feedback
Defect tracking that connects bugs to features and to fixes. DORA-style metrics, measured continuously: deployment frequency, lead time, MTTR, change-fail rate. Feedback loops that actually close, where the customer reported it, the pod fixed it, and the customer knows the fix shipped.
Dimension Nº 04
Operations & Observability
Production matters, and pods run what they ship. SLOs and error budgets are real, not aspirational. Incident response is fast, post-mortems are blameless, and the learning gets captured in the signal library.
Dimension Nº 05
Learning & Adaptation
Retros that produce changes, not lists. Knowledge that crosses pod boundaries through the AI CoP and other communities of practice. A process that improves at the speed of the org's fastest learners, the same standard the AI maturity model holds.
Role Nº 03
Engineers
Engineers are the builders. They turn ideas into working software, working alongside AI agents constantly. In a Cadence org the nature of the job hasn’t changed. The skills that compound have.
Three axes of engineering excellence
A great engineer in an AI-native org operates on three axes at once. Most are deeply expert on one and competent on the other two. A few, the apex role, are senior on all three.
Axis · Nº 01
Software Engineering
The foundation. System design, code quality, testing, performance, security. Without this axis, AI just generates faster nonsense.
Axis · Nº 02
Product and domain
Knowing what to build and why. Understanding the customer, the market, the unit economics. Engineers strong here translate intent into software the business can defend.
Axis · Nº 03
AI Engineering
Working effectively with AI agents: prompt engineering, context engineering, evaluation, orchestration. The axis that used to be a nice-to-have and now isn't.
What makes a great engineer in this world
A great engineer used to be a T: deep on one stack, competent across the adjacent ones. The shape now is closer to a three-pointed star. Software engineering is still the foundation, product and domain knowledge is still what makes the work matter, and AI engineering is the third point. It’s moved from a specialization to a literacy every engineer needs.
Pods don’t need every engineer to be the apex. They need a mix: software-deep engineers paired with AI-fluent ones and a couple who can hold the product context. The cube above maps where individuals can sit. It isn’t a target each one has to hit.
What’s non-negotiable is basic fluency on all three axes. An engineer who can’t write a useful prompt or evaluate an agent’s output is about as employable as one who can’t use git.
Role Nº 04
Product Owners
Product Owners shape customer value. They make sense of the signals coming into the system and, working with AI, keep a steady stream of well-shaped potential work available for pods to commit to.
What Product Owners own
- Signal sense-making. Strategic input from Align, customer feedback, market research, operational data, financial signals. POs synthesize the noise into a picture pods can act on. (See the Signals chapter for the full taxonomy.)
- A steady stream of potential work. Pods don’t scramble for what to do next. The PO ensures there’s always more well-shaped, validated work ready than the pod can pull.
- Prioritization decisions. POs are deciders of priority, not influencers. Within their scope, the PO chooses what gets pulled next.
- Multi-pod coverage. A PO often works with several pods. The pod-to-PO ratio depends on signal volume, value-stream complexity, and pod maturity.
Decider vs. influencer: the team-level distinction
The PO doesn’t remove the need for product insight inside the pod. It just plays a different role.
Pods need a product-aware engineer on the team. That person understands the user, can shape spec details with judgment, and keeps the pod from drifting from intent. They are an influencer of priority — they push back, they raise concerns, they suggest sequencing.
The Product Owner is the decider. When the influencer and the decider disagree, the decider decides. That clarity is what keeps pods from getting paralyzed by competing perspectives.
In practice this distinction matters most under pressure. When a deadline tightens, the influencer voices concerns and helps trade off scope. The decider commits the pod to a path and owns the outcome.
Role Nº 05
Flow Leads
Flow Leads provide the operational oversight of how pods work together. They usually support several teams at once: facilitating cadence, removing impediments, coaching practice, and keeping the process honest as it scales.
What Flow Leads own
- Cadence and facilitation. Pod ceremonies, multi-pod alignments when they exist, scaled events at the right intervals. The Flow Lead keeps the rhythm.
- Impediment removal. When a pod is stuck, the Flow Lead is the one who unsticks it, directly when possible and by escalating up the right channel when not.
- Process coaching. Pods grow on the process maturity curve. Flow Leads are the on-the-ground coaches that move them up.
Especially critical in an AI transformation
Why this role matters more right now
An AI transformation is also a human one, and it carries real risk to the people inside it. Roles shift, expectations move, and identities tied to old craft get unsettled. Without someone watching for that, dashboard gains mask the burnout, disengagement, and quiet attrition underneath.
The Flow Lead is positioned to catch it. They’re close enough to the pods to feel the temperature and far enough up the system to be heard when they raise it. In a Cadence org that makes the role an early-warning system for human impact, not just a process role.
A note on this list
These five roles aren’t meant to be comprehensive. Real organizations layer specialist roles, area leadership, COE heads, and program managers on top. What’s named here is only the minimum the lanes, pods, and events need to function.