Rethink Your Understanding

Transforming Software Delivery

Software Engineering

What Happens When We Eliminate the Agile Leader?

by

The hidden cost of removing the role that protects flow, team health, and continuous improvement

7 min read

Every few months, the “Agile is Dead” conversation surfaces in leadership meetings, LinkedIn threads, or hallway debates. Recently, I’ve been reflecting on it from two angles:

  • First, I’ve seen organizations under new leadership take very different paths; some thrive with dedicated Scrum Masters or Agile Delivery Manager roles, while others remove them and shift responsibilities to engineering managers and teams.
  • Second, I came across a LinkedIn post describing companies letting go of Scrum Masters and Agile coaches, not for financial reasons, but as a conscious redesign of how they deliver software.

Both perspectives reveal a more profound confusion. Many believe Agile itself is outdated; others assume that if Scrum changes, the role associated with it, the Scrum Master, should disappear too.

But are teams really outgrowing Agile?

Or are we simply misunderstanding the purpose of the Agile leader?

Agile Isn’t Dead, But It’s Often Misapplied

When people say “Agile is dead,” they’re rarely attacking its principles. Delivering in small batches, learning fast, and adapting based on feedback are still how modern teams succeed. What’s fading is the packaged version of Agile, the one sold through mass certifications, rigid frameworks, and transformation playbooks.

Much of the backlash comes from poor implementations. Consulting firms rolled out what they called “textbook Scrum,” blending practices from other frameworks, such as story points and user stories from Extreme Programming (XP), and applying them everywhere. Teams focused on sprints, standups, and rituals instead of learning and improvement.

Scrum was never meant to be rigid; it’s a lightweight framework for managing complexity. When treated as a checklist, it becomes “cargo-cult” Agile, copying rituals without purpose. When that fails, organizations often blame the framework, rather than the implementation.

That misunderstanding extends to the Scrum Master role itself. Many assume that dropping Scrum means dropping the Scrum Master. But the need for someone to coach, facilitate, and sustain continuous improvement doesn’t vanish when frameworks evolve.

Do We Still Need an Agile Leader?

Whether following Scrum or as organizations transition to Kanban or hybrid flow models, many are eliminating Agile leadership roles. Responsibilities once owned by a Scrum Master or Agile Coach are now:

  • absorbed by Engineering Managers,
  • distributed across team members, or
  • elevated to Program Management.

On paper, this looks efficient. In reality, it often creates a gap because no one is explicitly accountable for maintaining flow, team health, and continuous improvement.

The Role’s Evolution and Its Reputation

Over time, the Scrum Master evolved into roles such as Agile Coach, Agile Leader, or Agile Delivery Manager (ADM) leaders who:

  • coached flow and sustainability,
  • resolved cross-team dependencies,
  • championed experimentation and team health, and
  • used flow metrics to surface bottlenecks and team delivery performance.
  • connect delivery initiatives or epics with business outcomes.

These were not meeting schedulers. They were system stewards, enabling teams to deliver effectively and sustainably.

Unfortunately, the role’s reputation suffered as the industry scaled too fast. The explosion of two-day certification courses created an influx of “certified experts” with little experience. Many were placed in impossible positions, expected to transform organizations without the authority or mentorship to succeed. Some individuals grew into exceptional Agile leaders, while others struggled.

The uneven quality left leaders skeptical. That’s not a failure of the role itself, but a byproduct of how quickly Agile became commercialized.

When the Role Disappears (or Gets Folded Into Management)

In some organizations, the Agile leadership role has been absorbed by Engineering Managers. On paper, this simplifies accountability and structure. In practice, it creates new trade-offs:

  • Overload: Engineering Managers juggle hiring, technical design and strategy, people development, and implementation oversight. Adding Agile facilitation stretches them thin.
  • Loss of neutrality: It’s hard to be both coach and evaluator. Psychological safety and open reflection suffer.
  • Reduced focus: Good Agile leaders specialize in flow, metrics, and process improvement. Those responsibilities often fade when combined with other priorities.

I’m watching this shift happen in real time. In one organization that removed its Agile leaders, Engineering Managers now coordinate ceremonies and metrics while trying to sustain alignment. The administrative tasks are covered, but continuous improvement and team sentiment have slipped out of focus. There’s only so much one role can absorb before something important gives way.

These managers, once deeply technical and people-oriented, now find themselves stretched across too many competing responsibilities. It’s still early, but the question isn’t whether meetings happen; it’s whether performance, flow, and engagement can sustain without a separate role dedicated to nurturing them.

Redistribution to Program Management

Some of the higher-level coaching and metrics work has moved into Program Management. Many program managers at this organization hold Scrum Master certifications and act as advisors to Engineering Managers, while maintaining flow metrics and ensuring value stream visibility.

It’s a reasonable bridge, but scale limits its impact. A single program manager may support six to eight teams, focusing only on the most critical issues. The broader discipline of continuous improvement, including reviewing flow data, addressing bottlenecks, or mapping value streams, risks fading when no one on the team is closely involved.

Distributing or Rotating Responsibilities

Some teams attempt to share Agile responsibilities: rotating facilitators, distributing meeting ownership, or collectively tracking metrics. It’s a well-intentioned model that works for mature, stable teams, but it has limits.

  • Frequent rotation breaks continuity and learning.
  • Coaching depth is lost when no one develops mastery.
  • Under delivery pressure, improvement tasks fall to the bottom of the list.

Distributed ownership can work in bursts, but it rarely sustains long-term improvement. Someone still needs to own the system, even if the title is gone.

Leadership Mindsets Define Success

Whether an organization retains or removes Agile leaders often comes down to mindset.

Execution-First Leadership (Command & Control):

  • Believes delivery can be managed through structure and accountability.
  • Sees facilitation and coaching as overhead.
  • Accepts distributed ownership as “good enough.”

Systems-Enabling Leadership (Servant / Flow):

  • Believes facilitation and improvement require focus and skill.
  • Invests in Agile leaders to strengthen flow and collaboration.
  • Sees distributed responsibility as a step, not a destination.

Neither model is inherently wrong; they reflect different views on how improvement happens. But experience shows a clear trade-off: when continuous improvement is one of many responsibilities, it often becomes no one’s priority. A dedicated Agile leader keeps that focus alive; an overloaded manager rarely can for long. The key is designing a system where improvement has space to breathe, not just another task on an already full plate.

The Myth of the Unicorn

When organizations integrate Agile leadership into engineering management or product management, they often create “unicorns”-individuals expected to possess both deep core skills and be effective leaders, delivery owners, and process coaches simultaneously.

