How Architecture and Culture Go Hand in Hand

Intro

Charles Humble: Hello, and welcome to this episode of the GOTO Podcast. I'm Charles Humble. I'm a freelance techie editor, author, and consultant. This is the second in a mini-series of podcasts that I'm going to be doing, talking to engineering leaders. I'm aiming for each episode to have actionable insights and suggestions for further research, such as books and papers to read, conference talks to watch, and so on. For this episode, we're joined by Eoin Woods. Eoin has worked in the field of software engineering in one capacity or another for about 30 years. He's currently Chief Engineer at Endava, the established and fast-growing software engineering and technology transformation company. Prior to taking up his current role, Eoin served as their CTO for client delivery for about eight and a half years.

He is a regular conference speaker, and the author or co-author of several books on software architecture, including, "Software Architecture Metrics" for O'Reilly, and "Continuous Architecture in Practice," which he co-authored with Murat Erderand, Pierre Pureur, and which is published as part of the Addison-Wesley Signature series. Eoin, welcome to the show.

Eoin Woods: Thank you, Charles. Good to be here. Thank you for the invitation.

Recommended talk: Continuous Architecture in Practice Part 1/2 • Eoin Woods & Simon Brown • GOTO 2021

Evolution of Software Architecture: Navigating the Shifting Landscape

Charles Humble: Pleasure. So, I mentioned a couple of your architecture books there. So I thought maybe an interesting place to start would be to talk about the context of software architecture and how that's changed over time. Because I think you and I got started about the same time, plus or minus a few years. And certainly, when I started in software, I think it was maybe necessary to make more decisions upfront than it is now, or at least that was how it was done. So can you maybe talk about how the role of architecture has kind of changed and evolved?

Eoin Woods: Yes. Great question.  I think you hit the nail on the head, was that I always tell engineers now that they think I'm very, very old. Because I say, when I started building systems, we started with Unix and a C compiler. You perhaps had a database system. But sometimes you had a library, which gave you access to index files. I mean, it was a lot more primitive. And even coming forward from that into I suppose what mainstream application software was, as the internet boom was going on, there was a lot of stuff you had to build yourself. There were a lot of decisions that were quite hard to change later. And there was no such thing as a cloud that let you reconfigure your infrastructure on the fly.

So all of that meant that software architecture was inherently a fairly upfront design business. And of course, this is where in the early days of Agile, you had a real philosophical collision with Agile that was trying to defer decisions as long as possible. And lots and lots of people like me have been schooled in managing risk early, doing early prototypes, getting your critical decisions made, make sure you know what the structure of the system is before you start investing a lot in software development. Then, of course, everything changed. Languages became more flexible. We standardized on pretty well Linux as the platform for the industry. Cloud happens, a huge amount of infrastructure was just available, and you could reconfigure it on demand. And open source came along. So, suddenly, rather than having to build a lot from scratch, we were much more assembling pieces or building inside quite sophisticated frameworks. You look at things like the Spring ecosystem, or for the Python people the Django ecosystem, there's an awful lot of there to start with.

And so quite a lot of architecture exists already. But in return, people don't expect to have to make all their architectural decisions upfront. They do expect to be able to evolve things much more as they go. And so that's where the role of the architect has changed. I think some architects have made that transition very naturally. And some of them find it a little bit unsettling really. They do like to get things decided upfront, as they would put it. And while understanding the instinct today people expect to be able to evolve their systems much, much more quickly and much more continuously, because the old constraints have gone away. So why shouldn't they be able to modify and change their mind as they go, if you like? It's all about responding to an evolving business landscape, which your competitors are doing. So you better be able to do too. So architecture is now less about the big blueprint upfront, and more about making good decisions right through the lifecycle of the system.

Charles Humble: Yes, it's interesting, isn't it? I think it's probably fair to say that architecture kind of lagged a bit behind what was happening with agile and software delivery in general, at least to begin with. I guess some of that is that it was a big shift in terms of what we were used to doing. Do you think that change applies to all sorts of different types of architecture equally? That is the one, I think, aligns well with application architecture. But does it align equally well with maybe enterprise architecture or infrastructure architecture in the same way?

