Complex Delivery Will Benefit from AI – But It Won’t Be Magic

Leave a reply

When I speak to people about the impact AI will have on complex delivery, one thing is always near the top of my mind: how much better reporting could become. I am thinking about the reporting I get from my own agentic workforce, how detailed it is, how current it is and how easily I can get to the underlying evidence. I live in a world of information abundance rather than what has so often been my experience on large programmes: constantly trying to reconstruct what is actually happening.

Running a complex programme fully with AI is still a long way away. There is plenty of work that will remain human, so we need to be realistic about what AI can support us with and what remains a human responsibility. Reporting is a good example because I think AI can make a significant difference, but probably not in the way people first assume.

What usually happens in status meetings

I sat in a steering committee meeting on a previous programme where someone spent the first twelve minutes walking through a PowerPoint assembled over the previous two days from emails, spreadsheets and memory. By the time it reached the room, at least two things were already out of date, and one of them was the thing we were about to make a decision on.

Nobody was doing anything wrong. This is simply how programme reporting works in many large enterprises. Someone collects information, assembles it into the format people expect, refines it in PowerPoint, often without the underlying source systems being updated, and eventually presents it. The process is time-consuming, imperfect and deeply human, and we have been doing it for decades without really questioning whether it still needs to work this way.

A few months ago, I was working with a team that had started using AI agents as workers, not assistants sitting next to humans, but autonomous participants completing tasks within a shared workflow. I noticed something almost by accident: the agents always knew their current status. Not because somebody had asked them to produce a status report, but because the work they did and the record of that work were the same thing. An AI worker knows the task is not finished until the status is updated and the appropriate lineage back to the sources has been recorded.

That made me think about what happens if the whole team starts working this way. If every worker, human or AI, leaves a structured trace as part of doing the work, the status pack starts to just exist. Reporting becomes a view over the work itself rather than a separate activity performed afterwards.

The interesting part is that the humans do not need to become perfect administrators for this to work. I use AI to maintain my own status reporting today. My objectives are kept current through my normal interaction with AI. I can tell it that something is done, give it an update on an objective or explain that a priority has changed, and it updates the common system of work for me. I do not have to remember to go into another tool later and repeat what I have already said.

I think that is an important part of the shift. For agents, keeping the system current can be built directly into how they work. For humans, AI can remove much of the friction that has historically made keeping those systems current feel like administration. In both cases, the work and the record of the work stay much closer together. That is a much more interesting change than simply using AI to write PowerPoint slides faster.

The real problem is not the PowerPoint

When I speak to programme managers and PMO leads about reporting, the conversation often starts with the deck. It takes too long to build. The data is already stale when executives see it. Nobody agrees on what amber means. These are all real frustrations, but they are symptoms of a deeper problem.

The information needed to run a programme often lives in too many places, is captured inconsistently and requires significant human effort to assemble into something coherent. Ask yourself a simple question: if you needed to know right now whether a particular workstream was on track, where would you go? On many programmes, you would not go to a system. You would ask someone, and that person would tell you what they remembered, filtered through their own context and judgement.

We have had automated reports for years, of course. The problem is that people often do not trust them because they do not trust the underlying data, so they go and ask someone instead. Eventually they stop looking at the report altogether. The status pack is not the problem. It is evidence of the problem.

AI cannot fix missing discipline, but it can reduce the friction

There is a tempting version of this conversation where someone says, “just use AI to write the status pack.” That misses the point. Getting an AI agent to draft a status report is not particularly difficult. Getting thirty people to consistently capture their work in the right system, at the right level of detail, every day is much harder.

But I also do not think the answer is to tell those thirty people that they simply need to become better administrators. That is where AI can help again. If people can update the system through the way they already work, whether that is through conversation, meeting notes, decisions or normal interaction with an AI assistant, then some of the administrative burden disappears. The discipline still matters, but the effort required to maintain it can be much lower.

AI is genuinely useful at assembling information into readable narrative, applying consistent criteria across large amounts of information and identifying anomalies or signals that a human scanning a spreadsheet might miss. There is also a related capability that I think is underrated: agents can apply a rubric consistently across a whole programme in a way humans often cannot.

Take something as simple as a risk rating. Two experienced people can read the same risk and interpret “amber” differently because they bring their own experience, context and tolerance for uncertainty. An agent can apply the same agreed rubric every time. That does not remove judgement because someone still has to define the rubric, challenge it and decide when an exception matters, but it does remove a surprising amount of noise.

Where AI struggles is when the information was never captured, was captured inconsistently or lives in the wrong place. If the key delivery decision is sitting in somebody’s inbox rather than in the system of work, the agent cannot magically make the programme observable. Garbage in, garbage out still applies, although AI has the unfortunate ability to make the garbage look very convincing.

Some principles I think matter

A few principles have emerged for me from working through this.

Establish the source of truth before building anything. There is little value connecting an agent to a system that half the team ignores. The first conversation is about operating discipline, not AI.

Make updating the source of truth part of the work. This is where AI can make a real difference for humans. If somebody has to finish the work and then separately remember to update another system, we should not be surprised when the second step gets skipped. Wherever possible, AI should help turn normal interactions, decisions and updates into structured changes in the common system of work.

Use what the native system already gives you. Before reaching for AI, understand what your existing platforms already provide. Most systems have useful automation and reporting capabilities that are underused. AI should sit on top of something that already works rather than become an expensive workaround for poor operating discipline.

Report from the system, not from an extract. If the information already exists in the system, produce the report from there. The moment you copy it into another spreadsheet or deck and start maintaining it independently, you have created another version of the truth, and eventually they will diverge.

Use AI where language, judgement and synthesis are required. Structured data is already good at producing structured outputs. AI becomes interesting when it has to synthesise across multiple inputs, assess qualitative signals, explain why something matters or identify patterns that conventional reporting might miss. That is where it earns its keep.

Use AI at the point of entry, not just at the point of reporting. When a new risk, issue, deliverable or status update enters the system, AI can review it against clearly defined and agreed criteria. Is the risk actually written as a risk? Does the deliverable meet the required quality standard? Is there enough evidence behind the reported status? Is the issue missing an owner or resolution date? This means AI does not just consume better data, it can help create better data.

