p.dcast #3

Here is the transcript cleaned up and formatted with consistent line breaks, paragraph structures, and clear speaker headings for better readability.

PD Cast Transcript: The Intelligence Era Organisation

Tom Loosemore (00:00) Hello, you're listening to PD Cast, the podcast from Public Digital, where we talk about technology and change in organisations. I'm Tom Loosemore, one of PD's founders, and this episode is all about how senior leaders can actually see meaningful results from their organisation's investments in AI.

I'm joined by Adam Maddison, a digital transformation expert and PD network member, who is also the author of a new book entitled 'The Intelligence Era Organisation: Creating the Conditions to Thrive in the Age of AI'.

I'm also delighted to be joined by Nora Bereczkei, a product and delivery leader with over a decade of experience building and scaling internal platforms, operating models and productivity products at places like Spotify, the BBC, BT, and now at Gusto. So quite the CV there. Thank you, Nora, and hello for today and thank you for joining us on this podcast.

Nora Bereczkei (00:54) Hi, Tom thank you. I'm super happy to be here. I'm very excited about the conversation.

Tom Loosemore (00:58) Cool. Alright, well let's crack on, let's get stuck in. And in this episode, we're gonna be digging into the core ideas behind Adam's book to really understand what transforming your organisation to be ready for the intelligence era, the AI era. What does that look like in practice, not just in theory?

So, Adam, I'm gonna start with you, if that's alright, and just the very basics. What's meant by this phrase, the intelligence organisation? What do you mean by that?

Adam Maddison (01:14) Yeah, of course. That's a good place to start, given it's the title of the book. I guess let's compare it to historical eras, like starting with the industrial era, which was an interesting period where we mastered the means of mass production. It was a heady mix of human labor and raw materials and industrial machinery and quite a lot of burning of fossil fuels—maybe we'll come back to that regarding AI. That led to this extraordinary world that we live in. But there was a lot of hard manual labor involved in it and a lot of people worked really hard to build this world that we're still living in, still got the industrial era machinery around us all the time.

But then that moved into the information era. I keep referring to it as the internet era. Maybe we'll talk about the internet era and what that means for you, Tom. But the information era, where the advent of computers connected through networks and the invention of the internet completely changed the world around us and completely changed the work that a lot of us do. It involved the digitisation of data and information and the democratisation of access to that data and information, but they were still heavily dependent on human labor.

So we talk about knowledge work, we talk about cognitive load. There's still a lot of human labor involved in getting the real value out of that information. Humans doing the heavy lifting to synthesize data, to design the systems, to write the code if we're talking about computer software, which we quite often do in this world.

But now we've moved into the intelligence era with the advent of AI. AI has been around for some time. I told you, as you know, I studied AI some 30 years ago. But it's obviously taken off in the last few years with the advent of large language models and agentic AI and various other things, and maybe we'll touch on what some of those are. For those of us lucky enough to work in that world, it's brought that analysis of data, that synthesis of data to our fingertips. We can write new code, we can analyse large data sets, we can produce images and videos and front ends of software at the touch of a button. And so we've started to outsource for the first time a lot of that cognitive load, a lot of that heavy lifting to machines.

But that leads to all sorts of questions, and some of the questions that I tried to touch on in the book. If we are outsourcing to AI, when should we do that? Should we actually do that at all? What might be the protections in place? What might be some of the conditions that we need to make the most out of AI? And I think that's a particular interest to me is like what happens to the people in that world, let alone what happens to our fossil fuel dependency, which I touched on earlier. The ability to outsource really quickly, like heavy cognitive burden, has all sorts of implications for how we work these days and how we need to set ourselves up to work these days.

Tom Loosemore (04:09) I mean, I think for me, the best definition of what AI lets you do today is that you've got essentially infinite interns at your fingertips, for good or for ill. You touched on what's the role of people and what the conditions need to be to make the most of it. Could you give us a flavour of what those conditions need to be like to really make the most of the opportunities that are there from AI? Give us some examples.

