Figures & Tables

Every figure and table from Profitable Engineering, organized by chapter. If the narration references a visual, it's here.

Listening on Audible? The full companion PDF is also included with your audiobook in the Audible app.

Chapter 1 — The Cost Center Paradox

Chapter 1 · Figure 1.1

The Watermelon Effect

Chapter 1 · Figure 1.2

The CapEx vs. OpEx Trap

Figure 1.2 — CapEx vs. OpEx: The Factory vs. the Flow. On the left, a factory represents a CapEx asset built with a large upfront investment (depreciation) and periodic maintenance (OpEx). On the right, an infinity loop represents software flow with continuous investment (subscription/cloud). — Figure 1.2. CapEx vs. OpEx: The Factory vs. the Flow. AI-assisted illustration.

Chapter 2 — The Legacy Mirror

Chapter 2 · CAMVID Change Assessment

CAMVID Change Assessment

CAMVID Change Assessment
Dimension	Low-Impact Change	High-Impact Change
Cultural	Renaming roles or teams without mindset shift	Embracing autonomy, continuous learning, psychological safety
Architectural	Installing tools (CI/CD, dashboards)	Redesigning systems for modularity, speed, and ownership
Managerial	PMO-led Agile, top-down control	Flattened orgs, distributed decision-making, span of control redefined
Value-Oriented	Measuring features or output	Shifting to outcome-driven prioritization and business value alignment
Individual	Training in isolation, no role evolution	Redefining roles, enabling career growth in new delivery models
Delivery Model	New processes layered on old project model	Moving to continuous flow, product operating model, team topologies

CAMVID Change Assessment

Chapter 2 · Figure 2.1

The CAMVID Maturity Diagnostic Model

Chapter 3 — Practices That Drive Profitability

Chapter 3 · Figure 3.1

The Tuckman Cycle

Chapter 3 · Figure 3.2

Current State Flow of Value

Figure 3.2 — A current-state value stream map showing work flowing through stages — Decision & Approval, Backlog, Iteration Planning, Development (with Code Review), Build & Deploy, QA Testing, and Deploy — annotated with wait times between steps and bottlenecks A, B, and C marked along the flow. — Figure 3.2: Visualizing the Flow of Value. A Current State

Chapter 3 · Figure 3.3

The Dual Engine of Performance

Chapter 3 · Leadership Reflex vs. Leadership Discipline (Self-Assessment)

Leadership Reflex vs. Leadership Discipline (Self-Assessment)

Leadership Reflex vs. Leadership Discipline (Self-Assessment)
Practice	The Legacy Reflex	The Leadership Discipline
Funding	Revert to annual project cycles; restart work every year.	Protect continuous investment; let teams compound value over time.
Stable Teams	Reshuffle for deadlines; reset learning curves.	Defend long-lived, outcome-aligned teams that accelerate profitability.
Metrics	Default to outputs (velocity, feature counts).	Insist on outcomes, even rough ones; connect investment to ROI.
Team Experience (or DevEx)	Cut budgets first under cost pressure; treat sentiment as “soft.”	Treat DevEx and sentiment as profitability levers and focus on early-warning indicators.
Flow + Realization	Focus only on speed (how fast?) or only on outcomes (what value?).	Demand both; profitability requires speed and impact together.
Capacity & Focus	Treat every request as a priority; overload teams.	Enforce trade-offs; prioritize by customer or business outcomes, Flow, and capacity.

Leadership Reflex vs. Leadership Discipline (Self-Assessment)

Chapter 4 — Metrics That Matter: Measuring Flow, Predictability, and Outcomes

Chapter 4 · Figure 4.1

Forecasting Software Delivery

Chapter 4 · Figure 4.2

The Shift to Value

Figure 4.2 — Shifting from Outputs to Outcomes: an arrow labeled 'shift focus' moves measurement from Outputs (features, activity, story points, velocity) to Outcomes (business value, revenue, retention, customer impact). — Figure 4.2: The Shift to Value. Moving the organization’s focus from Activity (Outputs) to Business Value (Outcomes) requires a fundamental shift in measurement.

Chapter 4 · Figure 4.3

The Scope of Measurement

Figure 4.3 — Digital product workflow stages (Discovery, Delivery, Operation, Support) from concept/idea to cash/value, with brackets showing that DORA and DX Core 4 metrics and SEI platforms cover primarily the Delivery stage, while Value Stream Management (VSM) platforms span the broader lifecycle from idea to value. — Figure 4.3: The Scope of Measurement. As of this publication, DORA, DX Core 4, and many Software Engineering Intelligence (SEI) platforms are primarily centered on delivery-stage performance, while Value Stream Management (VSM) platforms are designed to span a broader lifecycle from idea to value.

