How should a large company start with AI?

With one team and one problem, not a company-wide program. Pick the team whose most expensive problem has a clear owner and reachable data, ship a production system there in weeks, and let the result decide what happens next. Starting small is not timidity; it is how the systems that survive get built.

Why do enterprise AI transformation programs fail?

They spread scarce attention across many workflows before any single one reaches production, and they answer to committees rather than the person who owns the work. The result is the documented pattern: activity, spend, and pilots, with little in production. One team collapses that risk to something shippable.

What makes a good first team for enterprise AI?

A team with a high-volume, expensive workflow, a decision-maker who owns it, data that can be reached, and the appetite to use the result. Fit is set by the work, not the size of the org around it.

How does starting with one team scale?

By proof, not lock-in. Once the first system is live and owned, the next-most-expensive workflow is the next engagement, independently scoped. The organization expands because something is working, and it owns each system it adds, so it is never trapped into the next step.

Start with one team: the way into enterprise AI

The short answer

The way into enterprise AI is one team and one problem, not a transformation program. Ship a production system where a single team feels the most expensive pain, in weeks, and let the running result decide what comes next. Starting small is how the systems that survive get built, and it is how you avoid the 95% that return nothing.

The instinct at enterprise scale is to match the size of the ambition with the size of the program: a strategy, a steering committee, a portfolio of pilots across every function. That instinct is exactly what the failure statistics are measuring. There is a smaller, faster way in, and it is the one that works.

The program is the problem

MIT's NANDA research found 95 percent of organizations investing in generative AI see no measurable P&L return, and the cause it names is approach, not model quality. Programs spread scarce attention across many workflows before any one of them reaches production, and they answer to committees instead of the person who runs the work. The output is activity: decks, pilots, and quarters, with almost nothing in production. Scale amplifies the failure rather than escaping it. The full anatomy is in why AI pilots fail.

The unit of work is a problem

The unit of work is a problem with an owner, not an org chart.

Forward-deployed engineering began inside large organizations, and its unit of work was never the department. It was one problem, with a person who owns it and can say yes. Pick the team whose most expensive problem has a clear owner and reachable data. That team is a complete problem: small enough to ship in weeks, real enough to matter. The discipline behind it is forward-deployed engineering, applied to a single team inside the enterprise.

One team becomes the proof

A system running for one team, with real users on real data, is worth more than any pilot portfolio. It ends the debate with evidence instead of a slide, and it does it where procurement risk is smallest: one scoped engagement, built in your cloud and owned by you, not a platform contract that spans the org. The team that ships first becomes the internal case study the rest of the organization can actually trust, because they can go watch it run.

Expand by proof, not lock-in

What happens next is a decision made on something working. The next-most-expensive problem is the next engagement, independently scoped and independently owned. The organization expands because the last system paid off, not because a multi-year contract obliges it to. That is the difference between shipping and advising, at enterprise scale: proof compounds, and you own every step of it. The team-level entry, and how we de-risk it for security and procurement, is the enterprise page.