Eoin Woods: I think it has affected different specializations differently. My background is very much software architecture and application architecture. I think, that has been most dramatically affected. I think infrastructure architecture has been affected pretty dramatically too. Now it's much more... Many of the skills they're now using as infrastructure architects are closer to software developers than originally when they were hardware engineers who knew a huge amount about physical devices. I think that the world has moved a lot. Many enterprise architects are stuck in a difficult situation. On the one hand, they're expected... You know, the enterprise expects a five-year plan. On the other hand, the technology organization expects them to be able to change every five weeks. And that's a very uncomfortable position to be in, where for some things they're trying to reflect upwards or across the organization, that there is stability, that is a plan, we know what we're doing, there is a strategy.

On the other hand, trying to make the application teams feel empowered. And the fact this is a modern and dynamic place to work. So I think EA is probably the point where the road is dividing a bit and skilled EAs are having to kind of bridge both parts of that, and talk a slightly different language and work out how you, within perhaps an overriding, well-understood structure, you provide people with the ability to evolve continuously.

Charles Humble: I think that's interesting. Because I know from some of the consulting work that I've done that, you know, enterprises might have fixed budgets and those kinds of things. And they want that degree of, you know, we're going to spend X million on this project, or this work stream, or whatever it is. It can be very difficult, I think, to fit that into the sort of continuous delivery models, that generally we want to be working in as IT people.

Eoin Woods: There's an awful lot of organizations talk about wanting to be dynamic and agile, and yet have a 12-month budgeting cycle and a five-year strategy. And you sort of feel those two things don't fit together. They're sort of asking for the impossible. And that's where I think often EA ends up in that very awkward kind of rather high friction boundary between the two.

Recommended talk: Democratising Software Architecture • Eoin Woods • GOTO 2023

Software Architecture: Insights on Requirements and Trade-offs

Charles Humble: Are there other tradeoffs in terms of the continuous architecture approach, do you think? Are there that things like technical data might be higher or are there tradeoffs, do you think?

Eoin Woods: I think they can be. I think it depends on your context. I think we used to kid ourselves that the big design up front avoided technical debt, and we were always in control. And, you know, there was always a plan. Things did change. We just had to sort of force them in. And often, perhaps, we weren't entirely honest with ourselves as to how effective the architecture was in there, why there was a lot of architectural drift. But, if you're going to make decisions as late as you can, and you're going to evolve all the time, you're going to end up in a situation where you need to change things. You can't always change things at the time, because there's a regulatory deadline, or there's competitive pressure, or you're running out of money, or whatever it is. And that inevitably, is going to create technical debt.

Is it more than it used to be? I'm not sure. Intuitively, I'm not sure it is. But it's something which in continuous architecture we're always saying, manage it much more intentionally, perhaps, than you used to. Whether or not it's higher or lower, you're going to have it. Continuous architecture almost implies a degree of accepting technical debt as you're moving. So if you don't manage that intentionally, we all know what will happen. It will eventually kill you because your velocity will go to zero. And you just won't be able to make progress anymore.

Recommended talk: Expert Talk: Continuous Architecture • Pierre Pureur & Kurt Bittner • GOTO 2022

Charles Humble: Yes, right. Something I wanted to talk about is the process you go through as an architect. And maybe you can talk about this a bit in the context of your experiences in Endava. Particularly, I'm thinking about how you go about things like gathering requirements, which was an endless source of frustration and challenge for me. You go and ask a question and get an answer, and then you seek clarification. And the stakeholder would go, "No, that's not what I meant at all." How do you sort of manage that process? What would your advice be in terms of getting requirements and understanding what the business needs?

Eoin Woods: A key insight I had some years ago was, that you only validate a requirement when it's running in production. You can ask stakeholders repeatedly, you can run surveys, and you can do workshops. We have a whole professional discipline, analysis, who are experts at all of that. And I think all of them would also say, yes, but actually, we don't know till it's running in production. It's just our best guess until we've got it with real users using it. So I think, for me, the key journey I've been on is going from... When I started, I came from a deep love of formal methods, very much getting things perfect to begin with. That was very much how I thought software engineering should be. I've been on quite a journey now so it's more important to get something imperfect, probably reliable, but imperfect into operation, and be able to change it, than it is to try to build exactly the right thing perfectly before you put it into operation.