Chapter 4 · Figure 4.4

Outcome Lifecycle for a Major Initiative

Figure 4.4 — Epic Outcome Process Flow: Epic Created → Anticipated Outcome Documented → Linked to Key Result (OKR/Goal) → Work Executed → Outcome Assessed Post-Delivery → Feedback: Adjust Priorities/Strategy. — Figure 4.4: Outcome lifecycle for a major initiative. To prevent feature-factory behavior, each initiative should begin with a documented anticipated outcome and end with an assessment of actual realization.

Chapter 5 — Redefining Product Operating Models

Chapter 5 · Figure 5.1

The Flow → Realization System

Figure 5.1 — The Flow to Realization System, showing layers from User Needs, System Architecture, Delivery Disciplines, System Visibility, Flow, and Realization (Outcomes), with the progression: understand the system, make work visible, improve flow, realize value. — Figure 5.1: The Flow Realization System

Chapter 5 · Table 5.1

Contrasting Models of Work

Table 5.1—Contrasting Models of Work
Dimension	Project Thinking	Product Thinking	Value Stream Thinking
Funding	Annual, tied to scope and deliverables	Continuous, tied to teams and outcomes (aspirational)	Continuous across domains, aligned to flow
Team Structure	Temporary, disbanded post-project	Persistent teams own outcomes	Teams aligned end-to-end across the value stream
Success Measure	On-time, on-budget delivery	Customer and business outcomes	Flow efficiency + outcome realization
Leadership Reflex	Move people to work	Give teams autonomy within domains	Protect flow, invest in reducing constraints

Table 5.1—Contrasting Models of Work

Chapter 5 · Figure 5.2

The Price of Alignment

Figure 5.2 — Before: Company A has three self-managed, cross-functional teams (Teams A, B, and C, each with three or four engineers plus QA and Agile roles) owning separate product portfolios and subdomains. After (acquirer model): a single larger pool/team of ten engineers managed by an engineering manager with mixed subdomains. — Figure 5.2: The Price of Alignment. Consolidating teams for organizational symmetry often breaks the architectural flow, illustrating Conway’s Law in reverse.

Chapter 5 · Table 5.2

Project Budgeting vs. Product Funding

Table 5.2—Project Budgeting vs. Product Funding
Dimension	Project Budgeting	Product Funding (Aspirational)
Cycle	Annual cycles, rigid approvals	Continuous investment in long-lived cross-functional teams
Investment Basis	Funds tied to deliverables	Funds tied to business outcomes
Justification	Business cases for fixed outputs	Investment cases for domains and learning

Table 5.2—Project Budgeting vs. Product Funding

Chapter 5 · Leadership Reflex vs. Discipline (Operating Model Edition)

Leadership Reflex vs. Discipline (Operating Model Edition)

Leadership Reflex vs. Discipline (Operating Model Edition)
Practice	Leadership Reflex	Leadership Discipline
Team Allocation	Redeploy teams or team members across products to chase capacity	“Keep teams intact, move work to them”
Funding	Annual resets tied to scope	Continuous investment tied to outcomes
Measurement	Activity and deadlines	Flow + outcomes + sentiment
Governance	Milestone reviews	Ongoing feedback and learning loops

Leadership Reflex vs. Discipline (Operating Model Edition)

Chapter 6 — A New Way to Look at Leadership

Chapter 6 · Leadership Reflex vs. Leadership Discipline

Leadership Reflex vs. Leadership Discipline

Leadership Reflex vs. Leadership Discipline
Domain	Reflex (Legacy Pattern)	Discipline (Modern Pattern)
Team Integrity	Redeploy team members or entire teams to chase capacity; treat them as interchangeable.	Protect long-lived, domain-aligned teams. Default to stable teams and move work into them. If cross-stream help is required, keep contributions bounded, time-boxed, and explicit. Quality and defect ownership always flows back to the original value stream.
Measurement	Ask for story points and deadlines to “prove” progress.	Hold the line on anticipated outcomes and Flow. Use sentiment as an early warning.
Governance	Milestone theater; approvals as control.	Frequent, lightweight reviews tied to outcomes and risk. Leaders remove friction, not add gates.
Funding	Annual resets push work back into projects (current reality).	Continuous, domain-based investment (explicitly aspirational for us).
Language	“Resources,” “utilization,” “velocity targets.”	People, outcomes, Flow. Teams deliver, not individuals.

Leadership Reflex vs. Leadership Discipline

Chapter 6 · Leadership Reflex vs. Leadership Discipline (Five Triggers)

Leadership Reflex vs. Leadership Discipline (Five Triggers)

