How to get hired as a technical program manager in 2026-27

Technical program manager, and the five titles it gets confused with

A technical program manager is accountable for landing a technical program. The working definition, and the one that decides whether a posting is really this job: engineering work that crosses more than one team, has a date that somebody outside those teams is counting on, and contains at least one dependency the TPM cannot order into existence. The deliverable is a changed production system, a completed migration, a shipped device, a passed audit. It is not a document, although you will write a great many of them.

The title confusion is not pedantry, it decides which resume you send. A product manager owns what gets built and why. An engineering manager owns the people and the technical quality of their output. A project manager in a tech org usually owns a bounded scope against a schedule and is often not expected to argue technically. A non-technical program manager owns a portfolio of related work, frequently in operations, marketing or go-to-market. A scrum master owns one team's process. And there is a historical trap: at Microsoft, 'Program Manager' for many years meant what the rest of the industry calls a product manager, so older Microsoft resumes and longer-tenured Microsoft people use the word differently. Microsoft has since moved most of that work to the Product Manager title, but the ambiguity survives in both directions. Read the posting's deliverables and its nouns, never its title.

The abbreviation itself is overloaded. 'TPM' in a posting can mean technical program manager, technical product manager (a genuinely different job, closer to product), technical project manager, or in risk and procurement functions, third-party management. In hardware and security documents TPM also means Trusted Platform Module, which is why keyword searches return noise. Two paragraphs into a job description you will know which one you are reading. If you cannot tell, ask the recruiter what the person is accountable for when a date slips. The answer separates them instantly.

TPM is also not one job across employers. The specializations below ask for different technical vocabulary, different artefacts and different evidence, and they are not interchangeable on a resume. Pick the one you can be interrogated about and write for it.

• Infrastructure and cloud: region builds, capacity planning, network, datacenter and power, large migrations, cost reduction. Vocabulary is distributed systems and operations.
• Data, ML and AI: pipelines and backfills, training and evaluation infrastructure, accelerator capacity, model release and deprecation, inference cost. The fastest-growing variant in this window.
• Hardware and new product introduction (NPI): the EVT, DVT and PVT gates through mass production and ramp, bill of materials, suppliers, tooling, certification and test. A slipped date here costs tooling money, which makes schedule discipline unusually literal.
• Security, privacy and compliance: SOC 2 and ISO 27001 audits, FedRAMP authorization, PCI DSS, penetration test remediation, vulnerability SLAs, GDPR and now EU AI Act obligations. The program is evidence collection and engineering remediation on a deadline set by someone else.
• Platform and developer productivity: build and CI health, large-scale code migrations, framework and language upgrades, deprecations, SDK versioning. Judged on long-tail completion, which is the hardest thing in this discipline.
• Product-facing launch and release: cross-team feature launches, staged rollouts, launch readiness review, the dependencies on marketing, legal, support and sales. Closest to product management and the variant most often cut when headcount tightens.

How TPM hiring actually works in 2026-27

The first screen is usually a technical recruiter working against an internal level guide, not a hiring manager. At large tech companies that guide is explicit about scope: how many teams, what organizational distance, whether you influenced a roadmap or executed one. This is why resumes without numbers fail here specifically. The recruiter is trying to decide whether you are a 'senior' or a 'staff' before anyone technical reads a word, and 'coordinated delivery across nine teams, roughly 120 engineers, four orgs, 14 months' answers that question in one line.

The hiring manager is typically a TPM lead, a director of engineering, or at a smaller company the VP of Engineering or CTO directly. That conversation is mostly one thing: pick a program and walk me through it. Expect to be stopped and pushed. Where did the date come from. Who disagreed with you. What did you cut. What did you get wrong. A candidate who narrates a clean success with no decisions in it reads as someone who was near a program rather than accountable for one.

The middle of the loop splits into two tracks that people prepare for unevenly. One tests technical understanding, covered in detail in the next section. The other tests execution: a scenario, usually delivered verbally, in which something slips and someone important wants the date held. Candidates from an engineering background tend to over-prepare the first and under-prepare the second; candidates from project management do the reverse, and the reverse is the more common rejection.