So, actually, I think that's the key to knowing what your requirements are. It's getting a good enough credible set to start with, not building too much, but getting it used. And getting it used, especially in a big enterprise, there's often... That culturally, it can be difficult. I haven't really got your risk management system, but I do have some screens that allow you to view this data, and people go, why would I bother? I wanted a risk management system. But so culturally, that's a bit of a discussion. There's a bit of movement on both sides. But even in big companies, it's trying to get people just to look at stuff and go, no, that's not what I meant. Great, because we've only done 5% of the development work. Now I understand what you actually wanted. The problem with that approach is, from the architect's perspective, there are architectural things, that you have to make quite big decisions. And some of those, although we try and make it as flexible as possible, are quite hard to reverse later.

And that I think is where domain knowledge and technical judgment come in, is that if you can get inside the domain... And often, of course, it's difficult for a consultant. I know you've been a consultant for many years crossing domains. But this is where domain knowledge really helps, I think, because you can just credibly think in your head, that it's going to be stream processing, or I think we will have to use events here. Or we can't use events here, we're going to have to make this, whatever it is, client-server. That's a blast from the past. You just intuitively know quite a lot about the data models and the way the system will be used to make some of the big goals quite early. Not that they couldn't be reversed, but it's going to be a lot of effort. So it's better to get the guests in roughly the right place.

Charles Humble: I think that's really interesting actually. And I think it's a really interesting trade-off with consulting. Because sometimes you have a sort of clarity. And obviously, you see lots of different organizations. So you get a sense of what does and doesn't work in different places. But at the same time, you don't have the sort of deep domain knowledge that perhaps an in-house architect who's been there 5 years or 10 years, or whatever, would have.

Eoin Woods: I think we've seen great results, actually, from encouraging some of our delivery workforce to specialize in certain industries. And it's not for everyone. Some people just don't want to do that. They want to be technical experts. And that's absolutely fine, too. We have people who are sort of domain generic, but technically specialists, but we also have people who've decided to, for example, stay for long periods in the insurance industry or the payments industry. And we think that, especially early on in projects, those people are really valuable just because they have that intuition. When the client says, you know, the process is going to work like this. They can think to themselves, that's strange because no one else does it that way. Have I misunderstood something? Rather than, yeah, that sounds fine. And just go ahead and misunderstand it.

Soft Skills for Architecture

Charles Humble: Yes, yes, absolutely. Can you talk about the necessary sort of...I hate to use the word soft skills, I'm trying to avoid it, people skills for architecture. What would you say are kind of, like, the essential skills that you need as an architect? Not from a technical standpoint, but beyond the sort of technical.

Eoin Woods: I think the key ones are all-around communication. And there's a number of different aspects to that. You do need to be able to listen. I do know, myself probably included, that quite a few architects are never happier than when in front of a whiteboard with their pen talking, using Miro today perhaps, but talking. Not all architects are brilliant listeners. And of course, unless you do listen, you're likely to end up building the wrong thing, or building it wrongly, or disappointing someone. So think listening is a skill. It's one that... I mean, for example, I'm not sure universities teach you to listen particularly well. It's not seen as a first-class skill. But actually, listening is important. Reason with empathy. Understanding, for example... It's being able to understand why somebody appears to be doing something illogical, inefficiently, or strangely. Just rather than being rather superior about it, and going, well, you know, we'll just improve all this. Thinking, no, they've been doing this for seven years. There might be a good reason. And just trying to understand them.

And then I think being able to present complicated ideas as simply as they can be, but not more so as the famous quote goes. I think the key supporting skill there is abstraction. It's not overwhelming your audience, whoever they are, actually technical or non-technical people, with all of the detail that's in your head. Being able to pull out the salient points from that conversation and relate the concepts very, very clearly, so that people understand what you're saying, why, and what the implications are. And then being able to go into a different conversation, and perhaps have a completely different set of points or level of detail. So Gregor Hohpe talks about... He's architecture elevator. You can talk to people in a boardroom, very abstract. And you can talk to people who are writing code, and that's considerably less abstract. But you actually have to be able to work in those different contexts.