Leadership Reflex vs. Leadership Discipline (Five Triggers)
Domain	Reflex (Legacy Pattern)	Discipline (Modern Pattern)
Control Reflex (Authority Over Information)	Centralize decisions, add approvals, and tighten gates “until things stabilize.”	Move authority to the information. Use guardrails to keep work safe, not gates to slow it down. Keep accountability close to the teams doing the work.
Funding Reset Gravity (Projects Rebranded as Products)	Annual resets force work back into scope, milestones, and short-term delivery commitments.	Invest in products through stable teams. Preserve continuity so ownership, learning, and outcomes compound rather than restart every cycle.
Metric Weaponization (Measurement Becomes Surveillance)	Turn metrics into scorecards for ranking, comparison, and punishment; teams optimize optics.	Treat metrics as steering signals and early warnings. Protect psychological safety so the system can tell the truth. Compare teams to their past selves, not to each other.
Decision Latency (Work Waits on Leadership)	Let tradeoffs stall, decisions drift, and priorities churn; teams wait and dependencies pile up.	Clarify decision rights and make tradeoffs explicit. Reduce decision latency by bringing decisions closer to the work and reviewing them frequently against outcomes.
Culture Discounting (Trust Treated as “Soft”)	Defer trust, DevEx, and team health until “after we deliver,” then wonder why performance is brittle.	Treat culture and DevEx as constraints on Flow. Invest early, protect feedback loops, and address engagement drops like production incidents.

Leadership Reflex vs. Leadership Discipline (Five Triggers)

Chapter 7 — Overcoming Barriers to Strategic Alignment

Chapter 7 · Figure 7.1

Connecting Strategy to Team Outcomes

Figure 7.1 — Three flight levels connecting strategy to teams: Flight Level 3 (Strategy) holds the organization's vision and strategic objectives with key results; Flight Level 2 (Coordination) cascades objectives and key results through divisions such as Sales, Marketing, Support, Product, and Engineering & Operations; Flight Level 1 (Operational) shows team-level objectives, with goals and anticipated outcomes flowing between levels. — Figure 7.1. Connecting strategy to team outcomes through the middle layer. Author illustration based on the Flight Levels model described by Klaus Leopold and Siegfried Kaltenecker. This illustration shows how strategic objectives and key results can cascade through divisions into team-level objectives. In this model, a division-level key result can become the basis for an operational team’s objective, helping product owners and teams define the anticipated outcome of the work more clearly.

Chapter 8 — Investing in People & Culture for High-Performing Teams

Chapter 8 · Figure 8.1

The Developer Experience Equation

Chapter 8 · Figure 8.2

The Change J-Curve

Chapter 9 — The Business–Technology Connection

Chapter 9 · Figure 9.1

From Flow to Realization

Figure 9.1 — Goal: value and fast flow. A product operating model spans Delivery Operations (Flow Efficiency) and Product Operations (Outcomes and Impact, Realization), with Value Stream Management running underneath from idea to value: Flow (flow efficiency) on one side and Realization (outcome) on the other. — Figure 9.1: From Flow to Realization. To speak the language of business, we must connect operational efficiency (Flow) directly to market outcomes (Realization).

Chapter 9 · Figure 9.2

Closing the Loop from Flow to Realization

Figure 9.2 — A circular loop of seven steps: Idea, Design, Build, Deploy, Operate, Outcome, and Learn/Improve, with Flow driving the first half and Realization the second, and Measure at the center connecting both. — Figure 9.2: Closing the Loop from Flow to Realization

Chapter 9 · Figure 9.3

The Hierarchy of Flow

Chapter 9 · Figure 9.4

The Feature Factory Ratio

Chapter 9 · Table 9.1

Traditional IT Management vs. Value Stream Thinking

Table 9.1: Traditional IT Management vs. Value Stream Thinking
Traditional IT Management	Value Stream Thinking
Focus on cost and activity	Focus on value and outcomes
Project funding with milestones	Product funding with steady outcomes
Success measured by scope and dates	Success measured by changes in growth, efficiency, and risk
Siloed roles and handoffs	Cross-functional teams aligned to a value stream
Governance by status reports	Governance by decisions and constraint removal

Table 9.1: Traditional IT Management vs. Value Stream Thinking

Chapter 9 · Table 9.2

Traditional IT Metrics vs. Outcome-Driven Metrics

Table 9.2: Traditional IT Metrics vs. Outcome-Driven Metrics
Traditional IT Metrics	Outcome-Driven Metrics
Number of deployments	Measured change in retention, expansion, or conversion
Feature completion rates	Reduction in cost to serve on a target workflow
Sprint velocity	Competitive position or customer satisfaction tied to a change
Cost reduction totals	Value delivered to users and the economics attached to it

Table 9.2: Traditional IT Metrics vs. Outcome-Driven Metrics