Those who can do this well are rare, and even they struggle with constant task-switching across competing priorities. When these high performers leave, the organization loses more than a person; it loses context, flow awareness, and continuity. Replacing them is difficult; few candidates in the market combine such a broad mix of technical, leadership, and coaching skills.

Scrum, Kanban, and What Doesn’t Change

Practices evolve. Scrum remains widely used, but many teams operate in Kanban or hybrid systems. The shift to continuous delivery doesn’t eliminate the need for Agile leadership; if anything, it heightens it.

As work becomes more distributed and complex, teams still need a steward of flow and feedback. Frameworks differ; however, the function that enables collaboration and systemic improvement remains the same.

The Path Forward: Protect the Capability, Not the Title

Instead of asking, “Should we bring Scrum Masters back?” leaders should be asking a more fundamental question:

Who in our organization is responsible for enabling collaboration, removing impediments, promoting improvement, maintaining team health, and driving systemic learning?

If the answer is “no one,” it doesn’t matter what you call the role; you have a gap.

If the answer is “partially someone (rotated or shared),” acknowledge the compromise, the diffusion of ownership, and a loss of focus, and revisit it as the organization matures.

Agile will continue to exist with or without a dedicated Scrum Master or Agile Leader. Frameworks evolve, but the principles, small batches, fast feedback, and empowered teams remain the same. Having a dedicated role strengthens a team’s ability to apply those principles consistently. Without one, Agile doesn’t vanish, but performance and improvement discipline often do.

The point isn’t about losing Agile practices; it’s about the risk of losing stewardship. Without it, the habits that once drove learning and improvement fade, and teams can inevitably slide back toward the rigid, hierarchical models Agile set out to change.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

Related Reading

If this topic resonated with you, you may find these articles valuable as complementary perspectives:

From Two Pizzas to One: How AI Reshapes Dev Teams

by

Exploring how AI could reshape software teams, smaller pods, stronger guardrails, and the balance between autonomy and oversight.

7 min read

For more than two decades, Jeff Bezos’s “two-pizza team” rule has been shorthand for small, effective software teams: a group should be small enough that two pizzas can feed them, typically about 5–10 people. The principle is simple: fewer people means fewer communication lines, less overhead, and faster progress. The math illustrates this well: 10 people create 45 communication channels, while four people create just six. Smaller groups spend less time coordinating, which often leads to faster outcomes.

This article was sparked by a comment at this year’s Enterprise Technology Leadership Summit. A presenter suggested that AI could soon reshape how we think about team size. That got me wondering: what would “one-pizza teams” actually look like if applied to enterprise-grade systems where resilience, compliance, and scalability are non-negotiable?

The Hype: “Do We Even Need Developers?”

In recent months, I’ve heard product leaders speculate that AI might make developers optional. One senior product manager even suggested, half-seriously, that “we may not need developers at all, since AI can write code directly.” On the surface, that sounds bold. But in reality, it reflects limited hands-on experience with the current tools. Generating a demo or prototype with AI is one thing; releasing code into a production system, supporting high-volume, transactional workloads with rollback, observability, and compliance requirements, is another. It’s easy to imagine that AI can replace developers entirely until you’ve lived through the complexity of maintaining enterprise-grade systems.

I’ve also sat in conversations with CTOs and VPs excited about the economics. AI tools, after all, look cheap compared to fully burdened human salaries. On a spreadsheet, reducing teams of 8–12 engineers down to one or two may appear to unlock massive savings. But here again, prototypes aren’t production, and what looks good in theory may not play out in practice.

The Reality Check

The real question isn’t whether AI eliminates developers, it’s how it changes the balance between humans, tools, and team structure. While cost pressures may tempt leaders to shrink teams, the more compelling opportunity may be to accelerate growth and innovation. AI could enable organizations to field more small teams in parallel, modernize multiple subdomains simultaneously, deliver features faster, and pivot quickly to outpace their competitors.

Rather than a story of headcount reduction, one-pizza teams could become a story of capacity expansion, with more teams and a broader scope, all while maintaining the same or slightly fewer people. But this is still, to some extent, a crystal ball exercise. None of us can predict with certainty what teams will look like in three, five, or ten years. What seems possible today is that AI enables smaller pods to take on more responsibility, provided we approach this shift with caution and discipline.

Why AI Might Enable Smaller Teams

AI’s value in this context comes from how it alters the scope of work for each developer.

Hygiene at scale. Practices that teams often defer, such as tests, documentation, release notes, and refactors, can be automated or continuously maintained by AI. Quality could become less negotiable and more baked into the process.

Coordination by contract. AI works best when given context. PR templates, paved roads, and CI/CD guardrails provide part of that. But so do rule files, lightweight markdown contracts such as cursor_rules.md or claude.md that encode expectations for test coverage, security practices, naming conventions, and architecture. These files give AI the boundaries it needs to generate code that aligns with team standards. Over time, this could transform AI from a generic assistant into a domain-aware teammate.

Broader scope. With boilerplate and retrieval handled by AI, a small pod might own more of the vertical stack, from design to deployment, without fragmenting responsibilities across multiple groups.

Reduced overhead. Acting as a shared memory and on-demand research partner, AI can minimize the need for lengthy meetings or additional specialists. Coordination doesn’t disappear, but some of the lower-value overhead could shrink.

From Efficiency to Autonomy

The promise isn’t simply in productivity gains per person; it may lie in autonomy. AI could provide small pods with enough context and tooling to operate independently. This autonomy might enable organizations to spin up more one-pizza teams, each capable of covering a subdomain, reducing technical debt, delivering features, or running experiments. Instead of doing the same work with fewer people, companies might do more work in parallel with the same resources.

How Roles Could Evolve

If smaller teams become the norm, roles may shift rather than disappear.

  • Product Managers could prototype with AI before engineers write code, run quick user tests, and even handle minor fixes.
  • Designers might use AI to generate layouts while focusing more on UX research, customer insights, and accessibility.
  • Engineers may be pushed up the value chain, from writing boilerplate to acting as architects, integrators, and AI orchestrators. This creates a potential career pipeline challenge: if AI handles repetitive tasks, how will junior engineers gain the depth needed to become tomorrow’s architects?
  • QA specialists can transition from manual testing to test strategy, utilizing AI to accelerate execution while directing human effort toward edge cases.
  • New AI-native roles, such as prompt engineers, context engineers, AI QA, or solutions architects, may emerge to make AI trustworthy and enterprise-aligned.

In some cases, the traditional boundaries between product, design, and engineering could blur further into “ProdDev” pods, teams where everyone contributes to both the vision and the execution.

The Enterprise Reality

Startups and greenfield projects may thrive with tiny pods or even solo founders leveraging AI. But in enterprise environments, complexity doesn’t vanish. Legacy systems, compliance, uptime, and production support continue to require human oversight.

