40 chapters10 modules40 labs45-60 hours0 of 40 complete

Free flagship course · Judgment before jargon

Technical program management, made clear.

A visual, practice-first course in technical judgment, cross-team execution, program architecture, and influence without authority.

Course promise

Turn ambiguous technical outcomes spanning many teams into safe, aligned, measurable launches, and know exactly where the TPM role begins and ends.

Start with Chapter 1

A technical program manager revealing and aligning the hidden dependencies between product, engineering, security, operations, and customers

Short on time?

TL;DR: Start here

The 60-second version: A TPM integrates a complex technical outcome across teams. The role centers on dependencies, decision closure, system-level risk, evidence, and readiness, while Product, Engineering, Architecture, and specialist functions retain their legitimate decision authority.

Use this today: Write one outcome, the three cross-team seams most likely to fail, and the next material decision that still lacks a named decider, deadline, or evidence standard.

Watch for: A green dashboard while teams hold incompatible assumptions, dependencies have no acceptance criteria, or leaders cannot name who accepts residual risk.

Worth the deeper read: The most useful TPM boundary is not a title description. It is a decision system that makes ownership, evidence, consequences, and escalation explicit.

A TPM does not own every decision. A great TPM makes the whole decision system work.

Technical Program Management is often explained badly. One description turns the TPM into a project manager who attends engineering meetings. Another turns the TPM into a substitute architect, product leader, engineering manager, and executive, all at once. Both descriptions create confusion because they start with activities: meetings, roadmaps, dashboards, requirements, and status reports.

This course starts with accountability.

A Technical Program Manager integrates a complex technical outcome across teams. The TPM combines program-level benefits and governance with enough technical judgment to expose dependencies, challenge assumptions, drive decisions, manage system-level risk, and establish delivery and operational readiness, usually without direct authority.

That is a center of gravity, not a universal job description. Titles change between companies, domains, and levels. A platform TPM, hardware TPM, security TPM, and AI TPM may spend their days differently. What survives those variations is the need to keep four kinds of truth connected: the outcome, the technical system, the execution system, and the human decision system.

flowchart TB O["Outcome truth customer value, benefits, success"] T["Technical truth architecture, interfaces, constraints"] E["Execution truth dependencies, sequence, readiness"] H["Human truth owners, incentives, decisions, trust"] P(("Integrated program outcome")) O <--> P T <--> P E <--> P H <--> P

This Four-Truth Model is an original course framework, not an industry standard. Use it as a diagnostic: if a program looks green while one truth is missing, the color is not trustworthy.

Everyday TPM: use the course on Monday morning

The course covers the strategic and technical depth of the role, but it is designed to pay off in ordinary work: preparing a review, following up on a dependency, writing a status update, negotiating capacity, handling disagreement, or deciding whether a launch is actually ready. Start with the moment you are facing.

Everyday moment	Practical move	Go to
A leader gives you a vague, urgent ask	Separate the desired outcome from the requested output; draft a one-page charter	Chapters 1, 4, and 13
Weekly planning feels like forty unrelated tasks	Group work by outcomes, interfaces, and dependency sequence	Chapters 14, 15, and 17
A dependency keeps slipping	Name the interface commitment, acceptance evidence, consequence, owner, and escalation date	Chapters 15, 18, and 24
Status meetings consume time but close nothing	Separate working, technical, and executive reviews; end each with decisions and owned actions	Chapters 16 and 19
Product and Engineering disagree	Clarify decision rights, surface interests and trade-offs, then record the decision and dissent	Chapters 3, 10, and 23
A team says it lacks capacity	Compare explicit scope, sequence, staffing, and risk scenarios instead of inventing a commitment for the team	Chapters 3, 17, and 21
You need to write the weekly update	Report outcome evidence, material changes, confidence, risks, decisions needed, and the next proof point	Chapters 17, 20, and 24
The launch date is close	Replace checklist confidence with traceable readiness, rollback, operations, and residual-risk evidence	Chapters 25 and 26
Bad news appears late	Use a non-defensive response protocol, stabilize harm, separate facts from inference, and close the loop	Chapters 22 and 27
An AI proposal sounds impressive but vague	Map data, model, tools, permissions, evaluation, human oversight, monitoring, and kill paths	Chapters 33 through 36
You inherit or hand off a program	Rebuild the local charter, system context, decision history, mechanisms, and remaining uncertainty	Chapters 4, 5, and 38

This is not a universal weekly calendar. It is a field guide for selecting the smallest mechanism that improves the next real decision.

A practical operating rhythm, adapted to your context