Company shapes worth knowing before you walk in. Amazon runs its Leadership Principles hard, includes a bar raiser, and weights written communication heavily; TPM candidates there are routinely asked for narrative, specific answers and sometimes a written exercise, and vague verbal answers that would pass elsewhere fail. Google's TPM loops are not coding interviews, decisions go to a hiring committee that reads written feedback rather than meeting you, and an approved candidate then goes through team matching, which means you can sit approved and unmatched for weeks. Meta grades execution and cross-functional partnership as separate signals. Enterprise IT and consulting loops look more like project management hiring: a panel, more process vocabulary, and the PMP appearing as a filter. Series B to D startups run three or four conversations fast, and the real question is whether you will also absorb the product work, release management and vendor management, which you should ask about directly rather than discover in month two.

A written or presented exercise has become common. Typical forms: here is a two-page brief, send us a program charter and the first weekly update; or, present your first 60 days on this program to three people. The scoring is not polish. It is whether you asked clarifying questions before producing anything, whether your assumptions are written down and labeled as assumptions, whether the risks are specific to this program rather than a generic list, and whether the first three lines of the status update tell a busy executive something they can act on.

One structural fact about this market worth acting on: TPM roles are filled internally or by referral more often than most, because the hiring manager is usually trying to replace a specific kind of judgment and would rather have someone a trusted engineer vouches for. The practical consequence is that applying cold to a two-week-old posting is the weakest available move. The stronger moves are being internal, being referred by an engineer or an existing TPM, and going in through a contract or agency TPM role at the company you want.

• Bring sanitized artefacts: a one-page program charter, a dependency map with the critical path marked, a RAID or risk log, a launch readiness checklist, and one weekly update. Most loops are still virtual, so have them as a PDF you can share on screen, and printed only if you are onsite. Candidates who put real paper in front of an interviewer are remembered.
• Rebuild those artefacts from scratch as sanitized facsimiles. Do not open a current or former employer's internal document in an interview. Change names, round or scale numbers, and say out loud that you did.
• Know your own numbers cold: teams, engineer count, duration, the original date and the actual date, and the outcome. Being vague about a figure that is on your own resume quietly ends the interview.
• Prepare one program that went badly, with the miss named, the cause named, and the change you made to how you work. Every TPM interviewer has been burned; a candidate with no failures reads as junior or dishonest.
• Ask who owns the roadmap and who owns delivery. If the same person owns both and it is not you, you are being hired to report. That is the single most common bad TPM job.
• Ask the TPM-to-engineer ratio and how many programs you would carry. One TPM across 150 engineers and six programs is a status-reporting job regardless of the title.
• Ask what happened to the last person in the seat. A backfill after a promotion and a backfill after a burnout are different jobs.

How technical the interview actually gets

This is the question most TPM candidates get wrong in both directions, so here is the plain answer. You will be asked to explain and draw real systems in detail and to reason about them under failure. You will almost never be asked to write code. The bar is not 'could you implement this', it is 'could you sit in a design review, follow it in real time, and ask the question that surfaces the risk nobody has named'.

What that looks like concretely. Draw the architecture of something you shipped, then go two levels below the slide you would show an executive. Where does a request enter, what does it touch, where is the queue, what is the data store and why that one, what is cached and what happens when the cache is cold, what happens when one region is unavailable, where are the retries and are they idempotent, what was your p99 latency and what moved it, how large was the dataset and how long did the job take, what was the rollback plan and did you ever use it. Then a second form: here is a design document or a one-page brief, tell us what is missing. The expected answer names unowned workstreams, an untested failure mode, a dependency with no date, an estimate that is obviously soft, and a success criterion nobody defined.