One-pizza pods might be possible in select domains, but scaling them down won’t be simple. Where it does happen, success may depend on making two human hats explicit:

  • Tech Lead – guiding design reviews, threat modeling, performance budgets, and validating AI output.
  • Domain Architect – enforcing domain boundaries, compliance, and alignment with golden paths.

Even then, these roles rely on shared scaffolding:

  • Production Engineering / SRE  -managing incidents, SLOs, rollbacks, and noise reduction.
  • Platform Teams – providing paved roads like IaC modules, service templates, observability baselines, and policy-as-code.

The point isn’t that enterprises can instantly shrink to one-pizza teams, but that AI might create the conditions to experiment in specific contexts. Human judgment, architecture, and institutional scaffolding remain essential.

Guardrails and Automation in Practice

For smaller pods to succeed, standards need to be non-negotiable. AI may help enforce them, but humans must guide the judgment.

Dual-gate reviews. AI can run mechanical checks, while humans approve architecture and domain impacts.

Evidence over opinion. PRs should include artifacts, tests, docs, and performance metrics, so reviews are about validating evidence, not debating opinions.

Security by default. Automated scans block unsafe merges.

Rollback first. Automation should default to rollback, with humans approving fixing forward.

Toil quotas. Reducing repetitive ops work quarter by quarter keeps small teams sustainable.

Beyond CI, AI can also shape continuous delivery by optimizing pipelines, enforcing deployment policies, validating changes against staging telemetry, and even self-healing during failures.

What’s Real vs. Wishful Thinking (2025)

AI is helping, but unevenly. Gains emerge when organizations re-architect workflows end-to-end, rather than layering AI on top of existing processes.

Quality and security remain human-critical. Studies suggest a high percentage of AI-generated code carries vulnerabilities. AI may accelerate output, but without human checks, it risks accelerating flaws.

AI can make reviews more efficient by summarizing diffs and flagging issues, but final approval still requires human judgment on architecture and risk.

And production expectations haven’t changed. A 99.99% uptime commitment still allows only 15 minutes of downtime per quarter. Even if AI can help remediate, humans remain accountable for those calls.

Practitioner feedback is also worth noting. In conversations with developers and business users of AI, most of whom are still in their first year of adoption, the consensus is that productivity gains are often inflated. Some tasks are faster with AI, while others require more time to manage context. Most people view AI as a paired teammate, rather than a fully autonomous agent that can build almost everything in one or two shots.

Challenges to Consider

Workforce disruption. If AI handles more routine work, some organizations may feel pressure to reduce the scope of specific roles. Whether that turns into cuts or an opportunity to reskill may depend on leadership choices.

Mentorship and pipeline. Junior engineers once learned by doing the work AI now accelerates. Without intentional design of new learning paths, we may risk a gap in the next generation of senior engineers.

Over-reliance. AI is powerful but not infallible. It can hallucinate, generate insecure code, or miss subtle regressions. Shrinking teams too far might leave too few human eyes on critical paths.

A Practical Checklist

  • Product risk: 99.95%+ SLOs or regulated data? Don’t shrink yet.
  • Pager noise: <10 actionable alerts/week and rollback proven? Consider shrinking.
  • Bus factor: ≥3 engineers can ship/release independently? Consider shrinking.
  • AI Maturity: Are AI Checks and PR Evidence Mandatory? Consider shrinking.
  • Toil trend: Is toil tracked and trending down? Consider shrinking.

Bottom Line

AI may make one-pizza teams possible, but only if automation carries the repetitive workload, humans maintain judgmental oversight, and guardrails ensure standards. Done thoughtfully, smaller pods don’t mean scarcity; they can mean focus.

And when organizations multiply these pods across a portfolio, the outcome might not just be sustaining velocity but accelerating it: more features, faster modernization, shorter feedback loops, and quicker pivots against disruption.

This is the story of AI in team structure, not doing the same with less, but doing more with the same.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

Beyond Delivery: Realizing AI’s Potential Across the Value Stream

by

Moving beyond AI-assisted delivery to achieve measurable, system-wide impact through value stream visibility and flow metrics.

10 min read

At the 2025 Engineering Leadership Tech Summit, Mik Kersten previewed ideas from his upcoming book, Output to Outcome: An Operating Model for the Age of AI. He reminded us of a truth often overlooked in digital transformation: Agile delivery teams are not the constraint in most cases.

Kersten broke out the software value stream into four phases: Ideate, Create, Release, Operate, and showed how the majority of waste and delay happens outside of coding. One slide in particular resonated with me. Agile teams accounted for just 8% of overall cycle time. The real delays sat at the bookends: 48% in ideation, slowed by funding models, approvals, and reprioritizations; and 44% in release, bogged down by dependencies, technical debt, and manual processes.

This framing raises a critical question: if we only apply AI to coding or delivery automation, are we just accelerating the smallest part of the system while leaving the actual bottlenecks untouched?

AI in the Delivery Stage: Where the Industry Stands

In a recent DX Engineering Enablement podcast, Laura Tacho and her co-hosts discussed the role of AI in enhancing developer productivity. Much of their discussion centered on the Create and Release stages: code review, testing, deployment, and CI/CD automation. Laura made a compelling point about moving beyond “single-player mode”:

“AI is an accelerant best when it’s used at an organizational level, not when we just put a license in the hands of an individual… Platform teams can own a lot of the metaphorical AI headcount and apply it in a horizontal way across the organization.”

Centralizing AI adoption and applying it across delivery produces leverage, rather than leaving individuals to experiment in isolation. But even this framing is still too narrow.

The Missing Piece: AI Adoption Across the Entire Stream

The real opportunity is to treat AI not as a tool for delivery efficiency, but as a partner across the entire value stream. That means embedding AI into every stage and measuring it with system-level visibility, not just delivery dashboards.

This is why I value platforms that integrate tool data across the whole stream, system metrics and visibility dashboards, rather than tools that stop at delivery.

Of course, full-stream visibility platforms are more expensive, and in many organizations, only R&D teams are driving efforts to improve flow. As I’ve argued in past writing on SEI vs. VSM, context matters: sometimes the right starting point is SEI, when delivery is the bottleneck. But when delays span ideation, funding, or release, only a VSM platform can expose and address systemic waste.

AI opportunities across the stream:

  • Ideation (48%) – Accelerate customer research, business case drafting, and approvals; surface queues and wait states in one view.
  • Create (8%) – Apply AI to coding, reviews, and testing, but tie it to system outcomes, not vanity speedups.
  • Release (44%) – Automate compliance, dependency checks, and integration work to reduce handoff delays.
  • Operate – Target AI at KTLO and incident patterns, feeding learnings back into product strategy.

