Affan: Hello and welcome back to the Agentic op model podcast. thank you very much for logging back in. today we're gonna be talking about the three lenses. So without further ado, I'll pass you over to Wout and over to Mark and let's talk pain points today. Wout what's your experience with pain points?
Wout Helsmoortel: Yeah, it's a it's it's a broad question, but I think in in transformation in general, what we're seeing is that many transformations are tackled from from different lenses. So some look at an architectural lens, very technological. operations is is a good one. and of course user experience. But what what I notice is that they are not being combined into one. you cannot look at a transformation separating those three lenses. and I'm not really seeing today a lot of transformations that are combining those three.
Affan: That's really interesting. So why why do transformations break at the joints then?
Wout Helsmoortel: Yeah, it's good. the joints between operations experiences is if you're transforming operations, how people work together, but you don't know how they are lived, how people are experiencing it today, you're designing an operating model system without user feedback, without knowing what the actual outcome will be or how that will be lived. Connection between operations and architecture is if you're creating this future operating model, but you don't know really how you how you want to build it, how you need to get there architecturally. You're building something that's not executable, you don't have the right systems, you don't have the things in place to to to get there. And and then the other seam is between experience and architecture. Architecture has to keep in mind that the systems it delivers are there for people, not the other way around. and that's a classic user experience technology architecture misfit. It's easier said than done. so th there's a lot of of things to dive deeper into, but I think we really have to get those lenses closer together. But I don't know, Marc how how you look at that, do you agree and and what where are the main issues?
Marc: Yeah, Wout it's always interesting to reflect back on transformation programs. I've seen good, bad, and ugly. And you generally probably remember more the ugly ones than you do the actual good ones. And if I think back to traditionally some of the ones that have actually really been quite successful, it's because they've engaged their user community. And it hasn't had that focus on the technology. It's had the focus on changing people and process predominantly. And I think one of of the things, certainly on one program I remember, which was probably about 400 people going through a transformation to change from one software system to another. And that was a phased program. It was the amount of communication sessions that were organized as well as putting in people champions. So the individuals who are going through the change, weren't left to be isolated. And equally, a lot of time and effort was spent on producing sufficiently appropriate content to help the change. And from that, mean, not too technical, not full of jargon, and something that people can sit down and just sit down and read without having to pick up a dictionary or constantly ask their colleagues, word mean and it's you know that in its emphasis skill of understanding how to actually translate something to be understandable relatively quickly but I think when you look at the size and scale of the transformation that we're going through now with working in AI Everybody is going to have some impact on it. know, traditional transformation programs, those people in the transformation team were at the advantage. They knew what was coming. They were part of that change process. Now, even the people trying to undertake the transformation don't necessarily have as much of an understanding. So if they're nervous, if they're not coming across as understanding and they're trying to communicate to a user group that's also uncertain and potentially, you know, very cautious about the change, you're going to have two very nervous parties trying to communicate with each other and that doesn't really bode well for me.
Affan: So you know, looking back to the the previous episode where we spoke about what is a not model and what a not model isn't, and the distinction between a not model and a business model. I've often found, and I'm I'm sure it's the same with you guys, is that when I've walked into an organization that's about to undergo a massive change initiative, is if you were to ask them what their operating model is, they could describe it in source, but it would be difficult for them to, you know Annotate it on paper. Do you guys have you had similar experiences?
Marc: I think it just depends where various different things sit. I mean, the business model is often seen as more of the strategic tool. So it's going to be with those people who are shaping strategy. So that could sit with the chief operating officer of the finance, more of the senior people that are there. Sometimes I suppose part of the problem is the secrecy of the business model because obviously they may have some commercial sensitivity to it. The operating model is in a sense the as is today. It's effectively how things are operating in this current state. I think we've mentioned before that years ago, it was often the case that the people who looked after the current operating model were generally in the quality management and HR set out as an organization chart and particularly policy documents for each department. And equally, when you talk about the operating model it often again sits with the more senior you know individuals who are going to be involved in the strategy or transformation and this is where an organization that has a lot of transparency should be actually you know sharing and getting better access to both the strategic plans in the business model the current operating model and the the target and you know if you really want some sort of classic examples of of where we can look to things to improve. A lot of the changes that took place in the 1970s and 80s with the Japanese manufacturing plants were just in time, various different other programs and they bought, I think it's the Andon cord or the Andon chain is a classic. that if an individual was working in a production line and they saw something, weren't happy with, they could pull on this cord and stop the process. And then they could have a review and they could see what was failing and all sorts of things. So a very direct way of interacting with the current operating model to almost stop it to a point so you can reflect upon what's wrong, change it, and in certain circumstances, maybe have a new target operator because it might be quite considerable thing. But.
Affan: And organisation would tolerate a a pause in production then, would they?
Marc: Yeah, and this is one of the things that at the time was quite revolutionary because to give someone the power to stop a production line when you're talking of tens, hundreds, if not millions of dollars are at stake for every minute or hour that a production line is halted, that was quite some undertaking for them to stop the current operating model. So, you know, that itself is an interesting way of looking at, the organization or is the organization willing to hand over more of the insight to the people who work in the company or is it going to be left to a very select group of individuals to actually build that.
Affan: but this falls into the governance framework, doesn't it? In as to permissions, decision rights, delegation of authority to what level and so on.
Marc: And again, you could argue that too many organizations have gone down using way too much governance. And again, when you look at the use cases from an agentic perspective, Is that going to work in that agentic hybrid environment? Are we going to be able to have, in a sense, too much dominance of governance because agentic systems may be able to apply that, which means there's no room for creativity and there's no room for flexibility because everything is so rigid, policy driven.
Affan: What about Wout in your experience, what about the relationship between effective communication and suffering pain points or lack of effective communication and suffering pain points in a transformation initiative?
Wout Helsmoortel: Yeah, it's it's a very definitely a pain point. So you first need to map out all the stakeholders, try to understand who's part of the transformation, to then tell them what's going to happen. also in traditional transformation, you often see that when you're not including your end users and they all of a sudden end up with a new process. With a new technology, there's hesitance to use it because they were not involved. So you always have to involve those end users. and definitely with a gentic transformation, people are a bit scared. so that's also why you should measure trust as a transformation evolves to understand how much trust is there, how can we increase trust? How can we let them understand this is actually. letting their job evolve. It's not taking away their job. so it's a very big issue and it's not addressed enough.
Affan: No. No, and you know, communication to me, as a being a former Royal Signals officer, it's communication is absolutely key. It's communication, the reasons for the change, communicating updates during the change initiative, and it's communicating at every single level of the organization in an appropriate manner using the eff most effective channels. And again, you know, it it could be, you know, having human champions th that communication to others in a language that they understand and so on and so forth. But it's absolutely key.
Wout Helsmoortel: What I'll propose to do is maybe we could have a look at the three lenses individually.
Affan: yes, please.
Wout Helsmoortel: so you know listeners get a bit more familiar on the on the lenses. funnily enough, we each represent one lens. it really fits with our background. To to look at experience, obviously from the previous episode we talked about the restaurant example, how you experience the value proposition, how you experience the service being delivered. But also for the person delivering in the restaurant, a lot is gonna change. So we were talking about agentic transformation. And I needed again a little bit of an example. so today what's happening in transformation that's technology driven, It's software as a service, so SAAS has been very big. A lot of old school processes have been transformed through software. So it's often like a tool, you work in it, a human does something. And that's how traditional SAAS used to work, Dropbox, all these all these tools that that we know, What we're seeing today is that the agentic model of that is that agents need briefing, they need they need context, then they connect with some tools and they act themselves. They act for you. So in our restaurant model, you're looking at certain jobs that are being done by an agent. So a table could be booked, a no-show could be refilled. So for the human experience, it's quite interesting because certain jobs are being automated completely. Before software was more making it easier and you still had to act. In this transformation, we're seeing that agents can actually do part of the job completely. For you. And to your prior question of trust, it's often it's very scary. Like, what will the agent do? What will it not do? But then it's very important that you understand how is my job made up, which kind of experiences, which kind of jobs, and which ones will we automate, and which ones do I want to keep? And I think this is giving back the power to the end user that they can try to understand: we're going to automate. Maybe things you didn't like and it gives you more time to do something else. now, of course, zooming out to experience the job experience will completely change. I hope for the better. That may be naive, but that should be the outcome. We should transform for humans and not to automate them away. Marc, any reflections on on the experience lens from your side?
Marc: y you know my background and you know w the areas that I specialise in and and one point that you made is obviously context 'cause that's a a real interest of mine. a huge subject so broad. I mean what does actually context mean? It it means effectively everything. You can't have everything embroiled in one. So to me, context is important for the user experience of getting the right context to the right person at the right time so that They have the right experience because if not, then the person's gonna be sitting there confused, unsure, has something worked, has it not worked, what do I do now? Do I go forward? Do I go backward? When you're working on your own and you're generally just working in the normal process, you've got some understanding of of how things unfold. If when you switch to an agentic environment and you're effectively looking at the screen to get some sort of confirmation of an action, all of these interface and user experience triggers and keys are going to be really important because how does a system trigger or indicate to a human that their turn or their time has has come for them to do something if there's going to be this exchange. And so to me, having the context and having the context visible on the interface I think is going to be one of the most important things. And and having the context in a way that is immediately transferred to the user so they can trust the context, they can act upon it, and they're not they're not causing delays or interruptions because otherwise you know the whole thing's just gonna break very quickly.
Affan: Well one of the things which I do when I'm working with agents is they provide me with a certain confidence score. And you know, pre-program them to accept a particular threshold. So the confidence score will come through, it will do something, it will offer a recommendation or something like that. But then next to that recommendation will be a percentage confidence score. So I've already pre programmed it and said Anything that's above seventy percent confidence, you crack on. Anything between fifty and seventy percent confidence, you ask me for permission to move forward. And anything below fifty percent, we don't proceed with that. And so does that does that help?
Marc: Absolutely. I mean you're literally put putting in ground rules, you know, guardrails into your process of engagement with that particular agent. If those thresholds aren't exceeded, there are no mistakes and you know the the the the the quality of that exchange is is relatively a hundred percent. You haven't experienced you know, it it's stepping over the line and and something happening.
Wout Helsmoortel: Yeah, and I really like it, Affan, because that's how you it you want to increase confidence. So it's really good because we know LLMs are overconfident. They always give an answer, which is a risk. but we can increase that confidence by feeding it the right context, by revising what it does, by getting a human in the loop. so that tracking that confidence score is super important, because it will then be become more useful.
Marc: Can I just something just come to mind, Wout So when you've demonstrated to me some of the the Figma user experience sessions that you've had with you know some of your clients and you you you're walking them through with the post-it notes and the various different things, I think that's going to be an interesting way of actually identifying what are the key things. You know, if you're participating or you've got a group doing participating in a user experience session, of looking at the way ways of which they need that confirmation. Is it something in the same way that Affan describes, which is a a threshold or a rule, or maybe they want some sort of other indicator. Maybe it's symbolic on the screen, maybe it's a sound or a noise. There's accessibility issues are gonna be brought into this as well. This is not one for now I suppose, but maybe in in a future podcast you could take us through one of those user experience Figma sessions so we can see how do you actually get out of a of a group of people what they need as confirmation in a experience process.
Wout Helsmoortel: Yeah, I would love to. And it's super crucial because I I recently booked a table, what was it, five hours before I came in the restaurant, nobody saw it because the system didn't let them know. That's a very basic system, a very basic thing. Agents will do things all the time, they will take over. so that interface layer is gonna be very different for many jobs. And like you say, it's it's super crucial that people are in control of how they experience their job today and how they want it to look like and how they feel comfortable engaging with agents.
Marc: There's one elephant in the room, and I think it's one of the things we haven't actually spoken about. And it comes down to customer service. How the heck are agents going to come across the concept? So you just talk about a bad customer experience of walking into a restaurant and they don't even know you're coming. You know, you could have traveled ten, fifteen miles, you know, all sorts of things. And you're there with the expectation that the booking was made, the contract was confirmed. You get there, whole customer experience breaks down because simple applications.
Affan: Yeah. Well so w you know, having talked about the experience lens from the orbit method, Mark do you want to talk about the architecture lens and how that relates?
Marc: Yeah, why don't I just bring up a couple of diagrams 'cause as you know me, once an architect, always an architect, you can't help having something there to to
Affan: Okay.
Marc: actually show. To be fair to architects, it's been quite an interesting couple of years because I know from talking to a few, they've almost felt left out in this massive change that we've undergone. But at the same time, those that probably understood that really early on that no organization is going to be able to build any form of agentic solutions without understanding the architectural view, all of the aspects of what that integration and that interface is. At the moment, predominantly communication with the AI is through prompting. Prompting is based on obviously, you know, language and language, you know, at the best of times isn't perfect. Therefore, you can have some ambiguity entering into the prompt or errors entering into it. So there's an awful lot of work still needs to be done to make sure that the context is right. And then finally, trust. If we are going to have this future of working with AI, then there has to be the means and the understanding conveyed through the interface and the experience of what that trust means. combined. I don't think that's going to go away, but here when you see some of the examples of orchestration reasoning and guardrails, they are quite challenging things to do. And to me, the last tier, which is the data tier, because so much of what we do now is drifting back into the cloud, or into data centers anyway, we don't have so much of the experience of what the infrastructure is, because it's just almost, in a sense, moved back into that back office space. So an awful lot of what we do and how we interact is always going to be through some sort of interface device, whether it's a mobile phone, whether it's a display in a vehicle, a display wherever you are, you're not. basically working with big screens and computers like you used to 20, 30 years ago. This whole idea of heavy infrastructure is just disappearing. Everything is gonna take on a much more lighter aspect. Watch, device, tablet, you name it. There's all sorts of ways that we can actually do that work. subsequently, that in sense is how I think things will unfold.
Wout Helsmoortel: Great, great, thanks. Yeah.
Affan: And I think everything you've spoken about, you know, it's it's very familiar to our listeners who will be enterprise architects and change leaders within organizations. And I just want to focus on the bottom right hand corner of this slide because the the entire reason an organization will undertake any s any sort of change will be because there's value to be obtained from the the the outcome of the change. That value translates into monetary value at some point down the line. So can you just spend a couple of minutes talking about that bottom corner which says the business payoff gives forty to fifty percent efficiency gains and there's four hundred and fifty billion dollars, yes I said billion dollars in economic value to be had. What's that all about?
Marc: that number seems quite small when you think about some of the numbers that are talked about with regards to the big frontier models. Maybe that's just the UK's economic value. We keep it much smaller. But yeah, mean, if you think about, I mean, just when you were talking before about how you're working with the agents that you work with, giving them rules to work with, I've been developing agents for a couple of years now and... Whilst in the early days it was a disaster, but now there isn't a day go by without me expecting something. Even this graphic was generated by AI. I give it what I want to create. This would have taken me an hour or two if I had to put this together in PowerPoint, but I could generate it in five minutes and get on with something else. That to me is a massive efficiency gain. I have to check the information that's on there. There's no mistakes, no spelling. I am still saving time. So me personally, I've already seen my own efficiency gain. And I think as organizations move from... the basic engagement with AI to those first steps of actually having agents in the process, then that's where we'll start to see those effective efficiency gains as long as the reliability and all the other things are actually done correctly.
Wout Helsmoortel: That's super interesting. And it's it's really great visual Marc to guide us through that architecture lens. Now, Affan do you mind sharing a perspective on the operations lens? I know you're you're quite deep in operations, you've you've got quite some different experiences. Could you tell tell us what, according to you, are the main pain points in operations and what the impact of AI will be on that lens?
Affan: Yeah, absolutely. I think you know, we we touched upon this very early on and it's all to do with the feasibility of an initiative. Is it feasible? Is it achievable? is it practical? And so on. Do you have enough resources? If not, can you obtain enough resources and so well because all of this is operational. At the end of the day, it's all good and well, and I'm sure we've all experienced this particular pain point where someone higher up in the organisation has a great idea. And everyone else is expected to follow suit. But that individual or group of individuals have not consulted everybody else in the organization to understand the impact it will have on them, you know, what the the outcomes and the outputs will be, h how that translates into the initiative itself, the change initiative itself, and so on. So from an operational perspective, the first thing to look at for me would be Is this achievable? Is it feasible? Is it practical? And you know, getting that feedback from those people who will be responsible for the enactment of whatever that change is. So let's say, for example, as a former military commander, and again I go back to being you know, royal signals, we would be given communications kit, which was tested in a lab somewhere and said, right now go and do some operational field testing with it. off you go. There's no real understanding of you know what's behind it, any real upskilling or education and training to do with it. So you know, go and test its robustness, go and test its resilience, go and test its usability in the field. And there's a thousand KPIs related to it, but you've not had any impact or any input rather into the creation of those KPIs. They've been created by somebody sitting at a desk in Whitehall who's responsible for the procurement of this kit. And so it all seems very abstract and very dislocated. how have these requirements been generated? Have they been generated from somebody who has, you know, operational experience? And this is where I think you know the orbit method is really quite cool, having used lots of different frameworks. I really like the orbit method because it these three pillars are very practical pillars, aren't they? Architecture, experience and operations. And then over those these three pillars, which are verticals, you can apply th horizontals, people, process, technology, data. and you know, it's transversal. So this greater understanding. And and you know, you you're you're you're the founder of the orbit method. What what is it that drew you? I I'm you know, I'm very, very keen to understand. What drew you to creating these particular verticals?
Wout Helsmoortel: Yeah, it's a it's a good question. And and I founded it together with with Mark as well. And and based on your insights as well, our fun. the verticals, well, they're derivatives from people process technology, but more applicable. if you don't mind, I could actually bring up one of the canvas templates that we use to in the map phase. So as you're aware, the map phase is getting understanding. So, orbit method is a collection of 50 plus tools. Each of them has their canvases. And actually, the current state canvas is the collection of all the map tools. So you first do a mapping on the three lenses, architecture operations experience. And at the end of the map phase, you get to your current state canvas. The current state canvas is an overview of where your organization is today. And I'm bringing it up because it's a good example of how everything comes together. So you're seeing here that in your architecture lens, you have your key systems, what is running today, your capabilities of the organization, and your technical debt. for many organizations, I I speak from experience, they don't know what their capabilities are today. a lot of issues start there because if you don't know what your capabilities are, what do you serve? Who do you serve? What needs improvement from an experience lens on the right? key skills, what are the skills of the people? what are their pain points and the trust levels? We discussed it actually in this episode. So you were able to map that on one on one canvas, and then you have your operations, your key processes, what are the processes today, roles and decisions, and governance gaps or governance overall. and if if you have an understanding. Of those nine blocks, you have quite a good understanding of your organization today. And that's why the current state canvas, that's how it starts. And then the second part of that canvas is actually your cross-dimensional insight. So we talked about how the biggest friction is that the connection between these lenses is not explained enough. So that's why we are focusing on the gaps. between the lenses. We're focusing on the misalignments, the dependencies, and also transformation drivers. Yes, but it's an end state. So this is an end state of the full map phase. Actually, you can do other exercises that lead to that information. So this is a bit of a collection of all the information, but you should start from your individual lower level tools. They're all on website. When you've done those individual exercises, it'll bring you to an end state of a of the mapping where you will collect all that information together in this integration exercise. Affan may I ask you from an operations lens, what do you think about three th these three parameters here?
Affan: Absolutely spot on. And right at the top, I I see it's no coincidence that key processes are right at the top. So as I said, most organisations will have operating models in place. However, they'll be hard pushed to be able to lay down on paper what those operating models are. The the starting point I'd imagine would be to define the key processes. What what is it that you do? What's the outcome? What are the outputs that are required to achieve the outcome? who is involved? What do you need? What resources do you currently have? Do you need more resources and so on and so forth? And by defining those processes, and especially, you know, a picture paints a thousand words, if it's there in front of you on paper, you can have a look at the the visual flow of the process and That's then how to start achieving the efficiencies because you realise, well, hold on a minute, there may be a better way of doing this process, or this process is duplicated somewhere else in the organization, and that duplication or triplication or whatever it might be maybe unnecessary, and so on and so forth. So I really like, you know, the the fact that the key processes at the top, and I know it's not in priority order, but it helps having that first, having that understanding of these are the key processes in the organization. And then just underneath that are the roles and decisions. So who does what? Really important to know. How does that fit in with those key processes? Again, really, really critical. If you don't know that and you can't define that, then there's a big problem there.
Wout Helsmoortel: I know I know from your experience, I find you've done role mapping. could you tell the listener a bit what the main issues there are? Because a lot of organizations don't know what the roles are in their organization today.
Affan: so role mapping essentially is the ability to map the roles or the landscape of the different roles within a given organization. So let's take let's take an organization, a large enterprise, for example, and if I was to go to the CIO or the CTO or the COO, for example, and ask, How many cybersecurity roles do you have within this organization? Most of the time they'd be able to give me a ballpark figure, but they would not be able to give me an accurate mapping of the cybersecurity landscape within their enterprise. Not only related to humans, but also related to the the tools and technologies that they're using. So why can they not do that? The greatest reason why these leaders are unable to map their landscapes effectively is because They don't use the same language, lexicon, taxonomy to describe roles in a standardized manner throughout the organization. And what we tend to find is that when we start mapping job descriptions to a standardized framework. So let's say, for example, for cybersecurity, you know, the global number one industry framework is NICE from NIST. If we take 50 job descriptions that are cybersecurity oriented from an enterprise, and we map those to NICE and NIST, what we'll tend to find is duplicates. Because again, it's it's a lack of communication, it's a lack of understanding of what different departments are doing and who's doing what within different departments. But the mapping of those Skills, competencies to a standardized framework and therefore language allows us to be able to look at things in a harmonized manner. And this is really important then because it goes back to those key processes, who is doing what. it then you know cascades down into roles and decisions. You are able to effectively map the roles within your organization. You have a very a much clearer understanding of who is doing what because you're using a a a standardized taxonomy. You know, everybody in the the organization is able to use the same language and then therefore you're able to allocate decisions more effectively.
Wout Helsmoortel: That's that's great explanation. And I actually like that it's in the middle part of the nine grid because roles and decisions, we discussed it before. If you're involving agents, you wanna know what the current roles are, how decisions are being made before you actually r are going to replace parts of these.
Affan: Absolutely. And I think that's a great segway into our next episode is when we start to talk about the division of labour between humans and AI. And what I will say is that if you want to know more and we've certainly caught your interest, please do come back to us.
Wout Helsmoortel: Definitely. And and actually we have another model here about the target operating model that we want to show you. We want to go through that and then explain how you're actually going to go from the map phase to that design phase where you're going to design that future state where agents and humans work together. So I'm really looking forward to going through that canvas with with you and explaining it to the listener.
Affan: Chaps, it's been a
Wout Helsmoortel: Thank you, Tang.
Affan: pleasure and see you next time.
Wout Helsmoortel: See you next time.
Wout Helsmoortel: Yeah, it's a it's it's a broad question, but I think in in transformation in general, what we're seeing is that many transformations are tackled from from different lenses. So some look at an architectural lens, very technological. operations is is a good one. and of course user experience. But what what I notice is that they are not being combined into one. you cannot look at a transformation separating those three lenses. and I'm not really seeing today a lot of transformations that are combining those three.
Affan: That's really interesting. So why why do transformations break at the joints then?
Wout Helsmoortel: Yeah, it's good. the joints between operations experiences is if you're transforming operations, how people work together, but you don't know how they are lived, how people are experiencing it today, you're designing an operating model system without user feedback, without knowing what the actual outcome will be or how that will be lived. Connection between operations and architecture is if you're creating this future operating model, but you don't know really how you how you want to build it, how you need to get there architecturally. You're building something that's not executable, you don't have the right systems, you don't have the things in place to to to get there. And and then the other seam is between experience and architecture. Architecture has to keep in mind that the systems it delivers are there for people, not the other way around. and that's a classic user experience technology architecture misfit. It's easier said than done. so th there's a lot of of things to dive deeper into, but I think we really have to get those lenses closer together. But I don't know, Marc how how you look at that, do you agree and and what where are the main issues?
Marc: Yeah, Wout it's always interesting to reflect back on transformation programs. I've seen good, bad, and ugly. And you generally probably remember more the ugly ones than you do the actual good ones. And if I think back to traditionally some of the ones that have actually really been quite successful, it's because they've engaged their user community. And it hasn't had that focus on the technology. It's had the focus on changing people and process predominantly. And I think one of of the things, certainly on one program I remember, which was probably about 400 people going through a transformation to change from one software system to another. And that was a phased program. It was the amount of communication sessions that were organized as well as putting in people champions. So the individuals who are going through the change, weren't left to be isolated. And equally, a lot of time and effort was spent on producing sufficiently appropriate content to help the change. And from that, mean, not too technical, not full of jargon, and something that people can sit down and just sit down and read without having to pick up a dictionary or constantly ask their colleagues, word mean and it's you know that in its emphasis skill of understanding how to actually translate something to be understandable relatively quickly but I think when you look at the size and scale of the transformation that we're going through now with working in AI Everybody is going to have some impact on it. know, traditional transformation programs, those people in the transformation team were at the advantage. They knew what was coming. They were part of that change process. Now, even the people trying to undertake the transformation don't necessarily have as much of an understanding. So if they're nervous, if they're not coming across as understanding and they're trying to communicate to a user group that's also uncertain and potentially, you know, very cautious about the change, you're going to have two very nervous parties trying to communicate with each other and that doesn't really bode well for me.
Affan: So you know, looking back to the the previous episode where we spoke about what is a not model and what a not model isn't, and the distinction between a not model and a business model. I've often found, and I'm I'm sure it's the same with you guys, is that when I've walked into an organization that's about to undergo a massive change initiative, is if you were to ask them what their operating model is, they could describe it in source, but it would be difficult for them to, you know Annotate it on paper. Do you guys have you had similar experiences?
Marc: I think it just depends where various different things sit. I mean, the business model is often seen as more of the strategic tool. So it's going to be with those people who are shaping strategy. So that could sit with the chief operating officer of the finance, more of the senior people that are there. Sometimes I suppose part of the problem is the secrecy of the business model because obviously they may have some commercial sensitivity to it. The operating model is in a sense the as is today. It's effectively how things are operating in this current state. I think we've mentioned before that years ago, it was often the case that the people who looked after the current operating model were generally in the quality management and HR set out as an organization chart and particularly policy documents for each department. And equally, when you talk about the operating model it often again sits with the more senior you know individuals who are going to be involved in the strategy or transformation and this is where an organization that has a lot of transparency should be actually you know sharing and getting better access to both the strategic plans in the business model the current operating model and the the target and you know if you really want some sort of classic examples of of where we can look to things to improve. A lot of the changes that took place in the 1970s and 80s with the Japanese manufacturing plants were just in time, various different other programs and they bought, I think it's the Andon cord or the Andon chain is a classic. that if an individual was working in a production line and they saw something, weren't happy with, they could pull on this cord and stop the process. And then they could have a review and they could see what was failing and all sorts of things. So a very direct way of interacting with the current operating model to almost stop it to a point so you can reflect upon what's wrong, change it, and in certain circumstances, maybe have a new target operator because it might be quite considerable thing. But.
Affan: And organisation would tolerate a a pause in production then, would they?
Marc: Yeah, and this is one of the things that at the time was quite revolutionary because to give someone the power to stop a production line when you're talking of tens, hundreds, if not millions of dollars are at stake for every minute or hour that a production line is halted, that was quite some undertaking for them to stop the current operating model. So, you know, that itself is an interesting way of looking at, the organization or is the organization willing to hand over more of the insight to the people who work in the company or is it going to be left to a very select group of individuals to actually build that.
Affan: but this falls into the governance framework, doesn't it? In as to permissions, decision rights, delegation of authority to what level and so on.
Marc: And again, you could argue that too many organizations have gone down using way too much governance. And again, when you look at the use cases from an agentic perspective, Is that going to work in that agentic hybrid environment? Are we going to be able to have, in a sense, too much dominance of governance because agentic systems may be able to apply that, which means there's no room for creativity and there's no room for flexibility because everything is so rigid, policy driven.
Affan: What about Wout in your experience, what about the relationship between effective communication and suffering pain points or lack of effective communication and suffering pain points in a transformation initiative?
Wout Helsmoortel: Yeah, it's it's a very definitely a pain point. So you first need to map out all the stakeholders, try to understand who's part of the transformation, to then tell them what's going to happen. also in traditional transformation, you often see that when you're not including your end users and they all of a sudden end up with a new process. With a new technology, there's hesitance to use it because they were not involved. So you always have to involve those end users. and definitely with a gentic transformation, people are a bit scared. so that's also why you should measure trust as a transformation evolves to understand how much trust is there, how can we increase trust? How can we let them understand this is actually. letting their job evolve. It's not taking away their job. so it's a very big issue and it's not addressed enough.
Affan: No. No, and you know, communication to me, as a being a former Royal Signals officer, it's communication is absolutely key. It's communication, the reasons for the change, communicating updates during the change initiative, and it's communicating at every single level of the organization in an appropriate manner using the eff most effective channels. And again, you know, it it could be, you know, having human champions th that communication to others in a language that they understand and so on and so forth. But it's absolutely key.
Wout Helsmoortel: What I'll propose to do is maybe we could have a look at the three lenses individually.
Affan: yes, please.
Wout Helsmoortel: so you know listeners get a bit more familiar on the on the lenses. funnily enough, we each represent one lens. it really fits with our background. To to look at experience, obviously from the previous episode we talked about the restaurant example, how you experience the value proposition, how you experience the service being delivered. But also for the person delivering in the restaurant, a lot is gonna change. So we were talking about agentic transformation. And I needed again a little bit of an example. so today what's happening in transformation that's technology driven, It's software as a service, so SAAS has been very big. A lot of old school processes have been transformed through software. So it's often like a tool, you work in it, a human does something. And that's how traditional SAAS used to work, Dropbox, all these all these tools that that we know, What we're seeing today is that the agentic model of that is that agents need briefing, they need they need context, then they connect with some tools and they act themselves. They act for you. So in our restaurant model, you're looking at certain jobs that are being done by an agent. So a table could be booked, a no-show could be refilled. So for the human experience, it's quite interesting because certain jobs are being automated completely. Before software was more making it easier and you still had to act. In this transformation, we're seeing that agents can actually do part of the job completely. For you. And to your prior question of trust, it's often it's very scary. Like, what will the agent do? What will it not do? But then it's very important that you understand how is my job made up, which kind of experiences, which kind of jobs, and which ones will we automate, and which ones do I want to keep? And I think this is giving back the power to the end user that they can try to understand: we're going to automate. Maybe things you didn't like and it gives you more time to do something else. now, of course, zooming out to experience the job experience will completely change. I hope for the better. That may be naive, but that should be the outcome. We should transform for humans and not to automate them away. Marc, any reflections on on the experience lens from your side?
Marc: y you know my background and you know w the areas that I specialise in and and one point that you made is obviously context 'cause that's a a real interest of mine. a huge subject so broad. I mean what does actually context mean? It it means effectively everything. You can't have everything embroiled in one. So to me, context is important for the user experience of getting the right context to the right person at the right time so that They have the right experience because if not, then the person's gonna be sitting there confused, unsure, has something worked, has it not worked, what do I do now? Do I go forward? Do I go backward? When you're working on your own and you're generally just working in the normal process, you've got some understanding of of how things unfold. If when you switch to an agentic environment and you're effectively looking at the screen to get some sort of confirmation of an action, all of these interface and user experience triggers and keys are going to be really important because how does a system trigger or indicate to a human that their turn or their time has has come for them to do something if there's going to be this exchange. And so to me, having the context and having the context visible on the interface I think is going to be one of the most important things. And and having the context in a way that is immediately transferred to the user so they can trust the context, they can act upon it, and they're not they're not causing delays or interruptions because otherwise you know the whole thing's just gonna break very quickly.
Affan: Well one of the things which I do when I'm working with agents is they provide me with a certain confidence score. And you know, pre-program them to accept a particular threshold. So the confidence score will come through, it will do something, it will offer a recommendation or something like that. But then next to that recommendation will be a percentage confidence score. So I've already pre programmed it and said Anything that's above seventy percent confidence, you crack on. Anything between fifty and seventy percent confidence, you ask me for permission to move forward. And anything below fifty percent, we don't proceed with that. And so does that does that help?
Marc: Absolutely. I mean you're literally put putting in ground rules, you know, guardrails into your process of engagement with that particular agent. If those thresholds aren't exceeded, there are no mistakes and you know the the the the the quality of that exchange is is relatively a hundred percent. You haven't experienced you know, it it's stepping over the line and and something happening.
Wout Helsmoortel: Yeah, and I really like it, Affan, because that's how you it you want to increase confidence. So it's really good because we know LLMs are overconfident. They always give an answer, which is a risk. but we can increase that confidence by feeding it the right context, by revising what it does, by getting a human in the loop. so that tracking that confidence score is super important, because it will then be become more useful.
Marc: Can I just something just come to mind, Wout So when you've demonstrated to me some of the the Figma user experience sessions that you've had with you know some of your clients and you you you're walking them through with the post-it notes and the various different things, I think that's going to be an interesting way of actually identifying what are the key things. You know, if you're participating or you've got a group doing participating in a user experience session, of looking at the way ways of which they need that confirmation. Is it something in the same way that Affan describes, which is a a threshold or a rule, or maybe they want some sort of other indicator. Maybe it's symbolic on the screen, maybe it's a sound or a noise. There's accessibility issues are gonna be brought into this as well. This is not one for now I suppose, but maybe in in a future podcast you could take us through one of those user experience Figma sessions so we can see how do you actually get out of a of a group of people what they need as confirmation in a experience process.
Wout Helsmoortel: Yeah, I would love to. And it's super crucial because I I recently booked a table, what was it, five hours before I came in the restaurant, nobody saw it because the system didn't let them know. That's a very basic system, a very basic thing. Agents will do things all the time, they will take over. so that interface layer is gonna be very different for many jobs. And like you say, it's it's super crucial that people are in control of how they experience their job today and how they want it to look like and how they feel comfortable engaging with agents.
Marc: There's one elephant in the room, and I think it's one of the things we haven't actually spoken about. And it comes down to customer service. How the heck are agents going to come across the concept? So you just talk about a bad customer experience of walking into a restaurant and they don't even know you're coming. You know, you could have traveled ten, fifteen miles, you know, all sorts of things. And you're there with the expectation that the booking was made, the contract was confirmed. You get there, whole customer experience breaks down because simple applications.
Affan: Yeah. Well so w you know, having talked about the experience lens from the orbit method, Mark do you want to talk about the architecture lens and how that relates?
Marc: Yeah, why don't I just bring up a couple of diagrams 'cause as you know me, once an architect, always an architect, you can't help having something there to to
Affan: Okay.
Marc: actually show. To be fair to architects, it's been quite an interesting couple of years because I know from talking to a few, they've almost felt left out in this massive change that we've undergone. But at the same time, those that probably understood that really early on that no organization is going to be able to build any form of agentic solutions without understanding the architectural view, all of the aspects of what that integration and that interface is. At the moment, predominantly communication with the AI is through prompting. Prompting is based on obviously, you know, language and language, you know, at the best of times isn't perfect. Therefore, you can have some ambiguity entering into the prompt or errors entering into it. So there's an awful lot of work still needs to be done to make sure that the context is right. And then finally, trust. If we are going to have this future of working with AI, then there has to be the means and the understanding conveyed through the interface and the experience of what that trust means. combined. I don't think that's going to go away, but here when you see some of the examples of orchestration reasoning and guardrails, they are quite challenging things to do. And to me, the last tier, which is the data tier, because so much of what we do now is drifting back into the cloud, or into data centers anyway, we don't have so much of the experience of what the infrastructure is, because it's just almost, in a sense, moved back into that back office space. So an awful lot of what we do and how we interact is always going to be through some sort of interface device, whether it's a mobile phone, whether it's a display in a vehicle, a display wherever you are, you're not. basically working with big screens and computers like you used to 20, 30 years ago. This whole idea of heavy infrastructure is just disappearing. Everything is gonna take on a much more lighter aspect. Watch, device, tablet, you name it. There's all sorts of ways that we can actually do that work. subsequently, that in sense is how I think things will unfold.
Wout Helsmoortel: Great, great, thanks. Yeah.
Affan: And I think everything you've spoken about, you know, it's it's very familiar to our listeners who will be enterprise architects and change leaders within organizations. And I just want to focus on the bottom right hand corner of this slide because the the entire reason an organization will undertake any s any sort of change will be because there's value to be obtained from the the the outcome of the change. That value translates into monetary value at some point down the line. So can you just spend a couple of minutes talking about that bottom corner which says the business payoff gives forty to fifty percent efficiency gains and there's four hundred and fifty billion dollars, yes I said billion dollars in economic value to be had. What's that all about?
Marc: that number seems quite small when you think about some of the numbers that are talked about with regards to the big frontier models. Maybe that's just the UK's economic value. We keep it much smaller. But yeah, mean, if you think about, I mean, just when you were talking before about how you're working with the agents that you work with, giving them rules to work with, I've been developing agents for a couple of years now and... Whilst in the early days it was a disaster, but now there isn't a day go by without me expecting something. Even this graphic was generated by AI. I give it what I want to create. This would have taken me an hour or two if I had to put this together in PowerPoint, but I could generate it in five minutes and get on with something else. That to me is a massive efficiency gain. I have to check the information that's on there. There's no mistakes, no spelling. I am still saving time. So me personally, I've already seen my own efficiency gain. And I think as organizations move from... the basic engagement with AI to those first steps of actually having agents in the process, then that's where we'll start to see those effective efficiency gains as long as the reliability and all the other things are actually done correctly.
Wout Helsmoortel: That's super interesting. And it's it's really great visual Marc to guide us through that architecture lens. Now, Affan do you mind sharing a perspective on the operations lens? I know you're you're quite deep in operations, you've you've got quite some different experiences. Could you tell tell us what, according to you, are the main pain points in operations and what the impact of AI will be on that lens?
Affan: Yeah, absolutely. I think you know, we we touched upon this very early on and it's all to do with the feasibility of an initiative. Is it feasible? Is it achievable? is it practical? And so on. Do you have enough resources? If not, can you obtain enough resources and so well because all of this is operational. At the end of the day, it's all good and well, and I'm sure we've all experienced this particular pain point where someone higher up in the organisation has a great idea. And everyone else is expected to follow suit. But that individual or group of individuals have not consulted everybody else in the organization to understand the impact it will have on them, you know, what the the outcomes and the outputs will be, h how that translates into the initiative itself, the change initiative itself, and so on. So from an operational perspective, the first thing to look at for me would be Is this achievable? Is it feasible? Is it practical? And you know, getting that feedback from those people who will be responsible for the enactment of whatever that change is. So let's say, for example, as a former military commander, and again I go back to being you know, royal signals, we would be given communications kit, which was tested in a lab somewhere and said, right now go and do some operational field testing with it. off you go. There's no real understanding of you know what's behind it, any real upskilling or education and training to do with it. So you know, go and test its robustness, go and test its resilience, go and test its usability in the field. And there's a thousand KPIs related to it, but you've not had any impact or any input rather into the creation of those KPIs. They've been created by somebody sitting at a desk in Whitehall who's responsible for the procurement of this kit. And so it all seems very abstract and very dislocated. how have these requirements been generated? Have they been generated from somebody who has, you know, operational experience? And this is where I think you know the orbit method is really quite cool, having used lots of different frameworks. I really like the orbit method because it these three pillars are very practical pillars, aren't they? Architecture, experience and operations. And then over those these three pillars, which are verticals, you can apply th horizontals, people, process, technology, data. and you know, it's transversal. So this greater understanding. And and you know, you you're you're you're the founder of the orbit method. What what is it that drew you? I I'm you know, I'm very, very keen to understand. What drew you to creating these particular verticals?
Wout Helsmoortel: Yeah, it's a it's a good question. And and I founded it together with with Mark as well. And and based on your insights as well, our fun. the verticals, well, they're derivatives from people process technology, but more applicable. if you don't mind, I could actually bring up one of the canvas templates that we use to in the map phase. So as you're aware, the map phase is getting understanding. So, orbit method is a collection of 50 plus tools. Each of them has their canvases. And actually, the current state canvas is the collection of all the map tools. So you first do a mapping on the three lenses, architecture operations experience. And at the end of the map phase, you get to your current state canvas. The current state canvas is an overview of where your organization is today. And I'm bringing it up because it's a good example of how everything comes together. So you're seeing here that in your architecture lens, you have your key systems, what is running today, your capabilities of the organization, and your technical debt. for many organizations, I I speak from experience, they don't know what their capabilities are today. a lot of issues start there because if you don't know what your capabilities are, what do you serve? Who do you serve? What needs improvement from an experience lens on the right? key skills, what are the skills of the people? what are their pain points and the trust levels? We discussed it actually in this episode. So you were able to map that on one on one canvas, and then you have your operations, your key processes, what are the processes today, roles and decisions, and governance gaps or governance overall. and if if you have an understanding. Of those nine blocks, you have quite a good understanding of your organization today. And that's why the current state canvas, that's how it starts. And then the second part of that canvas is actually your cross-dimensional insight. So we talked about how the biggest friction is that the connection between these lenses is not explained enough. So that's why we are focusing on the gaps. between the lenses. We're focusing on the misalignments, the dependencies, and also transformation drivers. Yes, but it's an end state. So this is an end state of the full map phase. Actually, you can do other exercises that lead to that information. So this is a bit of a collection of all the information, but you should start from your individual lower level tools. They're all on website. When you've done those individual exercises, it'll bring you to an end state of a of the mapping where you will collect all that information together in this integration exercise. Affan may I ask you from an operations lens, what do you think about three th these three parameters here?
Affan: Absolutely spot on. And right at the top, I I see it's no coincidence that key processes are right at the top. So as I said, most organisations will have operating models in place. However, they'll be hard pushed to be able to lay down on paper what those operating models are. The the starting point I'd imagine would be to define the key processes. What what is it that you do? What's the outcome? What are the outputs that are required to achieve the outcome? who is involved? What do you need? What resources do you currently have? Do you need more resources and so on and so forth? And by defining those processes, and especially, you know, a picture paints a thousand words, if it's there in front of you on paper, you can have a look at the the visual flow of the process and That's then how to start achieving the efficiencies because you realise, well, hold on a minute, there may be a better way of doing this process, or this process is duplicated somewhere else in the organization, and that duplication or triplication or whatever it might be maybe unnecessary, and so on and so forth. So I really like, you know, the the fact that the key processes at the top, and I know it's not in priority order, but it helps having that first, having that understanding of these are the key processes in the organization. And then just underneath that are the roles and decisions. So who does what? Really important to know. How does that fit in with those key processes? Again, really, really critical. If you don't know that and you can't define that, then there's a big problem there.
Wout Helsmoortel: I know I know from your experience, I find you've done role mapping. could you tell the listener a bit what the main issues there are? Because a lot of organizations don't know what the roles are in their organization today.
Affan: so role mapping essentially is the ability to map the roles or the landscape of the different roles within a given organization. So let's take let's take an organization, a large enterprise, for example, and if I was to go to the CIO or the CTO or the COO, for example, and ask, How many cybersecurity roles do you have within this organization? Most of the time they'd be able to give me a ballpark figure, but they would not be able to give me an accurate mapping of the cybersecurity landscape within their enterprise. Not only related to humans, but also related to the the tools and technologies that they're using. So why can they not do that? The greatest reason why these leaders are unable to map their landscapes effectively is because They don't use the same language, lexicon, taxonomy to describe roles in a standardized manner throughout the organization. And what we tend to find is that when we start mapping job descriptions to a standardized framework. So let's say, for example, for cybersecurity, you know, the global number one industry framework is NICE from NIST. If we take 50 job descriptions that are cybersecurity oriented from an enterprise, and we map those to NICE and NIST, what we'll tend to find is duplicates. Because again, it's it's a lack of communication, it's a lack of understanding of what different departments are doing and who's doing what within different departments. But the mapping of those Skills, competencies to a standardized framework and therefore language allows us to be able to look at things in a harmonized manner. And this is really important then because it goes back to those key processes, who is doing what. it then you know cascades down into roles and decisions. You are able to effectively map the roles within your organization. You have a very a much clearer understanding of who is doing what because you're using a a a standardized taxonomy. You know, everybody in the the organization is able to use the same language and then therefore you're able to allocate decisions more effectively.
Wout Helsmoortel: That's that's great explanation. And I actually like that it's in the middle part of the nine grid because roles and decisions, we discussed it before. If you're involving agents, you wanna know what the current roles are, how decisions are being made before you actually r are going to replace parts of these.
Affan: Absolutely. And I think that's a great segway into our next episode is when we start to talk about the division of labour between humans and AI. And what I will say is that if you want to know more and we've certainly caught your interest, please do come back to us.
Wout Helsmoortel: Definitely. And and actually we have another model here about the target operating model that we want to show you. We want to go through that and then explain how you're actually going to go from the map phase to that design phase where you're going to design that future state where agents and humans work together. So I'm really looking forward to going through that canvas with with you and explaining it to the listener.
Affan: Chaps, it's been a
Wout Helsmoortel: Thank you, Tang.
Affan: pleasure and see you next time.
Wout Helsmoortel: See you next time.