What is not asked, so stop preparing it: algorithm implementation, data structure puzzles, LeetCode, production code. The exceptions are narrow. Data and analytics TPM loops sometimes include a basic SQL question (joins, aggregation, a window function) because you will be reading dashboards and challenging numbers. Platform and developer-productivity loops sometimes show you a snippet or a CI configuration and ask what it does. Hardware TPM loops ask you to read a schedule, a test report and a yield number rather than code. If a posting genuinely requires coding, it is a technical product manager or an engineering role wearing a TPM title.

How to prepare the first half: pick two systems you genuinely worked on and be able to draw each from memory, with numbers, including the ugly part. Rehearse out loud and on a real surface. Then close the specific gaps for your target variant. For infrastructure: replication and consistency, partitioning, quorum, load balancing, retries with backoff and idempotency, canary and blue-green deploys, SLOs and error budgets, what an incident severity actually means in a real org. For data: batch versus streaming, schema evolution, backfills, lineage, data quality checks, why a backfill is a program and not a task. For ML and AI: training versus inference, evaluation sets, offline metrics versus online metrics, drift, retrieval versus fine-tuning, quantization, serving cost per request. For hardware: the NPI gate sequence and what each gate actually certifies, long-lead components, tooling cost, yield. For security and compliance: how a SOC 2 Type II observation window and audit actually proceed, what evidence collection costs engineering in hours, what a FedRAMP authorization timeline looks like, how vulnerability SLAs get negotiated.

Overclaiming is the fastest way to fail this interview, and the honest answer passes. 'I can read that design and follow the tradeoffs; I could not have designed the sharding scheme myself, and when it mattered I pulled in the staff engineer who could' is a good answer. It demonstrates calibration, which is exactly what a TPM is hired for. Inventing depth collapses on the second follow-up, and the interviewer will remember the collapse rather than the program.

• Be able to say, in one sentence each, what the hardest technical decision on your program was, who made it, what the alternative was, and what it would have cost to be wrong.
• Rehearse the diagram on an actual whiteboard or tablet, not in your head, and practise on the specific virtual whiteboard the company uses if they name one. Interviewers read hesitation at the drawing stage as borrowed credit.
• Have one number you fought for: a latency budget, a capacity figure, a cost per unit, an error budget. TPMs who have never argued about a number read as schedulers.
• When you do not know, say the boundary of what you know and who you would ask. That is a passing answer; a confident wrong one is not.
• Do not prepare algorithm puzzles. Prepare failure modes.

The execution interviews: what is actually being graded

The scenario is always some version of the same thing. Three teams, one committed date. Two weeks before launch, team B says they are four weeks late. A VP has already told a customer the date. What do you do. Interviewers are not grading optimism or process vocabulary. They are grading a sequence.

First, do you get to facts before reacting: what exactly slipped, is it scope or estimate or a dependency of theirs, what is the critical path now, what is the real blast radius if the date moves, and who outside engineering has made a commitment based on it. Second, do you name the levers out loud: cut scope, move the date, re-sequence so the dependent work starts against a stub or behind a feature flag, parallelize with a known cost, or accept the risk with a stated mitigation. Third, do you know who has authority to approve each lever, because a TPM who proposes cutting scope without naming the product owner who must agree has not actually proposed anything. Fourth, do you escalate with a recommendation and a decision deadline rather than carrying a problem upward. Fifth, do you tell the people who can act while they can still act. The correct answer to 'do you tell the VP now or at Thursday's review' is almost always now, with options attached. The whole interview is filtering for people who manage reality rather than report it.

The ambiguity question is the other standard: you join, there are six teams, no plan, and a date that has already been announced externally. Describe your first 30 days. A strong answer has shape. Find the actual goal and the actual constraint, which are usually not what the announcement said. Get scope written down with a named owner per workstream and get those owners to agree in writing. Build the dependency map and identify the critical path, which surfaces the two or three things that actually determine the date. Establish one cadence and one source of truth, and kill the competing trackers. Surface the top three risks with owners and dates. And if the date is already impossible, say so in week two, because early is the only time that conversation is cheap. Candidates who spend 30 days 'building relationships' before telling anyone the date is wrong are describing the most expensive failure in this job.

