Host Intro (Gene Kim)

So one of the next speakers is Ben Grinnell, who is currently a board member at Newton, an amazing consultancy. In this technology leadership community, he's been with us from the very beginning. He's one of the very few people who has been to every one of the 25-ish events that we've held since 2014. He's an incredible thinker and doer. He was the CIO of the UK Border Agency, and he's worked with CIOs since 2014, which is one of the reasons why we invited him to join our program committee over a decade ago.

And as a skilled business consultant, I was so grateful for the help that he gave us modeling out what it would take to run this conference smaller and more frequently. But what's dazzled me about the work he's been doing at Newton is how he is leveling up every engineer to enhance their work on behalf of their clients, and the surprising places it's taken them.

And incidentally, it's working with Ben that I've learned that one of my favorite things to do these days is to pair program with other engineers, and I'm so delighted to meet some of their fellow switched-on engineers for the first time this week.

So here to present with Ben is Tom Kilcommons, who is AI Innovation Lead, to talk about the work that they are doing. Here's Ben and Tom.

Ben Grinnell

Programmer for 20 years and then not programming for 20 years, and now vibe coding every day. Here from London, where I live with my wife and four kids. Great to be here.

So I'm going to give you a bit of background about how I came to be here, and then Tom's going to take us through some of the detail of the enterprise transformation.

In 2005, I left Deloitte and joined a startup with a dream of changing the way the world thought about consulting. I was disillusioned with the way it was perceived in the industry, thought, "We'll change that." I spent 20 years building that business, going international. And then in 2024, decided to retire. I hadn't really quite moved the dial on how the world thought about consulting — probably got worse, actually. So I was a bit frustrated, but retired at the end of 2024 and went traveling around the world, having a fantastic time.

I retired to do a portfolio — advise a few boards — and the second job I got was with a company called Newton. And I was a bit confused because it was a 700-person consultancy I'd never heard of in the business I was in in London. So I talked to the board members and the founders and was quite interested, because I found a consultancy that was not really a consultancy.

They had 700 people, and the first thing the board said to me was, "We've got a pipeline of a billion pounds." I was like, "Seven hundred people? You can't have a billion pounds. That's ridiculous." I can do the maths in my head. And it turned out they measured their pipeline in client benefits rather than consulting fees. So I thought, "That's really different."

And then I dug a bit deeper and found every contract they had was anchored on delivering the client benefits — you didn't get the consulting fees without delivering the client benefits. So that was a pretty unique business model, which I claimed to do lots of times, but no one really did. But they really did it.

So I was drawn in and thought, "Well, that sounds like a really good idea. I like the sound of the company. I'll go and work with them." And so I put together a plan with the board — an eight-month transformation that was going to take vibe coding from a thing where I think we had about three or four engineers, to making vibe coding a thing that everyone does, by running hackathons from the CEO to the new joiners, taking everyone through one in eight months. So vibe coding becomes a core skill for everyone.

Game changer. We also introduced voice agents as a way of gathering data from our clients and making that so much more efficient. Changing the way our knowledge is harvested on our programs — putting a knowledge bot at the center of every project, so all our calls with our clients and all our team member calls are transcribed into a bot, and when you join a project, you can have the knowledge there to hand. And lastly, just looking at the tools we had. Our laptops were Windows machines — we need really powerful Macs instead. So that was the plan.

And then I looked at the plan and thought, "Well, that's not really a board member position." I'm supposed to be advising, not implementing. But I was having so much fun working with the board, and I was seriously considering whether I wanted to stay retired and part-time.

I'd had a ball. I retired for a year. I went traveling around the world twice. I went up Everest. I ran around the world. But I was never really retired. It seems like 10 years ago, but this time last year I was in the Galápagos Islands on my exploration. But what I was actually doing in the evenings was reviewing a draft of Gene Kim and Steve Yegge's book, Vibe Coding — even in the Galápagos Islands. So I couldn't really leave it alone, and it does seem like 10 years ago that happened, but it was only a year ago.