When AI is applied across the whole system (value stream), we can ask a better question: not “How fast can we deploy?” but “How much can we compress idea-to-value?” Moving from 180 days to 90 days or less becomes possible when AI supports marketing, product, design, engineering, release, and support, and when the entire system is measured, not just delivery.

VSM vs. Delivery-Only Tooling

This is where tooling distinctions matter. DX Core 4 and SEI platforms, such as LinearB, focus on delivery (Create and Release), which is valuable but limited to one stage of the system. Planview Viz and other VSM platforms, by contrast, elevate visibility across the entire value stream.

Delivery-only dashboards may show how fast you’re coding or deploying. But Value Stream Management reveals the actual business constraints, often upstream in funding, prioritization, PoCs, and customer research, or downstream in handoffs and release.

Without that lens, AI risks becoming just another tool that speeds up developers without improving the system.

AI as a Force Multiplier in Metrics Platforms

AI embedded directly into metrics platforms can change the game. In a recent Product Thinking podcast, John Cutler observed:

“We talked to a company that’s spending maybe $4 million in staff hours per quarter around just people spending time copying and prepping for all these types of things… All they’re doing is creating a dashboard, pulling together a lot of information, and re-contextualizing it so it looks the same in a meeting. I think that’s just a massive opportunity for AI to be able to help with that kind of stuff.”

This hidden cost of operational overhead is real. Leaders and teams waste countless hours aggregating and reformatting data into slides or dashboards to make it consumable.

Embedding AI into VSM or SEI platforms removes that friction. Instead of duplicating effort, AI can generate dashboards, surface insights, and even facilitate the conversations those dashboards are meant to support.

This is more of a cultural shift than a productivity gain. Less slide-building, more strategy. Less reformatting, more alignment. And metrics conversations that finally scale beyond the few who have time to stitch the story together manually.

The ROI Lens: From Adoption to Efficiency

The ROI of AI adoption is no longer a question of whether to invest; that decision is now a given. As Atlassian’s 2025 AI Collaboration Report shows, daily AI usage has doubled in the past year, and executives overwhelmingly cite efficiency as the top benefit.

The differentiator now is how efficiently you manage AI’s cost, just as the cloud debate shifted from whether to adopt to how well you could optimize spend.

But efficiency cannot be measured by isolated productivity gains. Atlassian found that while many organizations report time savings, only 4% have seen transformational improvements in efficiency, innovation, or work quality.

The companies breaking through embed AI across the system: building connected knowledge bases, enabling AI-powered coordination, and making AI part of every team.

That’s why the ROI lens must be grounded in flow metrics. If AI adoption is working, we should see:

  • Flow time shrink
  • Flow efficiency rises
  • Waste reduction is visible in the stream
  • Flow velocity accelerates (more items delivered at the same or lower cost)
  • Flow distribution rebalance (AI resolving technical debt and reducing escaped defects)
  • Flow load stabilization (AI absorbing repetitive work and signaling overload early)

VSM system-wide platforms make these signals visible, showing whether AI is accelerating the idea-to-value process across the entire stream, not just helping individuals move faster.

Bringing It Full Circle

In recent conversations with a large organization’s CTO, and again with Laura while exploring how DX and Anthropic measure AI, I kept returning to the same point: we already have the metrics to know if AI is making an impact. AI is now just another option or tool in our toolbox, and its effect is reflected in flow metrics, change failure rates, and developer experience feedback.

We are also beginning to adopt DX AI Framework metrics, which are structured around Utilization, Impact, and Cost, aligning with the metrics that companies like Dropbox and Atlassian currently measure. But even as we incorporate these, we continue to lean on system-level flow metrics as the foundation. They are what reveal whether AI adoption is truly improving delivery across the value stream, from ideation to production.

Leadership Lessons from McKinsey and DORA

This perspective also echoes Ruba Borno, VP at AWS, in a recent McKinsey interview on leading through AI disruption. She noted that while AI’s pace of innovation is unprecedented, only 20–30% of proofs of concept reach production. The difference comes from data readiness, security guardrails, leadership-driven change management, and partnerships.

And the proof is tangible: Canva, working with AWS Bedrock, moved from the idea of Canva Code to a launched product in just 12 weeks. That’s precisely the kind of idea-to-operation acceleration we need to measure. It shows that when AI is applied systematically, you don’t just make delivery faster; you also make the entire flow from concept to customer measurably shorter.

The 2025 DORA State of AI-Assisted Software Development Report reinforces this reality. Their cluster analysis revealed that only the top performers, approximately 40% of teams, currently experience AI-enhanced throughput without compromising stability. For the rest, AI often amplifies existing dysfunctions, increasing change failure rates or generating additional waste.

Leadership Implications: What the DORA Findings Mean for You

The 2025 DORA report indicates that only the most mature teams currently benefit from AI-assisted coding. For everyone else, AI mostly amplifies existing problems. What does that mean if you’re leading R&D?

1. Don’t skip adoption, but don’t roll it out unthinkingly.

AI is here to stay, but it’s not a silver bullet. Start small with teams that already have strong engineering practices, and use them to build responsible adoption patterns before scaling.

2. Treat AI as an amplifier of your system.

If your flow is healthy, AI accelerates it. If your flow is dysfunctional, AI makes it worse. Think of it like a turbocharger: great when the engine and brakes are tuned, dangerous when they’re not.

3. Use metrics to know if AI is helping or hurting.

  • Flow time, efficiency, and distribution should improve.
  • DORA’s stability metrics (such as change failure rate) should remain steady or decline.
  • Developer sentiment should show growing confidence, not frustration.

4. Fix bottlenecks in parallel.

AI won’t remove waste; it will expose it faster. Eliminate approval delays, reduce tech debt, and streamline release processes so AI acceleration actually creates value.

5. Value of the message:

The lesson isn’t “don’t adopt AI.” It’s: adopt responsibly, measure outcomes, and strengthen your system so that AI becomes an accelerant, not a liability.

Ruba’s message, reinforced by both McKinsey and DORA, leads to the same conclusion: AI adoption succeeds when it’s measured at the system level, tied to business outcomes, and championed by leadership. Without that visibility, organizations risk accelerating pilots that never translate into value.

Conclusion: Beyond Delivery

The conversation about AI in software delivery is maturing. It’s no longer just about adoption, but about managing costs and system impact. AI must be measured not only by its utilization but also by how it improves flow efficiency, compresses the idea-to-value cycle, and reduces systemic waste.

The organizations that will win in this new era are those that:

  • Embed AI across the entire value stream, not just in delivery.
  • Measure ROI through flow metrics that connect improvements to business outcomes.
  • Manage AI’s cost as carefully as they once managed cloud costs.
  • Lead with visibility, change management, and partnerships to scale adoption.