Recommended talk: Build Abstractions Not Illusions • Gregor Hohpe • YOW! 2023

Charles Humble: I think that's really interesting. I think the point about listening actually is really key. And I have to say where I've got that wrong, and I have got it wrong. You know, I like to think I've learned a bit over the years. But certainly, on my first one or two projects, as an architect, I was maybe a bit overconfident. Surely we can shortcut all of that. And it's very, very tempting to think that you've understood something better than you have maybe?

Eoin Woods: Yes, absolutely. Yeah. Not really listening to the voices of experience that are in the room, often, because they're quite quiet. And they perhaps don't particularly want to make a big fuss about it. But they do actually know why something is done twice, or why we created this strange user interface that is navigated with the tab key and the arrow keys move to the mouse. Well, actually, the reason for that is, that it had to be used in this context. And it still does.

Charles Humble: I did a project for a retail bank call center in the UK many, many years ago. So it was mainframes, and the call center was literally using kind of green screens. And diving off to the two or three different mainframes that ran the... It was a bank that had merged with other banks. The call centers would like two or three green screens, and they were jumping around. And we were kind of modernizing the whole thing and doing a new UI with a browser-based UI. And we did these beautiful, beautiful screens. And we were terribly proud of them. And we put them in front of the call center staff, and they hated them. Absolutely hated them. And the reason was that they suddenly had to click around. So after you’d passed ID&V and got in, it's like, but here, I've got all the information you want. And yes, it has a learning curve like a brick, but once I've learned it, everything I want is in one place. Whereas with your thing I’ve got to go over here, and over here…So we ended up, you know, like, again with these desperate cryptic abbreviations, and fonts you needed to read with a magnifying glass, but they were happy.

Eoin Woods: I had a similar thing with an Endava client some years ago, where they had a desktop product, which was, I can't remember really, Turbo Pascal or something, really, really old. But still used lots of professional practices up and down, at least in Britain, maybe internationally, being replaced by a SaaS-based browser system. And just the same thing, lots and lots of people in these professional practices have learned all the keystrokes and sequences of keystrokes that are really fast. And they had to go and reproduce them in a modern web UI. It was kind of a hilarious exercise, really. Human backward compatibility rather than technical backward compatibility.

Charles Humble: Right. Yes. I said in my intro that you worked as delivery CTO for quite a while at Endava. So was part of that role around sort of setting the technical culture within the organization? Was that kind of a chunk of what you were doing?

Eoin Woods: Yes, and I'm still very involved in that. Yes. So my main job, my main day-to-day job now, and I'm now referred to as the chief engineer, which is...it's been more of a title change than a role change. Because a CTO, it confused everybody, because I had nothing to do with internal IT. So I had dozens of inbound sales calls from people wanting to sell me stuff or recycle my laptops. It was a constant thing. Waste of their time and a waste of mine. And obviously, most CTOs are very much sort of executive managers. And people who know me well know I'm not really the executive manager type. I'm much more of a principal engineer type. So we changed the title to make it clear that actually, I'm focused on how we do engineering. And as chief engineer, the main core of my role is, how we go about delivering client projects really well. So have we got the right skills in the right places? What should we be investing in? How should we be developing people's skills? And then how do we actually run a project? What do we know? What do we don't know? Where are the gaps? What have we done before that has been successful?

And we have a fantastic delivery framework called team, so Endava adaptive method. That really encapsulates what we've learned in 20 years of delivery. It's got a scaled agile model inside it, engineering practices. And also a model actually, we call engagement, which is how you deal with the client in a structured way that, you know, everything's very transparent, and the client doesn't get surprises, and we don't get surprises. So I'm responsible for that model. I have a terrific team work on it. But the key thing is, is that we don't write it. It's actually the practitioners in the job families who are doing the job every day, who actually write the content. We're custodians, and we're cheerleaders, and we're editors. And we coordinate, and we run communities. We try and get the whole thing moving. But actually, the input comes from the people who are working on the projects.