Adam Maddison (04:31) Building on that infinite number of interns—as well as doing all sorts of transformation stuff, I coach people. One of my coaching clients was talking the other day around social care in local authorities, but using AI in a startup world. And he said, "Well, you wouldn't get an intern into a social care organisation and just give them the most complicated caseloads that you could find and hope that they solve them."

And I think some of those things are true for AI. We wouldn't do that with AI. We wouldn't give it the most complicated problems without any guardrails and assume it could just solve the problems for us and come up with brilliant designs and brilliant solutions.

AI should be looking at having the ability to learn quickly. AI is brilliant at producing output really quickly, but if you don't have a feedback culture, if you don't have a learning culture, then you're just producing outputs and you've no idea what the impact is of those outputs. So those sorts of cultural things need to be in place as well.

Tom Loosemore (05:25) Fascinating. Fantastic. Thank you. That's a great analogy with the industrial era as well in your first answer. So thank you for that.

Nora, over to you now. Do any of these ideas, these concepts resonate with you in terms of your experience?

Nora Bereczkei (05:40) Very much so. I have to say I loved Adam's book. I really, really enjoyed it. I thought it's a really good kind of starter for ten. What do you need to think about when you embark on a transformation like this? I think for any leader who's starting a journey like this, I would recommend it as a really good baseline of what you need to be mindful of. I find it very relevant.

How I think about transformation is that it's really hard to be very clear on what success looks like, what you need to deliver throughout your transformation program. But also sometimes it's quite hard to articulate whether you're making progress on achieving it. And I think, Adam, you touched on in your book that sometimes we set ourselves milestones and output-based milestones just to kind of give us a sense of control, which I think I recognise from different stories in the past.

How I tend to think about it is it's really helpful to simplify as much as you can on what needs to be done and why. And I think about it in three facets: process, technology, and people, if you like, just to allow us to have simple conversations.

When you talk about processes—it was in my intro as well—I'm very passionate about thinking about our operating system. The collection of processes, rituals, languages, feedback loops, roles, responsibilities, and accountability models as a product on its own, as a product itself. And arguably, I could very easily make the argument that it's one of your most important products as a company. It can be a differentiator. Building the right thing is super important, but building it right can be kind of that operating leverage that will make or break a market or your competitive leeway or headway. So I like to think about processes and your operating systems as a product that has many uses, many use cases, and you have to go through quite intricate balancing, prioritising, and conscious conversations of what do you optimise for?

I think that is a really important first conversation to have when you embark on transformation, because once you can start talking about what you're optimising for, your trade-offs will be very, very clear as well. And then you talk about how difficult it is to kind of keep the current set of bureaucracies, funding models, reporting lines, and governance while trying to build something new. I think if you start with, "Okay, what do we optimise this system for? And what are we by default, then, prioritising?" it can sharpen those conversations and help leaders identify what they need to leave behind. But it also can help you identify iterations and your roadmap on how you might get there.

The second piece is technology, which Adam, you also really nicely talk about. These are your internal platforms and productivity products, your CI/CD pipelines, your work management system, your architecture that will enable those small nimble teams that we believe are an underlying enabler for a transformation, but also having that really robust, easy, and accessible data layer. This was super, super important before, but now with AI and agentic capabilities, without that, you won't be able to prompt yourself out from the data mass that you built yourself into. I think that has quite often been overlooked up until now because we could deprioritise it, we could kind of patch over it, and we could make shortcuts or hire more analysts, for example. That is very, very much in the focus of every organisation trying to embark on an AI-driven transformation or rethinking how they might work in this new era.

And the last one is people, which I think I really liked how you talk about the roles of leaders and middle management, Adam. It's very easy to kind of talk down and blame them for self-preservation, being that "iron ceiling" where you can't look down and you can't look up, stopping the grassroots excitement and the leadership sponsorship on the top. But in reality, they also have a lot of different things that they balance and maneuver.

When it comes to people, the biggest thing that we often don't talk about when we set out a transformation is: what are the behavioural incentives that we build out? What are the rewards of time, praise, positive feedback, or a seat at the table, which I think is super, super important? But also, one of the key incentives is: what are the metrics that we measure? What are the metrics that we leave behind, which is a beautiful moment of burning the bridges and letting go of what we used to be? The set of metrics that—you know, Adam, we talk about funding models and the return on investment of project X, Y, Z in our plans or annual budget cycles or whatever—and what are the new metrics that we are going to start cherishing and talking about?