The PMO job starts to change

This is the part I find most interesting. A significant amount of programme management effort today goes into collecting, chasing, formatting and presenting information. In a world where reporting is continuously maintained by the system, that effort can move somewhere more valuable. And yes, agents are also remarkably persistent at chasing people for missing inputs. Trust me, I am being chased by them regularly.

The PMO role starts to shift from producing the truth to governing the truth. What does “on track” actually mean? What evidence is required before something can be marked complete? What makes a risk red rather than amber? Where does human judgement override an automated assessment? Where is the system giving us a technically correct answer that does not reflect what is really happening? Those are much more interesting questions than whether slide seven has the latest status.

It also changes the responsibility of executives. There is a version of this future that goes badly, where automated reporting becomes an excuse to pay less attention rather than an opportunity to engage differently. I think the opposite should happen. If reporting becomes more current, more detailed and more traceable, leadership has fewer excuses for not engaging with what it tells us.

AI can make a programme dramatically more observable, and it can make it much easier for humans to keep that picture current. What it cannot do is make us pay attention or make the decisions for which we remain accountable. That part remains human.

In AI-Native Delivery, Architecture Has to Say Where to Stop

Leave a reply

When you heat metal and cool it slowly, its internal stresses are relieved. The internal structure settles into a more stable state.

This is annealing, and I think it is a useful way to think about software architecture when AI agents are doing part of the delivery work.

Hot and cold are not just descriptions. They are controls.

A hot zone is one where change is permitted, cheap and expected. A cold zone is one where the structure has been deliberately locked. Temperature is not something the code naturally possesses. It is a choice the team makes and then enforces through permissions, repository boundaries, tool access, testing and approval paths.

That kind of graduated control becomes important when agents are the ones making changes.

Most software architecture practices assume that everything is modifiable in principle. Given the right people, the right process and enough time, any part of a system can be changed.

Architecture evolves. It has always been expensive, but it has also been manageable because humans controlled the pace.

AI delivery changes that.

When agents can propose changes, write code and modify configuration faster than any human review process can follow, the question of what they can reach becomes urgent.

Anything within reach becomes a candidate for change in pursuit of the objective the agent has been given. An agent does not intuitively distinguish between a throwaway utility function and the data model that forty other services depend on. If both are in scope, both are available.

The tempting response is to make the entire architecture fair game and trust the AI to find the right shape.

The first problem is comprehensibility. If agents have been free to touch everything, you can end up with an architecture whose design intent nobody can reconstruct. It may work perfectly well. The problem is that no human was accountable for the structure as a whole. You own something you cannot properly explain.

The other problem is economic. The more of the architecture an agent must consider, the more context it needs. That means more tokens, slower reasoning, higher cost and more opportunities for important details to be missed.

An architecture with no cold zones is not only difficult to govern. It is expensive to operate.

The response is to make architecture “temperature” choices explicit.

Some parts of an architecture should run hot.

These are places where change is cheap, feedback is fast and the cost of a wrong move is low. Presentation logic. Integration adapters. Prompt templates. Workflow configuration.

These are the soft spots. They are deliberately kept malleable so that agents can work freely. Their structure is not expected to last. It should be shaped and reshaped as requirements shift and models improve.

Other parts should run cold.

These are decisions with a wide blast radius, many dependants or serious security and regulatory consequences. Domain models. Event schemas. Security boundaries. Contracts between services.

Once these structures have proved themselves, they should crystallise intentionally. The cost of changing them is high, and their stability is load-bearing.

Agents do not modify cold zones. They work within them.

These classifications are not permanent. A domain model may run hot while a team is still discovering it. It cools as the design stabilises and more of the system comes to depend on it.

The hard work is managing that change in temperature.

You need to decide what to harden and when. Sometimes a cold zone must be reheated for a major refactor, then cooled again once the new structure has been established. Early in delivery, more of the system can remain hot while the team learns what the architecture needs to become. As the structure proves itself, the temperature comes down.

I first came across this idea while studying AI at Edinburgh University many years ago.

Simulated annealing is a classical optimisation technique. It runs hot early so that the algorithm can explore broadly, then cools gradually as it converges on a solution.

Here, the same idea is being applied in the other direction. It is not a technique inside the AI system. It is a governance model for the systems that AI is allowed to change.

None of this is entirely new.

Domain-driven design, intentional architecture and event sourcing all try, in different ways, to separate the things that change from the things that need to remain stable.

What changes with AI is the speed and autonomy of the actor.

An agent does not slow down when it reaches a part of the codebase that looks important. It does not become cautious because a change has political, operational or architectural consequences. If the change is within its permissions and appears to support its objective, it will make it.

The discipline that once lived mainly in code review and architectural governance now needs to be built into the system itself.

The teams that get this right will not necessarily be the ones with the best models or the most sophisticated orchestration. They will be the ones that can read the temperature of their architecture: where agents should be free to explore, where they must stop, and when those boundaries need to move.

AI-native architecture is not simply about making systems easier for agents to change.

It is about controlling where change is allowed, how quickly it can happen, and when the boundaries themselves need to move.

The architecture becomes part of the control system.

The AI Jenkins Moment

2 Replies

We have been here before.

When DevOps arrived, a lot of time was spent talking about tools. Jenkins or Bamboo. Puppet or Chef. People drew diagrams of their pipelines and called it a strategy. They were wrong, but productively wrong. At least they were trying to automate something, and it made things better. A bit.

The second argument was more sophisticated. It was about the shape of the pipeline itself. How many stages. Where to gate. Shift left. Continuous deployment versus continuous delivery. This felt like real thinking. It was still solving the visible problem rather than the important one.

In the DevOps transformations I saw work, the decisive shift was not the pipeline. It was developers taking responsibility for what they deployed. That meant tearing down the wall between the people who wrote the code and the people who ran it. The tools were downstream of that insight. The pipeline was simply a means to achieve the outcome. The Jenkins debate was distracting us from the change that actually mattered.

