What is a program?
A program is a long-horizon effort that spans multiple workstreams, deliverables, and iterations: a named, ongoing initiative with a defined scope, a set of owners, cross-functional stakeholders, and signals distributed across multiple tools. The work of a program shows up as GitHub PRs, Slack decisions, Drive docs, tickets, and meeting transcripts. No single tool contains it, because no single workstream produces it.
A program doesn't run once; it cycles. Each pass plans, executes, and evaluates, and each evaluation feeds the next plan. That spiral through time is what separates a program from everything that merely ships.
Programs are how mid-to-large organizations have always planned. A 300-person company has hundreds of them, whether or not anyone has written them down. What's new is who needs them. AI-driven velocity means a 10-person team now runs the parallel, cross-functional workload that used to require 80, and it hits the same coordination problems at a fraction of the headcount. That's why small teams are adopting program engineering in place of task-based project and feature engineering, and it's the shift Serro is built to power.
How is a program different from a ticket or a project?
A ticket tracks one task. A project has a hard end date. A program is continuous: it has a charter, stakeholders, and a living record of decisions, commitments, and scope changes, and it ends only when the outcome is achieved or stops mattering.
The distinction changes what ownership means. Closing a ticket means the task is done. Owning a program means keeping an outcome healthy across many tickets, many quarters, and many contributors.
What does a program consist of?
- A charter: the outcome the program exists to produce, and its boundaries
- Owners: the engineers and leads accountable for the outcome, not just the tasks
- Sources: the repos, channels, docs, and meetings where the program's signals actually live
- A living record: decisions made, commitments outstanding, scope changes, blockers, and action items, accumulated across the program's life
When that record is maintained automatically rather than by hand, it becomes live program memory.
What types of programs are there?
- Product programs: the iPhone is the canonical one. It launches continuously, recurs through every cycle, and has been a central focus of the company for almost two decades. Maximally cross-functional, with hardware, software, operations, and marketing moving together every iteration.
- Engineering programs: "Platform Reliability," "Auth Modernization," "Mobile Launch Q3." Execution lives inside engineering, crossing team boundaries rather than functional ones: platform vs. product teams, service owners, infra.
- Design programs: a design system is a program. One function owns it, every product surface consumes it, and it never ships so much as it evolves.
- Operational programs: the Toyota Production System has run since the 1950s, sustained process improvement where each iteration deposits into the next.
Some programs recur indefinitely (reliability never ships); some converge on a milestone and then evolve (the launch becomes the postmortem becomes the next launch). Both are programs while they run.
Who owns a program?
Someone always does. The question is whether it's explicit. When a program has no name, no owner, and no shared visibility, it still gets run: by whoever has enough context to hold the picture in their head. That person becomes the accidental program engineer, doing the work on top of their actual job, with all the institutional knowledge trapped in their memory.
Naming the program and declaring its owner and sources is the first act of program engineering.
Learn more
- What Is Program Engineering?: the discipline of running programs deliberately
- What Is Live Program Memory?: the program's living record, maintained automatically
- Welcome to Program Engineering: why product engineering inevitably becomes program engineering