Over the last two decades, I have had the opportunity to work with startups, growth-stage companies, and some of the world’s largest enterprises. Across these organizations, I have helped product, engineering, design, and quality teams improve the way they operate. Sometimes the challenge was a lack of strategic alignment. Sometimes teams were working hard but prioritizing the wrong things. Other times the problem was execution, where ownership, planning, and delivery were disconnected from one another. Regardless of the company or industry, one lesson has remained surprisingly consistent: success is rarely determined by great ideas alone. It is usually determined by the operating system that helps teams turn those ideas into reality.
Unfortunately, that operating system is often the first thing leaders cut when revenue falls short and budgets need to be reduced. I have seen this happen more times than I can count. A company misses its financial goals and leadership begins reviewing costs. Product teams are viewed as essential because they drive innovation and define the future roadmap. Engineering teams are viewed as essential because they build the product and deliver features. Design teams are viewed as critical because they shape the customer experience. Then attention turns toward Technical Program Managers (TPMs), Project Managers, Delivery Managers, and PMO organizations. Since these teams are not directly writing code or defining product features, they are often perceived as overhead. The conclusion becomes simple: remove the program management layer and allow product and engineering leaders to absorb the responsibilities.
On paper, the decision sounds reasonable. However, it often creates far more problems than it solves. I have personally witnessed this firsthand in multiple startups I supported throughout my career. In two of the companies I worked at, leadership reduced a significant portion of the TPM and program management function during periods of financial pressure. The assumption was that product managers and engineering leaders could take over the coordination work while continuing to execute their existing responsibilities. Leaders hoped this would reduce costs without affecting delivery speed or business outcomes.
The opposite happened. Within a few months, product managers found themselves spending less time talking to customers and more time tracking dependencies across teams. Instead of validating market opportunities, refining roadmaps, and measuring customer outcomes, they were coordinating schedules, chasing updates, preparing reports, and managing delivery risks. At the same time, engineering leaders became consumed with sprint planning, program reviews, portfolio reporting, PI planning sessions, and other operational activities. Rather than focusing on architectural improvements, engineering productivity, DevOps optimization, developer experience, and technical mentorship, they were forced to fill an operational gap that nobody had anticipated. The work itself did not disappear. It simply moved to people who were hired to do something else.
As a result, execution slowed down, planning became less predictable, dependencies fell through the cracks, and leadership visibility decreased. While the company saved money on a spreadsheet, it lost efficiency across the organization.
One reason this happens is because great program management is often invisible. When TPMs and PMO teams are performing well, most people do not notice the work they are doing. They see smooth planning cycles. They see aligned roadmaps. They see risks identified early. They see stakeholders staying informed. They see teams moving together toward common objectives. Because the outcomes appear seamless, it becomes easy to underestimate the effort required to create and maintain that alignment.
The best way I can describe it is this: program management is the operating system of an organization. Just as Windows/Mac operating system allows hardware and software to work together efficiently, TPMs and PMO leaders create the frameworks, governance, communication channels, and execution mechanisms that allow product, engineering, design, and QA teams to work effectively together. When you remove the operating system, the individual components still exist, but they stop functioning together at the same level of efficiency.
This becomes particularly important as organizations scale. In small teams, coordination can happen organically. People can walk across the room, have a quick conversation, and resolve issues immediately. However, as organizations grow, dependencies increase. More stakeholders become involved. Priorities compete for attention. Teams become distributed across locations and time zones. Without strong operational frameworks and cross-functional governance, execution naturally becomes more difficult.
Many leaders today argue that Artificial Intelligence (AI) will eliminate the need for large PMO organizations. There is certainly some truth to that argument. AI is already helping organizations automate reporting, generate dashboards, summarize meetings, identify risks, and track work more effectively than ever before. I personally believe these innovations will continue to transform how TPMs and PMOs operate over the next several years.
However, automating tasks is not the same as replacing a function. AI can generate a status report. It cannot always drive organizational alignment. AI can identify a delivery risk. It cannot negotiate priorities across competing stakeholders. AI can provide project insights. It cannot build trust among leaders, challenge assumptions, facilitate difficult decisions, or create accountability across teams. The most valuable work performed by modern TPMs is not administrative. It is strategic. It is helping organizations make better decisions, focus on the highest-value work, resolve complex dependencies, and improve how teams operate together.
The irony is that companies often spend enormous amounts of money trying to improve engineering productivity, accelerate software delivery, improve customer outcomes, and increase organizational effectiveness, while simultaneously reducing the very teams responsible for enabling those outcomes. They invest heavily in building products but underinvest in the systems that make product development successful.
In my experience, the highest-performing organizations understand that operational excellence is not a luxury. It is a competitive advantage. They recognize that product managers should spend most of their time understanding customers, validating roadmaps, and measuring business outcomes. They recognize that engineering leaders should spend their time improving architecture, strengthening DevOps capabilities, mentoring engineers, and increasing delivery efficiency. They also recognize that somebody needs to own cross-functional execution, strategic prioritization, governance, dependency management, and organizational effectiveness. That “somebody” is often your TPM and PMO organization.
Are there program managers who simply act as messengers between teams? Absolutely. Every profession has people who contribute more value than others. But judging the importance of an entire function based on its weakest examples is a mistake. The best TPMs create leverage across the entire organization. They help companies prioritize strategic bets, improve product development processes, streamline software delivery, increase engineering productivity, strengthen Agile execution, and drive better business outcomes.
As technology continues to evolve and AI becomes increasingly capable, I believe the TPM role will evolve as well. Routine administrative work will continue to be automated. Reporting will become easier. Data collection will become smarter. But the need for leaders who can align strategy with execution, drive cross-functional collaboration, optimize operating models, and help teams deliver value faster is not going away anytime soon. If anything, it is becoming more important.
The next time an organization considers reducing its TPM, Project Management, or PMO function as a cost-saving measure, I would encourage leaders to pause and ask a simple question: Who will own the operating system that makes execution possible? Because building great products is only half the challenge. Building an organization that can repeatedly deliver those products at scale is what separates companies that survive from those that truly win.
Bhavin Gandhi's Blog 