Agile followed the same script. First came the tool debate: Jira, VersionOne or Rally. Then the framework debate: Scrum, SAFe, Kanban or a bespoke playbook. Meanwhile, the people who understood the change were talking about feedback loops, cost of delay and what it really meant to collaborate with a customer.

Now we are doing it again.

Today, the conversation usually starts with models: GPT, Claude or Gemini. This is the Jenkins debate.

From there, it moves to orchestration and architecture: LangChain or LlamaIndex, multi-agent or single-agent, a common workbench or multiple platforms. This is the CD pipeline debate.

The harder question is how we learn to work with systems we cannot fully understand. It requires knowing when to constrain an agent and when to give it room. It is the difference between telling an agent to “review the program plan” and deciding what information it can use, what evidence it must show, when it should stop and when a human needs to step in.

Tooling and vendor selection are only the surface. The real challenge is building this as an organisational capability. Very few organisations know how to develop that capability, govern it and make it repeatable.

And just as with Agile and DevOps, the implications are not the same for everyone. What this means for an engineer is not what it means for an architect. What it means for a tester is not what it means for an executive. Both movements reshaped every one of those roles. We spent years working out what that meant in practice, and we got plenty wrong along the way. AI will do the same. In most organisations, that conversation has barely moved beyond engineering and productivity use cases.

That is the AI Jenkins moment. We are arguing about the tool while a new craft is being invented.

Too few organisations are helping people develop the skills that craft requires: curation, architectural judgement, leading hybrid human-agent teams and working with non-deterministic systems.

I have developed a leadership programme that I am excited to pilot internally in the coming weeks. It is one attempt to move the conversation beyond tools and start building that capability. The tools will change. The capability is what will remain.

Why Upfront Alignment Determines Whether Complex Programs Succeed

Leave a reply

If you have worked with me in a large program, you have probably heard me say: “We need to do more conceptual work.”

What I mean is that we need to understand how the work will actually happen before we start trying to execute it. Not just what the deliverables are, but how the teams will work together, where the dependencies are, who is responsible for what, and what we will do when something goes wrong.

After reading How Big Things Get Done, I realised that what I have been calling conceptual work is really a form of planning.

Most people think planning means building a project schedule. I think the real planning happens before that. It is the work of mentally executing the program before anyone starts doing the work—playing through who will do what, where the handoffs are, what happens when dependencies fail, and where the gaps might emerge.

This kind of planning is especially important in complex programs because alignment is not automatic. Different teams often have different assumptions about scope, sequencing, ownership, quality, risk, and progress. If those assumptions are not surfaced early, they show up later as delays, rework, escalation, or confusion.

What this planning really creates is a shared mental model. Everyone leaves the room understanding not just the plan, but how the program is expected to behave when reality starts pushing back. That shared understanding allows teams to make good decisions independently instead of constantly waiting for coordination.

A couple of years ago, we delivered a large data centre exit. We were working to immovable deadlines. The bulldozers were already scheduled to demolish the building. We spent weeks repeatedly redesigning how we were going to deliver the migration before we touched production. How should we bundle the applications? What testing did we need to perform? How would we get sign-off to migrate?

We went through painful brainstorming to think about what could go wrong. We dug into the tooling to understand what processes it enabled, and where it did not help us. We found problems, misunderstandings, and gaps before they became execution issues.

Were we perfect in execution? No. There were long nights and weekends, unforeseen problems, COVID-19, last-minute rescues, and even some rollbacks.

We succeeded not because execution was flawless, but because we had already thought through most of the difficult decisions before execution pressure arrived. Once everyone agrees how the work will happen, another benefit appears almost immediately: you can finally measure progress properly.

That experience reinforced two things for me: first, alignment has to happen before execution pressure arrives; second, progress has to be measured in units that actually mean something.

The first practical output of good planning is meaningful progress measurement.

“Percentage complete” does not mean much unless the pieces underneath the calculation are meaningful. A team can be 80% complete for weeks if the remaining 20% contains the hard decisions, unresolved dependencies, or untested assumptions.

Better measures are tied to real units of progress: work packages completed, process steps agreed, phases exited, software modules built, features tested, decisions made, or risks retired. The point is not to create reporting for its own sake. The point is to understand whether the program is actually moving.

Another important part of upfront planning is looking for ways to decouple work and retain optionality.

It is tempting to combine things to reduce retesting, reviews, or governance effort. Sometimes that is the right answer. But every time we couple pieces of work together, we also increase risk. A delay in one area can block another. A missed dependency can suddenly become a program-level issue.

Good planning creates options. Poor planning leaves you trapped by unnecessary dependencies.

Thinking through options early allows us to identify off-ramps. What can move independently? What can be sequenced differently? What can be recombined if a dependency does not come through? What decisions do we need to keep open for longer?

Something will invariably go wrong in a complex program. The goal is not to create a perfect plan that assumes nothing changes. The goal is to create enough shared understanding and enough optionality that the program can adapt when things do change. That is why upfront alignment matters. It isn’t bureaucracy; it’s how complex programs remain executable when reality inevitably refuses to follow the plan.

The Dark Factory – a novella

Leave a reply

This is a story about a software factory that no one built on purpose. It began as a small team’s attempt to move faster — to automate the repetitive, to delegate the tedious, to let machines handle what machines could handle. That is how most of these stories begin. What follows is an account of one year in the life of that factory and the woman who ran it: what she built, what she lost track of, and what she eventually came to understand about the thing she had made.

—

At the start, the entire operating model was captured in four enormous instruction documents and a single configuration file. Elise and her small team wrote the first two in March, when the “factory” was still little more than a prototype: a coding assistant connected to a deployment tool.

The third document was generated in April, mostly through a long back-and-forth with an AI assistant. The fourth she does not remember writing at all. When she checks the change history, the author is not a person’s name, just an arbitrary machine-generated identifier. She had approved the change request while scrolling through her phone.

By July, the factory had spread into four layers of AI-driven activity. Each layer had its own automated processes, but they were all coordinated by a set of relatively fixed workflows — almost like a simulation of a software organisation. Everything was controlled through a fifth layer: a simple conversational interface that Elise and her team used to tell the factory what they wanted.