Again, if you can have those conversations with your leaders, your sponsors, and all the different users of your operating system as a product, it can be a really big enabler. We don't want to walk down a transformation path that will be hard to walk back on by the time we find that actually some of the resistance we are working against is part of our own making, because we haven't had those upfront conversations. This also should have a discovery phase where we discuss: Okay, where do we want to go? And how do we know those are the metrics that we should be tracking?

Tom Loosemore (11:36) I really like the framing around people, process, technology. There's so much emphasis on the technology and so little emphasis on the people, the behaviours, and incentives. To really get the benefit from AI, you are not going to be applying AI to your current process or your current organisational model; you're going to need to reinvent those fairly fundamentally. That's going to challenge people's empires, people's incentives, people's metrics.

And so the behaviors—the leadership behaviors, senior leadership behaviours, which is why Adam's book is so brilliant—need to recognise the fact that senior leaders need to allow fluidity and adaptability in organisations that have been rigidly focused often just on efficiency. I love the idea of saying goodbye to old metrics. You only really transform things when you've turned the old things off. And you've only really done an AI transformation when you've turned off the processes and the org model that predated AI, which takes a while.

Anyway, it's not meant to be about me, it's meant to be about you. So Adam, just quickly, where did the idea of the book come from? What's the genesis of this?

Adam Maddison (12:33) You say just quickly, but it could be a really long answer because I was thinking about this as I was writing it and over the last few weeks and months. I think the genesis of this started a while ago when Tom, you and I both met at GDS. I was working at the Government Digital Service; I started there right at the tail end of 2013.

And that was a place where it was very much a principle-led organisation. You had the things that I would like to see in an organisation, the things that I talk to people these days where they say the culture is amazing. We had small empowered teams. We were obsessed with users or customers, whatever you want to call them. There was a pressure to have these fast feedback loops and access to high-quality data that you touched on, Nora, and this culture of learning. It was an extraordinary place to be.

So I was looking out across other parts of government and looking at other organisations, and there was this obsession with large-scale agile frameworks. The Scaled Agile Framework (SAFe) was the most notorious one at the time. There was this sort of industrialisation of how do you transform an organisation? Things like SAFe and Large Scale Scrum and various other things were around, and people were selling this. Consultancies were selling this, but mostly because I think organisations were looking to buy it. They were looking for the quick fix. We'll come on to AI as a quick fix in a bit.

So I used to do conference talks on how we were principles-led, how we tried to set ourselves up, how we learned from various different ways of working, and how we would try things out and they would work or they wouldn't work, and how we shared those through communities of practice. A lot of that has appeared in the book like 13 years later.

But I guess there was an additional frustration more recently. Particularly of interest because my view of the product operator model stems from a reading—perhaps a misreading—of the Spotify model. Nora, you worked at Spotify, you would have seen what this looked like in practice sometime after it first appeared. But we've seen, and in fact, you know Nora, when you and I were both at BT, we saw this attempt at this wholesale adoption of a product operator model, which actually looked like: Let's rename our teams. Let's just move some people around in spreadsheets and let's not actually change any of the underlying conditions about how teams work, how information flows through teams, and how they get assigned work. And let's hope that we transform the way that the organisation works. So a wholesale adoption of somebody else's model still seems to be a very popular thing.

I touched on the conditions that we think are really useful for teams to do brilliant work. It's like organisations think they can outsource their transformation. They're thinking, We don't have the ability to deliver really good products and services very quickly. Our developers aren't coding quickly enough. Our designers aren't designing quickly enough. It's nothing to do with the structural issues of the organisation, with the funding models, the empowerment, the control, or the culture. It's to do with people not being able to type fast enough. AI can type really quickly. Let's just outsource everything to AI. AI is going to be the solution to our organisational problems. AI can do all the cognitive heavy lifting that I touched on earlier.