And critically, successful AI integration requires more than deploying tools. It requires thoughtful measurement, training, and best practices for implementation in software engineering to sustain quality while ensuring that training and strategy are applied consistently across all roles, from product and design to operations and support. Only then can organizations ensure that the promise of acceleration improves outcomes without undermining the collaboration and sustainability that long-term software success depends on.

In short: AI in delivery is helpful, but AI across the value stream is transformational.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

References

Further Reading

For readers interested in exploring AI ideas further, here are a few related pieces from my earlier writing:

Smarter Pull Requests: Balancing AI, Automation, and Human Review

by

Best practices for AI-enhanced pull requests, combining rules, templates, CI checks, and human review to deliver faster, safer code

6 min read

Author’s Note

This handbook began as a PDF. I used Cursor to help me convert it into a GitHub repository project/document. While I might reference Microsoft Copilot and Claude Code for AI-assisted implementation, the focus here is on AI pull request assistants, such as:

  • GitHub Copilot for Pull Requests – generates AI review comments, PR summaries, and change explanations. It’s useful, but like the others below, it is just one piece of the bigger picture.
  • CodeRabbit – delivers AI-powered PR summaries and line-by-line feedback.
  • AI Code Review (GitHub Action) – runs an AI model on each PR and posts intelligent review comments.
  • PR-Agent (by Qodo) – open-source tool that integrates with GitHub and GitLab to review, summarize, and improve PRs.

The examples lean on GitHub Actions for the delivery pipeline, though almost everything here can be adapted to other AI tools or CI systems (GitLab, CircleCI, Jenkins, etc.). Think of this less as a one-size-fits-all recipe and more as a set of patterns you can tailor to your stack.

AI can generate code at unprecedented speed, but accountability for what goes into production still rests with humans. This raises a new challenge: how do we ensure the quality, security, performance, and resilience of what enters production when code can be created faster than ever?

This guide explores how to integrate AI responsibly into the pull request process, using rules files, standardized templates, automation, and CI enforcement, while keeping human reviewers focused on design, correctness, and risk.

It proposes a framework for AI-augmented pull requests (PRs) that combines:

  • Rules files for context and consistency
  • An evidence-based PR template
  • AI pull request checks (such as GitHub AI PR Review tools, Copilot, or Claude Code) to surface gaps and propose fixes
  • CI enforcement to block merges if Core rules aren’t satisfied
  • Human review focused on design, correctness, and business alignment

This is not a set of coding best practices or AI coding instructions. It is specifically focused on pull request practices, where AI tools assist in review, validation, and context management.

Introduction

AI can help us write code faster, but this guide is not about AI writing code. It’s about AI assisting in the pull request process to ensure higher quality reviews. Today, and for the near future, AI does not carry responsibility for what runs in production. That accountability remains with developers and teams.

When throughput increases, small gaps in the review process become large risks: inconsistent PRs, checklist fatigue, missing links to tests or observability, and late integration surprises. AI can unintentionally worsen this by enabling more partially validated changes to reach review.

This handbook proposes suggested practices for PRs that raise the floor without slowing delivery:

  • Rules as guidelines: Core rules apply everywhere; supporting and domain-specific rules (e.g., architecture, observability, NASA “Power of 10”) layer on when relevant.
  • Evidence over assertion: A PR template that requires links to tests, scans, dashboards, and rollback plans.
  • AI + CI assist, humans decide: Copilot and Claude highlight gaps, CI enforces Core rules, and humans evaluate design quality, correctness, and risk.
  • Delivery-model aware: Works for both trunk-based delivery and batch releases, with extra release-level validation where needed.

The goal is to standardize within reason and establish clear, paved paths that teams can adopt, ensuring quality, security, and resilience are consistent across the organization.

A Spark of Inspiration

This handbook was inspired by an AI adoption all-hands discussion. In its wake, I shared an early draft of the handbook internally with our teams to offer an option to consolidate scattered conversations about AI in PRs.

At that time, more GitHub AI-assisted PR reviews and comments were showing up, but no single wiki or README explained how to integrate AI consistently into pull requests. The intent was simple:

If similar content already exists elsewhere, this can be ignored. However, if not, some parts of it can still be valuable. The goal is to provide guidelines, support standardization (within reason), and create paved paths others can benefit from.

That spirit continues here: not prescriptive rules, but a framework that others can adapt.

Why PR Automation Matters

PRs are the critical checkpoint between individual work and shared code. With AI accelerating output, weaknesses in the PR process become more visible:

  • Inconsistent PRs – some provide detailed evidence, others say “fixed bug” with no links.
  • Checklist fatigue – reviewers repeat “Did you add tests? Where’s the migration plan?”
  • Missing context – no links to test runs, coverage, or dashboards.
  • Integration risk – batch releases expose conflicts late.

Automation addresses these by:

  • Standardizing expectations
  • Automating validation of mechanics
  • Requiring evidence (links, not assertions)
  • Scaling across delivery models
  • Ensuring auditability

The Framework

Rules Files

  • Core rules (.ai/core-rules.md) are universal.
  • Supporting rules (architecture, observability, flags, etc.) apply when relevant.
  • Domain-specific rules (e.g., NASA “Power of 10”) may be adopted in specialized contexts.

PR Template

A standardized PR template ensures evidence over assertions:

  • Outcome & risk/rollback plan
  • AI assistance disclosure
  • Links to unit/integration tests, coverage %
  • Links to security scans (SAST, SCA, secrets)
  • Observability metrics & dashboards
  • Feature flag configs & rollback toggles

AI Gate Checks

  • Copilot: Summarizes diffs, fills PR template, highlights missing links.
  • Claude Code: Auto-loads CLAUDE.md; commands like /check-pr, /add-observability, /migration-plan.

GitHub Action: PR Rules Check

CI Enforcement

GitHub Actions validate that Core sections exist, placeholders are filled, and evidence is linked. Merges are blocked until fixed.

Human Review

Automation raises the floor. Humans still:

  • Evaluate design and architecture.
  • Confirm correctness and business fit. (Note: once business documentation is part of the AI context, AI can help with this as well).
  • Assess readability, maintainability, and tradeoffs.

Delivery Models

Trunk-Based Delivery

  • Each PR is a release candidate.
  • Core rules enforced at the PR level.

Batch Release Trains

  • PR-level rules still apply.
  • Additional release-level validation:
    • Manifest listing features, risks, and rollback plans
    • Integrated regression + performance tests
    • Migration coordination across features
    • Staged rollout with auto-abort thresholds