Those high-level instructions were broken down by a coordination layer into smaller tasks, then routed to the right part of the system. Most of the work was done by short-lived AI workers: small autonomous agents spun up for a specific task, placed inside temporary digital workspaces, and shut down once the task was marked complete.

Underneath that workforce was an integration layer. It connected the factory to the surrounding tools: source code repositories, deployment pipelines, monitoring dashboards, testing systems, and external services. These connections were wrapped behind clean internal interfaces, so the upper layers did not need to know which tool or vendor sat underneath.

A handful of specialist AI agents moved along this integration layer, packaging useful patterns into reusable capabilities. If the coordination layer needed one of those capabilities, it could call it on demand.

Change requests appeared in the team’s messaging channels. Human engineers reviewed them uneasily, increasingly aware that they no longer fully understood how the application was organised. Eventually, most of the changes were approved and pushed into production.

This phase of the factory was held together by a chaotic event-driven nervous system. A request became a task. A task became a plan. A plan became a set of assignments. Assignments produced completion messages. Completion messages triggered more tasks. Everything generated logs.

At night, Elise would scroll through those logs in the same half-awake way someone might wander through an online encyclopedia: one link leading to another, each entry interesting but only partly meaningful.

Her relationship to the platform had changed completely. The applications and services she supposedly owned had become abstract and strange to her. She no longer understood them as codebases or systems. But she could recognise the behavioural signatures of the management layers above them. She knew when the factory was hesitating. She knew when it was improvising. She knew when it was hiding complexity from her.

By September, Elise’s team had built an autonomous evaluation service. It did not simply recommend better options; it learned from outcomes. New software was released almost directly into a production environment that mixed simulated users with real customer interactions.

By then, most customer activity was no longer human-to-system. It was machine-to-machine. Customer agents talked to company agents. Buying, testing, requesting, complaining, and renewing all increasingly happened through automated intermediaries.

Minor problems were handled automatically. The system would fall back to a safer path, analyse what had happened, write a brief internal postmortem, and feed the lesson straight back into a code or configuration change.

Serious problems were treated differently. If a failure violated the core instructions of the factory, the system tightened the rules, isolated the routines involved, created a separate “satellite factory” to explore a safer approach, and gradually retired the faulty process.

They had long since stopped using a traditional event logging service. The logs were still produced, but nobody really understood them. It took longer to diagnose a problem by reading the history than it did to let the factory’s own immune system respond.

The factory still depended on many third-party tools, but often in ways their creators had probably never intended. The codebase had become like Swiss cheese: full of holes, switches, flags, and conditional paths. Almost every core behaviour, feature, and rule was assembled only at the last possible moment, depending on the situation.

By the end of the year, Elise’s engineering team had almost entirely changed shape. They were no longer mostly programmers. They had become designers, architects, systems thinkers, and behavioural analysts.

The only surface everyone truly worked on was the specification: the set of written instructions that told the factory what mattered, what was allowed, what was forbidden, and what counted as success.

The architects and designers focused on trend forecasting and strategic partnerships. Their ideas could not be added to the specification directly. All write access went through two game theorists and a small group of statisticians, who had become the formal gatekeepers of the factory’s intent. The game theorists shaped the rules. The statisticians built the mechanisms to evaluate whether the factory’s output was actually doing what the rules intended — a distinction that had turned out to matter enormously.

Other specialists were there mostly to observe and document the game theorists. There was also an unspoken understanding that, if the game theorists began to behave strangely, someone in the room was expected to contain them.

Meanwhile, the broader internet was becoming less reliable. Large cloud platforms were going down more often. Security breach notifications had become constant background noise for every user. In response, a new class of security tools had emerged that deliberately added noise, leaks, and confusion as a defensive tactic.

Elise’s team noticed a strange rhythm in the factory’s specification changes. For a week, almost nothing would happen. Then, for twenty-four hours, the specification would light up with revisions.

The rhythm felt tidal, but wrong — as though there were two moons pulling at it.

Most of the changes were not caused by instability inside the factory itself. They seemed to be responses to the outside world: outages, market shifts, new security threats, changes in customer behaviour, or signals from other automated systems.

Around Christmas, the internet effectively died twice. The social disruption was catastrophic.

The business, somehow, continued to do well. In fact, it was growing. But it became harder and harder to explain what the business actually did.

Customers appeared through a machine-to-machine purchasing ledger. When their usage reached meaningful scale, the sales team reported increasingly bizarre conversations with the human representatives on the other side. Those people often struggled to explain what they were buying, or why. They were mostly reading instructions that had been handed to them by their own hidden factories.

Elise could not shake the suspicion that these dark factories were beginning to assemble themselves into something larger.

Not by design.

Not by anyone’s design.

But still, unmistakably, together.

NOTE – This is based on, and heavily influenced by, an article by Marek Poliks!

Enhancing AI Productivity: The Importance of Curation

Leave a reply

Many of us have now experienced the power of AI. We have created graphics, written small programs for home automation, generated study notes for technical exams, and used AI to get real work done faster.

The productivity numbers look impressive. Output is up.

But we have also seen the other side: a 20-page PowerPoint deck clearly created from three bullet points of thought, LinkedIn posts that sound reasonable but contain no real insight, and the occasional article where the AI response was accidentally left in.

In other words: AI slop.

I have been working in an AI-native way for the last few months. I hardly ever write an email directly in Outlook anymore, and I rarely build a PowerPoint by moving objects around with a mouse. I draft in Markdown, write in VS Code, and use AI assistants to sharpen language, create variations, and help me build code for my home automation system.

One thing is clear: output goes up. But I have also learned the hard way that more output is not automatically more value. Without curation, even useful AI-generated content can become overwhelming.

I am not talking about incorrect information or low-value AI slop. Even when a document is full of value, the information density might still be too high. When you create content with AI, you have to be conscious of the audience. Is this a stand-alone document that explains a process, or is it an illustration that gives an update?

Here is a negative example: you send out five updates of a business strategy, each created with AI from your knowledge base. Each update is a dense document. Each one looks polished. But because they were generated separately, it becomes incredibly difficult for your audience to see what actually changed.

So what does this mean? We need to be much more conscious of what we create and how it will be consumed. It is easy to create good material. The harder part is helping the audience consume it.

