THE T&P100 REPORT 2026

A year ago, this report captured cynicism about whether AI was still in a hype cycle. That debate is over. 81% of this year's cohort say AI is central to their business strategy, and only a minority are being asked to justify that anymore. So I want to ask the harder question: if that’s the case, why has so little actually changed so far?

Look at what this report shows us about where AI is being used. While using AI to increase the productivity of engineering is commonplace, all other common applications are centred on processes like customer service, marketing and internal admin - useful, real but often peripheral to what these businesses actually do.

That's exactly where you would expect to see value first, because it's low risk and easy to measure. However, it shows us that while an organisation might call AI central to strategy, it still hasn't used the technology to change the core processes that make it unique. It means we have investment banks using AI in the same way as coffee chains, and retailers following the same playbook as energy suppliers.

As we are seeing at Faculty, there are signs within this report that this is about to change.

Boardroom representation is one. Technology & Product representation has gone from 40% to 70% in a year - a huge shift in the space of 12 months - because the people who understand what the technology can actually do are finally setting strategy, not receiving it. That's the precondition for AI strategy becoming part of business strategy, rather than running on a parallel track.

Talent is another. In the last year, roles with an AI specialism have become the hardest to hire, ahead of engineers and product managers. That's the market clocking on to something that’s been true for a decade - applied AI skills are essential to moving the needle on your adoption and growth. Organisations that are successful in competing for that talent are, not coincidentally, the ones most likely to move past the peripheral use cases.

If I was to make a prediction about what to expect next year, I’d say that leaders will see discussion of applied AI move from strategy slide decks to the bottom line. Results clearly attributable to single line items - a cost, a cycle time, a conversion rate - that moved because a core process was rebuilt around what AI makes possible, not because a tool made an old way of doing things marginally more efficient.

Finally, I’d like to thank Stephen Rosenthal, Hannah French and the Founders Keepers team behind this welcome report for spotlighting and articulating the challenges and trends those working in technology see day-to-day.

What challenges me the most is the growing gap between what AI systems are now capable of and how enterprise operating models are still structured. Many organisations remain optimised for static software and human-led workflows, while the technology has already shifted toward autonomous learning systems. Closing that gap between technical possibility and organisational readiness is one of the hardest parts of the role.

The most difficult challenges are not technical, but systemic. Determining how much autonomy is valuable and safe at each stage. Designing governance, accountability, and incentives when decisions are increasingly made by agents rather than people. And helping large organisations move from feature-centric delivery to outcome-driven systems without slowing innovation or defaulting back to manual control.

We've moved from AI as a productivity add-on to actively redesigning how we work and build products. Our teams are using AI across the development lifecycle — from prototyping to code — and we're embedding it into new AI-native workflows rather than layering it on top of existing ones.

We're doing this responsibly: always with a human in the loop, always with our members' interests at the centre. The goal is to deliver new experiences faster, to a higher standard, without compromising on security or quality.

The early signals are positive, but there's still work to be done to connect workflows end-to-end and drive adoption and consistency across teams.

The impact of AI is - and should be - beyond just engineering. It encompasses product, design and UX. Leveraging AI across the entire product development life cycle is what delivers the bigger productivity multipliers.

It has redefined how I think about talent and teams, and where I expect my engineers to deliver value. Engineers need to do the critical thinking and keep agents within the guardrails of quality and good software architecture.

They don't need to - and I don't want them to - write code anymore. They should still care about principles like test-driven development, but applied to validating what the agent produces, not to code what they've written themselves. Their job is to engineer the environment the AI works in - context, MCPs, guardrails, architectural integrity - and to judge what the AI produces.

We've proven this is possible in a heavily regulated environment. The hardest part wasn't the tooling. It was getting engineers to stop identifying with the code they write and start engineering the system that produces it. Small AI-generated stories, continuously delivered, with engineers owning throughout, quality and time-to-value. That is where the productivity gains come from.

AI has redefined what it means to be a CTO. It's made it remarkably easy to be a builder again — not necessarily writing production code, but prototyping, exploring and testing ideas myself.

The bigger shift is harder. While some principles still hold, the environment, ways of working, tools and methodologies I spent 20 years mastering are losing relevance fast. So it isn't just about reinventing the role. It's about unlearning and relearning the craft itself. There's no playbook to follow so we're writing it as we learn.

Code and artifact ownership and accountability have become diluted. Even the best engineers can create a report or a tool or a PR with AI that, at the first glance, looks very impressive. But then you start following the logic and you realise the code is written only with local awareness, and disregarding the big picture, and the produced artifact has logical gaps in it. You realise the engineer was optimising to deliver results faster, without consideration for long-term maintainability. Their intention was right, but the result is 'work slop' that may take longer to unpick than the time saved creating it.

I'm encouraging my engineers to use AI as a tool that can make them a lot more productive. At the same time, I am adamant that the engineer must own the outputs and the outcomes of what they produce, no matter what tool they use. When you put the code in front of me, if it doesn't make sense, I'm not going to ask AI to explain it to me. I'm going to ask the engineer to explain it to me - because they should own it. And that is one of the big learnings: ownership cannot be delegated and must ultimately lie with the engineer, not AI.