So I came back and decided that I needed to join full time. I'm now full-time as the Chief AI Officer at Newton, and loving every minute of it. So that's why we're here, and it's been a great journey.

There you are — retired for a few months. And that plan is now in full flow. The end of the eight months is the end of June, so we're getting through that. And Tom has been leading one of the major parts of that plan. So for the majority of this talk, we're going to describe some of that work. Over to you.

---

One thing before I hand over — the one thing I was doing with the board was putting into practice all of the knowledge I've built with this community. So all of that AI plan and all of the organizational operating model design that we're doing draws on my experience for the last 20 years and the experience I've had with this community.

I think all eight of those books on the left were written by people who are here or have been here in the last three years. And then some of the other things that I've been pulling on — podcasts, even Ethan Mollick, I think I met here. So it's been a fantastic enabler for me. I just want to say before I hand over to Tom: thank you, everyone that's come here, and keep sharing that knowledge because it's been so valuable to me.

Tom Kilcommons

So the question I want to start with is whether our projects — delivering our clients' most important results — were going to actually be fertile ground to innovate and experiment, or not.

On the one hand, the answer is yes, because we've got access to some of the most complex problems in industry across a variety of industries. You've got a team over here working on taking years off maritime build programs — really complex pieces of engineering. You've also got people deep in the retail supply chain, putting thousands of meals back on shelves that are going to waste. Really diverse problems, and people can take the solutions from different sectors and pull them together. And not unique to us, but you've also got access to concentrated, bright, driven people, which really helps.

But the thing you've got to know — and Ben mentioned it — is that when you contract exclusively on client outcome, you have complete flexibility to choose how you get there. Within reason, you can try different techniques, you can experiment, you can be really quite innovative. So on the one hand, you've got the perfect fertile ground to experiment.

But on the flip side, if you only get paid once you get there — if you only get paid on the client outcome — you can't afford to fail. So at the same time as being very innovative and very fertile for that, you also have to try techniques that you know are going to work, and you're disincentivized from trying new things. And that's the principal tension that we had to really bake into our approach for innovation at Newton: how do you create space for this in a company which is hardwired to get to that outcome?

So a little bit about us. Most people in Newton are not developers, and they're not engineers. The majority of our people are really bright, structured thinkers, problem solvers, operations and change specialists — that's the majority of our business. And we've got a really important but much smaller digital, data science, and software engineering capability that looks after a lot of our enduring products — the kinds of things that we use over and over again with clients for the most common types of problems. That's where the engineering lives. But most people don't have those skills, so they use Excel. I heard someone the other day talk about the PowerPoint Engineering Award, and I love that — that's our main stack historically. And there are fragments of people using more and more advanced tools depending on the client's systems, but a lot of this has got to live somewhere. So the big question was: how do we make that whole circle start using software at scale to solve these problems better?

---

On the 16th of October last year, we ran our first company hackathon. We got 30 of our brightest minds from my home cluster in consumer — consumer goods, retail, and so on. I had handpicked problem statements from the cluster that I knew really well. So we had people working on machine learning problems, looking at matching fashion products so that you could predict how a T-shirt you'd never sold before would sell in the next season. We had people working on building AI chatbots on top of existing products that we had, to help roll them out much more effectively to clients — where we normally put a load of resource into engaging lots of people, actually, if we can have an interactive chat experience, that would be much better.

And it was a fantastic success. Those were real problems — not toy exercises — and that was a very deliberate choice we made.

This is some of the feedback we had after the day, and I want to spend a moment on this slide. At an individual level, people felt genuinely able to contribute. These aren't engineers — they're technical people in the sense that they're problem solvers and structured thinkers, but they're not developers. There was a snowball effect throughout the day — those early wins compounded and compounded to actually produce a really quite high-quality product by the end of the day.