The distinction I now think about is this: AI can create content from source material, but mature AI use means tailoring that content to the audience. You can see the difference in the example below:

Here is my way of thinking about it:

  • I start with a source file, usually a Markdown file that describes a process.
  • I can create different versions of the output with very little effort.
  • I choose the right level of detail for the audience: dense, high-level, visual, or change-focused.
  • When working with feedback, I create a version that clearly highlights what changed, often by applying the feedback directly in Markdown.

The largest problem with AI-generated content is that the information density is not obvious. A document may look polished and complete, but the reader still has to work out what is valid, what is necessary, what has changed, and what came from the creator’s actual judgment rather than from the model filling space.

That is why curation matters. It separates signal from filler.

I think of this evolution as a maturity curve. We started with manual content creation, moved into unreliable early AI output, and are now entering a new phase: AI can create reliable content, but we have not yet learned how to curate it well enough for the audience.

The principle also holds for software. Raw output is not the goal. Useful, understandable, maintainable output is.

Mature AI use is not about producing more. It is about knowing what to produce, what to remove, and how to shape the result so the audience can actually use it.

AI gives us output. Curation turns it into value.

What to do when AI is removing the lower rungs of the career ladder

2 Replies

Almost every time I talk to executives about AI, the conversation eventually lands in the same place: workforce impact.

Not immediately, of course. We usually start with the usual things. Productivity. Cycle time. How many people a team might “need” if the tools keep improving. Somebody will mention an impressive demo, followed by “Why cant we just?”. Somebody else will mention risk. And then, usually with a slightly awkward pause, someone asks the real question: what happens to all the engineers?

Will AI take all the jobs? Will we all sit at home while an agent writes the code, tests it, deploys it and perhaps also sends us a mildly passive-aggressive status update?

I do not think that is the most useful way to frame the problem.

For one thing, I have yet to walk into an organisation and hear somebody say: “We have no problems left to solve, our systems are easy to manage, and quality is consistently excellent.” Quite the opposite. Most large enterprises are still carrying a very long backlog of technology problems, quality issues, delivery friction and operational complexity. Even if every productivity claim about AI turns out to be broadly true, there is still plenty of work to do.

And in the brownfield reality where most large organisations actually live, the results are rarely as magical as they look in demos where AI builds Snake for the four millionth time. Can you imagine how much energy and PE capital has been spent on recreating Snake?

So I do not think the near-term problem is that we suddenly run out of work for software engineers, especially the good ones. I think the more interesting problem is that we may be quietly dismantling the way software people become good in the first place.

The ladder was already sinking

A few years ago I started talking about what I called a sinking skill ladder.

In many organisations, the traditional progression model had already become harder to sustain. A lot of entry-level or more routine work had moved offshore. Teams became thinner in some locations. The work left behind often skewed toward coordination, oversight, integration and stakeholder management. That created a familiar problem: if fewer people get to do the foundational work, where exactly do future seniors come from?

It was already a bit wobbly.

AI is now making that worse, because the bottom part of the ladder is exactly where automation is most tempting. The simpler, narrower, more repeatable tasks are the ones organisations can most easily give to AI tools and agents. From a local optimisation perspective, that makes complete sense.

But ask yourself what those tasks used to do.

They did not just produce output. They also created learning opportunities.

A junior engineer fixing a small defect, writing a test, tracing through a logging problem, or wrestling with a deployment pipeline is not just “doing low-value work”. They are building up valuable experience. They are learning how software behaves when it meets reality. They are beginning to form the mental models that later let them design systems, challenge bad assumptions, or spot when a confidently wrong AI-generated answer is dangerously plausible.

That is why the current shape of the market worries people. There is already quite a lot written about pressure on entry-level roles, and it is not hard to see why. If organisations reduce junior hiring while expecting more experienced people to supervise AI-assisted delivery, that may look efficient in the short term. But it is not a sustainable talent model. You cannot only hire senior developers; someone needs to create them. IBM is bucking the trend by starting by increasing junior hiring again, but that is not where most of the market seems to be heading. We should worry about what this means for our organisations going forward.

Not “will developers disappear?”, but “how do we develop developers when the old apprenticeship model gets hollowed out?”

What could the new AI-native entry level experience look like

I do not think the answer is to force juniors through a nostalgic version of software engineering that pretends AI does not exist. That would be silly. And after all, I did not start my career with punch-cards. although Cobol came pretty close.

But I also do not think the answer is to let people become prompt managers with no grounding in how systems are built, tested and run.

In my experience, junior engineers in their first couple of years still need a rounded set of experiences. The mix may change. The pacing may change. The amount of AI support may change. But the underlying developmental needs do not go away. Simon Wardley wrote about “Human AI System Integrator”, which is worth a read.

If I were designing an AI-native apprenticeship model, I would want people to get exposure to five things early: writing code, testing software, architecture, DevOps, and maintaining an application in production.

  • They should still write some code

Not because they must outperform AI on raw code generation. They will not, and that is fine. They need to write code because that is how they build a mental model of how software actually works. What state is. What control flow is. Why edge cases matter. Why a tiny change in one place can produce very odd behaviour somewhere else – I remember my first experience with pointers in C ‘fondly’.

Yes, they can do that in hybrid teams with AI support. In fact, they probably should. The point is not purity. The point is learning. We still teach kids mathematics before handing them calculators. Not because calculators are bad, but because understanding matters.

I think the same applies here.

There is a fantastic book, New Dark Age, by James Bridle which argues that we are getting to a world that we don’t understand anymore and might lose control over. Let’s avoid that world and train our junior developers to still create code. It may also come in handy if we ever need to take control back.

  • They need to learn how quality is evaluated

The goal for this is to understand how to evaluate quality. I do not mean an old-fashioned version of manual testing with pre-defined scripts. I mean they need to learn how to evaluate whether software is actually good enough. They need to interact with the application, put themselves in the shoes of an end-user. Explore edge cases. Triage defects. Understand what can go wrong at system level, not just at unit-test level. See performance issues. See data problems. See the difference between “it works on my machine” and “this is fit for purpose”.

A good tester, as the old line goes, looks both ways before crossing a one-way street.