And I think that's what's so important, is that we're reusing real knowledge. We're not asserting that in an ideal world, something might be nice. This has worked before, or this doesn't work. That's another very common reason for changes to the framework, which is, that we thought this worked, and it does work. But generally, for a lot of projects, it doesn't work very well. You know, take that out, or add some extra columns to the spreadsheet, or give pointers to a wider range of resources. Because actually, the ones we had, we didn't realize were actually quite narrow. And a lot of people have arrived and said, this doesn't work for us. And so, you know, rework it. For example, testing is, a big field, but lots of advice on testing. And many times, we've taken good advice from one project, found it was actually quite a narrow domain, and then had to go back and generalize. Because lots of other projects arrived and went, "No, it doesn't work at all." So it's very much an iterative process of learning by doing.

Charles Humble: I think that's really interesting. As an industry, I think we are quite prone to sort of cargo cutting. Or, you know, we'll take that model from over here, and we'll stick it in over there. And sometimes it works quite well, and sometimes it doesn't at all. Because you don't have the... The Spotify model is probably the sort of canonical example of this. At this point we replicate the Spotify model. I'm not sure the Spotify model really ever worked with Spotify. It was quite theoretical when they were talking about it. They've ended up with something that looks a bit like that. But you now have something that's sort of like, we'll just pick it up and drop it in and, oh.

Eoin Woods: ...organization. Well, that's surprising.

Charles Humble:Isn’t that starterling?

Eoin Woods: We're a high street bank. And for some reason, a model that was successful in streaming music hasn't applied to our business. Who would have thought it?

When I took the job, there were two things that I realized very early, I didn't want to do what I'd seen elsewhere. One was to have some sort of methods group, a group of people who know a lot in principle, or theoretically, about software development. They've read all the books. I didn't want a group of those people writing sort of delivery method. And a lot of this predated me, but very much, you know, that was my philosophy on arriving. The other thing was not to have a quality department. That's people with clipboards who don't do the work, going around telling people how they should do the work. And so the team predates me by many years. I've just been lucky enough to run the team that's made it even better. But we've continued to reinforce this principle, by practitioners for practitioners.

And then rather than a quality department, we have what we call cross-project review. That's where one project, the technical seniors from one project, pops up on another project and says, can we help? Can we see what you do? And then they sort of explain what they do and they go, oh, that's very interesting. How about this? And is that the best you could do there? Well, no, actually. Now you mentioned it, we probably should improve there. So a whole discussion happens on a very part-time basis, a number of weeks, and then the review team writes up a standard sort of template of tables of stuff for improvement and hands it over. And the really fascinating thing is that when I first introduced this, I was a bit nervous as to, whether people would enjoy it or not. Actually, both teams love it. The team being assessed are normally quite proud of their project. I mean, and even if not, it can be quite cathartic to, you know, share the fact that it's not working very well. The team doing the review finds it really interesting, not just because they get to see another project but because they've seen really good stuff to take back to their projects.

I never really realized that it would work in both directions, but it does. And so, you know, Project A will look at Project B, Project B will go off and look at Project C, C will go and look at Project A, that's the idea. So rather than some department telling everyone what to do, again, you get projects just looking at each other, saying, if we were you, we would probably improve it, or I can see why you're doing that. I think that's probably better than what we're doing on our project. But yes, well done. That's really good. So it's more like, you know, having your professional friends turn up and give you some constructive coaching.

Preserving Culture Amid Growth: Endava's Approach

Charles Humble: I really like that. I hadn't heard that before. I think that's brilliant, actually. Presumably are there cultural aspects to that? I mean, I guess you need psychological safety and that sort of thing. 

Eoin Woods: We're a very open kind of organization. We're quite direct with each other. But we're also kind, I think, in most cases. I mean, being thoughtful is one of our values. As in, think about the other person when you're talking to them. So, yes, openness is important, but the thoughtfulness is important too. And I think just our culture is one of not annoying people trying to score points, trying to help people to be the best that we can be is our catchphrase. That's what our culture is really centered around. It's about, making sure the client's successful, you know, treat them like a person. You know, make them successful, because that's what they're paying for. And help yourself and everyone else to be the best you can be inside our company. So that sort of environment is quite good, actually, for peer-to-peer kind of reviews. Because you don't tend to get people turning up trying to score points or, you know, make some point that they're in some way superior. There's no benefit in doing that.

