Capability
Technical Program Management
The discipline that decides whether software ships at all: intake, architecture and security review, cross-team dependencies, vendor management, and status that reflects reality.
What is actually included
- Intake, approval, and change-control navigation
- Cross-team dependency management, where most delay actually lives
- Vendor and statement-of-work management, on both sides of it
- Steering-level reporting that does not hide bad news
The discipline that decides whether software ships
Inside a large organisation, the constraint on delivery is rarely how fast anyone can write code. It is approvals, dependencies, competing priorities, and the distance between what a steering committee has been told and what is actually true. Managing that is a distinct skill from building the thing.
Most of the last decade has been exactly this work, in financial services, where the controls are real and nothing gets waved through because the demonstration went well.
What it involves
Intake and approval
Packaging work for the architecture, security, and change-control reviews it has to pass, at the start rather than after it fails one.
Dependencies
Most enterprise delay is waiting on another team. Managing that queue actively is most of the schedule.
Reporting
Status that reflects reality, including when reality is bad. A committee surprised in month four was misled in month two.
On estimates
An estimate given by someone who cannot read the code is a guess being laundered into a commitment. Staying close enough to the implementation to know when a number is fiction is the single most useful thing a technical program manager can do, and it is the reason I have never fully stopped writing code.