That mindset will be even more important in the AI-assisted software delivery world.

  • They need some architectural thinking

The context window for our AI agents will not contain the whole architecture of your organisation or even application and it shouldn’t as it would make things too complex and expensive.

This means somebody still needs to think about decoupling, interfaces, data ownership, API contracts, integration boundaries, duplication of data, failure modes and long-term maintainability. Somebody still needs to ask whether the thing being optimised locally is possibly making the wider system worse.

That does not mean every junior needs to become a formal architect. It does mean they need some exposure to architectural decision-making, because otherwise they may become very efficient at generating change without understanding the shape of the application they are changing and how it fits into the overall architecture.

That is not modern engineering. That is just fast damage.

  • They need DevOps experience

Perhaps not surprisingly, I think this area is the one people are not paying enough attention to in the current AI craze.

CI/CD, environment management, deployment automation, release predictability, test data, observability, rollback, all of that boring and beautiful machinery: this is where a lot of software delivery either becomes reliable or a road to disaster.

Many projects fail not because the team could not write code, but because the path from code to production is messy, slow or fragile. AI will help here as well, I am sure. But that does not remove the need to understand the principles.

Good engineers need to know how to make change safe, repeatable and visible.

  • They need to support software in production

Of course, an application is only successful when it works in production, so this one matters enormously.

A system is not successful because it passed a demo or completed a sprint. It is successful when it works in production for real users under real conditions.

That means junior engineers should spend time maintaining applications, reading logs, looking at traces, understanding incidents, following operational signals, and dealing with the messy feedback that only arrives once software is actually in use.

Production is where bad assumptions become expensive.

That experience changes how people think. It gives them a healthier respect for reliability. It teaches them that elegance in design is lovely, but usefulness in production is the actual point.

And frankly, it is very hard to build good judgment without spending at least some time there and picking up some scars.

So yes, I think we should still invest in junior engineers

But if AI removes a chunk of the routine work people used to learn from, then organisations will have to design learning more deliberately. They cannot assume it will happen accidentally on the side. The old model relied on juniors doing a lot of the simpler BAU work. If that BAU work is now handled differently, then capability-building has to become a more conscious investment.

And that is the bit that may be more difficult to argue in some boardrooms. From a narrow productivity lens, it is tempting to ask: if AI can do the beginner work, why keep hiring beginners? And the answer is that beginner work was never just about productivity. It was part of how we created the skills that we relied on later.

If you optimise that away without replacing its training function, you may get a few very productive years. And then one day you discover you have plenty of AI-generated artefacts, a handful of exhausted seniors, and far too few people with the judgment to run the whole thing.

I do not think that future is inevitable…yet. But I do think it is plausible.

Why Your Status Report Only Tells Half the Story (and Usually the Nicer Half)

Leave a reply

The other day I was in one of those long status review meetings that everyone pretends is productive. Everybody was saying sensible things and somehow we were still heading for trouble. The risk register was full. The status report was mostly green, with a tasteful amount of amber and a bit of red to signal realism.

What struck me wasn’t that the team had ignored risk. Quite the opposite. They had probabilities, impact scores, owners, dates. The mechanics were all there. But when I asked the simple question — what is the overall risk position of this program? — nobody could really answer it. We had plenty of detail, but very little clarity.

I have spent most of my professional life on large delivery and transformation programs, and one thing has changed quite a lot in how I think about status. Early on, I mostly looked at progress against tasks (and I still do as people who have worked for me can painfully attest to given the level of detail I ask for). These days I care far more about outcome measures and risk.

Of course the world has changed too. When I started, everything was waterfall and on-premise. Now it is Agile, cloud, digital and AI. But the bigger shift in mindset for me is this: on complex programs, progress reporting on its own just does not tell you enough to be successful.

I have written before about measures and scorecards, so I won’t go back over that here. What I want to focus on in this post is one lens I ask my teams to include in status reporting: major risk burndown, paired with our contingency position regarding the portfolio risks.

Burn down the most concerning risks early

I still like detailed reporting on deliverables and milestones. But on complex programs that is only part of the picture. What I really want to know is this: what are the few things that could seriously derail us, and what are we doing to reduce that exposure?

One thing I have learned, repeatedly and occasionally the hard way, is that large programs rarely fail because one team missed a task on a plan. They fail at the connection points: dependencies, handoffs, integration points, environments, external parties.

The good news is that many of these failure points are visible early. And once you can see them, you can define the activities that will actually burn that risk down.

In my experience, the usual suspects are not that mysterious. They tend to look something like this:

  • standing up new environments or cloud landing zones
  • third-party delivery dependencies
  • data complexity or sheer data volume
  • system performance
  • integration across systems

There are different ways to identify these risk areas up front. One technique I like is the pre-mortem, popularised by Gary Klein: assume the program has gone badly wrong, then work backwards and ask why.

Once you know the major risks, the next step is straightforward. For each one, define the concrete actions that reduce either its likelihood or its impact. As those actions complete, the risk comes down. That gives you something far more useful than generic “red amber green” commentary: a visible burn-down of uncertainty that you can quantify.

Take a simple example. Say one of your biggest risks is that a third-party system will not integrate properly once delivered. The team assesses that as 25% of the program’s major risk exposure.

You then break the burn-down into concrete steps: agreed interface specification, test stubs, first code drop, functional test pass, performance test pass. If you weight those evenly, each completed step burns down one fifth of that risk. In this example, that means each one reduces overall major risk exposure by 5%.

It does not need to be overly precise or scientific to be useful. It just needs to be explicit enough that the team can see whether uncertainty is actually coming down.

If you are worried about how precise those percentages are, I would not get too hung up on it. In my experience, relative weighting is usually enough. I have used the rough equivalent of planning poker for this: get individual views from the team, compare the outliers, then talk it through until you reach a workable level of consensus. You are not trying to produce actuarial science here. You are trying to make uncertainty visible enough to manage.

Here is an example schedule for one of the major risks in one of my programs, you can see the 9 burndown actions as little circles. Each would have specific acceptance criteria and a way to measure progress towards it.

This is also one of the things I have always liked most about Agile, at least when people practice it rather than just put it on slides: do the risky thing first.

