RSS

Tag Archives: #EngineeringLeadership

Why Most AI POCs Stall and How to Build an AI Operating Model That Works

26 Aug
Why Most AI POCs Stall and How to Build an AI Operating Model That Works

A few months ago, I was speaking with a leadership team that had invested heavily in Generative AI. They had done everything right, at least on paper. They hosted hackathons, launched AI innovation days, encouraged teams to experiment with tools like ChatGPT, Cursor, Claude, and Gemini, and generated dozens of exciting proof of concepts (POCs). The demos were impressive. The excitement was real. Then I asked a simple question: “How many of these solutions are actually running in production and creating measurable business value?” The room went quiet.

If you have been involved in AI initiatives, you have probably seen the same pattern. Teams produce innovative AI prototypes, leadership gets excited, and everyone talks about transformation. Yet months later, very few of those ideas become dependable, secure, and widely adopted business solutions.

The problem isn’t the technology. Today’s AI models are incredibly capable. The problem is that most organizations are trying to scale AI without building the operational framework needed to support it. In my experience, the companies that successfully scale AI don’t necessarily have the best models. They have the best operating model.

One of the first challenges organizations encounter is what I call the “happy path” problem. Most AI POCs are built using clean data, predictable scenarios, and carefully controlled environments. Real-world systems rarely behave that way. Customers enter incomplete information, business rules change, systems fail, and unexpected edge cases appear. Many teams react by trying to perfect the solution before launch, spending months solving hypothetical problems. However, I believe that the smarter approach is the simpler one: release a focused solution to a targeted audience, gather feedback, learn from real-world usage, and improve iteratively. The fastest way to build a production ready AI product is to get real users into the loop as early as possible, not to spend months and years to perfect a solution.

Even when organizations overcome that hurdle, they often run into a second challenge: data and integration issues. Most AI failures are not actually AI failures. They are data failures, process failures, or integration failures. A POC can operate on a carefully curated dataset, but production systems need secure data pipelines, governance controls, monitoring, observability, auditability, and integration with existing business workflows. I have seen organizations spend months debating which model to use while completely overlooking the fact that their underlying data ecosystem wasn’t ready. Thus, companies should invest in building a stronger data pipeline, improving their integration testing capabilities, and creating an operational framework that can accelerate pace of innovation. After all, the AI isn’t the problem, the foundation is.

Another common trap is measuring activity rather than outcomes. These days, organizations proudly report the number of tokens used, experiments conducted, prompts executed, or AI tools adopted. Those metrics may indicate engagement, but they don’t necessarily indicate value. The questions leaders should be asking are much simpler: Did customer satisfaction improve? Did operational costs decrease? Did revenue increase? Did employee productivity improve? AI creates value only when it is connected to measurable business outcomes. Everything else is experimentation. That’s why I recommend that organizations regularly review AI adoption, engagement, and ROI through existing governance forums such as Monthly Product Reviews (MPRs), Monthly Business Reviews (MBRs), Engineering Operations Reviews, and Level 10 (L10) meetings. These forums help connect AI initiatives to measurable business outcomes, making it easier to understand what’s creating value, what’s falling short, and where organizations should focus their next investments.

As organizations mature, AI governance becomes increasingly important. Unfortunately, AI governance has developed a bad reputation and is often viewed as the enemy of innovation, since AI models are evolving at an unprecedented pace, heavyweight governance processes often struggle to keep up. In reality, governance is what allows innovation to scale safely. Whether it’s privacy, security, compliance, responsible AI, or human oversight, organizations need clear and repeatable processes that help teams move quickly while managing risk responsibly. The Air Canada chatbot incident serves as a reminder that companies remain accountable for what their AI systems do, regardless of how autonomous those systems may appear. Thus, I recommend that organizations rethink their decade-old governance models. Since AI is evolving rapidly, innovators should not have to navigate multiple approvals and disconnected stakeholders just to get an AI use case reviewed. Instead, organizations should establish a centralized governance forum where teams can bring ideas, ask questions, receive timely guidance, and understand the rationale behind governance decisions. The goal is not to reduce oversight, but to streamline it. By creating a transparent, well-socialized, and operationalized governance framework with regular follow-ups and clear communication, organizations can strengthen governance while simultaneously accelerating the pace of innovation.

Another common mistake organizations make is failing to invest in their people. Like any major transformation, AI augmentation is ultimately a transformation of how people work. Simply providing access to AI models or GenAI tools does not guarantee success. Organizations need to invest heavily in AI literacy, change management, coaching, upskilling, and adoption strategies, just as they would for any other enterprise-wide transformation. Leaders cannot assume that because AI tools are available, employees will automatically use them effectively or that productivity will magically improve. Without the right training, guidance, and support, most employees will either underutilize AI or use it only for basic tasks. Employees need to understand where AI can help, where it cannot, and how to integrate it into their daily workflows responsibly and effectively. After all, if people continue to view AI as nothing more than a chatbot, the vision of building AI-powered assistants, autonomous workflows, and agentic AI solutions will remain out of reach. This is why leaders must build an operating model that reinforces the right behaviors, creates opportunities for learning, and encourages adoption through the right incentives. Ultimately, AI transformation is not a technology transformation. It is a people transformation.

