RETHINK
WORK.

Anyone who works intensively with artificial intelligence over an extended period changes how they work.

Not necessarily as a person. But in how information is gathered, how problems are categorized, and how decisions are prepared.

I notice this in myself. And I notice it in how others react.

People who work with AI daily can sometimes seem hard to understand to those around them—perhaps even erratic or impatient. They arrive at assessments in a very short time that would take others considerably longer. From the outside, this can feel unsettling.

I believe this is precisely where a misunderstanding arises that stalls many good projects.

How work changes

Intensive use of AI creates new ways to contextualize information and rapidly iterate on ideas.

Background research runs in parallel with the actual work. Technical literature, videos, documents, and competing viewpoints can be reviewed and compared in a fraction of the time.

A simple example:

Ten technical videos on a subject used to take several hours. Today, they can first be automatically parsed, summarized, and categorized. Only then do I decide which ones are worth watching in full.

It is similar with documents.

A quick photo with a smartphone camera is enough to verify a claim, a product label, or a table. A 100-page PDF can be structured, summarized, and searched for key statements in minutes.

This does not replace close reading where it matters.

But it helps identify very quickly where it matters.

AI agents compile information, digital note-taking systems grow continuously, and new publications can be monitored regularly and pulled in only when genuinely relevant to a project.

The result is not automatically a better decision.

But a well-informed decision can be prepared in substantially less time.

What changes in working with others

This new way of working has a side effect.

Those who work intensively with AI may turn to colleagues less frequently for purely factual and research questions.

Not because the experience of others is worth less.

Rather, because much of the information has already been researched, cross-referenced, and checked in advance.

This is precisely why AI practitioners must stay vigilant.

Colleagues can easily feel that their opinion or experience is no longer needed.

And that impression can damage collaboration.

This is especially critical because the most vital information in an organisation is often not found in documents at all.

It resides in experience.

In routines.

In customer knowledge.

In knowing which shortcuts actually work and which seemingly elegant solution has already failed three times in practice.

This kind of knowledge cannot simply be researched in a few minutes.

And what if the AI is wrong?

The obvious objection is: AI makes mistakes.

That is true.

And it possesses a distinct characteristic that calls for caution:

A false answer can be formulated just as convincingly as a correct one.

That is why an AI’s answer should always be treated as a working hypothesis first.

Critical statements must remain verifiable.

Sources must be checked, different models compared, and contradictions deliberately investigated.

Varying results are often particularly valuable.

They highlight exactly where closer inspection is required.

However, agreement among several AI models by no means guarantees that a statement is correct. Multiple models can inherit the same bias or rely on the same flawed sources.

In the end, what remains decisive are the exact same qualities that mattered before AI:

Skepticism.
Judgment.
Experience.
And responsibility.

AI does not replace one's own judgment.
It can, however, provide it with a much broader foundation.

When two worlds collide

The difference in working methods becomes particularly evident when an organisation brings external AI expertise in-house.

Two worlds often collide in a very short space of time.

The external specialist can process vast amounts of information rapidly, evaluate alternative solutions, and present a first proposal in just a few hours.

People within the company often experience this process completely differently.

They may have been dealing with the topic for years.

Then an outsider arrives, spends a few hours on it, and already presents a solution.

The understandable reaction may be:

How can anyone judge this after such a short time?

The external expert may think just the opposite:

Why has this problem been debated for years when key parts of it can be analysed in a matter of hours?

Both perspectives are understandable.
And both are incomplete.

The external specialist brings speed, methodology, and a broad information base.

The people inside the company bring something that no AI can acquire in a few hours: years of lived experience within this specific organisation.

They know how processes actually function—not just how they are documented. They know customers, exceptions, past decisions and their consequences. They know which seemingly simple change triggers new problems in three other places.

An external expert can gather a vast amount of knowledge in a few hours. Ten or twenty years of lived organisational experience cannot be acquired in the same timeframe.

Good projects therefore need both: acceleration and experience.

Different speeds are not the real problem

Things become difficult when differing tempos breed mutual disregard.

To the AI specialist, internal workflows may seem unnecessarily sluggish and established conventions cumbersome. Employees, in turn, may view the specialist as someone who judges prematurely and does not understand the realities of their business.

At that point, both sides may be talking about the same project, but no longer truly talking to each other.

The specialist presents solutions to problems whose context they do not yet fully grasp. The organisation, meanwhile, defends workflows whose original purpose no one can quite explain anymore.

