TPM System Design: The Twelve-Factor Approach
Because I come from such a non-traditional tech background (I started in Public Education), I meet a lot of Program and Project Managers who ask me about getting into Technical Program Management. I'm not a software engineer, but I grew up in the early days of blogging, so I'm pretty well versed in early languages and concepts like HTML, CSS, PHP, and MySQL and took a few computer science classes in high school and college.
Many people see the requirement for a Bachelor's degree in Engineering, Computer Science, or a related technical field on job applications and immediately think they are out of reach, that isn't so!
As TPMs, we orchestrate multiple engineering teams, aligning priorities and resolving dependencies without owning the code ourselves. Deep software engineering experience is helps, but isn't a hard requirement because the role emphasizes facilitation: defining clear requirements, sequencing milestones, and ensuring accountability across silos. For example, in migrations like my program to migrate 150K databases to AWS Aurora, success hinged on stakeholder buy-in and phased rollouts, not me writing database schemas!
I didn't have a strong background in systems design before joining Heroku, but while working there, I was exposed to the Twelve-Factor App methodology, which provides a proven framework for designing cloud-native systems that scale reliably across teams and environments.
Developed by Heroku engineers, these principles emphasize portability, maintainability, and resilience and it has become a key reference for me when aligning cross-functional programs around infrastructure transformations.
Here's how I use it as a TPM!
Twelve-Factor Principles for TPMs
The Twelve-Factor App distills SaaS best practices into 12 actionable factors, each addressing a common pitfall in cloud deployments. As a TPM, these become your north star for scoping programs, mitigating risks, and ensuring designs that enable continuous delivery.
| Factor | Principle | TPM Relevance |
|---|---|---|
| I. Codebase | One codebase tracked in revision control, many deploys | TPMs encourage single-repo discipline for programs |
| II. Dependencies | Explicitly declare and isolate dependencies | TPMs ensure dependencies are isolate |
| III. Config | Store config in the environment | TPMs confirm drive env-var standardization, avoiding secrets in code during global rollouts |
| IV. Backing services | Treat as attached, swappable resources | TPMs review design docs to ensure backing services are as attached resources. |
| V. Build, release, run | Strictly separate stages | TPMs verify there is a safe rollback method in place |
| VI. Processes | Stateless processes | TPMs promote statelessness for horizontal scale (like encouraging the use of Kubernetes |
| VII. Port binding | Self-contained service export | TPMs ensure self-contained services |
| VIII. Concurrency | Scale via process model | TPMs plan process-type scaling (ex: web/worker) |
| IX. Disposability | Fast start, graceful shutdown | TPMs make sure designs include fast-restart tolerance into migrations |
| X. Dev/prod parity | Minimize env gaps | TPMs highlight any difference between development, staging, and production environments |
| XI. Logs | Treat as event streams | TPMs advocate for the integration of OpenTelemetry streams for unified observability |
| XII. Admin processes | One-off tasks as app processes | TPMs sequence these tasks into production programs with zero-downtime strategies |
These factors promote apps that are agile, portable, and resilient which are core tenants to TPM-led programs.
Integrating Twelve-Factor into your TPM role for System Design
I like to use it as a checklist after clarifying requirements. TPMs use it as a post-requirements checklist to validate designs deliver robust, portable apps that reduce risks. It's not perfect, sometimes my questions are way off base, but occasionally I am able to connect dots other miss and save us from something that could have been a huge headache (or an incident!) down the road.