The limits of efficiency: not every slow step in engineering is waste

Much of my work has focused on making engineering information easier to find, use, and trust. So I am not suspicious of tools that remove waste.

AI is a clear case in point.

If a trusted document set can be searched in seconds, that is usually better than having to work through an index and read irrelevant sections.

When information can be summarised or compared more easily, teams can spend less time on avoidable effort and more time on the decision.

But speed only helps if the information behind it is reliable. The better the tools become, the more standards, ownership, and context matter.

It is understandable that organisations want to reduce friction and improve productivity. The question is which friction is only waste, and which pauses are doing useful professional work.

Some friction is wasted effort

Asset information is a simple example. For complex assets, different teams may hold separate records for valuation, maintenance, operations, finance, and commercial purposes.

Each may have a reason to exist, but fragmented records can create multiple versions of the same asset.

The duplicate data is the visible waste. The deeper problem is the time spent reconciling differences, explaining inconsistencies, and making decisions when people are unsure which information to rely on.

A centralised register, or another authoritative source of asset information, is valuable when different functions can draw from it for their own purposes. This friction stems from weak information ownership.

AI, automation and better data standards should help reduce it.

Some friction is human and useful

A whole-life review of an asset creates a different kind of friction.

A good review brings different time horizons into the same decision. The designer may be testing whether the solution works, the contractor thinking about buildability, the operator about service and resilience, the maintainer about access and safety, and the client about cost, funding and policy.

Those views will not always align, and they should not be treated as interchangeable. A saving during design can become an operating burden later. A convenient standard detail can create maintenance difficulty.

AI can help prepare a review. It can find relevant information, compare options and make issues easier to see.

It should not remove the moment when the right person can challenge the assumption behind the answer.

Client and policy choices still sit where they always have. The job of review is to make the technical consequences visible before those choices are made.

When slowing down is helpful

I remember an example from when I was part of a review for a new railway programme.

A maintainer had asked for access tracks on both sides of the line. A previous section had already been commissioned that way, and the view was straightforward. This was what the maintenance team needed.

The request was reasonable. Access affects safety, reliability, and response time once an asset is in operation. It also affects capital cost and buildability along a long route.

The useful pause came when the review asked for evidence. Which parts of the route carried the greatest operational risk? Where were failures most likely? What would downtime mean? How close were critical locations to depots, roads, and existing access?

The answer was more targeted than the starting position. The maintainer's concern remained valid but the requirement became more precise.

Some locations could justify better access because asset criticality or maintenance needs were higher. In others, providing the same access by default was harder to justify.

That is useful friction. It brings the maintainer, designer, client, and wider project team into the same decision, and turns a familiar requirement into a discussion about evidence, risk, and long-term operation.

Many meetings are waste. A review is valuable when the right people are present, the information is reliable enough to challenge, and the discussion can change the outcome.

How to know when to use the tools? Stay current

Engineering has always changed its tools. Calculators, computer-aided design, and digital workflows have changed how work is done. AI is another shift in tools and it still needs care.

This is where CPD has a practical role. The world moves on, and professional qualification carries an obligation to keep learning.

The trust placed in professionally qualified engineers rests partly on staying current as tools, risks, and expectations change.

This applies to AI, as well as to safety, sustainability, new standards, public expectations, and changing delivery models.

ICE Strategy 2030 states that engineers should use technology intelligently and ethically.

The current ICE Code of Professional Conduct also makes clear that members must understand the limitations and risks when interpreting AI derived data, and that accountability cannot be delegated to such tools.

A practical test

Before removing a step, engineers should ask what it was doing.

In the railway example, the question was not whether maintenance access mattered. It was where it mattered enough to justify the cost, and who needed to be involved before that decision was made.

Was the step only moving information around, reformatting outputs or reconciling records that should already agree? That is a good candidate for automation.

Was it bringing the right people, assumptions and consequences into view? Removing it may save time but weaken the decision.

For any AI-supported task, the test should be practical. What is the consequence if this is wrong? How reliable is the information behind it? Who is competent to challenge the result?

Low-risk administrative work may suit a high level of automation. Decisions affecting safety, operability, maintainability, cost, or long-term asset performance need clear ownership, competent review, and enough time to test assumptions.

Around AI Appreciation Day, that is a practical way to value the technology. Use it where it genuinely improves engineering work and be clear about where responsibility remains with accountable professionals.

The next time we shorten or automate a process, we should ask what that step was doing and who still needs to be part of the decision.