Tech Talks Daily
00:01:46 · Ben Grinnell
[00:01:46] S1: Hi. Thanks, Neil. Great to join you. So I'm Ben Grinnell. I'm the chief AI and capabilities officer at Newton, which is about 700 people delivering strategic delivery work for our clients. Bit about my background, I started off founding a web consultancy back in the nineties, '94 because I... They did to fund my university studies. That was when Marc Andreessen was writing Netscape, so pretty early days. And then my first encounter with AI was when Kevin Warwick, who's professor of cyber management at Warwick now, think, is... Bought the seven dwarfs to university, and they were sort of eight node neural networks. And he showed me them, and everyone was giving them human dwarf names, dopey and bashful. And I thought, that's eight nodes. What would 8,000,000,000,000 do? So I've been on the sort of AI journey for a long time. I did go and set in a self drive car in 1996 when I was at the IFAC Control Conference in San Francisco as part of my PhD. And, yeah, I've been frustrated at how long it's taken to get those out into the world. And I started my career at Anson's Delights and then joined a startup consultancy, but with an aim to change the way to both of our consulting, I spent twenty one years there, retired in late twenty twenty four, and I built a big network with the DevOps and AI community at the time. And I retired and went around the world, and I was sitting in the Galapagos Isles in April last year reading a draft manuscript of the vibe coding book that Gene Kim and Steve Yegge wrote. And I just looked at it and thought, I can't be retired. It is such an exciting time to be in the workplace. So I came back. I was advising the board of Newton around the AI strategy, and I just thought it's gonna take more than advising a board. So I went full time into the role and have loved what you can achieve if you've got the backing of the sort of board and the leaders in the business. And it's been a fantastic roller coaster of a year since then, so brilliant fun.
00:03:42 · Neil C. Hughes, Ben Grinnell
[00:03:42] S0: What a great story right from the heart of the browser wars to present day in AI retiring. Almost feels like that scene in the Godfather three where Al Pacino says, just when I think I'm out, they pull me back in. You know? But [00:03:55] S1: Yeah. Absolutely. [00:03:56] S0: But I mean, funny because I've spoke to so many founders a lot. I've had huge exits. I think, you gonna sit on the beach and drink cocktails for the rest of your days? And they say, all that is great. But once you've you've got that travel bug out your system, you've seen everything you wanted to see. And in your case, the Galapagos Island is absolutely amazing. But once you've done all that, you need a reason to get out of bed in the morning again, don't you really? [00:04:17] S1: Yeah. I mean, I had a 22 year old, fuck it, goal there. It was to do the seven marathons on 07:00 in seven days. So I did that at the start of the year, and having crossed it off, thought, well, now I haven't got any reason to get up and run anymore, so I better do some work. [00:04:30] S0: Love it. And, I mean, obviously, fast forward to present day here. You're right in the heart of AI now, and I was reading that you argue that one of AI's biggest opportunities right now is actually putting tools directly into hands of people who understand the business problem. So what changes when those people can test and build solutions themselves? Because all too often, we've gone tech first, problem second. But what happens when you do it the other way around?
00:04:56 · Ben Grinnell
[00:04:56] S1: Well, it's just been an evolution, hasn't it? I mean Yeah. If you look back twenty years, we were outsourcing a lot of that and offshoring it. And then we had the DevOps movement where you said, okay. Well, let's make sure developer can deploy stuff so we can get faster iterations. And I think 2007, was it 10 deployed today at Flickr, famous conference with John John Allspaw. And, you know, that always fascinated me. And I look at now and I think, okay. So now I can put one of my consultants in front of a client, and I can have the same person listening to the problem as the person's building the solution. And if I think about the effects of that, as you become more and more agile, less and less waterfall in your delivery, then the the speed of the iterations is all that matters. So how fast could these iterations be? Well, if you remove the handoff to the developer or especially when there's a contract involved in that handoff, then you've literally got someone building and experimenting with the client's thinking on the fly. And what that removes is you always lose a lot of context when you describe what you heard to another person, And people have different understandings as well, so it's a bit like Chinese whispers. So get rid of the Chinese whispers. So the person building a solution has the full context. There's a lot of cognitive load when you have to describe to another person as well, so you remove some of that cognitive load. And then the context, the the cost of the coordination of one person is the problem and one person is doing the work, that goes away too. So you end up with an ability to build the right thing faster. And in the world we're in, that's so important. So I think the the thing you don't want to do is when you build the right thing faster, get caught in there. Well, I've just really... I've coded this thing for the client. They can see it working. It's finished. Because, obviously, there's a ton of security, nonfunctional requirements, and architecture that gets frequently lost in that. So there's definitely a need to make sure that I... I'm trying to make sure that I put the guardrails around those sort of client facing developers so they could develop safely, which is exactly what I did in the DevOps world. I put guardrails around... You know, I I automated operations so the developers could do it.
00:07:05 · Ben Grinnell, Neil C. Hughes
And, again, that was an extension of world where people had to build servers once, and then we had the cloud, then we had DevOps. So it's just a continuation of that journey, but now it's reached a point where it's literally one person sitting in front of a person that's actually describing a problem that can solve it for them. [00:07:24] S0: And I must admit, I've been in enough stakeholder meetings with IT and people from around the business to know that traditional projects can lose important context as that idea moves from a a business team and then onto the technology specialists and the project teams there. So for what you're seeing and hearing here, where does AI shorten that journey, and where is specialist engineering still essential? Because those days of IT team taking, I don't know, eighteen months to two years to deliver a project, those days are long gone. They need to move faster now. Right?
00:07:58 · Ben Grinnell
[00:07:58] S1: Yeah. And the the biggest problem is the world's changing so fast. So if you do take eighteen months to do a solution, even if you got the requirements right at the start, it's definitely wrong by the time it comes out. So we have to be in a world where we deliver iterative value very, very fast. And the AI can speed up all bits of that. So I know we've seen live coding and some of that work speed up the development cycle. And we have got tools like Blitzy that allow legacy code bases to be looked at and to bring that context in. So a lot of the early problems with via coding have now been solved. But I was with a group in San Jose in April where we were writing some thought leadership papers on how you automate the testing bit of that work and how you can get models set up to challenge the the code that's been written by a different model and make that bit faster as well. And whereas a year ago, maybe six months ago, you couldn't really ask the model about the architecture or to get the architecture right. Now you've got a very good architecture coach in a lot of those models. So I think the the speed's brilliant. AI can... AI AI AI can speed up any element of that pipeline, but only if the person controlling it or directing it knows what questions to ask. And that's where it all goes wrong. If you don't know to ask the right questions, if you don't know to ask about what nonfunctional requirements should I consider, if you don't need... Know know to ask, how should I make this a modular architecture so it's easy to maintain? Then you won't get that.
00:09:31 · Neil C. Hughes
[00:09:31] S0: Yeah. And looking back, if we go about, what, ten, fifteen years, we had BYOD, then shadow IT. Now we're hinted at shadow AI. Just the thought of employees creating their own AI tools or workflows ten years ago would have been unthinkable, but this is where we are. So what kind of guardrails are needed now so experimentation doesn't accidentally drift into introducing security data or or even governance problems.