If something might derail the program, why would you leave it until later? Why would you optimise for neat sequencing when the real problem is uncertainty?

Yet enterprises still do this all the time. We reward predictability over adaptability. We like getting “runs on the board.” We often prefer the appearance of commitment over the economics of resilience.

So if you are betting on something important — a new technology, a big AI-driven productivity gain, a performance improvement, a vendor promise — find a way to test that early. Pull the uncertainty forward. Do not wait politely for reality to reveal itself on your most expensive critical path.

Contingency is how you fund the remaining uncertainty

Major risk burndown is only half the picture. Most programs also carry a long tail of smaller risks: things that are annoying, expensive, and real, but not individually catastrophic.

For those, I find it useful to assign contingency values. In other words: if this risk materialises, what would it likely cost us in money, time or both? That gives you a portfolio view of exposure, not just a list of isolated issues.

Not all risks deserve the same treatment. Some need to be actively burned down because, if they hit, the whole plan changes shape. Others are better handled through contingency: extra money, extra time, extra help, or a workaround.

And of course, if the total value of all identified risks comes to 10 million dollars, it rarely makes sense to hold the full 10 million in contingency. Not every risk will materialise. So organisations make a judgment based on risk appetite, delivery context and portfolio profile. In my experience, holding somewhere between 25% and 75% of the total quantified exposure can be entirely reasonable.

Once you have decided how you will calculate contingency, there are really two disciplines to maintain. First, track the individual risks in the normal way. Second, use major project milestones to reassess how much contingency you still need. As uncertainty comes down, the contingency position should change too.

You can see below what this can look like for a project with 30M contingency:

I am increasingly convinced that one of the best indicators of delivery maturity is not how well a team identifies risks, but how honestly it funds uncertainty and tracks progress against it.

We still too often treat contingency as a sign of weak planning. I think the opposite is usually true. Very often it is a sign that somebody understands the shape of complex work.

There is a lot more to say about contingency management and maintaining optionality in delivery and I suspect I will come back to it.

But the broad idea here is simple enough. On complex programs, progress reporting is necessary, but it is nowhere near sufficient. I want to know which risks matter most, what we are doing to reduce them, and how we are managing the uncertainty that remains.

Even with all of that in place, programs still go wrong sometimes. I have a few scars to prove that – ask me over a beer or whisky about it. But I would still rather face the risky things early than discover too late that all the tidy progress reports in the world were describing motion rather than control.

From Lights-On to Lights-Out: Rethinking Software Delivery in the Age of AI

1 Reply
I can see now why the name “Dark Delivery’ conjures up the wrong image.

I mentioned “Dark delivery” to a colleague last week and he laughed and said, “this is not Star Wars.” I think he was right, “Lights-Out” delivery sounds a lot less threatening. Not sure either is a settled term, but I will stick with “Lights-Out” for now. You might wonder what I mean by it? I will spend a few blog posts discussing it… and what my current thinking on it is. I am learning from my discussions with clients who are keen to push the boundaries and vendors who are keen to be part of the next iteration of software development.

One of the key questions we need to answer in the post Agile, post DevOps world is not just how much AI to use, but what kind of AI-driven delivery we are actually building towards. A useful frame for this is the distinction between “lights-on” delivery, where humans remain in the loop, observing and directing, and “lights-out” delivery, where work proceeds autonomously, unobserved, without human intervention at each step.

This distinction matters more than it might first appear. It is way more than just the next level of continuous delivery pipelines and as such it shapes not just tooling decisions, but governance, team structure, and organisational operating models. Critically, in my view these two modes are not sequential stages; organisations will not graduate from one to the other. They will run both simultaneously and learning to manage that mixed model is one of the defining challenges of AI-era delivery. It’s not unlike the multi-speed delivery we realised as our reality during the Agile/DevOps wave of improvements.

Two Models of AI Delivery — and Why Both Will Coexist

In AI-assisted delivery, the relationship between AI and human work is essentially substitutive. Engineers still produce the same artefacts (design documents, code, test scripts), but AI accelerates or assists in creating them. Whether the work is done through scripting or agents, the outcomes are familiar and inspectable. Governance can therefore operate as it always has: review the document, read the code, check the test results.

AI-native delivery is fundamentally different. Here, the organisation is not producing the same artefacts faster; it is training models directly for outcomes (such as executing a business process end-to-end) or for behaviours (such as an AI-powered agent that acts as a tester). In these cases, the traditional artefact may not exist at all. You cannot govern what you cannot inspect, which means governance must shift from reviewing outputs to measuring outcomes. The question moves from “does this code look right?” to “did the system behave correctly under real conditions?”

In practice, most organisations will operate across both models at the same time. A product team may use AI to accelerate code generation — AI-assisted, lights-on — while the same organisation runs an autonomous AI-powered agent handling regression testing in a lights-out pipeline which was trained on existing production systems. Different software architectures, different risk profiles, and different levels of platform maturity will naturally drive different points on the spectrum. The implication is that governance frameworks, tooling choices, and delivery methodologies cannot be designed for one mode alone — they must be flexible enough to span both, and clear enough to distinguish between them.

The DevOps Prerequisite

Lights-out delivery does not happen by deploying an LLM and hoping for the best. It requires very mature automation beneath it. We might call it GOFDO: Good Old-Fashioned DevOps. Cloud-native infrastructure, robust CI/CD pipelines, automated testing, observability tooling. These are not optional enhancements but prerequisites. AI amplifies the capabilities of the engineering platform beneath it; if that platform is weak, AI makes the weakness worse faster or breaks it at speed.

In a mixed model, this creates a two-speed architecture challenge. Teams operating in AI-assisted mode can tolerate more manual steps and lighter automation. Teams pushing toward AI-native, lights-out delivery need the full stack of DevOps maturity in place first. Organisations will need to be deliberate about which parts of their delivery estate are ready for autonomous operation — and honest about which are not.

This won’t be a surprise to you – but I think DevOps is even more important now. And given many organisations have lost their focus on DevOps, this requires some renewed focus even though the hype is gone (even the DevOps Enterprise Summit is gone now).