Finally, organizations need to answer one critical question: When AI fails, who is accountable? As tools like Claude, Gemini, Cursor, and GitHub Copilot become part of everyday software development, accountability can quickly become blurred. My view is straightforward. AI can generate content, code, and recommendations, but it cannot own responsibility. The engineer who deploys the code remains accountable for its quality. The product manager who launches the feature remains accountable for its business impact. Human ownership must remain intact, regardless of how much AI contributed to the solution.

The biggest obstacle preventing companies from realizing value from AI isn’t model performance or innovation. It’s the absence of an AI operating system that connects governance, measurement, accountability, data readiness, and talent development into a repeatable framework. AI doesn’t reduce our need for leadership, governance, operational excellence, or execution discipline. It increases it.

 
3 Comments

Posted by on August 26, 2026 in 21st Century, AI Leadership, Leadership, Management, technology

 

Tags: , , , , , , , , , , , , , , , , , , ,

The Most Expensive Cost-Cutting Decision in Technology

13 Aug
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.

 
Leave a comment

Posted by on August 13, 2026 in 21st Century, AI Leadership, Leadership, Startup

 

Tags: , , , , , , , , , , , , , , , , , ,

Dependency Management with AI: From Tracking to Forecasting

08 Jul
Dependency Management with AI: From Tracking to Forecasting

A few years ago, I was in a Roadmap Planning Onsite in a room full of incredibly smart, driven people, the kind of team any company would be proud of. Product leaders, engineers, designers, program managers, everyone aligned, everyone motivated. The roadmap looked solid, the timelines felt achievable, and there was real excitement in the air. If you had walked in at that moment, you would have confidently predicted a couple of successful launches. And yet… these launches slipped.

It didn’t happen all at once. First, a small delay in a review. Then a meeting got pushed out. A dependency that seemed “almost ready” turned out not to be ready at all. One team was waiting on another, and that team, in turn, was waiting on someone else. Before long, what had started as well planned initiatives turned into a series of urgent follow-ups, escalations, and frustration.

What struck me most was this: no one lacked talent, and no one wasn’t working hard. The failure wasn’t about capability. It was about something much quieter and far more dangerous…….unmanaged dependencies.

In smaller companies, this problem is easier to avoid. Decisions happen quickly, often made by a single founder or a small group of leaders. Teams are lean, and the same people who define the problem often see it through to completion. Dependencies still exist, but they are visible, human, and manageable. If something is blocked, everyone knows about it almost immediately, and adjustments happen quickly. The feedback loop is tight, and the risk is contained.

But as organizations grow, so does complexity. What used to be a simple flow, from idea to execution, turns into a chain of handoffs. Product defines the “what,” design shapes the experience, engineering builds it, QA tests it, DevOps deploys it, and along the way, legal, finance, content, and other teams may also get involved. No single person owns the entire journey anymore. Instead, execution depends on how well these teams coordinate with each other. And that’s where things start to break down.

Without a clear operating model and a strong way to track and manage dependencies, teams begin to work in silos. Each team focuses on its own deliverables, assuming that everything else will fall into place. Progress is reported optimistically, but risks remain hidden until it’s too late. Eventually, you start hearing the same familiar line: “We have done everything on our end, but we are blocked by another team.”

On the surface, that sounds reasonable. But when every team is saying it, it points to a deeper issue. It means the system itself is not working.

One of the most challenging aspects of dependencies is that they rarely fail loudly. They fail quietly, almost politely. A review gets postponed. A requirement remains unclear. A deliverable is “in progress” just a little longer than expected. Nothing feels urgent in the moment, so it doesn’t get escalated. But over time, these small slips compound. By the time the impact becomes visible, the situation is already critical. Deadlines are missed, launch dates shift, and trust between teams begins to erode.

I have seen this play out in both small and large organizations. In smaller teams, you might lose a few weeks before the issue becomes visible. In larger enterprises, the problem becomes even harder to detect. Dependencies spread across teams, tools, systems, and time zones. They get buried in JIRA, Asana or Trello tickets, scattered across calendars, and diluted across layers of communication. They don’t become less severe, they just become harder to see.