Cadence	What the TPM is trying to learn or change	Lightweight technique
Daily signal scan	What changed, what is newly blocked, and what now needs a decision	Review material changes, aging decisions, risky handoffs, and promised follow-ups; ignore activity that does not alter an outcome
Before a meeting or 1:1	What alignment or evidence is needed before the group spends time together	Pre-wire the owner, clarify the decision, collect dissent, and send the smallest useful pre-read
After a meeting	Whether anything actually moved	Record the decision, rationale, owner, due date, evidence, dissent, and communication audience
Weekly integration reset	Whether the roadmap, dependencies, confidence, risks, and stakeholder messages still agree	Refresh the Everyday TPM cockpit, then publish a short evidence-based update
Monthly or at a phase boundary	Whether the program should continue, reshape, pause, or stop	Revisit benefits, counter-metrics, capacity, decision rights, readiness, and invalidating assumptions

The rhythm is intentionally small. A TPM should not turn every signal into a meeting or every follow-up into a new document.

What you will be able to do

By the end, you will be able to:

distinguish a project deliverable from a program outcome and benefit;
explain what makes program management technical without pretending the TPM
must be the deepest engineer in every room;
map decision rights among Product, Engineering Management, Tech Leads,
Architecture, Project/Program Management, Scrum, Chief of Staff, and TPM;
read a system context, trace requests and data, and locate risky interfaces;
ask engineering questions that reveal constraints, uncertainty, trade-offs,
maturity, and operational consequences;
turn ambiguity into an outcome map, charter, workstreams, interface contracts,
owners, dependencies, milestones, and governance;
run risks, decisions, changes, metrics, working reviews, technical reviews, and
executive reviews as one coherent operating system;
influence without authority through incentives, candor, trust, productive
conflict, negotiation, clear writing, and clean escalation;
lead reliable, secure, operable launches and coordinate incidents without
replacing the specialists who own engineering, security, privacy, or operations;
adapt the operating model to zero-to-one, migration, platform, hardware,
vendor, global, reliability, compliance, and organizational programs;
govern AI and agentic programs using evaluation, permissions, human oversight,
security, observability, and kill paths; and
operate at Senior and Principal level by connecting programs to strategy,
building mechanisms, recovering failing work, and defending a launch decision.

The role boundary in one view

The table below describes common centers of gravity. It is a conversation starter, not a weapon. Your company may explicitly assign different decision rights.

Role	Default question	Typical center of ownership	TPM relationship
Product Manager	What and why?	Customer problem, vision, priority, value	Make the chosen direction executable; do not silently reprioritize the product
Engineering Manager	Who and with what capability?	People, team health, capacity, engineering environment	Integrate commitments; do not manage another leader's people through a plan
Tech Lead / Architect	How should it work?	Detailed design, technical direction, engineering quality	Ensure decisions happen and consequences are visible; do not seize design authority
Project Manager	How and when will a defined deliverable complete?	Scope, plan, resources, milestones, delivery control	Add system-level technical integration where the work demands it
Program Manager	How do related efforts produce strategic benefits?	Benefits, governance, cross-project coordination	Add technical judgment, interfaces, engineering risk, and readiness
Scrum Master	How can this team use Scrum effectively?	Facilitation, coaching, team process, impediments	Coordinate across teams and methods; do not reduce the program to ceremony
Chief of Staff	How can the executive's agenda move?	Executive leverage, planning, communication, special initiatives	Own the technical program outcome, not the executive's entire operating agenda
TPM	How does this technical outcome come together across boundaries?	Integration, dependencies, decision closure, system risk, governance, readiness	Clarify boundaries and make the full decision system work

Current Amazon TPM interview guidance explicitly evaluates both technical and program-management dimensions. Current Google TPM descriptions emphasize technical expertise, multidisciplinary end-to-end work, risks, schedules, and trade-offs. PMI distinguishes program benefits from project deliverables. Those sources support the course's center of gravity; none proves that every employer uses the title identically.

Choose your route

You do not need forty chapters before receiving value.

Route	Time	Chapters	Outcome
Role clarity	90 minutes	1–3	Explain the TPM difference and stop role collisions
Fast Path	4–6 hours	1, 2, 3, 5, 9, 13, 15, 21, 25, 30, 34, 40	Diagnose a program, ask better questions, and defend a plan
Working TPM	20–30 hours	Modules 1–7 plus one topology and one AI chapter	Run a complex program with reliable mechanisms
Mastery Path	45–60 hours	All chapters, work products, simulations, and capstone	Build evidence of Senior/Principal-level judgment

Fast does not mean superficial. It means fewer carefully chosen decisions. Return to the Mastery Path when a real program makes a chapter relevant.

Three programs will grow with you

The course uses synthetic cases so the work is realistic without exposing customer, company, or confidential information.

Meridian Pay

A marketplace must migrate a monolithic payment system to regional services without double charging, losing settlement records, breaking compliance, or taking a global outage. Product wants speed, Finance wants reconciliation, Security wants new controls, and engineers disagree about the cutover.