The third thing was we found a massive retention signal. Consulting has a really high attrition rate in the industry, and the people who attended one of these hackathons bucked the trend — you can see it in the numbers up there. And then we surveyed everyone afterwards and saw data in terms of the level of confidence and competence that people scored themselves on in terms of digital capability and their ability to innovate and try new things — completely step-changed in 24 hours. Really remarkable.

---

So we started sharing this stuff really widely, and I want to talk about our senior leadership team who saw the results. These are our senior directors, our partners — the people who have spent years and years deep in the markets they work in. They know their clients intimately and know all too well the problems that those markets face. And they saw the examples coming out of this hackathon, and it completely changed the mindset — from "we can use AI to solve our programs more efficiently," a kind of efficiency play, to "we can tackle completely new problems, or tackle things in ways we could never have thought about before." And that created a real energy in the business that was palpable.

So we sat down with the CEO and decided: this approach is fantastic, and we need everybody in Newton to experience this, because this is going to change the way that we think about work. And so Ben, Steve, and I decided that by the end of June this year, we want every single employee to go through a hackathon — from the CEO down to the newest graduate joiner. A really big statement. We're on track for that goal. You can see the guide path there.

---

A few things we've learned along the way — we've run eight of these now.

Got to make it easy. People are very intelligent, but they're under a huge amount of pressure, and that's for a lot of reasons including some of the stuff I spoke about around the way that we contract on outcomes. So you've got to make it easy for people to pick this up.

You've got to give permission. People need permission to say, "I'm going to try something that might not work." That's what experimentation is all about. So you've got to reward engagement. You've got to reward learning for its own sake, not because of the outcome you got to — because we will get there, but we've got to try it and take some risks first.

Generating FOMO was fantastic as well. Sharing these results at our company review days — one of the fantastic things about our business is every two weeks we get together at a company all-hands off-site day, and we share what we're working on, we collaborate on our most complex client problems, and in this case we shared our hackathon outputs. This generated a fear of missing out that meant people were queuing up for the next one, and even when they hadn't been to a hackathon, they were trying to get their hands on the tooling.

Use the frontier tooling. I'm a big fan of that. We didn't want to commit to any one vendor — we rolled out Claude Code really quickly, and we always chose the API credits version so that we weren't tied into seat-by-seat licensing. That meant we had the optionality to switch when better tools come along. And that meant it was really easy. We also didn't have to convince ourselves that people would definitely get the value from it — we could just say, "Well, if you're using credits, you're using tokens, it's all good." And that worked.

---

So, talk a bit more about making it easy. Most people at Newton are not developers. What do they have on their laptop? First of all, it's Windows. Second of all, they don't have VS Code. They don't have any developer tooling. So we had to create a standardized environment, because if you've never coded before and you're already a bit freaked out because you've got a flashing terminal cursor in front of you, the last thing you want is to be faced with an environment where things conflict, where things don't install, and you're troubleshooting. That's not what you came for.

So for the very first hackathon, we made good use of Azure's DevTest Labs — essentially ephemeral virtual machines. That meant we had a really clean environment. We could pre-install some things, and it worked pretty well. We didn't have any of those nasty merge conflicts. But there was still quite a lot of manual setup — I reckon we spent an hour at the start of the day just installing and configuring things. It all worked, but it was an hour that wasn't the point of the day.

For hackathons 2 and 3, we iterated and learned, and I really fell in love with dev containers — because of the way we could preload and pre-configure, in as much detail as we wanted, everything that would be in there. We used GitHub Codespaces for that. And that meant for these non-developers, we could get the whole experience about as close to one click as you can possibly get. There's a great button that says "Open Codespace," and five minutes later, everything that you need is pre-installed. We could even push the Claude API key in there so you didn't have to worry about logging in, and we could track usage by team. We iterated that over quite a few hackathons, and that's been a big part of it — we have this Hack Ops team which takes that whole process, looks at feedback, and iterates to remove all of the friction so that everyone has the best possible experience.