Example: Day in the Life of a PR

  1. Developer opens PR → template fills automatically.
  2. Runs /check-pr in Claude → surfaces missing test link & observability metric.
  3. Adds links to unit/integration tests, coverage report, CodeQL scan, Grafana dashboard.
  4. Pushes update → GitHub Action validates Core rules.
  5. Human reviewer now focuses on API design, domain model, and risk.
  6. PR merges with confidence.

Evidence Links Table

RuleExample Evidence
Unit/Integration testsGitHub Actions run
Coverage %Codecov report
Security scansCodeQL, Snyk, Gitleaks
ObservabilityGrafana dashboards, trace spans
FlagsLaunchDarkly or similar Flag configs
ProvenanceSBOM artifact

Workflow Diagram

Resources (complete versions of the handbook)

Want the deep dive? Grab one of the complete handbook versions below.

Conclusion

AI speeds up coding, but responsibility for production code remains with humans. By embedding rules, templates, AI gate checks, CI enforcement, and human judgment into PRs, organizations can keep pace with AI while preserving accountability.

This handbook is a starting point: a framework of guidelines to help identify areas of standardization and clear paths forward that teams at all levels of an organization can benefit from.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

References

So, What Does a VP of Software Engineering Do?

by

7 min read

This article began as a response to a colleague in the industry, Patrice Corbard, a DevOps advisor, trainer, and author in France, who asked me a simple but difficult question:

“Can you describe what you consider to be the most important jobs-to-be-done in your role as VP of Engineering, as well as the pains and gains, ranked in order of importance?”

It’s a fair question. If you search online, you’ll find plenty of job descriptions and responsibility lists. What you won’t find is a candid look at the role from the inside, what you’re accountable for, what makes the job rewarding, and what makes it challenging.

My answer to Patrice became the inspiration for this article. What follows isn’t a universal definition of the VP of Engineering role. It’s how the role has applied to me, shaped by my experience, the transformations I’ve led, the leadership cultures I’ve worked within, and the context of our change initiatives, growth, and acquisitions in a highly evolving digital industry.

When most people ask me what I do as a VP of Software Engineering, they sometimes expect a simple answer: “You lead engineers, right?”

The truth is, the role of VP of Engineering isn’t black-and-white. It depends heavily on:

  • The size and stage of the company
  • The leadership culture you operate within
  • The context of the organization

What I can share is my journey, how the role has evolved for me, what I’ve been held accountable for, and what it’s been like.

My Journey to VP of Engineering

When I joined Parchment over a decade ago, I brought over a decade of enterprise software engineering, architecture, and leadership experience.

At Parchment, the engineering teams were still operating in waterfall silos. The organization just started moving to Agile and Scrum ceremonies. Delivery was slow, fragile, and disconnected from business outcomes.

My earliest accountability as a Director of Engineering was helping engineering transform with highly skilled, passionate, open-minded team members, moving us toward Agile, Lean, and DevOps practices that allowed us to ship with confidence.

The shift wasn’t simply about adopting new frameworks, but demanded a deeper transformation. It required me, my team, and many leaders around me to learn, unlearn, and relearn. To lead effectively, I had to embody humility and set the standard through my own actions.

Over time, my role expanded as the organization scaled. What started with a few dozen engineers as a Director eventually grew to more than 175 people across 10 countries as a VP of Engineering. And with that growth, the scope of my responsibilities shifted.

Four Pillars of Accountability

Looking back, I can summarize my VP responsibilities into four enduring accountabilities:

1. Enterprise-Level Software Quality and Resilience

  • Ensure stability and reliability of delivery
  • Support automation initiatives and efforts, shorten lead times
  • Use flow metrics to measure and improve

2, People Engagement

  • Without engaged teams, delivery grinds to a halt
  • Engagement comes from psychological safety, inclusion, autonomy, purpose, and leadership that people trust

3. Retention and Development

  • Attracting great talent is hard; retaining them is harder
  • Build career frameworks, coach managers, and provide growth opportunities
  • Much of my time went into developing engineers who had just stepped into leadership

4. Skills and Capabilities

  • Keep teams competitive in today’s tech landscape
  • Don’t chase every shiny tool, but invest in learning, experimentation, and the right capabilities

Everything else I did, adopting Value Stream Management (VSM), integrating AI copilots, partnering with Product, aligning with Finance, flowed back into these four pillars.

Balancing Global Talent

Another dimension of the VP role is managing the distribution and cost of talent. U.S. hiring alone can’t always scale, so part of my responsibility was building a model that included nearshore, offshore, and local teams.

Sometimes that meant intentionally diversifying where and how we hired. Other times, it meant adapting through acquisitions in new geographies, inheriting engineering teams with their own culture, practices, and expectations.

In both cases, the challenge wasn’t just financial. It was about creating alignment across different regions, time zones, and cultures, while still building one cohesive engineering organization.

Getting this right was critical not only to scaling sustainably but also to retaining talent and protecting delivery resilience as the company grew globally.

Beyond Delivery: Transformation and Business Alignment

The VP role isn’t only about keeping the trains running.

I was deeply involved in:

  • Technical due diligence in acquisitions
  • Aligning metrics with business outcomes
  • Contributing to valuations during funding rounds and ownership changes

It also meant championing long-term transformation strategies:

  • Moving from waterfall to Agile, Lean, DevOps, and Continuous Delivery
  • Adopting Value Stream Management for end-to-end visibility
  • Driving AI literacy and adoption across engineering

AI adoption is about building a culture of learning, experimentation, and practical adoption so teams build real capability.

One truth I learned: engineering only matters if it’s connected to the growth engine of the business. Otherwise, it gets treated as a cost center.

VP of Engineering vs. CTO

I’m often asked: “What’s the difference between a VP of Engineering and a CTO?”

From my experience:

  • CTO puts technology first, people second. They set the vision, connect strategy to growth, and influence investors.
  • VP of Engineering puts people and practices first, technology second. My job is to build engaged teams and strong delivery systems so the strategy is executed at scale.

Both roles are essential. One is about what we bet on. The other is about how people and systems deliver it.

Leadership Culture Shapes the Role

Another factor that defined my journey was who I reported to and the leadership culture around me.

  • For most of my tenure, I reported to a leader who gave me autonomy and trusted me. Those years were expansive; we built team autonomy, focused on improving delivery cadence, agility, and flow, and made measurable progress.
  • When that leader retired, a new CTO arrived. He spoke Agile but led with command-and-control habits. It clashed with our progress and felt like a hand grenade in the middle of our transformation.
  • Later, after an acquisition, a VP of Product replaced the CTO and owned both Product and technology. Our philosophies diverged, but where we were aligned, in people and culture, we found common ground.

The lesson: your autonomy and alignment with peers and superiors shape the job.