The conflict question: two staff engineers disagree on an approach and the date is slipping while they argue. What is graded is whether you drive to a decision rather than mediating indefinitely, and whether you understand that the technical call is usually not yours to make. The good answer: get the disagreement written down as two options with costs and risks, find the person who owns that decision, give them a deadline, and make the cost of not deciding visible. The bad answers are making the call yourself to look technical, or escalating with 'they cannot agree' and no framing.

The strongest TPM answer available in any loop is a mechanism that outlived you. A launch readiness checklist that caught a class of failure twice. A migration dashboard that made the long tail visible and turned a stalled deprecation into a finished one. A weekly exception-only report that replaced a 40-minute status meeting across four teams. A dependency intake process with a response SLA. Mechanisms are how senior TPMs are distinguished from competent ones, because a mechanism scales past the person who built it, and interviewers hiring at staff level are explicitly looking for that.

• Structure every scenario answer as: facts I would get, levers available, who approves each, what I recommend, who I tell and when. Say the structure out loud; it reads as experience, not as a framework.
• Quantify the escalation. 'Four weeks late on a dependency that gates two other teams, so the real exposure is nine weeks, not four' is the sentence that gets you hired.
• Name one mechanism you built, what it caught, and how often. Then say who runs it now.
• Failure modes interviewers listen for: 'I would get everyone in a room' with no decision owner, 'I would push the team to go faster' with no lever, 'I would escalate' with no recommendation, and holding a date you have already been told is impossible.
• If the company is Amazon or otherwise writing-heavy, practise the one-page narrative: the ask in the first three lines, the data in the middle, the risks named, the decision requested at the end.

What actually gates the role: no licence, and which certifications matter where

Nothing licences this job. There is no board, no registration, no protected title and no required exam. Anyone can be hired as a technical program manager tomorrow if someone believes they will land the program. That cuts both ways: there is no credential you can buy to shortcut the gate, and there is no credential anyone can require you to hold. The gate is a program you can survive 45 minutes of interrogation about.

The PMP is the certification candidates ask about most, and the answer depends entirely on where you are applying. It appears constantly in enterprise IT, consulting, government and defense contracting, healthcare IT, utilities, banking and insurance, and it is a common screening credential in markets outside the US, including Canada, the Middle East, India and parts of Europe and Asia. At product-led software and infrastructure companies it is close to irrelevant and occasionally reads as a preference for process over outcomes. The test takes twenty minutes: read thirty postings in your target sector and geography and count how many name it. Eligibility, so you can plan: PMI requires either a four-year degree plus 36 months of experience leading projects, or a secondary diploma plus 60 months, with that experience inside the last eight years, plus 35 contact hours of project management education (a current CAPM satisfies the education hours). Expect a couple of months from decision to exam once you already have the months of experience. Read the current PMP Handbook on pmi.org before paying, because PMI revises the wording for what counts as leading projects, and the experience record is where most applications fail or get audited.

SAFe certifications (SAFe Agilist, Release Train Engineer, Product Owner/Product Manager) are worth money only where the employer runs SAFe, which means large enterprises, finance, telco, insurance, government and defense primes. The Release Train Engineer role is the closest certified analogue to a TPM inside a scaled-agile org, and in those companies the certification is sometimes a literal requirement. At a product company it signals the wrong background. Buy it if and only if your target postings name it.

Cloud certifications are the exception that genuinely helps a specific candidate: someone moving into an infrastructure-adjacent TPM role without an engineering background. AWS Certified Solutions Architect, Associate, Microsoft AZ-104, or the Google Associate Cloud Engineer are checkable evidence that you know the nouns and will not be lost in a design review. They do nothing for a candidate who already shipped infrastructure as an engineer, and they are not a substitute for being able to draw a system. For security and compliance program roles, CISSP, CISA and CRISC do appear in postings; note that CISSP requires several years of relevant paid experience in its domains before you hold the full certification, with an Associate status available while you accrue it. For ML and AI programs there is no certification that carries weight; one real program with a model on the critical path outweighs any course certificate.