Take a simple example. Your team is ready to launch an A/B test. Everything is built, tested, and ready to go. You assumed that the experimentation platform team would support your test when you needed it. But it turns out that team is already running multiple experiments and doesn’t have the capacity to take yours on. No one flagged it early, no one anticipated it, and now your launch is blocked. What seemed like a minor assumption quietly becomes a major delay, impacting not just one feature, but potentially a significant portion of your roadmap.

This is why, in my experience, unmanaged dependencies are the single most consistent reason why even the best companies struggle to execute. It’s not technical difficulty. It’s not lack of talent. It’s the invisible gaps between teams.

What is encouraging, though, is that this is starting to change. One of the most powerful shifts I have seen with GenAI is the move from simply tracking dependencies to actively forecasting them. Instead of asking AI, “What are our dependencies?” teams are beginning to ask better questions like “Which dependency is most likely to surprise us?” “Which team is likely to become a bottleneck based on past data?” “What should we be watching closely in the next few weeks?”

This shift changes the entire tone of planning. Conversations move away from debating optimistic timelines and toward understanding risk and building resilience.

This is where AI plays a transformative role. AI is uniquely good at something humans struggle with at scale, it can reason across both time and structure. It can look at historical patterns and identify where delays typically occur. It can spot patterns in scheduling mismatches, highlight recurring bottlenecks, and even identify situations where one team consistently absorbs the impact of another team’s delays. Traditional tools (like JIRA, Asana, Planview PPM) show you connections between Features, Epics, and their relevant User Stories/Tasks. However, AI takes this further and it helps you understand the consequences of those connections.

And when teams start working this way, something interesting happens. Conversations become calmer and happen earlier. Risks feel less like surprises. Escalations decrease. Instead of reacting to problems at the last minute, teams begin to anticipate them and adjust ahead of time. The culture shifts from blame to problem-solving, from urgency to clarity.

In the end, execution doesn’t fail because people aren’t capable or committed. It fails because the space between teams is left unmanaged. When that space is made visible, when dependencies are not just tracked but understood and anticipated, everything changes. Teams move faster, with more confidence, and with far less friction. And that’s the real unlock: not just building great things, but building the systems that allow great teams to deliver them, consistently and predictably.

 
Leave a comment

Posted by on July 8, 2026 in 21st Century, AI Leadership, Leadership, Management

 

Tags: , , , , , , , , , , , , , ,

AI is Breaking the Illusion of Engineering Velocity

18 Jun
AI is Breaking the Illusion of Engineering Velocity

For most of my career, I have been deeply involved in guiding product, engineering, design, and program teams to accelerate their growth through a data driven approach. If I look back, a big part of my role was helping teams understand how fast they were moving and where they were getting stuck. I worked with multiple teams and workstreams, tracking their velocity, reviewing pull request timelines, and connecting code check-ins to actual feature releases. The goal was always the same, to figure out where things were slowing down and what was getting in the way.

Over time, I built frameworks around common product and engineering operational metrics from story points, sprint burndowns, capacity charts, to PR cycle times, and more. These frameworks weren’t just about tracking numbers; they were used to drive conversations and actions. At the leadership level, especially with Executive Leadership Teams (XLT) and the C-suite, these metrics helped tell a story that progress was happening and that teams were moving in the right direction. I have seen this play out repeatedly across large organizations like Amazon, Facebook, GE, Schneider, etc. The scale varied, the tools were different, but the pattern remained the same.

Then AI entered the picture, and it started changing this dynamic in a very profound way. For the first time, the gaps between what teams reported and what was actually happening became much harder to ignore. Earlier, it was possible for teams to highlight improvements in velocity while delivery timelines kept slipping in the background. Dependencies would quietly pile up, and engineers would feel the pressure, but those signals often stayed hidden beneath layers of reporting. Now, with AI, these patterns don’t need someone to escalate them, they become visible on their own.

To put this into perspective, think about smaller, leaner organizations. In a team of 5 within a company of 50, if something slows down, everyone feels it immediately. There is no insulation, no layers to absorb the problem. The impact is direct and visible. But in large enterprises, those same problems are often diffused across multiple layers, making them harder to detect. AI removes that insulation. It surfaces patterns in a way that makes them almost impossible to overlook.

At its core, this change forces us to rethink what “flow” really means.Flow is not about how fast a team completes tasks. It’s about how smoothly work moves from an idea to actual impact. When you start looking closely, most flow problems are not caused by individuals. They come from the system itself. For example, there could be too many handoffs, too many approvals, too many hidden queues, etc. These issues build up slowly and are spread across teams and processes, which makes them very hard for humans to detect. We tend to focus on what is visible in front of us, but these problems live in the connections between steps.