The other thing which was really important to me was that there are loads of tools online that create these slightly dummy developer environments, and I didn't want to use one of those. I wanted people to come out of this set on a trajectory where, when you want to do this for real, it's not extra scary. So they're using VS Code like the rest of us. They're using Claude Code like the rest of us. We've just abstracted away some of that complexity right at the start to make it more accessible, and we can build the learnings from there.

---

On giving permission — as well as having the CEO say everyone can take a day off to do this, we also scored the teams and said 60% of the value is going to come from trying new things, whether or not they work, and learning. That was right at the headline of this whole experience.

And the results have been fantastic. Two I want to share: we had this product on the left — our cost of goods tool, essentially a supply chain modeling tool for retailers that helps them understand where the costs come from in their products. We built an AI tool on top of it that meant our clients, who we normally spend a lot of time taking through how to use the tool, could actually interact with it using natural language.

And then a tool which began life as a Python script — really detailed analysis of company supply chains — we could put that on a user interface and enable clients to interact with it, contribute to the model, and run scenarios. A much better experience than before. Because we're data scientists, but we kind of weren't software engineers, and so it bridged that gap for us really nicely.

But something about this wasn't quite good enough, in the sense that we only get paid when we deliver the outcome. So we can't have this stuff live on our laptop — that's not delivering any outcome. The question naturally came: how do we get this stuff into production? How do we make this real? And how do we use the engineering resource that we do have to scale everything else up?

Our solution was to really use pair programming — to bring the people who know the solution and have been working hard at prototyping together with someone who knows about production, who knows about cloud infrastructure, who knows a bit about security, and help bridge that gap. Because these things aren't about plugging into existing complex codebases — this is about bringing something to life that's solving a really important client problem.

---

Something really interesting happened in the hackathons. Nobody signed up for a Git masterclass. But they started writing code, they started using Claude, and it overwrote stuff they were working on before, or they overwrote each other's code, and they were like, "Oh, we should have something to fix this." So they figured out how to use Git, and they learned some lessons there. They found that context documents — when you actually spent the first few hours of the day getting all the information down on paper — meant that the rest of the day was on steroids and they could do so much more. So they discovered spec-driven development by accident and ended up learning these engineering fundamentals organically. And of course they learned about branching because they started writing over each other's code and had endless merge conflicts. And we asked the teams at the end of the day, "What have you learned today?" And they were like, "Never work in main."

---

So this is a bit of a case study. I've been working with this client for a long time — it's a major fashion retailer. We were working with them to build a simulation of their whole supply chain to help them make some really big strategic decisions: how they should position depots, how stores were going to be opening, and how they could make sure their stock was available to customers on the shop floor — which, if you've ever worked at a retailer, is a big issue.

This was billions of products flowing through the supply chain, and it was one hell of a simulation. And we got to the point where we were like, we need some real infrastructure to run this because what we have isn't working. So we sketched this out — and anyone who's worked in scientific computing will have done something a bit like this. We used Azure Batch to essentially use containers to run our simulation code.

I'm going to point back to what was said earlier about bringing in external expertise and also about the two-person pairing model. My colleague Jean and my colleague Yasmin worked on this. We had been quoted a month by a contractor to build this system for us, and they built it in six hours.

The impact was fantastic. In order to do that, we had to have our infrastructure team on call throughout the whole experience — we didn't know what permissions we needed in Azure before we started, so we were constantly running up against roadblocks. But we had the infrastructure team on call, 15 minutes away to get stuff unblocked. They spent most of the time waiting for things to run and for permissions to come through, but still — they did it in six hours.

And whilst that was all happening, the team copied the context out of the main chat into a second Claude Code instance and had the whole thing recreated in GCP in 25 minutes. And this was something we'd been grappling with for a long time.