Degrees: a computer science or engineering degree helps at the resume screen, particularly at large tech companies, and plenty of effective TPMs do not have one. What substitutes is demonstrable technical depth plus a program you owned. A degree in an unrelated field plus five years of shipping infrastructure beats a CS degree plus coordination work, in this specific role, consistently.

Clearance is a real gate in one slice of the market. Defense, intelligence and some federal civilian TPM roles require an active Secret, Top Secret or TS/SCI clearance, and sponsorship from scratch is measured in many months, sometimes more than a year. Those postings often say 'active clearance required' because the employer cannot afford to wait. If you hold one, it is the most valuable line on your resume for that sector; if you do not, filter those postings out rather than applying hopefully, and plan for a long gap between verbal offer and start date on anything clearance-gated or contract-award-dependent.

The resume: what gets you past the screen, and what gets ignored

A TPM resume is a list of programs, not a list of responsibilities. The structure that works: two or three lines of role context at the top, then two to five program blocks. Each block answers five things in a fixed order. What shipped and for whom. Scale, in numbers: teams, approximate engineer count, orgs, services touched, users or requests or data volume, dollars where they are the point. Duration, with the original date and the actual one. The mechanism you personally built or the decision you personally drove. Then one outcome line with a number and a date. Four blocks in that format beat a full page of verbs.

Technical nouns are mandatory and their absence is fatal. Name the systems, clouds, data stores, pipelines, protocols, frameworks and hardware your program actually touched. A resume that says 'drove cross-functional alignment to deliver a complex technical initiative' with no technical nouns in it is filtered as a project manager resume, because that is what it looks like. You do not need to claim you built those things; 'migration of 240 services off a self-managed Kafka cluster to a managed service, across 9 teams' tells the reader your depth without a single claim about your own code.

Be precise and honest about authority, because experienced readers check. Do not write 'managed 150 engineers'; TPMs do not manage engineers and the claim marks you as someone who does not understand the role. Write 'coordinated delivery across 9 teams, roughly 120 engineers, 4 orgs'. The honesty is itself a positive signal, and the number still does its work at the screen.

What is ignored or counted against you: ceremonies run (standups, retros, planning sessions), meetings facilitated, tools administered, 'stakeholder management' as a bullet with nothing attached, a skills section listing Jira, Confluence, Smartsheet and Asana with no outcomes, certifications stacked above experience, and soft-skill adjectives. Every one of these is true of every person with the title, so each reads as nothing. Jira is table stakes; what you did with it is not.

On confidentiality: give the shape rather than omitting the number. 'Mid-eight-figure capital program', 'roughly 120 engineers across 4 orgs', 'eight-figure annual infrastructure spend, employer under NDA'. A missing number is read as a small one. If you have rounded or scaled a figure, say so explicitly, in the resume and in the interview.

Two rewrites, for calibration. Weak: 'Led cross-functional program to improve platform reliability, working with multiple teams and stakeholders to drive alignment and deliver on schedule.' Strong: 'Reliability program across 6 service teams (roughly 70 engineers): cut customer-facing Sev-2 incidents in the checkout path from 11 per quarter to 3 over 9 months by sequencing a retry and idempotency audit, a load-shedding rollout, and an SLO-based release gate; the release gate is still in use.' Weak: 'Managed migration project to cloud.' Strong: 'Migrated 240 services off a self-managed Kafka cluster to a managed service in 14 months against a 12-month original date; built the per-team migration dashboard that made the 40-service long tail visible and drove the last 15% to completion; decommissioned the cluster, removing a seven-figure annual run cost and one on-call rotation.'