This is where AI becomes incredibly powerful. AI is exceptionally good at spotting patterns that are distributed and slow-moving. Even at a tech giant like Amazon, I have seen AI uncover insights that would have taken months to identify manually. For example, it could highlight that a certain type of work consistently spends more time waiting than actually being built. Or that specific dependencies only create delays when they interact with quarterly planning cycles. These are not patterns that a single program manager could reliably detect on their own, especially at scale. But once AI is fed historical data, like cycle times, it can surface these insights almost instantly.

The real breakthrough, however, happens when teams change how they use AI. Thus, instead of using AI to simply track performance metrics like velocity or PR turnaround time, you should shift your focus on understanding behavior. Instead of asking, “How fast are we going?” or “What is our average velocity?”, leaders should start asking, “Why does work slow down?”, “Where exactly is it slowing down?”, and “What are the real bottlenecks in our system?”

When these answers are connected back to the data from tools like JIRA, Asana, Trello, or Monday.com, something interesting happens. Conversations change. I have seen this firsthand at Amazon. Within a single quarter, meetings evolved from being about defending estimates to being about removing friction. The tone changed from justification to problem-solving.

To make this more practical, I built an AI agent to bring this idea to life. My AI agent pulled in team data like JIRA movements, PR merges, review times, etc., and translated it into simple, plain-language insights about what was slowing teams down. Instead of showing a chart, it told a story. For example, it could say, “Work slowed because reviews were clustered toward the end of the sprint.” That single sentence made the problem feel real and actionable.

And the response from teams was immediate. Engineers started breaking their work into smaller pieces. They updated JIRA more consistently. They distributed reviews more evenly instead of letting them pile up at the end of the sprint. As a result, more work was completed within the sprint itself. What is important here is that the underlying data was not new, it was always there. But presenting it as a clear explanation, rather than a metric, drove faster behavioral change. A velocity chart alone would not have created that shift in such a short time.

This is why I strongly believe that AI accelerates speed in a very different way than traditional tools. It doesn’t just help teams move faster, it helps them see the truth earlier. And in engineering systems, that matters a lot. These systems rarely fail in obvious ways. They don’t break loudly. Instead, they degrade slowly and quietly over time.

AI brings that quiet degradation to the surface before it turns into a major problem. And that, more than anything else, is where its real power lies.

 
Leave a comment

Posted by on June 18, 2026 in 21st Century, AI Leadership, Leadership, Management

 

Tags: , , , , , , , , , , , , , ,

How AI Transforms Program Management: From Reporting to Strategic Partnership

20 May
How AI Transforms Program Management: From Reporting to Strategic Partnership

Early in my career at a couple of Fortune 500s, program management excellence often meant one thing: being able to produce a clean, defensible status report. Green boxes built credibility. Red ones triggered escalation. The irony was that by the time something turned red, everyone already felt the pain, the report simply made it official.

Fast forward to today, use of AI often exposes an uncomfortable truth: much of what we call program management has been information movement, not decision support. Startups figured this out long ago. They don’t have the luxury of formal status cycles; they rely on shared situational awareness. AI finally allows large organizations to do the same without collapsing under scale.

What changes is not visibility, but interpretation. AI is extremely good at synthesizing fragmented signals into a coherent story. That’s something PMOs have historically tried to do manually, often under time pressure and political constraints.

In most of these big tech giants, I have often seen programs where risk doesn’t emerge explosively, it creeps. A dependency slips a sprint. A scope assumption quietly changes. A team compensates heroically. None of this is “red,” but all of it matters. AI excels at spotting these slow burn patterns precisely because it doesn’t get tired, defensive, or distracted by hierarchy.

Thus, I have been extensively using AI into my day-to-day activities by replacing weekly status decks with weekly sense‑making narratives. Instead of asking teams to explain why something is red or green, I have been using Rovo and Cursor to ask questions like: What’s drifting from plan but not yet obvious? What commitments are most vulnerable if nothing changes? These questions provoke far better conversations, provide helpful insights to the leadership team, and help the core project team to maneuver challenges.

The practical change required to implement this workflow is surprisingly small. You just need to enable Rovo agent in JIRA, work with your teams to fix JIRA hygiene challenges, and connect Cursor with your Atlassian suite. Once you do the groundwork, you can then feed AI your existing artifacts like Jira updates, roadmap changes, sprint notes, and ask it to generate insights rather than summaries. You can then review these insights and share it with your teams. This workflow and its visibility will fundamentally change how your teams operate. Over time, teams will stop optimizing for optics and start optimizing for coherence.

So, I strongly believe that AI won’t make program managers irrelevant, but it will make them more like strategists and less like couriers. The PMO of the future won’t be judged by how accurate its reports are, but by how early it helps leaders see reality and help them win through data driven decision making.

 
2 Comments

Posted by on May 20, 2026 in 21st Century, AI Leadership, Leadership, Management, technology

 

Tags: , , , , , , , , , , , , , , ,