In that moment, valuable time is lost.

What helps

In my experience, the solution does not require each side to understand the other's methods down to the last detail. That would be neither realistic nor necessary.

What matters more is a shared understanding of what problem needs solving, what outcome is expected, and where the boundaries lie.

This situation is not entirely new. It resembles the relationship between a client and a master carpenter:

The client does not need to understand every detail of joinery or roof construction. They need to know what kind of building they need, what standards apply, and how to verify that the result fits.

For the carpenter, the master craftsman certificate, industry standards, experience, and warranties create trust. For AI specialists, such established anchors of trust are still limited. They must therefore build trust through other means:

Through transparent assumptions. Through verifiable results. Through honesty about risks. And by taking responsibility for their work.

Transparency does not mean that every stakeholder must follow every technical step. Transparency means that assumptions, risks, and results remain auditable.

People in the company are not a bottleneck

A crucial role in such projects is easily underestimated.

Employees within the organisation are not merely data providers for the external expert. They are trailblazers. They open doors. They provide context. They explain interrelationships found in no process manual. They clarify responsibilities. And they help spot obstacles before a technically elegant solution becomes a practical disaster.

This role is vital. Because a fast solution that bypasses the company's reality is never a good solution.

And the expert has obligations too

Anyone working at high speed with AI must accept that speed alone is not quality.

The expert's role is not just to analyze quickly. It is also to listen before accelerating. They must understand why certain workflows came to be. They must know the difference between sensible caution and unnecessary habit. And they must explain their results so that others can trust them and build upon them.

A skilled craftsman does not explain every single movement to the client. But they can explain why the roof will hold. AI specialists need that exact capability.

What I advise managing directors and executives

• 1. Define problem and success metric clearly

  When bringing external AI competence into your organisation, start by defining clearly which problem needs to be solved. And determine how you will measure project success. The shared goal bridges both worlds—not the methodology.

• 2. Designate an internal project sponsor

  Designate an internal project sponsor with enough standing to gather information, open doors, and drive necessary decisions. This role is not an afterthought; it is often decisive for success.

• 3. Evaluate outcomes and value

  Do not evaluate whether a way of working feels familiar. Evaluate outcomes, risks, clarity, and value. An unfamiliar working method is not inherently a poor working method.

• 4. Demand respect for lived experience

  At the same time, expect the external expert to respect your organisation—even where it operates more slowly than they do. Because slower does not automatically mean worse. Often, it simply means that more experience, responsibility, or dependencies must be taken into account.

Two speeds do not have to be a problem

Even today, significant differences in pace can arise between those who use AI intensively and those using traditional methods.

These differences will occupy organisations. Yet they do not have to lead to conflict. Friction begins only when speed is mistaken for superiority. Or experience for obsolescence. Both would be a mistake.

The defining capability of the coming years will not merely be mastering artificial intelligence. It will be combining human experience and machine acceleration in a way that produces better decisions.

Because working faster is not progress in itself. Reaching the right solution faster is.

A few months ago, an established engineering and technology company approached me with a clear challenge.

A critical process had been running inefficiently for years, causing substantial ongoing overhead. Management had recognized the issue. The people involved in the process itself, however, hardly saw a problem.

The task was understood quickly, and I was asked the two usual questions:

How long does a solution take?
And what does it cost?

The answers were encouraging. Implementation would have been possible in just a few days, at very manageable cost.

Today, this is no longer an exaggeration. Modern, AI-assisted software development is transforming the speed at which bespoke applications can be built. What previously took weeks or months can now be implemented in a matter of days for well-defined tasks.

Yet this was precisely where the real problem began.

What became visible during the analysis

If you want to automate a process, you must first understand it in detail.

And that was exactly when the sheer volume of unnecessary complexity accumulated over the years became apparent.

Around what were essentially simple tasks, numerous bureaucratic rituals and obstacles had evolved: controls whose original purpose nobody could really explain anymore, manual steps that could have been automated long ago, and coordination loops offering no discernible value.

None of this was dramatic in isolation.

Yet taken together, it created a process that tied up far more time, attention, and staff than should ever have been necessary.

It quickly became clear: A new application would not merely accelerate individual steps. It would bring transparency to a central workflow that had previously been fully understood by only a handful of individuals.

The project was therefore more than a technical exercise. It offered a golden opportunity to fundamentally simplify a historically grown process.

Then came the rules

When internal IT learned of the initiative, the small project was practically finished before it had even begun.