• One page per decade of work, two pages maximum. Program blocks, not paragraphs.
• Put the single largest-scale program first, even if it is not the most recent, and say so in a line of context.
• Mirror the posting's variant in the top third: infrastructure leads with capacity, migration and reliability; data and ML leads with pipelines, evaluation and model release; hardware leads with NPI gates, suppliers and tooling; compliance leads with the audit, the framework and the remediation; launch leads with rollout, readiness and cross-functional dependencies.
• Include the original date alongside the delivered date. Candidates who hide schedule variance are assumed to have a lot of it.
• Carry a portfolio of sanitized artefacts you rebuilt yourself: a charter, a dependency map, a launch readiness checklist and one weekly update. Mention it in the cover note and have it ready to share on screen.
• Name the exact title variants you are open to, because the same job is posted as Technical Program Manager, Technical Project Manager, Engineering Program Manager, Program Manager (Technical), Delivery Manager, Technical Delivery Lead, Release Manager and occasionally Chief of Staff to Engineering.

Pay, levels, and the contract route

In this role the level is the pay. TPM ladders at large technology companies are senior-weighted and explicitly scoped: a mid-level TPM runs one program inside an org, a senior TPM runs a program across orgs, a staff or principal TPM owns a problem area and the mechanisms around it, and compensation tracks that scope far more than it tracks negotiation. TPM ladders are usually mapped onto the same level bands the engineering ladder uses, so verify against the published band for the level you are interviewing at rather than assuming parity. Most of the spread between two offers at the same level is equity and location, not base salary.

Where to get a number you can actually trust, in order of reliability. First, the posting itself: US state pay-transparency laws now cover a large share of large-employer postings, so pull twenty postings at your target level in your metro and write down the published bands. That gives you your own distribution in an hour, current, and specific to the roles you are actually applying for. Second, levels.fyi for leveled total compensation including equity, which is the only public source that separates base, stock and bonus by level at named companies, with the caveat that it is self-reported and skews toward people paid well enough to report. Third, US BLS Occupational Employment and Wage Statistics for the broad market and for non-tech employers: Project Management Specialists is SOC 13-1082 and Computer and Information Systems Managers is 11-3021, both readable at state and metro level. BLS does not see equity and has no TPM-specific code, so treat it as a floor for the general market rather than a read on a big-tech offer. For government-side equivalents, the published GS scale and locality tables; for defense contractors, the labor category rates in the contract.

Do not anchor on a single average from a salary aggregator. The range for this title across employers, levels and geographies is wide enough that any single average is misleading everywhere, and walking into a recruiter screen with a number from a content-farm page is a visible tell. 'My read of published bands for this level in this metro is X to Y, and I am calibrating to the top of that given the scope you described' is the sentence that works.

The contract route deserves plain description because it is a real and underused path in. Large technology companies staff a meaningful share of TPM work through staffing vendors on fixed-term contracts, usually W-2 through the agency. The honest tradeoffs: it is substantially faster to land, the technical bar in the interview is often lower, you get the company name and real program experience on your resume, and you get an internal network. Against that, there is no equity, benefits are the agency's, access to systems and meetings is often restricted in ways that make the work harder, tenure caps exist at some companies, and conversion to full-time happens but is never promised and should not be assumed in planning. Ask three things before signing: the contract length and whether it has been extended before for this team, whether this team has converted a contractor in the last year, and what systems and meetings you will not have access to. If you want the full-time job, treat the contract as twelve months to produce one program you can describe in an interview anywhere.

Where TPM openings actually are in 2026-27

An honest read of the market, without invented numbers. The 2021 to 2022 expansion hired technical program managers broadly, including into roles that were mostly status reporting. The 2023 cuts were publicly framed by several large companies as flattening management and coordination layers, and TPM-to-engineer ratios got leaner and stayed leaner. Hiring since has recovered unevenly and is now concentrated rather than general. The practical consequence for a candidate: the generalist 'I coordinate across teams' positioning that worked in 2021 does not clear a screen now, and the positioning that does is 'I have landed this specific kind of program'.