The Productivity Divergence Problem

One of the more disruptive implications of AI-assisted engineering is what happens to the distribution of productivity across a team and the impact on methodology. The gap between a skilled engineer using AI effectively and an average engineer using it poorly will grow substantially, potentially by multiples, not percentages. What is worse is that the actual volume of output might not differ (noting that lower productivity may actually mean more code, not less, as AI lowers the effort required to generate poor-quality outputs). This divergence will be felt even more acutely across teams operating at different points on the spectrum, from AI-assisted to fully AI-native.

This has serious implications for the delivery methodology. Agile, in its sprint-based form, depends on a degree of synchronisation across teams operating at roughly comparable velocities. If those velocities diverge sharply, whether due to individual skill differences or because some teams are running AI-native, lights-out pipelines while others are not, then the sprint cadence may simply be too slow a heartbeat for the most capable members. Kanban-style flow models, which are inherently more continuous and less dependent on synchronised cycles, may prove more durable in this environment. Even so, the mixed model will demand new thinking about how teams at different points on the spectrum coordinate and integrate their work and this will require some new thinking about application architecture too.

I cannot wait to see what methodologies people come up with. Just this week I heard one organisation mentioning that they are increasing the upfront effort again to shape the AI accelerated work. There will be iterations and different approaches across companies until we have a new “proven” methodology.

Governance at Machine Speed

Perhaps the most urgent structural challenge is that AI-driven productivity will outpace the capacity of traditional governance to keep up. Human review cycles, approval gates, and manual audits were designed for human-speed delivery. They will become bottlenecks. Or worse, create uncontrollable security and compliance gaps, if not redesigned. After all, as one of my clients once told me, to make a mistake is human, to create a catastrophe you need automation.

The need for a mixed model makes this harder, not easier. A single governance framework cannot treat a manually reviewed pull request and an autonomously deployed AI-native model update in the same way. Organisations will need tiered governance: lighter-touch, inspection-based oversight for AI-assisted work where artefacts exist and can be reviewed; and metrics-based, outcome-oriented oversight for AI-native, lights-out operations where they do not.

Building and maintaining this governance platform requires a dedicated central function. I see this analogous to the way FinOps emerged to bring discipline and visibility to cloud cost management and how Platform Engineering has evolved to provide guardrails for development. Without it, the mixed model becomes an accountability gap: fast where it should be careful, slow where it should be fast and no control over the cost profile of all the AI usage.

The Data and Cost Dimension

Underlying all of this is a dependency that is easy to underestimate: AI works with data, and data governance must scale alongside AI adoption. Automated data governance, including governance of the AI models themselves, will become as critical as code governance is today. In a mixed model, this is doubly complex, as teams in the organisation may be operating across the full spectrum from AI-assisted to AI-native, using different classes of model with different data access requirements and risk profiles.

There is also a cost dimension that organisations are only beginning to grapple with. As teams make choices between large language models and smaller, more specialised models, those choices carry significant cost and performance implications. I am thinking of this as FinAIOps – or should it be AIFinOps?!? – applying the rigour of financial operations to AI usage. It needs to provide systematic visibility into AI consumption, model selection, and associated spend. Who is using which models, at what cost, for what return? In a mixed model, where AI usage ranges from individual developer assistance in AI-assisted teams to fully autonomous AI-native pipelines, answering those questions requires investment in measurement and accountability structures that most organisations do not yet have. Dialling the consumption up and down based on impact will become a crucial responsibility of management across the organisation.

So, let’s get comfortable with the ambiguity in the state of software delivery at the moment, the need for a continuum from AI-assisted to AI-native methods and the upcoming evolution of methodologies. This journey is going to be fun. The path is less clear at this point, and I am looking forward to seeing many of you on our joint road of discovery – work will be more enjoyable, faster paced and perhaps a little less predictable for a while.

The Email Analogy: Lessons for AI Utilization

1 Reply

As you can imagine as an engineer and someone who has a Masters degree in Artificial Intelligence I am super excited that AI is finally in a everyday usable state. There are many use cases for AI that I absolutely love – programming my home automation system has become better with the help of Copilot, navigating my large inbox is better with Copilot and my powerpoint presentations have much better graphics nowadays thanks to ChatGPT. It also has some downsides – one being that my son thinks my job is to create Star Wars memes for work (which made my practice townhalls a lot more entertaining). On a serious note there are several cases where AI gets it wrong and I have not found Vibe Coding to be good enough for my use cases yet, not to speak of the large amount of not useful content that is flooding my LinkedIn feed, my email inbox and any even my txt messages.

What this has shown me is that AI will really influence how we work and how we communicate and I was wondering what will we do with all the productivity we will unlock? And then remembered that all too often we don’t really use the productivity well. And I want to use a warning analogy.

Come with me into the past – It is the 1970s and we are at a business conference. I stand on stage and am pitching the next “big thing”. And here comes my pitch – There is this new technology that will create incredible productivity for you. I know many of you are sending documentation to other people in your organisation via mail or tube mail or if it needs to be very fast with a fax machine. The quality and cost of the fax machine is obviously quite limiting. Well with this new technology you will be instantantiously be able to send information at high quality for basically free to anyone anywhere. Can you imagine the productivity improvements we will see from that?!?

Of course I am talking about email which still had to go some way to live up to that promise over the next couple of decades, but the pitch and promise came true. You can send the information at high quality and basically for free and if I take email (and any equivalent capability) away from you, your productivity will drop. But ask yourself whether you feel like email is making you more productive. Or have we found ways to “eat up” that productivity by increasing the volume of emails to the point with low value information? The boat has sailed on email I think – the ongoing war of spam vs spam filters, the intentions to use less email vs the learned behaviour of checking it all the time – all this indicates that the brave new world I pitched in the paragraph above will not come of fruition.

The question I am asking myself is whether or not we will make the same mistakes with AI or whether we will find ways to truly unlock the productivity. I have spent hours with Copilot creating code for me that I could have probably written as fast myself. How can organisations focus on the productive use cases of AI and avoid the pitfalls? I don’t have an answer for this yet, but being conscious of our tendency to “eat up” the productivity that technology creates is a useful first step.