Charles Humble: Yes, absolutely. Absolutely. I mean, I'm still a big fan of code reviews, which I think are sort of fairly unfashionable. But I learned so much from having...you know, when I started out, from having someone who knew more than me, coming in and looking at my code, and going, "Why have you done that?" Or, "Have you thought about..." You know, I learned a bunch that way. But again, you've got to feel safe. Otherwise, you just feel like your work is being ripped apart. And that's...

Eoin Woods: Yes Or you feel very defensive. Some people are great code reviewers, and some are a bit brutal. Often undoes actually the very useful input that they had, because it's just rejected because it's presented in a particular way. Which is a shame.

Charles Humble: I worked as an editor at InfoQ and places for years as well. And I've had it there too, where, you know, some people really like feedback on their articles, but you've got to do it in the right way. Otherwise, you know, you get people's defenses up. You know, and then they're less receptive to the feedback you're trying to get them. I'm curious as to how you keep that culture going as you scale the organization because Endava has grown quite fast, hasn't it?

Eoin Woods: It has. It was about 1700 people when I joined, and it's now something like 11,500 to 12,000. So, yes, it's a lot bigger. We were just in three or four countries when I joined, and now it's... I lose track, but I think it's 14, 15, 16, something like that. I think the culture is partly carried by people. When we start in new countries, we find great culture carriers from our existing countries and invite them to spend a year or two years in the new country, building the culture. I think another thing is the culture is very explicit, and we talk about it quite a lot. It's one of the things that always reassures me. I've had people, quite senior levels, come into the organization. And after a number of months, they'll almost in a positive way, say, "People here are actually think the values are important, don't they?" and you go, "Well, yes, that's why we put them on the wall." And they go, "Yeah, a lot of places put them on the wall. That doesn't necessarily mean anyone thinks they're important."

I mean, it comes from the top. I mean, our CEO John Cotterell is an exceptional person. Of course, he's a manager, because he has a tremendous amount of direct power. But he's also a great leader. I mean, there are two things. John can inspire people to do the right thing. And also has the ability to tell people what to do. But he's very good at living the culture himself and being very demonstrative in how he's applying it. And I think that just kind of comes down then through the senior people, is that, even when we're doing mergers and acquisitions, as soon as people meet John, they realize he is behaving in a certain way, which is perhaps unusual for a CEO. And then people realize that this is actually the way that the company operates.

Recommended talk: Structures Shape Results: Software Insights • Elisabeth Hendrickson & Charles Humble • GOTO 2024

Charles Humble: It's interesting. I think it's impressive. You know, a lot of companies struggle when they get beyond a certain size to keep the sort of culture alive and going. Presumably, you hire according to your values and that sort of thing as well, do you? 

Eoin Woods: Yes, that's sort of part of our hiring checklist asking some probing questions about how you view different kinds of situations, asking people what our kind of values mean to them. Actually making that people will feel comfortable in them. We're not for everyone, I'm quite sure of that. And I'm sure lots of people will find us a very annoying place to work for whatever reason. Luckily, many people like working here, which is great, but I'm sure there are people who wouldn't fit in. But yeah, culture and value alignment is an explicit part of the hiring process. Absolutely.

Charles Humble: And you've been there quite a long time as well, which isn't... We tend to move around quite a lot. So, presumably …

Eoin Woods: Oh, it's the longest I've ever been. Yes, I mean, before, Endava, I think the longest I've been anywhere was five years. And I've been here nine and a bit now.

Charles Humble: What do you do to encourage innovation within Endava?

Eoin Woods: So we've got various ideas on innovation. I think on the one hand, completely grassroots and informally, we just try and make people think about what they're doing intentionally. I've often said my catchphrase around innovation is, that it's applying the right tool and technique to the right job, and thinking about it every time. And not just doing it the way we used to do it. And sometimes that's applying quite pedestrian technology, but in a completely new way. And that is, in my view, just as innovative as taking something bleeding edge and applying it for the first time. The way that we do it a bit more systematically is that we have an innovation community. Simona Tanislavis our group innovation manager. She has fostered, and built a community of people interested in innovation. It's a big, distributed one, right across the firm. We get little local innovation communities, and they all come together for global events, which are all virtual, as you can imagine.