But the problem is the same underlying conditions aren't changing. Towards the end of last year, both Google and IBM did a few studies looking at where AI was successful in transforming organisations and where it wasn't—where the return on investment was coming from that you touched on, Nora. Which companies were gaining significant return on investment from AI and which companies weren't.

The results of their studies turned out to show that it's pretty much the same conditions that I was talking about 12 or 13 years ago when I was talking at conferences about how GDS operates. It's the same conditions that are necessary for companies to make the best use of AI. It's around small, empowered teams, access to data, fast feedback loops, and a culture of learning and experimentation.

So I wanted to write something about, A, my frustration, but B, about the fact that I know this works, it's amazing, and the opportunity is amazing. I remember the day I first walked into GDS in 2013; the culture was extraordinary. You were there, Tom, it was just this vibrant place. It was an exciting place. And so if we can help organisations actually get to that position, then it's better for them as a business and it's better for their people. It's a more exciting place to work, and you deliver brilliant products and services for your users. It's just a really good place. So I tried to distill all my knowledge and experience of what works, and what needs to be done in order to learn what works. I guess that's probably the biggest thing—that culture of learning, that culture of feedback. And actually produce something which... go on, Tom.

Tom Loosemore (17:00) Well, I think that... I mean, I just want to congratulate you on having done a really good job, not just of writing a book, but writing a short book. Those messages around small empowered teams that have clarity of outcome that they're seeking, that have access to the data, and that really have a culture of learning and expectation of fast feedback—that shines through. Particularly, I think, the challenges around what incentives and behaviours you need from leaders.

Nora, I'd love to hear your experiences around senior leadership behaviours that really give teams the top cover that's needed to make the most of things like AI, to allow them to thrive and learn quickly and safely. I'd love to hear some examples from you on what leaders need to be doing and not doing in order to enable the ideas that are in Adam's book to really shine.

Nora Bereczkei (17:46) I think probably the cheapest and most important thing that you can do is to go down to the factory floor and see how things work in real life. I feel like, you know, as I've described, buying a cookie-cutter solution... I think leaders would be more mindful about how applicable or non-applicable they are if they could go down and spend a week with different types of teams. I think that would really help them empathise with the challenges the teams have and the opportunities that we could easily capitalise on.

I loved Adam talking about picking your pilot teams. Find a team that has some of the opportunities already there. In the past, what has worked really well for me in one situation is finding the pilot team that feels the most pain at the time. They will be the most enthusiastic to hop on any journey and be the guinea pigs because the cost of the current system is higher than experimenting with something else. So that's also quite a good way of picking a pilot team, but you can only do that if you spend some time with the teams. I think that's quite often overlooked. We spend more time talking to different companies who are offering their services to solve our pain than going and understanding the pain firsthand. I think that is very important.

Then we can also identify what the blockers are as we go through. Once we have that interface, I think it makes it much easier. I also would recommend thinking about your user groups, because it's not just that companies are different and therefore what worked over there won't necessarily work over here without the right adaptation, but also our teams are very different within a company. If you are a platform team, your needs and requirements are very different than if you're a nimble, front-end experimentation team. I think that's also quite often overlooked because when we embark on a large transformation program, we only see the hill, right? And we want to be on the top of the hill as quickly as possible so we can celebrate success. But quite often, instead of climbing straight up, this wave-like approach is much better. What are the first steps, second steps, third steps that build on each other? And also prioritising, which is a difficult thing to do.

We are having this conversation right now as we are embarking on a very exciting transformation to experiment with how we can become AI-native. It's a super exciting time to be, and we're having this conversation of: What do we want to do? Do we want to look at our team portfolio and the different team profiles and uplift everyone to step one? Or do we want to give people and teams a bit more space and freedom to identify their own journeys? And if a team is further ahead, give them much more leeway to experiment, while different teams who might have other risk profiles, depending on the work and the context that they have, take a slightly different approach, perhaps a more cautious approach. All of these take a lot of time and consideration.