The discussion suddenly shifted away from business value to tooling.

Why not use the existing, already licensed low-code platform? Did the planned solution align with internal IT philosophy? Which enterprise development standards had to be met?

The plan was a lean, independently developed web application with clean, well-defined interfaces to existing standard systems.

Nothing exotic. Nothing unmanageable.

Nevertheless, extensive conventions had to be resolved just to set up a completely isolated sandbox database before a single table was permitted to be created.

To be fair: Legitimate concerns underpin such questions.

Who maintains an application if the external developer is no longer available? How are permissions governed? What about information security, data privacy, documentation, and auditability?

These are the right questions.

A good solution must answer them.

The problem, therefore, is not the existence of rules.

The problem arises when a small, clearly scoped experiment is subjected to the exact same organisational hurdles as the rollout of a mission-critical ERP system.

An isolated project carrying manageable risk must not be treated organisationally like a core enterprise backbone.

It was precisely this distinction that was missing.

The result

The solution could have been built within days and likely introduced just as swiftly.

Today, nearly a year later, it still does not exist.

The process continues as before, generating avoidable overhead day after day.

Nobody in this story acted with malice.

Every single rule probably had a good reason at some point. Every person involved was able to defend their position with sound logic.

And yet, the sum of reasonable individual decisions led to a poor collective outcome.

The truly remarkable aspect lies elsewhere:

Management had identified the problem.
They knew the cost.
They knew a viable solution.
And yet, they could not prevail against their own organisation.

There was no lack of knowledge.
There was no lack of money.
There was no lack of technology.
What was missing was a decision.

In the past, this was expensive. Today, it becomes dangerous.

Years ago, one might have viewed such a case primarily as an internal efficiency deficit.

Today, it is a matter of competitive survival.

For a long time, organisations could comfortably afford organisational friction. Inefficient processes, redundant alignments, and bloated structures were ultimately absorbed through margins, prices, or additional headcount.

Nobody should rely on that today.

Because the pace of technological change has accelerated dramatically.

Artificial intelligence increasingly allows clients and customers to complete tasks independently for which they previously required external service providers. Specialist support is often needed much later in the workflow.

Simultaneously, new companies are emerging that deliver comparable services far faster—with smaller teams, minimal internal complexity, and modern tools.

The crucial point is:

These competitors do not necessarily possess better technology.
They simply deploy existing technology faster.

And therein lies the existential risk for incumbent organisations.

The very technology that is debated internally for months is already being run in production by a nimble competitor.

Slowness was once expensive. Today, it can become fatal.

Many companies do not have a technology problem

Discussions about digitalisation often create the impression that companies primarily need to discover the right technology.

The better software.
The better AI model.
The right platform.

Yet frequently, the real issue lies elsewhere.

The technology is already available.
The knowledge is already present.

What is lacking is the organisational ability to translate this rapidly into a decision and subsequently into a working solution.

And that is why digitalisation is ultimately a leadership responsibility.

What I advise managing directors and executives

• 1. Create a fast track for small, bounded initiatives

  Define binding baseline standards for information security, privacy, documentation, and maintainability. But avoid subjecting every small experiment to the full bureaucratic machinery of a corporate enterprise platform. Risk and governance must be proportionate.

• 2. Put a deadline on objections

  Concerns are valuable when they arise early and lead to better solutions. They become destructive when they delay decisions indefinitely. Once a defined deadline expires, a decision must be taken. By someone who carries accountability. Not by inertia.

• 3. Make someone accountable for solving the problem

  Organisations usually have clearly defined roles for rules, standards, compliance, and gatekeeping. Far more rarely is someone made accountable for actually making the problem disappear. Both are important. But only one of them actually improves the process.

• 4. Regularly question entrenched habits

  Ask yourself regularly which workflows in your organisation exist solely because they have always been done that way.

Inaction is also a decision

Companies do not inevitably fail because they lack access to new technologies.

They can also fail because their organisation prevents them from leveraging existing opportunities in time.

This represents one of the greatest challenges of the coming years.

The tools exist.
The knowledge exists.

What is required are leaders willing to challenge entrenched structures, dismantle unnecessary complexity, and make decisions before the market makes them on their behalf.

Because even when no decision is made, a decision has been taken.
Then the existing process decides.
The existing organisation decides.
The existing overhead decides.
The existing inertia decides.

The good news is: As long as an organisation retains the capacity to act, that decision rests with its leadership.