AI-Enabled Operating Model

AI-Enabled Operating Model

In previous articles, I looked at how AI may change IT roles and how this can affect team size throughout the SDLC. But after these discussions, I think the next question is even more important: how can an organisation actually move from today’s delivery model to an AI-enabled operating model?

In real life, transformation isn’t just about changing job titles. You can rename a Business Analyst to Product Discovery Lead or a developer to AI Product Engineer, but if the process stays the same, the result will not be very different. The real change happens when the way of working changes.

Many IT organisations are still built around handovers. Requirements are prepared by one group, delivery is handled by another, testing is done by another, release is managed by another team, and support is involved in the last stage of the flow.

This model is common. It worked for many years, it helped enterprises to scale delivery, create structure and manage complex programmes. But it also created a lot of hidden costs, and now there is room for improvement.

That cost is not always visible in budgets. It is visible in waiting time, meetings, unclear ownership, repeated explanations, duplicated documentation and delayed decisions. People are busy, calendars are full, but the work is not always moving as fast as it should or in the expected direction.

This is where AI can help. Not only by writing code faster, but by reducing some of the friction around the work. I would not start an AI transformation by cutting the budgets and team size. This is not the right first question.

The better question is related to speed and friction — Where does work slow down? Where do we lose context?

A practical first step is to map one value stream from idea to production. Not the perfect process from a slide deck, but the real one. Where does the idea start? Who writes the requirements? Who approves them? When does development start? When does testing happen? How many times is the work waiting? How many people need to be informed before a release? How many tickets are created only to move information from one place to another?

This exercise is very useful because it makes the hidden work become visible.

In many organisations, the biggest opportunity is not only in coding. It is in the work around coding: coordination, reporting, testing, release preparation, environment management, support and monitoring. Once the flow becomes visible, the organisation can start to see where roles can be merged or reshaped.

Business Analyst, Product Owner and Process Analyst activities can move closer into a Product Discovery Lead role. Scrum Master, PMO and project coordination activities can become part of a stronger Delivery Manager role. Developer, QA Automation and basic testing can move into an AI Product Engineer model. DevOps, release and environment work can be redesigned around Platform Engineer and Release Reliability Engineer roles.

Wait! This should not be done as a big-bang reorganisation. It’s a step-by-step process.

In my view, the most effective method is to start with one product stream, one value stream or one ART (<60 people). The point is not to remove the framework overnight. The point is to understand which parts still create value and which parts are there mainly because the organisation has too many handovers.

A pilot can run for a few delivery cycles. During this time, the team should measure simple things: lead time, number of handovers, waiting time, meeting hours, release effort, defect leakage, incident volume and support tickets. These metrics will show whether the new model is really better or just smaller on paper.

One important topic is governance. AI-enabled delivery does not mean less control. It means stronger control, better traceability and metrics.

Code review, security scanning, automated testing, architecture decisions, release approvals and compliance evidence still matter. The difference is that they should be embedded into the flow, not added at the end as a separate step.

This is especially important in enterprise environments. Large organisations cannot simply remove roles and hope that AI will fix the process — this is just an illusion. They need clear guardrails, robust platforms, strong quality gates, and human accountability for critical decisions.

From my experience, this is where many transformations fail. Companies change the org chart, rename some roles, maybe reduce some capacity, but the work still moves through the same queues, approvals and dependencies. After a few months, the team is smaller, but delivery is not really better.

A real AI-enabled operating model should be visible in the day-to-day work. Requirements should not lose context when they move to engineering. Testing should not discover basic issues only at the end. A release should not need ten people only to confirm the same information in different meetings. Support should not start from zero every time a user reports a known problem. The way we run meetings and ceremonies today needs to change fundamentally.

This is the change I would look for: less energy spent on transferring information and more on solving the actual problem. The human work does not disappear. It moves to the places where experience really matters: understanding trade-offs, managing risk, improving quality, making architectural decisions and deciding what is actually worth building.

AI transformation in IT should not be driven by headcount and costs. It shall focus on flow simplification. When the flow becomes simpler, the new team shape becomes clearer. And only then the real FTE impact can be understood in a responsible way.