Adam and I found that when we were together at BT, what makes it quite difficult is that it's a significant undertaking. Quite often, while sponsorship from senior leadership is a must—you can't do without it—it can also put pressure on people when they try to find the quickest way they can show results, which is a really important communication tool in change management. But we must carve out the time for discovery to identify our user segments, the different types of users and teams that we've got, the different functions, the different areas in the business, and create that kind of roadmap and pathway depending on the risk profile and the context of where we want to be, which is not an easy job. I think Adam's book is a really good first kind of quick pathfinder, if you like.

Tom Loosemore (21:48) There are a couple of things there that really resonate with me in what you just said, Nora. The importance of sort of building on different phases—that you take what you learned in the early days, build it into the next wave, build it into the next wave. So you've got a feedback loop at the heart of your transformation journey, and you don't just have a singular plan.

I remember Mike Bracken, the chief executive of GDS, when I would introduce him to new people, he would always start by saying, "Well, my job is actually to say no to lots of brilliant ideas that come through our door every day because we have to focus on GOV.UK, we have to focus on the platforms, you know, the really important things." So the ability to prioritise what you're doing and when in your transformation journey, and to have a theory of change around that that you learn from, is really, really important.

I'm also really struck by the sort of leadership behaviours around cookie-cutteroring what worked elsewhere, and I love the idea that you've really got to look at the teams and where they are at an individual team level and think: What freedom should I give these people? What boundaries should I be setting around them? What stage are they at? A team is an organism.

Adam, I really like the way in your book you're really empathetic towards senior leaders around what gets in the way. One of the things that gets in the way of the product operating model is it's kind of seen as a one-size-fits-all magic cure. It's only really a few others that sort of dig under and say, How do you actually make this work in practice? I'd love to hear from you a bit about what does get in the way of organisations. The theory of needing an adaptable, multidisciplinary, fast-feedback culture is quite widely embraced, but what actually gets in the way and what do you do about it as a senior leader?

Adam Maddison (23:06) Yeah, there's so much. I mean, read the book, Tom. No, do read the book—you have read the book! Building on some of the stuff that Nora said, I really liked the idea, and you talked in your first response around treating an organisational design as a product, going to see the team, and treating those people as users. The sort of things that we would naturally do when we're building a product that we're putting out to customers or external users—having the same respect for our people and the same respect for our processes internally is a really powerful thing.

But to answer the question, the sort of things that get in the way... the legacy culture of an organisation is such a big thing. You know, I mentioned that we worked in the Government Digital Service; the civil service is hundreds of years old. And so the legacy culture is a massive thing. There is a culture of fear amongst leaders of looking like they've done the wrong thing, that they've invested money in the wrong area. The culture of blame that goes with that, finger-pointiness, and the impact that has on the ability of teams to actually deliver stuff, knowing that getting something wrong might actually be okay because you're learning. That culture around fear and blame gets in the way.

And the "good news culture" is so pervasive in so many organisations. You cannot say something is not going well; you have to say positive things. That's such a detriment to the organisation. If you promote, encourage, and reward that sort of culture—only come to me with good news, only say yes—it's the antithesis of Mike Bracken saying no, or saying "this isn't working" or something else. So you've got that legacy culture and the legacy structures associated with very hierarchical organisations. Particularly, we've seen organisations that have grown by acquisitions and mergers get this dissonance of different hierarchies, different cultures, and different reward systems—sometimes explicit reward systems, sometimes implicit reward systems. Who is actually rewarded for what behaviour? What sort of behaviours do I need to demonstrate in order to get to the top of this shop? Those sorts of things are really difficult.

And then, project funding and annual funding... I could probably talk for hours about funding and how you fund.

Tom Loosemore (25:15) Give us five minutes on funding, 'cause I thought that was a particularly strong bit in the book. It sounds boring, but I'm totally with you that it's right at the core of what gets in the way of really embracing the principles in your book.