One of the most underestimated jobs-to-be-done for a VP of Engineering is this: setting and sustaining long-term strategy, digital transformation, Agile, VSM, team outcomes and performance feedback, and building competitive advantage through culture and delivery. But here’s the catch: a change in senior leadership above you can accelerate that strategy, or derail it overnight.

From T-Shaped to V-Shaped Skills

A VP of Engineering can’t stand still.

Early on, I had strong T-shaped skills, depth in engineering, and breadth in adjacent areas. But to operate at the executive level, I had to develop what I call V-shaped skills: depth in engineering plus meaningful depth in several other domains.

That meant deliberate, ongoing investment in learning:

  • Scaling organizations: team topologies, value streams, spans of control
  • Strategy and OKRs: translating strategy into objectives and results
  • Funding, M&A: diligence, integration, and how maturity shows up in valuation
  • Thinking like a CEO: runway, margins, growth levers, complex tradeoffs
  • Product management: enough depth to partner with product leaders
  • Finance fluency: COGS, OPEX, ROI, metrics that tie tech to earnings
  • Modern architecture & technology: staying credible without micromanaging
  • Leadership craft: books, workshops, conferences, sharpening coaching and communication

It also meant mentoring beyond engineering. In 2024, I participated in our Women in Leadership program, coaching a developing leader. Supporting leaders outside my org was a way to invest in a broader leadership fabric.

And it wasn’t just about formal learning. My success was shaped by mentors and the network I built both inside and outside my organization. Collaborating with senior executives in other companies helped me benchmark our progress, validate practices, and learn from both successes and failures. That external perspective was invaluable in shaping my decisions and accelerating transformation.

The Hard Parts

It isn’t all bright spots.

Being VP of Engineering also meant being accountable for cost-saving measures and layoffs. Those are the darkest days, balancing empathy with business realities while protecting trust and continuity as best you can.

The Highlights

But there are bright spots, too, the moments that make the hard parts worth it.

  • Contributing to a team driving significant organizational growth.
  • Watching team members progress and grow into leaders, contributors, and mentors themselves.
  • Seeing the organization thrive and succeed because of the engineering team’s partnership with product and business.
  • Having the opportunity to mentor others, both inside and outside engineering, and know you’re investing in the company’s leadership future.
  • Helping to build a culture that makes teams proud to come to work, where people feel connected, trusted, and valued.
  • Having a direct impact on something bigger than you.

These are the outcomes that fuel purpose in the role and make the investment in people and practices pay off.

What I’ve Learned

So what does a VP of Engineering do?

  • Ensure software is reliable and resilient
  • Keep teams engaged and thriving
  • Retain and develop people with absolute growth paths
  • Invest in skills and capabilities so teams stay competitive
  • Lead transformation by learning, unlearning, and relearning
  • Align execution with business outcomes
  • Contribute to M&A, funding, and investor communication
  • Drive practices like AI adoption to build long-term capability
  • Navigate leadership cultures, reporting lines, and autonomy
  • Expand from T-shaped to V-shaped skills, supported by mentors and networks
  • Balance global talent through local hiring, nearshore/offshore models, and acquisitions in new geographies

And most of all, accept that the role is never static; it shifts as the company shifts.

Closing Thought

If you’re wondering what a VP of Engineering does, the only honest answer is: it depends.

It depends on the organization, its maturity, and the leadership culture. My story is just one version, shaped by digital transformation, scaling, global talent strategy, AI adoption, mentorship, and peer networks.

What hasn’t changed is this: the job is about building systems of delivery and leadership that last, systems that sustain people, products, and business value long after a single leader has moved on.

And remember: this is just a taste of how the VP of Engineering role has applied to me, in my organizations, and my context.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

AI in Software Delivery: Targeting the System, Not Just the Code

by

7 min read

This article is a follow-up to my earlier post, AI Is Improving Software Engineering. But It’s Only One Piece of the System. In that post, I explored how AI is already helping engineering teams work faster and better, but also why those gains can be diminished if the rest of the delivery system lags.

Here, I take a deeper look at that system-wide perspective. Adopting AI is about strengthening the entire system. We need to think about AI not only within specific teams but across the organizational level, ensuring its impact is felt throughout the value stream.

AI has the potential to improve how work flows through every part of our delivery system: product, QA, architecture, platform, and even business functions like sales, marketing, legal, and finance.

If you already have robust delivery metrics, you can pinpoint exactly where AI will have the most impact, focusing its efforts on the actual constraints rather than “speeding up” work at random. But for leaders who don’t yet have a clear set of system metrics and are still under pressure to show AI’s return on investment, I strongly recommend starting with a platform or framework that captures system delivery performance.

In my previous articles, I’ve outlined the benefits of SEI (Software Engineering Intelligence) tools, DORA metrics (debatable), and, ideally, Value Stream Management (VSM) platforms. These solutions measure and visualize delivery performance across the system, tracking indicators like cycle time, throughput, quality, and stability. They help you understand your current performance and also enable you to attribute improvements, whether from AI adoption or other changes, to specific areas of your workflow. Selecting the right solution depends on your organizational context, team maturity, and goals, but the key is having a measurement foundation before you try to quantify AI’s impact.

The Current Backlash and Why We Shouldn’t Overreact

Recent research and commentary have sparked a wave of caution around AI in software engineering.

A controlled trial by METR (2025) found that experienced developers using AI tools on their repositories took 19% longer to complete tasks than without AI, despite believing they were 20% faster. The 2024 DORA report found similar patterns: a 25% increase in AI adoption correlated with a 1.5% drop in delivery throughput and a 7.2% decrease in delivery stability. Developers felt more productive, but the system-level metrics told another story.

Articles like AI Promised Efficiency. Instead, It’s Making Us Work Harder (Afterburnout, n.d.) point to increased cognitive load, context switching, and the need for constant oversight of AI-generated work. These findings have fed a narrative that AI “isn’t working” or is causing burnout.

But from my perspective, this moment is less about AI failing and more about a familiar pattern: new technology initially disrupts before it levels up those who learn to use it well. The early data reflects an adoption phase, not the end state.

Our Teams’ Approach

Our organization is embracing an AI-first culture, driven by senior technology leadership and, additionally, senior engineers who are leading the charge, innovating, experimenting, and mastering the latest tools and LLMs. However, many teams are earlier in their adoption journey and can feel intimidated by these pioneers. In our division, my focus is on encouraging, training, and supporting engineers to adopt AI tools, gain hands-on experience, explore use cases, and identify gaps. The goal isn’t immediate mastery but building the skills and confidence to use these tools effectively over time.

Only after sustained, intentional use, months down the line, will we have an informed, experienced team that can provide meaningful feedback on the actual outcomes of adoption. That’s when we’ll honestly know where AI is moving the needle, and where it isn’t.