Where the openings concentrate in this window. AI and accelerator infrastructure, including capacity, GPU and accelerator supply, cluster builds and the data center and power programs behind them. Data platform and evaluation infrastructure. Model release, deprecation and migration programs. Security, privacy and compliance programs, driven by enterprise customers' contractual requirements, FedRAMP authorizations and new regulatory obligations. Hardware NPI across devices, robotics, automotive and medical devices. And large migrations and deprecations, which are perennial and chronically understaffed because nobody gets promoted for finishing one, which is exactly why a TPM who has finished one is valuable.

The second, less obvious concentration: employers outside technology hiring their first technical program managers. Banks, insurers, health systems, retailers, logistics, automotive, energy and industrial companies that have built real engineering organizations now need the role and often do not have the title yet. The competition is thinner, the titles are inconsistent (search Delivery Manager, Engineering Program Manager, IT Program Manager, Technical Delivery Lead), the pay is lower than big tech and the scope is frequently larger than the level suggests. For someone trying to get the first TPM line on a resume, this is the most accessible part of the market.

Where it is thin: generalist product-launch TPM roles at mid-size SaaS companies, and anything that was essentially cross-team status reporting, which is the function tooling absorbed most completely. If a posting's responsibilities are all cadence, reporting and tracking with no technical ownership, read it as a role that may not survive the next planning cycle.

The search tactic that follows from all of this: search by the program noun rather than the title. Query 'migration', 'capacity', 'region build', 'deprecation', 'FedRAMP', 'SOC 2', 'NPI', 'latency', 'cost reduction', 'model release', 'data center' alongside 'program manager', and you will surface roles that keyword-matching on 'technical program manager' misses entirely. Then read each posting for the one thing that decides whether the job is real: is this person accountable for a date, or for a report.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Technical program manager
• TPM
• Technical program management
• Program management
• Engineering program manager
• Technical project manager
• Technical delivery lead
• Cross-functional program delivery
• Cross-team dependencies
• Dependency management
• Dependency mapping
• Critical path
• Program charter
• Scope definition
• Schedule management
• Milestone tracking
• Risk management
• RAID log
• Risk register
• Issue escalation
• Escalation path
• Stakeholder management
• Executive communication
• Executive status reporting
• Exception reporting
• Decision log
• Roadmap planning
• Quarterly planning
• OKRs
• Capacity planning
• Resource planning
• Vendor management
• Third-party dependency management
• Launch readiness review
• Go-live
• Cutover planning
• Staged rollout
• Feature flags
• Canary release
• Blue-green deployment
• Rollback plan
• Release management
• Change management
• Incident management
• Post-incident review
• Postmortem
• Service level objectives (SLOs)
• Error budget
• Reliability program
• Latency reduction
• Cost reduction
• Cloud migration
• Large-scale migration
• Service deprecation
• Platform migration
• Data center build
• Region build
• Infrastructure program
• Data pipeline
• Backfill
• Data platform
• Machine learning program
• Model release
• Model evaluation
• Evaluation set
• Offline and online metrics
• GPU capacity
• Accelerator capacity
• Inference cost
• Data labeling program
• AI governance
• EU AI Act
• NIST AI RMF
• ISO/IEC 42001
• SOC 2
• ISO 27001
• FedRAMP
• PCI DSS
• Vulnerability remediation
• Compliance program management
• New product introduction (NPI)
• EVT DVT PVT
• Bill of materials (BOM)
• Supplier management
• Hardware program management
• Agile
• Scrum
• Kanban
• SAFe
• Release Train Engineer (RTE)
• Jira
• Confluence
• Linear
• Azure DevOps
• Asana
• Smartsheet
• Microsoft Project
• Looker
• Tableau
• SQL
• AWS
• Microsoft Azure
• Google Cloud Platform
• Kubernetes
• Terraform
• Kafka
• CI/CD
• Distributed systems
• System design literacy
• Design review
• PMP
• Project Management Professional
• AWS Certified Solutions Architect
• Security clearance
• Program mechanism design
• Automation of reporting

Mistakes that cost people this job

Questions people ask