Adam Maddison (25:25) It is, yeah. It's the idea that you must have absolute certainty of what the outcome is going to be, that you have absolute certainty over how long this piece of work is going to last, and that it is project-based. The traditional definition of a project is that it's a time-bound organisation that will disperse at some point. That just goes counter to the idea that when you're first starting out—you talked about phases of delivery—and you're literally learning what the problem is that your users are facing (whether they're internal within the organisation or external customers), you don't know what you're going to be building. You don't know what you're going to try and do to solve those problems. So you don't know what you will need some point down the line.

Then you start building stuff, you start releasing stuff, and you start learning whether it's solving the problems that your users have or helping them achieve the outcomes that they want to achieve. That is a continuous process where you're continually learning, and there may be a point where you go, "Okay, we've built enough and we can move on to something else," and that could be time-bounded. But most of the time, you should be devoting a team to continually improving the way they work and the products and the services they deliver. That requires long-term funding of the team. The team will change, and your focuses and your priorities may change, in which case you can move funding around, but you have to respect a team that is long-lasting, that is learning about its users and its customers.

Nora Bereczkei (26:47) But I think sometimes we forget to give people time to grieve, because these practices and these legacy cultures exist because once upon a time, this was what was needed to make the company successful. I find that we need to give people some time to acknowledge that this was brilliant, and you have become a successful leader in this structure, and this was very much necessary for the company to be what it is today. However, environments and circumstances have changed, and now we need to evolve. I feel sometimes very tempted, and sometimes guilty, to arrive at the conversation saying, "All of this is wrong, and you are wrong, and what you're doing is wrong, and I'm going to tell you what right is." I think that's why the empathy that you showed in the book is really important, because sometimes people are fighting for relevance. If someone is telling you that from tomorrow, this organisation will be transformed and what it was today is no longer applicable—that your practices and behaviours that made you successful up until now will have to go, and we don't know what the new ones are because it will be an iterative process—I mean, that is quite difficult for any human to be excited about. They wonder, Can I reserve what I understand? I have learned to pull these five levers in the past 20 years; what do I pull now? And we quite often don't have a very good answer. It's like, "Well, you know..."

Tom Loosemore (28:14) I mean, I think that's a really great pushback on the idea of "out with the old and in with the new." I like the idea of grieving, but I sometimes use a couple of different analogies to say that many organisations thrived during a period of relative stability of user expectation and behaviour, and they succeeded because there was relative certainty. You optimise for efficiency when you've got relative certainty, which is why you get projects and why you get some of those behaviors. The know-ability in advance of an investment is greater when you haven't got things like LLMs emerging every day that kind of change the weather.

What AI has done, for me, has changed the balance between needing efficiency as your primary and only real goal as an organizing principle, to needing adaptability, fast feedback, and learning what works as the primary goal. That's often the narrative I use. But I've never grieved for an efficiency-based project culture. Maybe we should. I think that's a really interesting idea—have a wake!

Nora Bereczkei (29:12) I think I've seen meetings where people have this kind of fear and hesitation on their faces of: I want to be excited about it, but I don't know if I can or should be. Because of the pressure of time and showing results, I feel like we have to be very mindful of carving that time out. Also, these are cultures where having these conversations is harder by default—conversations about what are the behaviours that we need to have? What do we reward as leaders, sometimes subconsciously? If this is not the culture that your company has today, it will be quite a while until you can have these honest conversations. And without those conversations, we can't set up the environment for us to succeed.

Tom Loosemore (29:55) Completely.

Adam Maddison (29:56) There's a lot of fear, and that fear leads to paralysis and then perverse behaviors. We know we need to change; people can see the existential threat out there. I start the book with the anecdote about Octopus, which is only 10 or 11 years old now, and is now the largest utility provider in the UK, overtaking British Gas, which is 150 or 160 years old.

People can see that there's this exponential threat, but yet, what's the immediate solution? The immediate solution is: I can just outsource this problem because I don't know, I don't understand, and I'm scared. So, hopefully, the book, the steps, and the guide help people realise that there is a sequence that one can go through—some things that people can try, some of which may work and some of which may not work. That's okay. As long as you're doing that with the idea that we're embedding a learning culture, I think that's a really important part of it. We can try some stuff and we can learn. In doing something that may fail, if we're talking openly and honestly about that and embracing it, then you are embracing a learning culture. That's part of the transformation; that's part of the first step to get away from this control and certainty. You need to get to this learning culture, I think.

Tom Loosemore (31:06) You know, the perils of false certainty are very appealing for people. They're a dangerous reef that you're drawn towards on your ship of change because you think it's going to be solid ground, and actually, it's gonna rip the bottom off your ship. That's a terrible metaphor, but let me ask you an unfair question, Adam. And actually, Nora, I'll leave you a bit longer to think about this one. You know I like things to be really short. I'm gonna ask you to make things impossibly short now, which is: if I was a senior leader and senior executive in a commercial company and I haven't even got time to read your book, but I'd like you to tell me one thing to change in how I lead tomorrow, what would that one thing be?

Adam Maddison (31:33) Okay, I think you've both touched on this earlier. The single biggest barrier to transformation isn't technology. Technology is a solved problem in many regards, and technology will keep accelerating. And actually, it's not funding; I think funding can be solved. I think the single biggest barrier to transformation is culture, and that culture is driven by what leaders do, not what they say.

People model the behavior of their leaders. They model what is necessary to get to the top of this shop, as I said earlier, which in historic, bureaucratic, hierarchical organisations is often fear and various other things we touched on. And so, what can one do to change the culture? As a leader, it's about demonstrating different behaviors. It's about demonstrating trust. There's a whole section on trust, which some people might think is a soft and fluffy thing, but it's vitally important.

I need to read this because the figures are extraordinary: in organisations with high trust, employees are 260% more motivated. Turnover is 50% lower. And recovery from setbacks—like when things go wrong—high-trust teams recover 26 times faster than low-trust teams. If you think about it, if a team hits a setback with a problem with some data and some AI, and it takes a week for that team to recover, in a low-trust team, that's six months of not being able to recover from that setback. So trust is like the fundamental thing. Is that a short enough answer for you, Tom?

Tom Loosemore (33:04) So the TL;DR is like: find ways to exhibit that you're going to trust a team to learn. Cool.

Nora, you got an extra two minutes to answer that question. Over to you.

Nora Bereczkei (33:14) Well, I can't decide between two. I think it's systems thinking and focus.

For systems thinking, all of the different bits and bobs that transformation will touch connect to each other and reinforce each other. If you have trust but you don't have the right funding model, you will still struggle, right? If you have the right funding model but you don't have trust, you still struggle. If you don't have the right technology, you might have the right behaviors, but you still can't realise value as and when. So kind of understanding what are the different moving parts is really important, and putting your bets—distributing your bets—to the highest priority areas.

And then the second was focus, which is kind of in tension with each other. One thing that I find difficult is that we quite often still want to keep the operational excellence that we have today while, on top of that, doing transformation. I think that makes it harder to leave things behind because we don't have the leeway—the space and leeway—built into the system. We know that when going through a change, there will be a learning dip, there will be a performance dip. I think quite often as leaders, we don't want to acknowledge that, so we keep pulling the pressure lever that we know well and has been working in the past for us—that's how we got here—while also trying to pull the transformation lever. Then, it's kind of like the brake and the gas are both being pushed at the same time. And I think, you know, that is really difficult because leaders are also under pressure. So it's not an easy job for anyone.

Tom Loosemore (34:55) Trust me, there's a reason I became a consultant. It's a really hard job, and much respect to leaders doing it. The trade-offs are really difficult, and the legacy culture you have to still live within... I've got so much respect for the bravery of leaders who are actually trying to change large legacy organisations. It's one of the hardest jobs out there.

Cool. So getting towards the end now... Just a couple of things that I think Adam, you touched upon at the start, which is if you've been following me on LinkedIn, you know I've got very excited about AI agents and agentic stuff. Can you touch upon that? It'd be really good to get your perspective on agentic AI and where you think it might be going and what organisations should be doing.

Adam Maddison (35:31) Yeah, I kind of deliberately stayed away from talking about what AI can do—as you said, it touches on it at the end of the book—because even though I started a PhD in AI many years ago (didn't quite finish it), it moves on so quickly. But I work with teams, and I'm working with a team at the moment that uses AI internally, not to write code, but to help manage the team.

The ability to generate prototypes, to prompt ideas, to write code is extraordinary, and it's just accelerating so rapidly. I've loved watching Tom create finders for petrol prices based on data coming from various services.

Tom Loosemore (36:10) Official government service API that was. Official government API. Yes.

Adam Maddison (36:13) It's an official government API, it's very good. Sorry, not dodgy—it's a very good API. Access to high-quality data is obviously vital. And actually, you and I had not an argument, but a disagreement over the role of data in the book. You reminded me that AI's specialty is to find patterns in really horrible, messy data, so there are huge opportunities, and those are only accelerating.

There are all sorts of things that people can do around prototyping. I know Octopus are looking at hyper-personalisation—building and delivering services that know the customer intimately. When a human at Octopus gets in touch with a customer, they have in front of them a really clear understanding of the person that they're talking to. It's not just an anonymous person at the other end of the call, which makes the customer feel really special, which is amazing. That's why they are the most popular company out there, because of their ability to do that.

I guess I would counter that at the same time the possibilities of AI are just accelerating, things are moving so quickly. I also think it's really important to try and remember why you're using AI and what about the humans in your organisation. I've talked to people at various organisations that we would consider to be internet-era organisations, and they feel under threat from organisations that they describe as AI-first—like literally started in the last year or six months—that are just building software, building services, and building products entirely by AI. Like a "two teenagers in a bedroom" type company that will do amazing things.

But I think it's really important—and I've touched on humanity a couple of times—organisations are collections of people, and we should still use the opportunity to find really interesting, empowering problems for those humans to solve. I think probably AI affords even more of an opportunity. You can take away some of the drudgery from their jobs and give them really interesting problems to solve. And so, actually, I think the possibilities for AI are really positive, and they can drive a really good culture in an organisation.

Tom Loosemore (38:12) I couldn't agree more with that. I think the opportunities come from really being bold about reimagining the role of the human in solving the problem in a radically different way, rather than bolting it onto an existing process. I think it's relatively rare to find organisations that have reached that realisation of just how radically they're going to need to change and how exciting the opportunities are for them to deliver value in brand-new ways, if they can break out of their legacy culture, structure, and behaviours.

But Nora, I'd love to hear from you. Your reckons on all things where AI is going, where it's useful, and where you think the challenges remain.

Nora Bereczkei (38:43) There are multiple fronts, right? You can think about personal productivity, which we talk about—you know, how we can enable engineers to be faster, use agents as much as possible. You can talk about organisational productivity, where especially for older and more legacy, heritage organisations, there are a lot of different systems that they have built over time that are quite difficult to integrate, while you can prompt over these differences. I think there is a big opportunity for understanding where these organisations can overcome internal "human glue" type of work that we know exists and pulls on productivity quite a bit. And there's also what are the offerings that we can do within our product to our users to make it more relevant with the new opportunities that we have.

When it comes to organisational productivity, that's what I'm most excited about. I think Adam touches on it in the book that AI will amplify the good, the bad, and the ugly. We don't always own the complexity of our internal structures and systems; we quite often offload that complexity to the teams or the individuals. I think this is the point where that's no longer an option.

When it comes to employee experience, you might be able to offset it in different ways. When it comes to agentic experience, you can't. It will be expensive and it will be very obvious. The incentives to invest in developer experience might have been lower than investing into agentic experience. I don't know what that says about us as humans, but that's where we are.

Tom Loosemore (40:26) Yeah. That's a rabbit hole that sadly we haven't got time to go down, fascinating though it would be. But well, thank you. Sadly, we're out of time, and I just want to end by saying thank you to both Adam and Nora for a really fascinating conversation, and thank you for going down a really interesting set of avenues to understand the role of AI in large organisations and what you really need to do to make the most of it.

If you want to know more about how you can transform your organisation to be ready for the Intelligence Era, for the AI era, whatever you want to call this era, copies of the book, 'The Intelligence Era Organisation' are available for order on the Public Digital website. Get yours now if you haven't already.

And if you've enjoyed this episode—and we hope you have—and you want to hear more, you can find other episodes of PD Cast on Public Digital's website, public.digital, or your podcast platform of choice. I've always wanted to say that! And just to finish, thank you all for listening and hope to see you for the next PD cast. Thank you.