Lifting the Boat

A joint edition by Tobias Zwingmann and
Karl Ivo Sokolov (Reasonable Intelligence).

You’ve probably noticed it, too.

A few people in your organization are already doing surprisingly advanced things with AI. But compared to the vast majority, there’s often a huge gap.

So what do you do?

We don't think the answer is simply more training sessions or courses. While they provide an important foundation, they’re not enough to “lift the boat”.

What’s missing is a way to build broader AI capabilities while people are actually doing their work.

Let’s dive in.

Almost every organization has a handful of “AI champions” who are incredibly skilled with tools like Claude, ChatGPT, or Copilot. Often because they’ve taught themselves in their free time.

But having a few incredible AI users does not make you an AI-capable organization.

In fact, even having a lot of them doesn’t necessarily mean the organization itself has become more capable. There’s a ceiling to individual productivity gains from AI.

Having highly skilled people is, of course, helpful.

People who know how to use AI typically know how to experiment quickly, figure out what works, and discover use cases nobody else has yet thought of.

But they can also create a misleading picture of how far the organization has actually moved.

A handful of people might have started automating their workflows or building a personal AI agent, but the vast majority probably still uses AI only occasionally for tasks like summarizing emails (and often, the just blindly trust the results).

If you look at the average, those power users pull the number up.

The more interesting question is the median:

What actual leverage does AI give to the typical person in your organization?

That’s the capability you need to move.

The obvious response is to train the rest of the organization until they catch up.

That assumes everyone has the same (or a similar) problem. But there are usually very different groups inside the same organization:

These are very different problems.

That’s why an organization can spend a lot on licenses, courses, champions, hackathons, and adoption programs while its ability to produce actual AI-powered business outcomes barely changes.

And with AI, access to information is increasingly not the bottleneck. Everyone can ask almost anything, at any time. The bottleneck is being able to apply what you’ve learned to real work, inside your organization.

And that is more than a training job.

This is where we think the biggest shift needs to happen.

Traditional training typically starts with the question:

What should people learn?

But in the age of AI, the more important question is:

What should people be able to accomplish?

That sounds like a small difference, but it changes the whole setup.

Instead of:

Learn → test → forget

you get:

Business problem → attempt → limitation → learning → iteration → outcome

Real projects force people to deal with things that classroom training usually leaves out: the jagged AI frontier, messy business context, ugly data, legacy workflows, stakeholder constraints, and individual judgment.

Having people learn that “AI can hallucinate” is not enough.

They need to run into a mistake in their own process, figure out why it happened, fix it in a reasonable way, and carry that learning into the next project.

That’s a much stronger learning loop.

And it creates two outputs at the same time:

That second output is what eventually lifts the boat, especially if you run this loop repeatedly.

Because unlike the output of a single project, that capability can transfer across problems, roles, and functions.

Karl calls this Executional Learning – a tightly scoped project that is:

The important part is that the learning happens while the work is being done, not before it.

Think of it as the opposite of a weekend hackathon.

Hackathons can be great for experimentation, but they naturally attract the enthusiasts and power users. By Sunday evening, they have a great showcase.

The problematic part is what happens afterwards:

How do you bring this back into the organization?

Very often, you assign a sponsor, form a project group, and expect people to deliver results “on top” of their existing work.

And very often, that doesn’t work.

A better approach is to start by defining a relevant business outcome, then form a small team of people who actually matter for that outcome. Give them direct executive support, enough time to focus on the problem, and access to someone who understands modern AI and is able to coach them through the tricky parts.

Then let them work toward that outcome for a boxed period of time, which might be anything from a few weeks to a few months.

Karl has seen firsthand what this can look like in banking.

In a recent case, a small team took on a legacy RWA calculation engine that different departments had worked around for years. The legacy solution also came with significant external vendor costs.

The team took a targeted approach to the core business problem at hand. They focused on understanding the logic from first principles, considered what could be achieved with modern AI, and rebuilt the critical parts on a modern platform while ensuring the end goal would be to retry the legacy system.

That work took weeks, not years, and it’s now saving the organization six figures every year.

But there was a second – probably even more valuable – outcome: a group of people inside the organization who now deeply understood how to tackle the next problem.

And the next.

That is the whole point.

To make this kind of Executional Learning work, you need executive support from day one.

Because many of the problems the team will run into are not technical. They are organizational decisions around access, priorities, ownership, process changes, or incentives.

And those decisions often can only be made at the top – someone steps into the no-man’s land between shared IT, business, and HR responsibilities.

Ideally, that’s the CEO – or someone with their full support.

So if you want to “lift the boat,” you can’t delegate this to HR. You have to create the conditions under which more people can become capable.

Concretely, that means:

Build the ecosystem in wich gardeners can thrive.

This is also where execution-based learning gets slightly uncomfortable organizationally.

HR typically owns training. IT owns platforms, tools, and access. Business owns the outcome.

An execution-based learning project cuts across all three.

That means someone senior needs to own the outcome and make sure the initiative does not disappear between budgets, responsibilities, and priorities.

And it also changes what you should measure.

Instead of asking: “How many people completed AI training?” or “How many employees are using Copilot?”

ask:

What can the typical person now accomplish with AI that they could not do six months ago?

More AI usage is not the goal.

The goal is higher overall AI capability.

The first phase of enterprise AI was largely about giving people access, running trainings, and finding the enthusiasts.

That was useful, and many organizations have already made substantial progress on this phase.

The next phase is about making exceptional AI capability less exceptional.

To achieve that, training still matters and won’t go anywhere. But if you want to truly lift the boat, you need to create the environment for your teams to build capability while solving real business problems.

You make the organization more capable by making AI capability less dependent on a small group of “champions.”

And you know you’re lifting the boat when that capability has simply become the new normal.

See you next Saturday,
Karl & Tobias