RSS

Tag Archives: #BusinessTransformation

The Most Expensive Cost-Cutting Decision in Technology

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.

Beyond the AI buzz: Delivering measurable results through real-world examples

29 Jul

I still remember working on an AI initiative 5-6 years ago for a healthcare company that wanted to transform the patient experience. At that time, AI wasn’t readily accessible to everyone. There were no consumer grade AI assistants generating content on demand. There were no established implementation playbooks. Organizations that pursued AI were often entering relatively uncharted territory.

We were building what felt like a first-of-its-kind platform designed to simplify interactions between patients and healthcare providers using AI. While the vision was exciting, the project was filled with uncertainty. Questions such as how to train the model, how frequently retraining should occur, what datasets should be used, what level of accuracy was acceptable, and what operational costs would look like remained largely unanswered. Every decision felt like an experiment.

Today, most of those technical barriers have been significantly reduced. Powerful AI models are available through cloud providers and APIs. Organizations can now build capabilities in weeks that previously would have taken years. But while many technical challenges have become easier, business challenges have become significantly harder.

The challenge today is no longer whether AI works. The challenge is whether companies understand the operational, financial, and governance implications of deploying AI at scale.

One of the most overlooked aspects of AI adoption is cost predictability. Historically, organizations planned budgets around relatively stable variables such as labor, infrastructure, licensing, and operational expenses. Financial forecasts could be created quarterly and adjusted annually with reasonable confidence.

AI is changing that equation. A company’s AI consumption could fluctuate dramatically based on customer adoption and usage patterns. An application might consume 100,000 tokens on one day and 10 Million tokens the next. A highly successful AI-powered feature can introduce operational costs that were never anticipated during planning.

For technology giants such as Microsoft, Apple, Google, Amazon, and Nvidia, these fluctuations can often be absorbed because of their scale and ability to invest heavily in AI infrastructure. For most organizations, however, especially those dependent on product revenue and operating within tighter margins, this new consumption driven model introduces uncertainty that many finance teams have never had to manage before. Thus, today’s companies should shift their focus from “Can we build it?” to “Can we sustainably support it?” That is where organizations need a different approach.

So, let me provide you some pointers through which you can implement AI sustainably in your organization.

1. Use AI as a Tool, Not a Strategy:

One of the most common mistakes organizations make is treating AI as a technology initiative instead of a business initiative. AI should never be implemented simply because it is available or because a competitor is using it. If you want to be successful in this AI race, then you need to identify a specific business outcome and then determine whether AI is the right tool to achieve that outcome.

Instead of asking: “How can we use AI?”, you should ask: “What business problem are we trying to solve?”. The answers should be measurable and meaningful, not just some buzz words. For example, AI will reduce customer service costs by X%, or it will improve employee productivity by Y%, or it will increase customer retention by Z%, etc.

In one Fortune 500, I was called to coach the team in launching an AI chatbot because competitors had announced similar initiatives. But after several workshops, I identified the underlying problem. The real issue turned out to be the excessive amount of time employees spent searching for information across disconnected systems to help their customers. So, rather than building a flashy external facing solution, we implemented an AI-powered knowledge search platform for internal users. Adoption was immediate, employee productivity improved by 20%, and the ROI justified the costs of tokens. Thus, I recommend that you should also focus on outcomes first and technology second.

2. Start With High-Value Use Cases

Many Fortune 500 companies are attempting AI transformation through large, organization-wide initiatives. While it might work for 20% of the top tech companies, I believe that other Orgs should identify use cases that are easy to measure and relatively low risk, before heavily investing into AI transformation. In some of the companies where I have recently consulted, I often see AI augmentation opportunities within internal knowledge management, customer support automation, document summarization, meeting intelligence, workflow automation, and sales enablement.

For example, in one of the largest companies, we introduced AI-generated meeting summaries for their sales calls. While this initiative sounds relatively small compared to larger transformation, the productivity gains and lead conversion rates were transformational for the company. SDRs and BDRs had all the insights about their clients on their fingertips and they spent less time in refreshing their memories and more time in converting the lead into an actual sale.

Thus, I believe that AI should be used in these targeted initiatives to provide immediate value and actual ROI. This approach isn’t flashy, but it works. Small wins create confidence, confidence creates momentum, and momentum enables scale.

3. Build Guardrails Before Scaling

Once organizations begin seeing success, there is a natural temptation to expand AI rapidly. After all, C-Suites are pushed by their stakeholders to show big wins through AI quickly.

However, I believe that AI adoption without governance can quickly become expensive, inconsistent, and difficult to manage. I strongly believe that all the Orgs should establish guardrails before broad deployment. This includes monitoring usage trends, creating cost management controls, setting spending thresholds, defining approval processes, implementing security standards, and establishing performance monitoring frameworks.

Recently, I was coaching this S&P 500 company that had seen situations where individual departments adopted multiple AI solutions independently. Marketing purchased one platform, operations implemented another, and customer support selected a third. While each decision appeared reasonable in isolation, the organization eventually found itself managing overlapping vendors, inconsistent security controls, and rapidly increasing costs. Thus, I strongly recommend you to think through your AI strategy and implement internal support systems for building guardrails and governance before everything goes out of hand.

In the end, the organizations that succeed with AI over the next decade will not necessarily be those spending the most money or tokens. They will be the companies that approach AI with discipline. They will understand the difference between experimentation and strategy. They will balance innovation with governance, ambition with financial accountability, and opportunity with measurable outcomes. Most importantly, they will stop asking: “How can we say we are using AI?” And instead ask: “Where can AI create sustainable business value?” That distinction may seem small, but it changes everything.

The future will not belong to companies that can simply claim they use AI. It will belong to companies that can clearly demonstrate why they use AI, how they govern it, and the value it delivers. Because in the end, AI should be more than a buzzword. It should be an impact multiplier.