Most companies build AI departments the way they build conference rooms — they plan the space, order the furniture, and then figure out what to do in it.

I did it the other way around. The department existed for months before anyone called it one.

TL;DR

  • Don't announce an AI department — prove one exists by delivering results first
  • Start with one business head's real pain point, not an "AI strategy"
  • Co-build alongside domain experts so the solution becomes theirs, not yours
  • Make yourself unnecessary within six months — the results will sell the next project
  • Proof creates mandate; mandate without proof creates a cost centre

Forget AI. Find a painful Friday.

The first thing I built wasn't an AI system. It was trust with one person.

The Head of Asset Management had a ₹926 crore mixed-use development to model. Multiple revenue streams, complex JV structures, scenarios that changed every board meeting. His financial model was brilliant — and completely trapped inside his head and one spreadsheet only he understood.

I didn't pitch him on AI. I sat in a three-hour workshop and watched him build models in Excel. Then I did it again. And again.

I wasn't there to judge his process. I was there to understand exactly where it broke — where institutional knowledge lived in one person's brain, where the same calculations got rebuilt from scratch every quarter, where one wrong assumption cascaded into a week of rework.

That's the problem worth solving. Not "we need AI." The problem is: this company's decision-making depends on things that live in people's heads instead of systems.

Build with them, not for them

Here's where most AI teams go wrong, and it's the same mistake consulting firms make. They take the problem away, build something clever in isolation, and come back with a presentation. Six months later, nobody's using it.

We co-built everything. Every assumption in the model, he validated. Every output, he stress-tested against twenty years of intuition. I wasn't building a tool and handing it over. We were rebuilding his workflow together, with AI filling the gaps that used to eat his weekends.

Three workshops in, he said something that changed how I think about this entire job:

"We're not building a model — we're building a system. One that's not person-dependent, serves all products, and eliminates monotonous work."

That's the moment I knew the handoff would work. He wasn't describing something I'd built for him. He was describing something that was already his.

This is the test: if the business owner can't explain every part of what you've built, you haven't created a system. You've created a dependency. And dependencies are the first things that get cut.

Make yourself unnecessary

Your six-month target for any AI initiative should be this: the person you're working with doesn't need you anymore for the thing you built together.

That sounds like a terrible career strategy. It's actually the only one that works in a traditional company.

Because here's what happens. When the Head of Asset Management starts running financial models independently — faster, more accurate, covering scenarios he never had time to explore before — people notice. The Head of Leasing asks what happened. The CFO sees the board deck and wants to know how the analysis got so much sharper.

You don't need to sell the next project. The results sell it for you.

Let the org chart catch up

By the time I presented a department structure to leadership, it wasn't a proposal. It was a description of what already existed.

The financial model work was running. The market intelligence pipeline was delivering. Stakeholders across departments were already using what we'd built.

I didn't ask for a department. I showed them one that was already producing results, and asked them to make it official.

This is where most transformation leaders get the sequencing wrong. They want the mandate first and the proof second. In a traditional organisation — where budgets are scrutinised and new functions are viewed with suspicion — that's backwards.

Proof creates mandate. Mandate without proof creates a cost centre that's first on the chopping block when the next quarter disappoints.

What I'd do differently

Two things.

I'd document obsessively from day one. When you're moving fast and co-building with business heads, the knowledge about how the AI systems work can end up just as person-dependent as the original problem. The irony isn't lost on me. The systems we built to eliminate single points of failure nearly became single points of failure themselves.

And I'd think about the connective layer earlier. Individual AI initiatives are valuable. But the real unlock — the thing that turns four separate projects into one intelligence system — is the architecture underneath them. Getting SAP data to talk to your financial models, getting construction data flowing into operational dashboards. That plumbing isn't glamorous and it doesn't demo well, but it's where the compounding returns live. I wrote more about why that architectural layer matters more than the AI itself.

The thing nobody tells you

Building an AI department inside a traditional company isn't a technology challenge. It's a trust-building exercise that happens to involve technology.

You're not proving that AI works. Everyone already knows AI works. You're proving that you understand their business well enough to make their expertise more powerful — not replace it.

Start with one person's painful Friday. Build alongside them until the solution is theirs, not yours. Make yourself unnecessary. Then do it again. And when you need to grow the team, hire for how people think under pressure, not how they present on paper.

The department is what emerges when you've done this enough times that formalising it becomes obvious.

For the bigger picture on which AI companies survive and why ownership of the stack matters, see The AI Shakeout.