The Business Technologist

The Managing Director bought a Mac.

Not for the keynote photo. Not because someone told him to. He bought it because the tool he wanted — Claude Code — ran better on it, and he had decided he was going to build, not watch. A man who has an entire organisation to build things for him sat down to do it himself.

I couldn't stop thinking about that all week.

Because it wasn't curiosity. Curiosity is reading the article and nodding. This was a leader rearranging his own desk so he could put his own hands on the thing. The motivation wasn't "let me understand AI." It was "let me build with it."

That was day one of our AI Transformation Sprint with Enchanting Travels. By day three I'd stopped taking notes on the code and started taking notes on the people — because the interesting thing in the room wasn't what we were building. It was who was building it.

For years the model had been simple. Business tells Product what it needs. Product tells Engineering what to build. Engineering builds it, everyone waits. The handoff was the process. The translation was the work — my work, for most of my career.

And during those three days, the handoffs just… stopped happening.

The Business Tech Partner cloned the repo and set up his own environment. A subject-matter expert sat down and started shaping the occupancy rules and meal-plan logic directly — not describing them to someone who would then describe them to a machine, but putting them in. The conversations drifted upstream, away from "how do we code this" and toward "how does this part of the business actually work, and where does it break?"

Nobody announced any of this. It just happened, the way water finds the low ground.

There's a name for the person this turns you into. I want to be careful here, because it isn't mine.

Gartner coined the term Business Technologist — someone who sits outside IT but builds real technology and analytics capability themselves. I first heard it the way most good ideas reach you: secondhand, from someone I trust, who'd heard it from someone they trust. It stuck.

So I'm not coining anything. I'm just watching that archetype evolve in front of me, in real time, faster than the definition was ever meant to move.

The traditional business user defines requirements, hands them off, and waits. The Business Technologist defines requirements, then keeps going — builds a version, tests the idea, iterates, and partners with Product and Engineering instead of depending on them entirely.

This doesn't make engineering disappear. Architecture still needs real expertise. The gnarly integrations still need engineers. Infrastructure is still specialist work.

The model isn't Business replaces Tech. It's Business + AI + Product & Engineering.

Watching a domain expert and an engineer build side by side — neither one waiting on a ticket — is a genuinely different thing to witness.

I want to sit with the Product role a little longer. Because that's where I live.

For most of my career, being a PM meant being the translator. Business wants X. Engineering can build Y. My job was to find the middle and write it down clearly enough that everyone could agree. That was the value. The translation.

Here's the part that keeps me up. When the cost of building drops, the translation layer gets thin. Domain experts connect straight to implementation. Engineers need less spec up front. The PM who's been holding onto their worth through tidy documents and well-groomed tickets is going to feel the floor move.

The PM who thrives now is the one who redesigns the workflow itself — who stops asking "what should we build?" and starts asking "how should this whole thing run, now that building is cheap?"

That's a bigger, harder, far more interesting question. In the old model, Product owned the requirements. In the new one, Product owns the system — the shape of how work flows, where AI speeds it up, where a human is still the point.

Product doesn't disappear here. It graduates.

If you're trying to figure out where you actually sit on this, here's a rough ladder. Be honest about the rung you're on, not the one you'd like to be on.

1. Consumer — uses AI for personal productivity.
2. Operator — uses AI inside existing workflows.
3. Builder — creates tools and solutions with AI-assisted development.
4. Systems Thinker — redesigns workflows around what AI can now do.
5. Transformation Leader — changes how the organisation operates by building capability with AI.

Most people I work with are somewhere between Consumer and Operator. Most organisations think they're at Builder when they're really at Operator. The honest ones know the difference — and the honesty is the whole game.

I don't have this figured out. The questions I'm still carrying around:

Which roles actually evolve into this — and what separates the people who make the jump from the ones who don't?

Does it scale past the early adopters, and what has to be true about governance when it does?

How much engineering support stays necessary as the tools keep getting better?

No clean answers yet. But I've seen enough to believe the questions are the right ones.

The long-term hunch I keep coming back to is this: AI may not mostly make us more developers. It may make us more Business Technologists.

And if you want to know whether it's happening in your own building, don't look at the engineers.
Look for the Managing Director who went out and bought a Mac.