The output was fantastic. We were able to scale up the biggest simulation we'd ever run, which meant we could run loads more scenarios, which meant the value the client got was fantastic. There's a brilliant quote from my client counterpart on the value they're getting from it. And we were also able to build it in a way that was truly in production — we could bring other simulations from other parts of the business. We had one in healthcare, which we can then package up, put it into a container, express our simulation parameters in the same way, and run it all the same. So we've created a genuine piece of reusable infrastructure in six hours, which is going to change the game for a lot of our work.

Learnings from this:

Self-serve is super important. Being able to use the Azure CLI to create these resources made a massive difference. So too did having the security and infrastructure team on call — premeditating that before the experience and going, "We know there are things we don't know, and there are permissions that we know we don't know we have." Making sure that was in place was really important.

And the pairing completely changed the game, as did the external expertise. There are points in this where you hit a point of despair — you want to give up because you're banging your head against a brick wall and it's just not working. And if you haven't got the experience to push through that, or even just another person to bounce ideas around, that can be really demoralizing. The amount of work you get through as a pair is significantly more than you can get through on your own — it's definitely more than twice.

---

So the big question, and what I personally need help with: we've figured out where hackathons get you. They get you comfortable with a terminal. They get you comfortable with Git basics. They certainly get you comfortable with vibe coding and building basic applications. And for our people who were already experts at problem-solving and already know the problems really well, this was enormously valuable. This is where the value lives for us — it starts here and it grows. It doesn't start on the far side.

People built real engineering fundamentals organically through the process. We never sat down and differentiated between engineer and non-engineer. We said, "We're going to expose you to the same tools everybody else uses. We're going to make sure it's safe. We're going to make sure we're not putting any sensitive data in there, so if you make mistakes, it's not the end of the world. And you're going to learn." And then the paired programming nudges you further along that path — you start to get experience with cloud infrastructure, with pipelines, with testing, with all the kinds of assurance things that we talk about.

Where it doesn't quite get you is to that engineering excellence piece — being able to think several steps ahead and think about how we're going to assure the system, how we're going to control it in the long term, how we're going to observe what's going on. So the big question I'm grappling with at the moment is: with an organization that's mostly non-engineers, how far along this spectrum can we take people?

---

Ben Grinnell

And some of the things I learned were how important it was to get every single member of the board aligned, because this is an organization running at full pelt. It grew 40% year on year, expanding into Australia and America, all in the last 12 months, and did all this work. So it required a big investment of time and people when that meant we couldn't do client delivery quite as fast. There's an eight-month waiting list on clients at the moment — we're telling some of them, "Because we're doing the hackathons, we can't start in November. We're going to start in December with you." So that's the trade-off. It's finding the time and making sure you've got the board alignment to learn, which we managed really well. I was really pleased with that.

So I think anyone who's struggling to make their organization API-led — a bit like Jeff Bezos did at Amazon, but our organization is a pick-up-the-phone-and-speak-to-someone type — the question is: how do we make sure that we've got APIs in every area of the business? How do we make sure that our curation of knowledge is AI-based rather than people-based? Do we go with open by default or closed by default in terms of how we share knowledge across the organization? And we've got agents going across the enterprise.

The two things I really need help with at the moment are these: if we all believe that what we're seeing today is going to continue, then I see a massive inference crunch — especially if we let everyone loose and use all the tokens we've got in the world. So if there's an inference crunch and the ability to vibe code is part of our critical infrastructure, then how do we protect that? I'm seriously looking at whether we need to build our own data center.

And the other one is: we're pushing vibe coding into a lot of areas — public sector, defense, infrastructure, mission-critical areas. So how do we make sure we're not just pushing speed, but pushing safety? Can we get formal methods and things like that in, particularly in a world where AI attacks are going to be so sophisticated that we're going to need much better firewalls and defenses?

Those are the things I'm really interested in. I've heard quite a few people interested in formal methods, so look me up. Thank you.