About

I learned this problem before AI.

The technology arrived before the rules did. That has happened to me before, and the way through it was not caution or enthusiasm. It was building judgment and a system at the same time, out of the same real work.

What I do now

Practical AI workshops for teams.

I help teams get real speed from AI without handing over their judgment.

The sessions are built around the team's own work. People learn where AI saves meaningful time, how to give it the business context it does not have, how to improve and check what it produces, and where a person has to stay in the loop. Then how a prompt that worked becomes a repeatable process, and eventually something a system can be built on.

The goal is not to use more AI. It is to do better work faster without becoming reckless about it.

2002

A queue, two analysts, and the owner of the company.

In 2002 I joined 2Checkout, an early ecommerce payments company, when online fraud was still being worked out in public. There was no established playbook and very little technology worth buying, so we built what we needed.

Another analyst and I reviewed orders. The company's owner built the queue we worked from. At the end of the day, the three of us went through what we had seen and identified what the system had missed. He changed the system, and the next day we tested it against another set of real transactions.

That loop ran for a long time, and it is the most useful thing I have ever been part of.

  1. Review real orders
  2. Identify what the system missed
  3. Change the system
  4. Test it against the next day's transactions
Then again the following day, and the day after that.

What that taught me

The judgment and the system get built out of each other.

Neither one holds up alone. A system built without the judgment of the people using it encodes somebody's guess. Judgment without a system stays in one person's head, works only while they are in the room, and leaves when they do.

What made the loop work was that both halves were fed by the same thing: real cases, reviewed together, on a short cycle. We were not theorizing about what fraud might look like. We were looking at what it had looked like yesterday and asking what the queue would have to see to catch it tomorrow.

That is why the workshop I run now ends where it does. A team that improves how it uses AI but never writes anything down has bought a good afternoon. A team that documents what worked has bought something that compounds.

Device fingerprinting

Recognizing our own thinking in a new tool.

A few years in, we outgrew what we had made ourselves. Our fraud team became one of the first customers of 41st Parameter, an early pioneer in device fingerprinting.

The first time I sat down in their product, it felt familiar. Much of what it surfaced reflected patterns we had already learned from working real cases. That is worth saying plainly, because it is the same situation teams are in with AI now. The tool is genuinely powerful, and it is still only as useful as the judgment of the person reading its output.

Sixteen years

Teams, leaders, procedures, and technology.

Across sixteen years in fraud prevention and risk, the work was decisions made with incomplete information, at speed, where being wrong in either direction cost something. Decline a good customer and you lose the sale. Approve a bad one and you lose the money.

Most of what I did was make those decisions repeatable by other people. I hired and trained analysts. I built teams. I developed new leaders. I wrote the procedures. I introduced the processes and the technology people relied on to make sound calls consistently rather than personally.

At 2Checkout I helped grow an early fraud operation into an established fraud and risk department. Later, at Alliance Data, I joined the leadership team rebuilding a large Account Protection department while it kept running, which is a different kind of problem from building one from nothing. I also mentored developing leaders through the company's Leadership Development Program.

Sebbe Jones

Why it transfers

The same room, with a new technology in it.

AI adoption is not primarily a technical problem for most teams. It is a judgment problem with a technical trigger, and the parts that decide how it goes are the ones I spent sixteen years on.

  • Deciding under uncertainty, with less information than you would like, and being accountable for the call.
  • Working with a technology that arrived before anyone had written the rules for it.
  • Knowing where a person has to stay in the loop, and being honest about where they do not.
  • Recognizing the thing that looks completely legitimate and is not.
  • Designing a process that holds up when the people running it are busy.
  • Training a team so the standard is shared rather than personal.
  • Moving quickly on purpose, which is not the same as moving quickly by default.

Now

The workshop

The session I run is called Your Judgment, at Machine Speed. It is three hours, or ninety minutes when the calendar is the constraint, hands-on and built around the team's real tasks. Nobody sits through a tool demonstration, and nobody is told that everything should be automated.

Teams are standing in that 2002 room again. AI is moving faster than the rules, and the people being asked to use it are the ones who will carry it when something goes wrong. They deserve better than a warning or a sales pitch.

What happens in the workshop →

Start here

Start with fifteen minutes.

Your name, your email, and one line about the team. I read them myself and reply within one business day with a few times that could work.