Helios Support

A company wants a generative-AI support system that retrieves policy, reads account data, and sometimes proposes protected actions. The model can be confidently wrong; retrieved text can be hostile; regional privacy rules differ; leaders want a launch date before evaluation thresholds exist.

Northstar Devices

A hardware-software product is launching across regions. Firmware, mobile apps, cloud services, factory tests, certifications, suppliers, logistics, and support training must converge. Then a severe field incident appears during rollout.

flowchart LR L["Learn a TPM decision"] --> M["Apply to Meridian Pay"] M --> H["Contrast with Helios Support"] H --> N["Transfer to Northstar Devices"] N --> R["Retrieve after delay"] R --> L2["Use at a harder level"]

Interleaving prevents a common learning failure: memorizing one template and calling it judgment. Migration, AI, and hardware programs share principles but expose different failure modes.

How the learning system works

Reading produces familiarity. TPM performance requires retrieval, discrimination, transfer, and action under ambiguity. Every chapter therefore follows the same loop:

Predict → See → Explain → Decide → Practice → Retrieve → Revisit.

Prediction: commit before the explanation so your current model becomes visible.
Purposeful visuals: see relationships that prose hides: interfaces, dependencies,
feedback loops, decision rights, and failure propagation.
Worked-example fading: inspect one full solution, complete a guided version,
then solve independently.
Decision-rights practice: answer “Who owns this decision?” without turning
collaboration into ownership fog.
Hidden model answers: produce your answer before opening the rubric.
Retrieval practice: recall from memory instead of merely rereading.
Spacing: revisit after time has made recall effortful.
Interleaving: distinguish neighboring roles and program patterns.
Work products: leave with artifacts you can adapt, not only concepts you can name.

The design draws on evidence for retrieval practice, distributed practice, worked examples, and corrective feedback. The studies do not guarantee a particular learner's outcome; they support the choice to make practice effortful, spaced, and feedback-rich.

The confidence rule

At each retrieval checkpoint, score your answer:

0: no usable answer;
1: a guess or slogan;
2: partly right but missing a boundary or consequence;
3: correct, specific, and defensible;
4: correct, quick, transferable, and able to survive a challenge.

High confidence plus a wrong answer is the most valuable signal in the course. It reveals a model that needs repair.

Your program evidence pack

Across forty chapters you will assemble:

a local TPM charter and decision-rights map;
a system context and request trace;
a requirements, constraints, and assumptions register;
an alternatives and trade-off record;
an outcome and benefits map;
an integrated roadmap and dependency graph;
RAID, change, configuration, and decision logs;
working, technical, and executive review formats;
outcome, flow, quality, and program-health measures;
launch, operational-readiness, security, privacy, and rollback evidence;
an AI evaluation and human-oversight plan; and
a capstone recommendation and defense.

Templates are deliberately plain. A beautiful dashboard cannot rescue a weak decision. Build the information system first; style it only after the signal is sound.

Open the copyable TPM Workplace Toolkit

Evidence discipline

The course separates five kinds of support:

Standards and regulatory guidance describe accepted or required practices.
Empirical research reports observations under particular methods and contexts.
Named-company practice shows how one organization frames work.
Expert interpretation synthesizes experience and evidence.
Context-dependent recommendation is advice that must be tested locally.

You will see explicit qualifiers because TPM work punishes false certainty. A DORA association is not automatically a causal law. A current job description is not a global role constitution. A framework is not a substitute for the judgment that selects, adapts, or rejects it.

What this course will not teach

It will not teach meeting volume as leadership, color-coded status as truth, process as a substitute for accountability, escalation as punishment, architecture theater, or the idea that a TPM is “the only role that matters.” It will not tell non-engineers to bluff technical depth. It will teach you to make uncertainty visible, ask precise questions, preserve specialist ownership, close decisions, and connect consequences.

It also will not promise that one artifact or personality type works everywhere. Introversion and extroversion are not TPM castes. Empathy does not mean avoiding hard calls. Psychological safety does not mean comfort or absence of standards. Influence without authority is not manipulation; it is the disciplined construction of shared context, credible commitments, and legitimate decisions.

Graduation standard

Page completion is not mastery. You graduate when you can defend:

the outcome and why a program is the right unit of work;
the role charter and decision rights;
the system boundary, key interfaces, and quality attributes;
the chosen alternative and rejected alternatives;
the integrated plan, dependencies, uncertainty, and confidence;
launch, operational, security, privacy, and rollback evidence;
the communication and escalation system;
the measures that will reveal benefit or harm; and
the residual risks that remain after reasonable controls.

Start with Chapter 1. Save your first answers. In Chapter 40 you will revisit them and see whether your work has changed from “manage the plan” to “architect the outcome.”