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.
Bhavin Gandhi's Blog 