And then the big event we have once a year is Endava Innovation Labs. And it's a competition. Where it happens at the local level, so inside locations and countries. And the winners of that go through to regional finals. The people from the regional finals go through to...about 10 teams go through to a grand final, that's the global final. And for that, we actually fly people into a center, all 10 teams present. So a group of pretty senior people we bring into judging. I've been there for many years. John Cotterell, our CEO comes. David Churchill, our Head of People. Matt Cloke, our CTO, will try and be there. So, you know, it's quite a big event. We make quite a big fuss. We do lots of videos at the event and make videos afterward. And frankly, we just get remarkable entries. This year was the year of AI, you will not be surprised to hear. But even that, people were applying it in really clever and really thoughtful ways, lots of different problems, from information processing, to medical, transport, and others. It was great to see.

I think what happens is that we keep saying at the grassroots, think about what you're doing. Don't do it the same way as last time, if you can improve it. We then have a community that is pretty friendly, and quite informal and relaxed. And then we have a competition, which gets a lot of attention. And so that reinforces the loop back to people thinking, yeah, all this stuff went on in the innovation labs. Well, actually, at my level, I could be rethinking, whether are we using these properly. Because that's also innovation. So those are really the three levels that we use to keep innovation running inside the company, inside cloud delivery.

Charles Humble: That's really interesting. Your sort of innovation community, that's different, I'm guessing from, like, an innovation center type of approach? I'm just curious to get your sort of take on...

Eoin Woods: It totally is. Firstly, it's all self-selecting people. It's a combination of company time and their own time, but there's quite a bit of their own time involved. And it's very self-directed. So it's a group of people in one of our locations, who want to talk about innovation or to practice innovation, want to learn more about innovation. And then the global community is those local communities deciding to be part of the global community, and attend events, present to others, or show off projects that they've done. So yeah, I mean, the idea is to get it permeating in the organization, rather than have a group off here somewhere called the innovation center, who apparently do all the innovation. I've seen that in corporate land quite a lot. And I've tended to find that... There are some good examples. But in many cases, it doesn't transfer into the organization very well. Because often these people are freed from all of the constraints that everyone else is under, because they're sent off to a WeWork, and they all get Macs when the corporate standard is Windows. And they don't have to take corporate security into account. And they don't have to go through reviews.

And they can use loads of crazy technology that some corporate standards ban. And they create lots of lovely stuff. And then everyone goes, "Okay, can we just put that in production?" And everyone goes, "Oh. Oh, no. Well, it doesn't run on Windows." And we've used all this crazy stuff. And it's not very secure. And you're thinking, what was the point of that, honestly? I mean, it kind of made everyone feel better for 20 minutes, but it's not going to transfer. What we're trying to do is to just get the thinking about innovation, permeating the organization. We also have a budget, our internal projects group, and a very snappy name, which I run. Which, you know, we try and support... If people need small amounts of money or time, try and sponsor things. Because we're just trying to get it across the organization rather than centered in one place.

Charles Humble: Are there things that individual managers can do or do to encourage sort of innovation within a team?

Eoin Woods: I think on a client delivery project, at least at Endava, the thing that the delivery manager, that's the person accountable for the whole project, they can constantly be doing, is challenging the team. Is that the best way we could have done it? What are the problems with that? Is that different from the last time we did it, and is it better? It's simple questions like that, the sort of continuous improvement mindset, which I think actually leads to real innovation. Just keeps it alive and keeps challenging people. And that sort of has to run down the project. I mean, the tech leads and we have a thing we call the technical leadership scrum, which is all of the tech leads on a project. They need to be challenging themselves, and going and asking the teams, what have we improved, this scrum, this sprint, this month, this quarter, whatever it is?

Charles Humble: That's brilliant. I think that's a really good place to round it up actually. Eoin Woods, thank you very much. Indeed. That has been fascinating. Really appreciate your time.

Eoin Woods: Thank you, Charles. Really enjoyed talking to you.

Charles Humble: Likewise.