How I Respond When Asked “Is AI Working?”

This approach is inspired by Laura Tacho, CTO at DX, and her recent presentation at LeadDev London, How to Cut Through the Hype and Measure AI’s Real Impact (Tacho, 2025). As a leader, when I face the “how effective is AI?” debate, I ground my answer in three points:

1. How are we performing

We measure our system performance with the same Flow Metrics we used before AI: quality, stability, time-to-value, and other delivery health indicators. We document any AI-related changes to the system, tools, or workflows so we can tie changes in metrics back to their potential causes.

2. How AI is helping (or not helping)

We track where AI is making measurable improvements, where it’s neutral, and where it may be introducing new friction. This is about gaining an honest understanding of where AI is adding value and where it needs refinement.

3. What will we do next

Based on that data and team feedback, we adjust. We expand AI use where it’s working, redesign where it’s struggling, and stay disciplined about aligning AI experiments to actual system constraints.

This framework keeps the conversation grounded in facts, not hype, and shows that our AI adoption strategy is deliberate, measurable, and responsive.

What System Are We Optimizing?

When I refer to “the system,” I mean the structure and process by which ideas flow through our organization, become working software, and deliver measurable value to customers and the business.

Using a Value Stream Management and Product Operating Model approach together gives us that view:

  • Value stream: the whole journey of work from ideation to delivery to customer realization, including requirements, design, build, test, deploy, operate, and measure.
  • Product operating model: persistent, cross-functional teams aligned to products that own outcomes across the lifecycle.

Together, these models reveal not just who is doing the work, but how it flows and where the friction is. That’s where AI belongs, improving flow, clarity, quality, alignment, and feedback across the system.

The Mistake Many Are Making

Too many organizations inject AI into the wrong parts of the system, often where the constraint isn’t. Steve Pereira’s It’s time for AI to meet Flow (Pereira, 2025) captures it well: more AI output can mean more AI-supported rework if you’re upstream or downstream of the actual bottleneck.

This is why I believe AI must be tied to flow improvement:

  1. Make the work visible – Map how work moves, using both our existing metrics and AI to visualize queues, wait states, and handoffs.
  2. Identify what’s slowing it down – Use flow metrics like cycle time, WIP, and throughput to find constraints before applying AI.
  3. Align stakeholders – AI can synthesize input from OKRs, roadmaps, and feedback, so we’re solving the right problems.
  4. Prototype solutions quickly – Targeted, small-scale AI experiments validate whether a constraint can be relieved before scaling.

Role-by-Role AI Adoption Across the Value Stream

AI isn’t just for software engineers, it benefits every role on your cross-functional team. Here are just a few examples of how it can make an impact. There are many more ways for each role than listed below.

Product Managers / Owners

  • Generate Product Requirements Documentation
  • Analyze customer, market, and outcome metrics
  • Groom backlogs, draft user stories, and acceptance criteria.
  • Summarize customer feedback and support tickets.
  • Use AI to prepare for refinement and planning.

QA Engineers

  • Generate test cases from acceptance criteria or code diffs.
  • Detect coverage gaps and patterns in flaky tests.
  • Summarize PR changes to focus testing.

Domain Architects

  • Visualize system interactions and generate diagrams.
  • Validate design patterns and translate business rules into architecture.

Platform Teams

  • Generate CI/CD configurations.
  • Enforce architecture and security standards with automation.
  • Identify automation opportunities from delivery metrics.

InfoSec Liaisons

  • Scan commits and pull requests (PRs) for risky changes.
  • Draft compliance evidence from logs and release data.

Don’t Forget the Extended Team

Sales, marketing, legal, and finance all influence the delivery flow. AI can help here, too:

  • Sales: Analyze and generate leads, summarize customer engagements, and highlight trends for PMs.
  • Marketing: Draft launch content from release notes.
  • Legal: Flag risky language, summarize new regulations.
  • Finance: Model ROI of roadmap options, forecast budget impact.

Risk and Resilience

What happens when AI hits limits or becomes unavailable? Inference isn’t free; costs will rise, subsidies will fade, and usage may be capped. Do you have fallback workflows, maintain manual expertise, and measure AI’s ROI beyond activity? Another reason for us to gain experience with these tools is to improve our efficiency and understand usage patterns.

The Opportunity

We already have the data to see how our system performs. The real opportunity is to aim AI at the constraints those metrics reveal, removing friction, aligning teams, and improving decision-making. If we take the time to learn the tools now, we’ll be ready to use them where they matter most.

What Now?

We already have the metrics to see how our system performs. The real opportunity is to apply AI purposefully across the full lifecycle, from ideation and design, through development, testing, deployment, and into operations and business alignment. By directing AI toward the right constraints, we eliminate friction, unify our teams around clear metrics, and elevate decision-making at every step.

Yes, AI adoption is a learning journey. We’ll stumble, experiment, and iterate, but with intention, measurement, and collaboration, we can turn scattered experiments into a sustained competitive advantage. AI adoption is about transforming or improving the system itself.

AI isn’t failing, it’s maturing. We’re on the rise of the adoption curve. Our challenge and opportunity is to build the muscle and culture to deploy AI across the lifecycle, turning today’s experiments into tomorrow’s engineered advantage.

For anyone still hesitant, know this: AI isn’t going away. Whether it slows us down or speeds us up, we must learn to use it well, or we risk being left behind. Let’s learn. Let’s measure. Let’s apply AI where it’s most relevant and learn to understand its current benefits and limitations. There’s no going back, only forward.

Poking Holes

I invite your perspective on my posts. What are your thoughts?

Let’s talk: phil.clark@rethinkyourunderstanding.com

References

Afterburnout. (n.d.). AI promised efficiency. Instead, it’s making us work harder. Afterburnout. https://afterburnout.co/p/ai-promised-to-make-us-more-efficient

Clark, P. (2025, July). AI is improving software engineering. But it’s only one piece of the system. Rethink Your Understanding. https://rethinkyourunderstanding.com/2025/07/ai-is-improving-software-engineering-but-its-only-one-piece-of-the-system/

METR. (2025, July 10). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

Pereira, S. (2025, August 8). It’s time for AI to meet flow: Flow engineering for AI. Steve Pereira. https://stevep.ca/its-time-for-ai-to-meet-flow/

State of DevOps Research Program. (2024). 2024 DORA report. Google Cloud / DORA. (Direct URL to the report as applicable)

Tacho, L. (2025, June). How to cut through the hype and measure AI’s real impact. Presentation at LeadDev London.  https://youtu.be/qZv0YOoRLmg?si=aMes-VWyct_DEWz0