Tom: Hello and welcome to Flow by Design, a podcast series brought to you by Project 4 Learning Lab. In the previous episode, I was joined by Drew McPain, where we discussed the importance and benefits of empowering teams to be self-organized. This time I'm joined by Andy Barr. Andy has over 25 years of experience working at Rolls-Royce, starting in turbines as a designer and ultimately leading multiple teams across different engineering projects. Recently, Andy has served as an agile coach for many programs within the organization and now works in the PMO function as an agility business partner. And in this episode, we discuss the topic of knowledge flow and lessons learned from working knowledge and process flows to deliver highly complex systems.
Tom & Andy: Andy, welcome to the podcast. Hi Tom. How are you doing? Good, thank you. Great, this is a nice coincidence. I always like peeling back the curtains on things, but you just happened to be around. Just happened to be in Derby with no place to be. It's amazing. Keith and I were talking about knowledge and process flows and going, who could we have to talk about this? And then five minutes later, I'm getting a call from you saying, I'm in the area. So it's a really happy coincidence, really glad you're here. recently achieved 25 years in Rolls-Royce, which is always a bit of a surprise when such a long time has racked up on me. But most of that time within engineering teams, helping to either be part of a team that are designing a new part for a new product or helping to improve a part that might be in service. So a lot of time really with knowledge workers, understand how to improve the coordination and collaboration within that kind of context. So perfect for this, I think. And I think we've worked together in the past as well using different tools and different projects. And I reckon we can deep dive into some of the challenges I think we've faced in the world of knowledge flow. I guess in your experience, let's start off with a big question. What's one of the biggest, blockers to knowledge flow that you encounter and Maybe what's the ideal way of overcoming that? blocker I think if I reflect on where my connection with with Kanban and flow started was managing a team of design stress PDG modelers and and you know the work we did was really needed all of us working effectively together And it was very hard in that knowledge work context to be able to really understand who had what stuff on their plate. And so we had examples in those days of effectively paper question sets being dropped on somebody's desk in the team. overnight and the expected turnaround was a couple of days on those things and the first that I would know about that as a manager was when we got a phone call from the department that needed it back saying well why haven't you returned this in time and you know I had no awareness of it so that awareness and visibility of the work in the team there was literally stuff being dropped in the dead of night and was lacking for me I think a company like Rolls-Royce where there's a lot of manufacturing knowledge and expertise, we were doing a lot of work with Lean and it absolutely made sense to me and the principles behind it of avoidance of waste. But a lot of the tools that we were then being recommended to use in our office, in our knowledge work context, didn't really fit. And so we'd be doing a five S or sort of a stand up, but we weren't standing up next to anything. We weren't talking about And so it was really, as I started to learn more about Kanban and started to understand how we could take that step of visualizing the work of the team and how that can really help you to then get a better understanding of what the real picture is, where some individuals might have a view of the burdens. Thinking about the teaming strategy you might want to apply, whether it's a cross-functional team, whether it's a single discipline. all suddenly made sense for me and felt like a improvement opportunity for us to start to use more of those tools. visualization you've alluded to there is a real key piece and I found sometimes as obvious as it can be, it's sometimes a hard sell to people of going, just put what you're working on somewhere that's visible to all. Do you feel there's, when we ask people these things to visualize work, is there sometimes a resistance because of vulnerability or people not being used to showing their work? Because culturally, think sometimes that happens and people feel resistant to showcase the work, they feel they're doing it. I think there's obviously problems behind that when they do I think there's a couple of aspects for that. I think that there can be cultures that can penalise people being transparent and there is that clarity about the things that they are doing and perhaps a stakeholder that's not happy with the responsiveness picks up the phone or gets on the teams and starts to contact them. that's not quite the spirit of transparency that I think is intended in the sort of agile approaches. So I can really understand why people might have reticence to share that and give that transparency. I'll be honest, I'm guilty as well as sort of not necessarily fully, you know, breaking down the work that I'm doing on my team's Kanban. And I think if I explore that a bit more, There are times when you're in a team and actually it's really helpful to have that clarity about what the other folk are doing and also what they can be helping you with. If that's not the nature of the team and the work, then you get less back for taking that step of putting the information into a Kanban tool. So I think there can be some pretty valid reasons for why people might be reticent to put stuff there that gives that exposure and potentially doesn't bring them any benefit. So I think that the real key then is to try and make sure that that act of putting the thing there does pay back. They get more help. There is more support to remove things that slowing them that they don't get those kind of contacts that are trying to falsely expedite the thing that they care about and pull work through that shouldn't be prioritized. if you can sort of couple up, you know, the card in whatever tool it might be with things like, well, this is where you find the link to access the documents that you need to work on. Suddenly you find that things naturally align and people recognize the value they get from taking that step. And then all kinds of things can open up. We've had some really good success recently where one of our program teams was starting to create a flow board for some of the hardware in build and that's opened up more collaboration with some of the other departments that are responsible for either producing the delivering the parts to make those products or for assembling those products and so it's starting to bring them together in a really really pleasing way that's opening up more opportunities but it does have to work for the people that need to put the data in. Absolutely, any context in that to them to go this is why we're doing it, this is what's going to benefit you because if someone visualises the work, like you say, they can understand then maybe how utilised they are, that their work is leading up to bigger objectives connecting that strategy through to action. and also being able to overcome problems faster because once it's there it becomes easier to understand there's a problem and easier to escalate to the right people. actually hand in hand visualizing the work at the start and trying to bring people together at Cadence are almost two key things at that point to start off with if you're getting into any project or area and they don't have either of those things it's almost the first step to go let's align people and this is what we're to align them towards. Absolutely yeah I think people naturally want to see what is the outcome of their efforts and there are plenty of tools that can really give a good insight into how things connect up. I think the hard part is trying to keep it simple. There are often organisations that I work with where... where we have pretty complex sort of, it's a complicated system. There's a lot of different demands on that system, lots of different work products trying to flow through it. Lots of different teams that each play a role in those things. They're trying to prioritize across it all in an effective manner trying to then not overburden teams with a really complicated network of boards that they've got to update. It's really important that because it starts to degrade that sort of, that value equation for them. You mentioned prioritization there and in an organization where you have this incredibly complex product, how on earth do you prioritize? I think the first question that is very much at the forefront of everybody's mind is safety. So we respect and recognize that the products that we are involved with have real sort of... real world safety significant implications and so anything that comes in that's of a sort safety related nature would naturally be prioritised. After that, it can be really hard that there's a mixture of both long term sort of larger project activities that might be washing up in the same team that are also involved in some short turnaround sort of quick assessment work and very different in terms of the immediacy of the impact of not responding. But equally, you don't want to always put off the longer term things for the short wins, the quick wins. And so that is something that we've sort of, I think you have to very much be aware of the context of the work that you're doing. I think it can be helpful if you can sort of separate out some of those very different work types. have a, I don't know, a group of people that are... more aligned to the longer term work for a quarter, almost like a capacity allocation decision, because it really is a bit arbitrary sometimes to try and prioritise a short term versus a long term thing. So perhaps trying to prioritise them within their sort of neighbourhood of the longer term stuff as one priority system and then the short term stuff in a slightly separate system is something we're experimenting with at the moment and trying to have. steady sort of allocation of people into each of those categories of work to try and simplify it. But that might look very different in another team. There are other programs that I've worked on where it's all about the longer term stuff and so the priority then is a little bit easier in some respects if they're all aligned around a single product. It's then just trying to bring the right stakeholders together to thrash it out a little bit and try and give clarity to those teams. It must feel easy in that kind of environment to generate a big list of priorities because there are lots of important things going on. Yeah. Have you experienced that and I guess what would be the consequence to having just a crazy list of priorities in a project? Definitely experience that. love the fact that haven't really researched it beyond a quick Google search but the fact that the word priority was only singular when it first came around, I think is really significant one to reflect upon. think we kid ourselves that you can have multiple priorities and I can only peel one potato at a time. I think that needs to be the forefront of our minds and trying to keep as few things on that list as possible and really prioritize work on one thing and do it well. Where that's difficult, think where you have teams who have a variety of customers, that becomes very difficult very quickly, whether those are internal or external customers. And so trying to have a bit more clarity about who is the in-person that's empowered to take a balanced view across the different stakeholders and customers and make that priority call is really key. Certainly for some of the programs where a scrum type team or team of teams approach is practical and we've tried to really make it more clear who is the product owner to set those priorities to try and give that team clarity because I think the harm that we often don't sort of... take stock of is that without a clarity on priority, then different people will pick different things and it might add up to not a lot. So yeah, it can be a hard call to make, but not making those choices can lead to a worse outcome overall. You've elaborated on the importance of a product owner there and I totally agree with you. Having that person to almost go, this is where we're steering the ship is crucial. You've heard this, I've heard this before on what these methods are perceived to be doing, which is to make people deliver faster. But sometimes it's about getting people to deliver in the right direction first and then delivering fast. And it's trying to negotiate between the two to get to someone to go, it's actually this way. And if we don't do this now, if we don't have that person to go, we're heading in this direction and this is the best we have right now. If we approach... turbulence along the way if we approach a problem then we change our direction, requirements change for example. That can be a difficult thing to sell to people because people just want to deliver faster and leaders want to go we're just going to deliver as fast as possible So with that in mind, think predictability is a big factor. When we've got these existing systems, we're wanting to just deliver as as fast as possible, knowing we're in the right direction. How would you ensure that people are delivering the predictable things and... maybe thinking about how to find the first or the best improvement to make now with the team so that any future problems are not eradicated but reduced risk wise. Yeah, I think... think that the ideal scenario to make it as close a relationship as possible between a group of people and the out-counters would be that that team are all collaboratively working on a single sort of workflow. And then if that becomes their of information radiator, their source of truth, then you start to implement, well, firstly, know, WIP limitations so that they're not trying to multitask too much in context switch so that they can work on finishing these things. You do the good Kanban practices, you know, starting at the right hand end of the board, what have we finished and what are the things that are closest to being done that we can work together on getting done. helping to focus on delivery of stuff and not just starting new stuff. And then the use of blockers, trying to capture and characterize the reasons why things get stuck, looking at where you're getting within that process flow, perhaps a bit of a backlog forming would all be good indicators of where those short skills are or the steps in the process that are proving more difficult. All of that theory is really pretty simple and really hard to argue with. think where it can sometimes be challenging in the real world context that we often find is that those teams may be collaborating with a number of different work products and processes. And so you kind of almost have to try and take a step back then and look at that bigger system, I think, to really start to understand where there is tension between one work product and another work product. And it really comes down to about our choices on the capacity we allocate to different things and then trying to monitor it and use the blockers, et cetera, to help us put it improvements. I think, though, we should still strive towards perhaps that more sort of simple clarity of this group of people are all working on this specific work that. Which wouldn't mean to say that people are forever going to be working on that same thing. We have a range of different skilled people within teams that I work with that wouldn't want to only do the same kind of work forever. But I think if we take a more sort of quarterly approach to allocation to things, then I think that might be a nice balance between getting really good as part of a team, doing a certain type of work for a period of time, and then still getting that personal development and growth through changing that up every so often. I really like that. I'm an advocate for simplicity, even for complex projects and deliveries. can simplify or scale back to almost scale up. can... it's almost an easier win to bring people in to go if it's this way and you're focusing on working these things that direction and clarity it can be really helpful even as someone who's been the team member going this is what you're doing today and sort of removes the the ambiguity of that I want to go back to the context switching because I have a really relevant funny story that includes you I remember we were doing some training videos and I remember doing the editing for your training videos and there was one on context switching and mid video you elaborate the point so well because you said I'm doing this video on context switching and I got a work call and it changes your mind completely and it puts you in another mindset and another frame where you come back to the work and then you're like right well I've got to reset back on this and it's like it might feel like minutes at the time we are having to readjust but in the real world that can be continual and people will just have to reshift their minds from going from one thing to the next in there. So when you mentioned context switching that was the first story that came to mind and... It's a really powerful example, think, because it's real and people will experience that in projects for sure. And maybe some of that ties in with how people are utilized. You mentioned WIP limits in there as well. How would we recognize when someone is really utilized, maybe to 100%, and how do we get them out of that? think that I think in this scenario that I'm currently working with a number of teams that are involved in a number of different work products and flow lines and I don't know where to put the whip limits because a whip limit on one or more of those flow lines would not necessarily result in taking some of that utilization down on whichever of the key specialist teams happens to be the real bottleneck. So it feels more appropriate to put the WIP limit onto the team board where they receive the demands from each of those flow lines and then discharge them as a team. So I think in that scenario, that's the least bad option. But I very firmly, in my experience, that there's very little that we can get done in the kind of engineering work that we're often doing where it's really only one discipline that you need on the pitch. So my preference would still tend to be to bring in the mixture of skills you need to support a flow line and for them to be a team working that flow line as a team for a period of time to try and get. improvement on it because it can be so hard to really work out the real picture when you've got these fragments of things on flow lines, things on teams, lots of different work products going through there. It's a very complicated world and you can unpack that with you know good stuff in PowerVR and so on but I feel like it's still where there are good synergies and opportunities to group things together to have a... simplify prioritisation, simplify the teaming of cross-functional teams, then I think that's probably the direction to go. And I think that's what we're starting to explore now in that programme, which is good because it wasn't necessarily clear that that was, that the appetite was including sort of team changes. And I'm not talking about necessarily managerial or organisational changes, but simply deployment sort of teams. So it's quite exciting to have that on the table now. thinking about the context switching and that living example I had when recording that video. A few weeks later I was involved in an event and part of the preparation for that I was looking back at some of the heritage in Rolls-Royce in Bristol and obviously the Olympus engine in the Concorde was part of the products that were developed in that location over the years. And what really struck me looking back at some of the photos from what work was like at that point in time was obviously very paper-based. You had large project walls, lots of drawing boards. Some of the guys that were around when I started in Rolls Royce had experienced that environment and would talk about how the... the design supervisor or the chief design engineer could walk down the line, could see what people were doing. So there was a real visual aspect and immediacy of being able to see what different people in the team were doing, being able to coach, guide, question, trying to make sure that it integrate together in a way that I think we've lost over the years with the move to computers and everything being more within your own screen. on top of that, I think we've also made it much easier to contact people and whilst they're are many many benefits to that it also results in more context switching. And it just strikes me that the time of time scales that we manage to do things like developing Concord in, are not that different to the kind of time scales that we're still taking to develop new products. And whether, despite the advances in computers and so on and the capability, whether we've lost something in the focus on task, the avoidance of context switching, that perhaps is a bit of an unseen and unaccounted for deficit compared to the older ways of doing stuff, which isn't necessarily, so I want to go back to that. days but it's just an interesting reflection that actually overall time scales aren't that different. It really is. And yeah, reflect back to my time as an integrator and yeah, it's always about shifting minds from one thing to the next. I had to contact a lot of people and I was probably a disturbance, but it was a drive for me to deliver what I needed to do. bit guilty when I was going up to people at their desks or calling people, but I think it's all about balance as well and it's trying to accept that there's a level of context switching that is appropriate and applicable and not getting to the mindset where I need to be doing everything all the time now. And I think that always ties back into the clarity on what we need to do. not the focus from I need to make sure that everyone's loaded so that we're delivering and going I need to make sure that everyone's doing the right work to get to the outcomes that we need to achieve. And I think that gives clarity in the tasks. the definition of done are things can sometimes be so powerful because then you just go, right, I've done that, we don't need to have continual meetings or continual calls with people to argue about whether this is done or not. It's there, it's done. Yeah, I think that's a good point. And I think trying to just encourage and make it more acceptable that... it is okay to perhaps turn the notifications off on your email or Teams or whatever and just have some focus time. Because I certainly feel like I'm always attracted to and drawn by those pings, those things that come along and you drop it and then it will be, know, a few minutes even afterwards that your flow is gone. You've got to kind of get back into where you were. So I think, yeah, trying to find that balance is important. I think it ties as well into how teams coordinate with each other because, you in the projects that we've been involved in, we can have teams that are working incredibly well and effectively. But if that network of teams, that team of teams isn't working together effectively, it can still all fall apart. We can still end up shifting deadlines to the right. So I guess in your experience, what's been a good, effective way of bringing those teams together so that we can feel confident we're giving them the right work and they can interact with each other effectively. Yeah, so a couple of different scenarios where it's been a large program with, I don't know, 50 plus people involved, so probably looking at maybe five teams at the smaller end of that spectrum up to you know, probably 50, 80 teams in some of the larger ones, then having a cadence at which we do seek to clarify what's important in the next quarter, give the team some time to configure themselves, to be able to deliver that as effectively as possible and together on what they need to do as a team and what they need from other teams to achieve it and have a handshake on those things. That's all going to help to try and effectively deliver value in a changing sort of scenario where actually either the requirements aren't totally locked down and our knowledge and experience to be able to be really confident about the predictability of our plan is not there. And that's often the case when you're developing a new product. It's literally not been done before. So I think having those regular points to sort of course correct and think about things are really key. If it's more a scenario where the team are there to service a number of different flow lines that are perhaps more sort of typical for projects that are in service with a kind of a natural churn of new stuff, new smallish tasks coming in just to keep making sure that everything's safe and working effectively and available. Then I think trying to monitor how the flow lines have been performing in the previous period. So still a cadence, maybe a quarter is not a bad one to take stock on how that flow line is performing. What level of resources have we been investing in that flow line? And do we need to change that balance if we want to target, you know, a batch of production in future, et cetera? It can also be useful. having that, doing that across the whole system, having that prioritization across the whole system so that we collectively put the right resources onto those things that we've agreed are the right priorities and not just leaving it to the haphazard nature of each team trying to work out and do their best to guess. So I think the key things on both is cadence and having a good attempt at prioritization of the demands on the teams. And you've elaborated in there as well, and I think you put it beautifully, is how all these things tie in together. So all the things we've covered so far, you're thinking prioritization, you're thinking cadence, you know, these are all crucial elements to it. And in the world of process and Kanban. and cadence, governance is a big part of that. ensuring that when we do bring the teams together to talk about stuff, it's targeted and focused on the right things in there. So I guess what's your experience in implementing governance, making process policies explicit in a workflow or in a system or in a project? we're in the midst of that at the moment, actually. So it's a good, challenging question. I with any change, the engagement and buy-in of the teams involved is key. So I tend to be fairly inquisitive and assume that folk are doing things for a good reason. So try and understand whatever governance is in place and how the teams are interacting on that work. to be open to think about is our proposed solution actually going to represent an improvement? So once you've got both that leadership level buy-in but also a good amount of confidence from the discussions with teams that this should lead us to a better place. Noting that it might be that for some specific teams and flow lines perhaps it's not necessarily going to be a win straight away, that it's more about the systemic sort of improvement rather than... sort of optimizing a smaller part of Then I think trying to start something but maybe start small is always good. So we're going to be starting to roll out some of that governance on some of the flow lines. We've already got a couple of teams that are nicely adopting that new approach and just trying to stay close to those folk as they go through that journey is important learn from their experience as well. And actually, we've also had a subset of people within that team structure who we've taken through some of the training on the background and principles behind Flow and Kanban. So they've got, you know, there was a little bit of self-selection in terms of the people that wanted to learn more. them with a bit more knowledge and a bit more of that bigger picture of what we're to get to. And then they are back in their home teams able to start to implement more of these things sort of spread hopefully the successes and get more sort of a snowball effect going on. I think I don't know whether I've drawn too agile because I'm not very good at planning. And I hate to say that because for me Agile is not about not having a plan, we should have a plan, but I certainly find some of the people and change management outside of things can be very difficult to plan out at the start and needs a certain amount of adaption to what you find along the way. And so, yeah, sort of getting the allies together, giving them the knowledge to go out and do stuff, start to showcase some of the successes that you've got and building on that, but also being open to change along the it will happen. I find that super important as well because I think going back, you and I, when we met in a really large complex organization like Rolls-Royce and We were maybe enthusiasts of a topic at the time, but even that as a starting point to coach others, to guide people on the journey from the inside is super powerful. I was talking with Sally who... has reflected on transformation as a both as a leader and as a consultant and actually the difference between the two as a consultant coming in it can be difficult to manage that to tell people this is what you need to do. We found that trying to embed those practices with networks of people who become specialists can be it's super important because it becomes more sustainable to carry out those practices they go and see other people they go and talk to people in their day to day and it's bringing casting that net of people in to align them to the same way of working. And when we were working with a tool and we were advocates for introducing that tool, the community of practice was a key thing at the start and just getting together a network of people. And I think that's something that still exists and works today. And that's a tool in a system that adopts different ways of working, but it brings value. of people in to working on that tool and it's benefits to that. So I really liked what you said there about when we're trying to embed those specialists inside it's not necessarily their job but even as advocates it can be super powerful to at least get people going. and help to know what the tool is capable of. and just with a few minutes to say, have you seen this functionality? That could be useful for you is really important. I think one of the things I've learned recently though, because the program I'm involved with at the moment was a program that I previously worked in seven, eight years ago some stuff that we'd set up then in terms of Kanban. has endured but it's also not quite adapted as the organization and the nature of the team structures has changed you've also then got sort of almost at a board level changes being implemented that means that a system level that can be really hard to understand what's going on. And so my learning, think, is about, and I think I tend towards an approach of, give somebody a bit of opportunity to explore something and they'll find a good way of doing it. And I guess that's being tempered a little bit by recognising that actually when that team is part of a bigger system, perhaps we do need a bit more structure and data rules and sort of mandating and filling in certain fields to enable that bigger picture to be drawn together. So it's been very, very good learning to go back into an area after a period of kind of a lack of stewardship of it, a lack of coordination of it and seeing just how those natural changes, whilst perhaps being useful from an individual team level, have meant that a system level it doesn't quite stick together anymore. And it's a perfect example of going, you even someone who's new into an organization will go in and see this complex network of activities and boards and I think that ties back into the simplicity element it's essential in especially in workflows and being able to make a decision quickly based on what we can see at a glance either through the state of the board itself or through a simple set of metrics in there. So I started with a question about the big blocker. A big blocker for you. I'll tie you now into blockers in general because we want to be predictable in delivery and we want to make sure that we're reducing risk as much as possible. How do you manage, say, sequences or types of blockers? And what is, in your experience, a really good method of eradicating or reducing the chance of those blockers occurring in future? I think whilst it's not obvious, to can-ban visualization of works on boards, think people get pretty quickly and quite naturally. But I think it would then be easy to overlook another aspect of Kanban method and approach and flow that is about a regular cadence in which the teams still come together to improve and focus on improvement. And that is crucially important as well, not only when it's important when you've got a single team working on a single board, but when you've got multiple teams working on multiple boards. it's even more important. And so that kind of honest appraisal of how we're performing and what could we do to improve. is really important, but I think it can be very easy to overlook that in and amongst more normal inverted commas kind of governance meetings. So I think trying to, something I'm taking from doing work with Scrum where that's a more overt kind of part of the cycle is how valuable that part of it is. And then... tool where you can categorize different reasons for being blocked and get the good data to help drive where the errors from proven are is crucial. But interestingly blockers can be perceived as a very negative thing and I guess if your goal is getting the work through the flow line then I understand that. But if you then almost outlaw the use of blockers because, well, that's about the team needing to go and contact somebody. You're losing some really valuable insights about the things that stopped the work coming through the machine and the system. So I think we perhaps just need to do a bit of work on almost like the reputation of blockers that whilst the goal is to minimize and avoid them. you don't achieve that goal by just outlawing them, if that makes sense. We need to have a sensible collection of blockers to truly understand what does prevent any of the work products from coming through this machinery so that we can then seek to improve and drive those reasons So there's an interesting sort of tension there in some of the perceptions around blockers that we're working with at the moment. But think, yeah, think by and large people can see the value in trying to capture those reasons. I think in my experience and probably in your experience, leaders value that more because it gives them an understanding of what is stopping the flow of work. What is preventing delivery? Because by knowing that you can then be targeted in action. And so the point you made about, we don't know about law blockers. and it might seem like a taboo, but if we don't see them and we're not visualizing them, how can we do anything about it? Yeah. Yeah. And I think if one of your real issues is actually you need to speak to a different specialist team and you can't get hold of them, that is a piece of information that the system needs to reflect upon and try and improve. And so let's capture it. Let's make it transparent. And then you've got a chance of trying to do something about it. I'm gonna, I've been really interested in hearing your experience on this. And I think in your experience, you'll be not thrown into scenarios, but maybe as a last question, when you do enter a project and you're probably given the task to improve the knowledge flow to... you know, in part on others how to deliver more effectively and improve processes as well. What's the first thing that goes through your mind when you go into any project? What's the first thing that you go, this is me as Andy Barr, how I'm going to start off my approach? I think I always really value time to understand the current state access to people that are living here to try and get under their skin a bit so trying to do a bit of go look see and talking to people. I'm fortunate one of the benefits of sticking around so long as you have quite a good network of people that know you and trust you and are prepared to tell you kind of a fairly true current state picture. so working with that network both is great from getting insights about where the real problems lie, but also starts to create allies that are invested in trying to help improve it as well, which has been benefit from this sort of of people that we've taken through a training pathway as well is that the insights we gained from those folks being with us for some time was crucial. So yeah I think if you're trying to change an organisation then really you're trying to change how people work and behave and think about things so you absolutely have to engage with people. I think there's a lot for me to still learn on how to do that. I've seen different approaches from quite sort of, we've got the answers, here's how you do it, kind of coming from a slightly outside perspective. That's not really my natural style. So I think I tend to offer the more sort of, I mean, here with you, let's understand what's happening. I think somewhere, a bit of a mixture of the two can be really powerful actually, to sort of... engage with different styles that the individuals that you need to engage with will respond to. we were joking on the way down, I'm very good at spotting the things that are going to be difficult and sort of almost like early warning of, well, we're going to need to engage with these folks, or we're going to need to do this and kind of spotting those potential challenges, can come across as negative and other people will respond much better to a more positive, we've got the answers kind of approach. So I think trying to find that balance is really key. So actually allies is important, having other experts to try and consult with as well is really helpful in that context as well. Yeah, think persistence is a necessary characteristic for somebody who wants to change an organization, especially as those organizations are bigger, then I think you are likely to need a bit of time to get there. But it's also really rewarding to see changes, especially when they stick. And I think that perhaps the slightly longer times that I tend to spend working with a program hopefully lead to slightly longer lasting outcomes as well because you don't want to leave them for everything to then just stop. yeah, still very much learning though and trying to find a range of approaches for different contexts but it's certainly interesting every day is different. And some days you win and some days you maybe don't win so much. Well, I could tell you for one thing, we've won on this day where we've had the joy of you joining us in our offices in Derby. It's a really, really nice coincidence, Andy. And I really enjoyed our conversation. So thank you very much for joining us on the podcast. No, my pleasure, Tom. Thank you.
Tom: Thank you for listening to this episode of Flow by Design. If you would like to learn more about how we can help you improve knowledge flow within your organisation, contact us at info at p4learninglab.com. We hope you're enjoying Flow by Design. And if you are, please share the series within your network and join us for the next episode. See you there.
Tom & Andy: Andy, welcome to the podcast. Hi Tom. How are you doing? Good, thank you. Great, this is a nice coincidence. I always like peeling back the curtains on things, but you just happened to be around. Just happened to be in Derby with no place to be. It's amazing. Keith and I were talking about knowledge and process flows and going, who could we have to talk about this? And then five minutes later, I'm getting a call from you saying, I'm in the area. So it's a really happy coincidence, really glad you're here. recently achieved 25 years in Rolls-Royce, which is always a bit of a surprise when such a long time has racked up on me. But most of that time within engineering teams, helping to either be part of a team that are designing a new part for a new product or helping to improve a part that might be in service. So a lot of time really with knowledge workers, understand how to improve the coordination and collaboration within that kind of context. So perfect for this, I think. And I think we've worked together in the past as well using different tools and different projects. And I reckon we can deep dive into some of the challenges I think we've faced in the world of knowledge flow. I guess in your experience, let's start off with a big question. What's one of the biggest, blockers to knowledge flow that you encounter and Maybe what's the ideal way of overcoming that? blocker I think if I reflect on where my connection with with Kanban and flow started was managing a team of design stress PDG modelers and and you know the work we did was really needed all of us working effectively together And it was very hard in that knowledge work context to be able to really understand who had what stuff on their plate. And so we had examples in those days of effectively paper question sets being dropped on somebody's desk in the team. overnight and the expected turnaround was a couple of days on those things and the first that I would know about that as a manager was when we got a phone call from the department that needed it back saying well why haven't you returned this in time and you know I had no awareness of it so that awareness and visibility of the work in the team there was literally stuff being dropped in the dead of night and was lacking for me I think a company like Rolls-Royce where there's a lot of manufacturing knowledge and expertise, we were doing a lot of work with Lean and it absolutely made sense to me and the principles behind it of avoidance of waste. But a lot of the tools that we were then being recommended to use in our office, in our knowledge work context, didn't really fit. And so we'd be doing a five S or sort of a stand up, but we weren't standing up next to anything. We weren't talking about And so it was really, as I started to learn more about Kanban and started to understand how we could take that step of visualizing the work of the team and how that can really help you to then get a better understanding of what the real picture is, where some individuals might have a view of the burdens. Thinking about the teaming strategy you might want to apply, whether it's a cross-functional team, whether it's a single discipline. all suddenly made sense for me and felt like a improvement opportunity for us to start to use more of those tools. visualization you've alluded to there is a real key piece and I found sometimes as obvious as it can be, it's sometimes a hard sell to people of going, just put what you're working on somewhere that's visible to all. Do you feel there's, when we ask people these things to visualize work, is there sometimes a resistance because of vulnerability or people not being used to showing their work? Because culturally, think sometimes that happens and people feel resistant to showcase the work, they feel they're doing it. I think there's obviously problems behind that when they do I think there's a couple of aspects for that. I think that there can be cultures that can penalise people being transparent and there is that clarity about the things that they are doing and perhaps a stakeholder that's not happy with the responsiveness picks up the phone or gets on the teams and starts to contact them. that's not quite the spirit of transparency that I think is intended in the sort of agile approaches. So I can really understand why people might have reticence to share that and give that transparency. I'll be honest, I'm guilty as well as sort of not necessarily fully, you know, breaking down the work that I'm doing on my team's Kanban. And I think if I explore that a bit more, There are times when you're in a team and actually it's really helpful to have that clarity about what the other folk are doing and also what they can be helping you with. If that's not the nature of the team and the work, then you get less back for taking that step of putting the information into a Kanban tool. So I think there can be some pretty valid reasons for why people might be reticent to put stuff there that gives that exposure and potentially doesn't bring them any benefit. So I think that the real key then is to try and make sure that that act of putting the thing there does pay back. They get more help. There is more support to remove things that slowing them that they don't get those kind of contacts that are trying to falsely expedite the thing that they care about and pull work through that shouldn't be prioritized. if you can sort of couple up, you know, the card in whatever tool it might be with things like, well, this is where you find the link to access the documents that you need to work on. Suddenly you find that things naturally align and people recognize the value they get from taking that step. And then all kinds of things can open up. We've had some really good success recently where one of our program teams was starting to create a flow board for some of the hardware in build and that's opened up more collaboration with some of the other departments that are responsible for either producing the delivering the parts to make those products or for assembling those products and so it's starting to bring them together in a really really pleasing way that's opening up more opportunities but it does have to work for the people that need to put the data in. Absolutely, any context in that to them to go this is why we're doing it, this is what's going to benefit you because if someone visualises the work, like you say, they can understand then maybe how utilised they are, that their work is leading up to bigger objectives connecting that strategy through to action. and also being able to overcome problems faster because once it's there it becomes easier to understand there's a problem and easier to escalate to the right people. actually hand in hand visualizing the work at the start and trying to bring people together at Cadence are almost two key things at that point to start off with if you're getting into any project or area and they don't have either of those things it's almost the first step to go let's align people and this is what we're to align them towards. Absolutely yeah I think people naturally want to see what is the outcome of their efforts and there are plenty of tools that can really give a good insight into how things connect up. I think the hard part is trying to keep it simple. There are often organisations that I work with where... where we have pretty complex sort of, it's a complicated system. There's a lot of different demands on that system, lots of different work products trying to flow through it. Lots of different teams that each play a role in those things. They're trying to prioritize across it all in an effective manner trying to then not overburden teams with a really complicated network of boards that they've got to update. It's really important that because it starts to degrade that sort of, that value equation for them. You mentioned prioritization there and in an organization where you have this incredibly complex product, how on earth do you prioritize? I think the first question that is very much at the forefront of everybody's mind is safety. So we respect and recognize that the products that we are involved with have real sort of... real world safety significant implications and so anything that comes in that's of a sort safety related nature would naturally be prioritised. After that, it can be really hard that there's a mixture of both long term sort of larger project activities that might be washing up in the same team that are also involved in some short turnaround sort of quick assessment work and very different in terms of the immediacy of the impact of not responding. But equally, you don't want to always put off the longer term things for the short wins, the quick wins. And so that is something that we've sort of, I think you have to very much be aware of the context of the work that you're doing. I think it can be helpful if you can sort of separate out some of those very different work types. have a, I don't know, a group of people that are... more aligned to the longer term work for a quarter, almost like a capacity allocation decision, because it really is a bit arbitrary sometimes to try and prioritise a short term versus a long term thing. So perhaps trying to prioritise them within their sort of neighbourhood of the longer term stuff as one priority system and then the short term stuff in a slightly separate system is something we're experimenting with at the moment and trying to have. steady sort of allocation of people into each of those categories of work to try and simplify it. But that might look very different in another team. There are other programs that I've worked on where it's all about the longer term stuff and so the priority then is a little bit easier in some respects if they're all aligned around a single product. It's then just trying to bring the right stakeholders together to thrash it out a little bit and try and give clarity to those teams. It must feel easy in that kind of environment to generate a big list of priorities because there are lots of important things going on. Yeah. Have you experienced that and I guess what would be the consequence to having just a crazy list of priorities in a project? Definitely experience that. love the fact that haven't really researched it beyond a quick Google search but the fact that the word priority was only singular when it first came around, I think is really significant one to reflect upon. think we kid ourselves that you can have multiple priorities and I can only peel one potato at a time. I think that needs to be the forefront of our minds and trying to keep as few things on that list as possible and really prioritize work on one thing and do it well. Where that's difficult, think where you have teams who have a variety of customers, that becomes very difficult very quickly, whether those are internal or external customers. And so trying to have a bit more clarity about who is the in-person that's empowered to take a balanced view across the different stakeholders and customers and make that priority call is really key. Certainly for some of the programs where a scrum type team or team of teams approach is practical and we've tried to really make it more clear who is the product owner to set those priorities to try and give that team clarity because I think the harm that we often don't sort of... take stock of is that without a clarity on priority, then different people will pick different things and it might add up to not a lot. So yeah, it can be a hard call to make, but not making those choices can lead to a worse outcome overall. You've elaborated on the importance of a product owner there and I totally agree with you. Having that person to almost go, this is where we're steering the ship is crucial. You've heard this, I've heard this before on what these methods are perceived to be doing, which is to make people deliver faster. But sometimes it's about getting people to deliver in the right direction first and then delivering fast. And it's trying to negotiate between the two to get to someone to go, it's actually this way. And if we don't do this now, if we don't have that person to go, we're heading in this direction and this is the best we have right now. If we approach... turbulence along the way if we approach a problem then we change our direction, requirements change for example. That can be a difficult thing to sell to people because people just want to deliver faster and leaders want to go we're just going to deliver as fast as possible So with that in mind, think predictability is a big factor. When we've got these existing systems, we're wanting to just deliver as as fast as possible, knowing we're in the right direction. How would you ensure that people are delivering the predictable things and... maybe thinking about how to find the first or the best improvement to make now with the team so that any future problems are not eradicated but reduced risk wise. Yeah, I think... think that the ideal scenario to make it as close a relationship as possible between a group of people and the out-counters would be that that team are all collaboratively working on a single sort of workflow. And then if that becomes their of information radiator, their source of truth, then you start to implement, well, firstly, know, WIP limitations so that they're not trying to multitask too much in context switch so that they can work on finishing these things. You do the good Kanban practices, you know, starting at the right hand end of the board, what have we finished and what are the things that are closest to being done that we can work together on getting done. helping to focus on delivery of stuff and not just starting new stuff. And then the use of blockers, trying to capture and characterize the reasons why things get stuck, looking at where you're getting within that process flow, perhaps a bit of a backlog forming would all be good indicators of where those short skills are or the steps in the process that are proving more difficult. All of that theory is really pretty simple and really hard to argue with. think where it can sometimes be challenging in the real world context that we often find is that those teams may be collaborating with a number of different work products and processes. And so you kind of almost have to try and take a step back then and look at that bigger system, I think, to really start to understand where there is tension between one work product and another work product. And it really comes down to about our choices on the capacity we allocate to different things and then trying to monitor it and use the blockers, et cetera, to help us put it improvements. I think, though, we should still strive towards perhaps that more sort of simple clarity of this group of people are all working on this specific work that. Which wouldn't mean to say that people are forever going to be working on that same thing. We have a range of different skilled people within teams that I work with that wouldn't want to only do the same kind of work forever. But I think if we take a more sort of quarterly approach to allocation to things, then I think that might be a nice balance between getting really good as part of a team, doing a certain type of work for a period of time, and then still getting that personal development and growth through changing that up every so often. I really like that. I'm an advocate for simplicity, even for complex projects and deliveries. can simplify or scale back to almost scale up. can... it's almost an easier win to bring people in to go if it's this way and you're focusing on working these things that direction and clarity it can be really helpful even as someone who's been the team member going this is what you're doing today and sort of removes the the ambiguity of that I want to go back to the context switching because I have a really relevant funny story that includes you I remember we were doing some training videos and I remember doing the editing for your training videos and there was one on context switching and mid video you elaborate the point so well because you said I'm doing this video on context switching and I got a work call and it changes your mind completely and it puts you in another mindset and another frame where you come back to the work and then you're like right well I've got to reset back on this and it's like it might feel like minutes at the time we are having to readjust but in the real world that can be continual and people will just have to reshift their minds from going from one thing to the next in there. So when you mentioned context switching that was the first story that came to mind and... It's a really powerful example, think, because it's real and people will experience that in projects for sure. And maybe some of that ties in with how people are utilized. You mentioned WIP limits in there as well. How would we recognize when someone is really utilized, maybe to 100%, and how do we get them out of that? think that I think in this scenario that I'm currently working with a number of teams that are involved in a number of different work products and flow lines and I don't know where to put the whip limits because a whip limit on one or more of those flow lines would not necessarily result in taking some of that utilization down on whichever of the key specialist teams happens to be the real bottleneck. So it feels more appropriate to put the WIP limit onto the team board where they receive the demands from each of those flow lines and then discharge them as a team. So I think in that scenario, that's the least bad option. But I very firmly, in my experience, that there's very little that we can get done in the kind of engineering work that we're often doing where it's really only one discipline that you need on the pitch. So my preference would still tend to be to bring in the mixture of skills you need to support a flow line and for them to be a team working that flow line as a team for a period of time to try and get. improvement on it because it can be so hard to really work out the real picture when you've got these fragments of things on flow lines, things on teams, lots of different work products going through there. It's a very complicated world and you can unpack that with you know good stuff in PowerVR and so on but I feel like it's still where there are good synergies and opportunities to group things together to have a... simplify prioritisation, simplify the teaming of cross-functional teams, then I think that's probably the direction to go. And I think that's what we're starting to explore now in that programme, which is good because it wasn't necessarily clear that that was, that the appetite was including sort of team changes. And I'm not talking about necessarily managerial or organisational changes, but simply deployment sort of teams. So it's quite exciting to have that on the table now. thinking about the context switching and that living example I had when recording that video. A few weeks later I was involved in an event and part of the preparation for that I was looking back at some of the heritage in Rolls-Royce in Bristol and obviously the Olympus engine in the Concorde was part of the products that were developed in that location over the years. And what really struck me looking back at some of the photos from what work was like at that point in time was obviously very paper-based. You had large project walls, lots of drawing boards. Some of the guys that were around when I started in Rolls Royce had experienced that environment and would talk about how the... the design supervisor or the chief design engineer could walk down the line, could see what people were doing. So there was a real visual aspect and immediacy of being able to see what different people in the team were doing, being able to coach, guide, question, trying to make sure that it integrate together in a way that I think we've lost over the years with the move to computers and everything being more within your own screen. on top of that, I think we've also made it much easier to contact people and whilst they're are many many benefits to that it also results in more context switching. And it just strikes me that the time of time scales that we manage to do things like developing Concord in, are not that different to the kind of time scales that we're still taking to develop new products. And whether, despite the advances in computers and so on and the capability, whether we've lost something in the focus on task, the avoidance of context switching, that perhaps is a bit of an unseen and unaccounted for deficit compared to the older ways of doing stuff, which isn't necessarily, so I want to go back to that. days but it's just an interesting reflection that actually overall time scales aren't that different. It really is. And yeah, reflect back to my time as an integrator and yeah, it's always about shifting minds from one thing to the next. I had to contact a lot of people and I was probably a disturbance, but it was a drive for me to deliver what I needed to do. bit guilty when I was going up to people at their desks or calling people, but I think it's all about balance as well and it's trying to accept that there's a level of context switching that is appropriate and applicable and not getting to the mindset where I need to be doing everything all the time now. And I think that always ties back into the clarity on what we need to do. not the focus from I need to make sure that everyone's loaded so that we're delivering and going I need to make sure that everyone's doing the right work to get to the outcomes that we need to achieve. And I think that gives clarity in the tasks. the definition of done are things can sometimes be so powerful because then you just go, right, I've done that, we don't need to have continual meetings or continual calls with people to argue about whether this is done or not. It's there, it's done. Yeah, I think that's a good point. And I think trying to just encourage and make it more acceptable that... it is okay to perhaps turn the notifications off on your email or Teams or whatever and just have some focus time. Because I certainly feel like I'm always attracted to and drawn by those pings, those things that come along and you drop it and then it will be, know, a few minutes even afterwards that your flow is gone. You've got to kind of get back into where you were. So I think, yeah, trying to find that balance is important. I think it ties as well into how teams coordinate with each other because, you in the projects that we've been involved in, we can have teams that are working incredibly well and effectively. But if that network of teams, that team of teams isn't working together effectively, it can still all fall apart. We can still end up shifting deadlines to the right. So I guess in your experience, what's been a good, effective way of bringing those teams together so that we can feel confident we're giving them the right work and they can interact with each other effectively. Yeah, so a couple of different scenarios where it's been a large program with, I don't know, 50 plus people involved, so probably looking at maybe five teams at the smaller end of that spectrum up to you know, probably 50, 80 teams in some of the larger ones, then having a cadence at which we do seek to clarify what's important in the next quarter, give the team some time to configure themselves, to be able to deliver that as effectively as possible and together on what they need to do as a team and what they need from other teams to achieve it and have a handshake on those things. That's all going to help to try and effectively deliver value in a changing sort of scenario where actually either the requirements aren't totally locked down and our knowledge and experience to be able to be really confident about the predictability of our plan is not there. And that's often the case when you're developing a new product. It's literally not been done before. So I think having those regular points to sort of course correct and think about things are really key. If it's more a scenario where the team are there to service a number of different flow lines that are perhaps more sort of typical for projects that are in service with a kind of a natural churn of new stuff, new smallish tasks coming in just to keep making sure that everything's safe and working effectively and available. Then I think trying to monitor how the flow lines have been performing in the previous period. So still a cadence, maybe a quarter is not a bad one to take stock on how that flow line is performing. What level of resources have we been investing in that flow line? And do we need to change that balance if we want to target, you know, a batch of production in future, et cetera? It can also be useful. having that, doing that across the whole system, having that prioritization across the whole system so that we collectively put the right resources onto those things that we've agreed are the right priorities and not just leaving it to the haphazard nature of each team trying to work out and do their best to guess. So I think the key things on both is cadence and having a good attempt at prioritization of the demands on the teams. And you've elaborated in there as well, and I think you put it beautifully, is how all these things tie in together. So all the things we've covered so far, you're thinking prioritization, you're thinking cadence, you know, these are all crucial elements to it. And in the world of process and Kanban. and cadence, governance is a big part of that. ensuring that when we do bring the teams together to talk about stuff, it's targeted and focused on the right things in there. So I guess what's your experience in implementing governance, making process policies explicit in a workflow or in a system or in a project? we're in the midst of that at the moment, actually. So it's a good, challenging question. I with any change, the engagement and buy-in of the teams involved is key. So I tend to be fairly inquisitive and assume that folk are doing things for a good reason. So try and understand whatever governance is in place and how the teams are interacting on that work. to be open to think about is our proposed solution actually going to represent an improvement? So once you've got both that leadership level buy-in but also a good amount of confidence from the discussions with teams that this should lead us to a better place. Noting that it might be that for some specific teams and flow lines perhaps it's not necessarily going to be a win straight away, that it's more about the systemic sort of improvement rather than... sort of optimizing a smaller part of Then I think trying to start something but maybe start small is always good. So we're going to be starting to roll out some of that governance on some of the flow lines. We've already got a couple of teams that are nicely adopting that new approach and just trying to stay close to those folk as they go through that journey is important learn from their experience as well. And actually, we've also had a subset of people within that team structure who we've taken through some of the training on the background and principles behind Flow and Kanban. So they've got, you know, there was a little bit of self-selection in terms of the people that wanted to learn more. them with a bit more knowledge and a bit more of that bigger picture of what we're to get to. And then they are back in their home teams able to start to implement more of these things sort of spread hopefully the successes and get more sort of a snowball effect going on. I think I don't know whether I've drawn too agile because I'm not very good at planning. And I hate to say that because for me Agile is not about not having a plan, we should have a plan, but I certainly find some of the people and change management outside of things can be very difficult to plan out at the start and needs a certain amount of adaption to what you find along the way. And so, yeah, sort of getting the allies together, giving them the knowledge to go out and do stuff, start to showcase some of the successes that you've got and building on that, but also being open to change along the it will happen. I find that super important as well because I think going back, you and I, when we met in a really large complex organization like Rolls-Royce and We were maybe enthusiasts of a topic at the time, but even that as a starting point to coach others, to guide people on the journey from the inside is super powerful. I was talking with Sally who... has reflected on transformation as a both as a leader and as a consultant and actually the difference between the two as a consultant coming in it can be difficult to manage that to tell people this is what you need to do. We found that trying to embed those practices with networks of people who become specialists can be it's super important because it becomes more sustainable to carry out those practices they go and see other people they go and talk to people in their day to day and it's bringing casting that net of people in to align them to the same way of working. And when we were working with a tool and we were advocates for introducing that tool, the community of practice was a key thing at the start and just getting together a network of people. And I think that's something that still exists and works today. And that's a tool in a system that adopts different ways of working, but it brings value. of people in to working on that tool and it's benefits to that. So I really liked what you said there about when we're trying to embed those specialists inside it's not necessarily their job but even as advocates it can be super powerful to at least get people going. and help to know what the tool is capable of. and just with a few minutes to say, have you seen this functionality? That could be useful for you is really important. I think one of the things I've learned recently though, because the program I'm involved with at the moment was a program that I previously worked in seven, eight years ago some stuff that we'd set up then in terms of Kanban. has endured but it's also not quite adapted as the organization and the nature of the team structures has changed you've also then got sort of almost at a board level changes being implemented that means that a system level that can be really hard to understand what's going on. And so my learning, think, is about, and I think I tend towards an approach of, give somebody a bit of opportunity to explore something and they'll find a good way of doing it. And I guess that's being tempered a little bit by recognising that actually when that team is part of a bigger system, perhaps we do need a bit more structure and data rules and sort of mandating and filling in certain fields to enable that bigger picture to be drawn together. So it's been very, very good learning to go back into an area after a period of kind of a lack of stewardship of it, a lack of coordination of it and seeing just how those natural changes, whilst perhaps being useful from an individual team level, have meant that a system level it doesn't quite stick together anymore. And it's a perfect example of going, you even someone who's new into an organization will go in and see this complex network of activities and boards and I think that ties back into the simplicity element it's essential in especially in workflows and being able to make a decision quickly based on what we can see at a glance either through the state of the board itself or through a simple set of metrics in there. So I started with a question about the big blocker. A big blocker for you. I'll tie you now into blockers in general because we want to be predictable in delivery and we want to make sure that we're reducing risk as much as possible. How do you manage, say, sequences or types of blockers? And what is, in your experience, a really good method of eradicating or reducing the chance of those blockers occurring in future? I think whilst it's not obvious, to can-ban visualization of works on boards, think people get pretty quickly and quite naturally. But I think it would then be easy to overlook another aspect of Kanban method and approach and flow that is about a regular cadence in which the teams still come together to improve and focus on improvement. And that is crucially important as well, not only when it's important when you've got a single team working on a single board, but when you've got multiple teams working on multiple boards. it's even more important. And so that kind of honest appraisal of how we're performing and what could we do to improve. is really important, but I think it can be very easy to overlook that in and amongst more normal inverted commas kind of governance meetings. So I think trying to, something I'm taking from doing work with Scrum where that's a more overt kind of part of the cycle is how valuable that part of it is. And then... tool where you can categorize different reasons for being blocked and get the good data to help drive where the errors from proven are is crucial. But interestingly blockers can be perceived as a very negative thing and I guess if your goal is getting the work through the flow line then I understand that. But if you then almost outlaw the use of blockers because, well, that's about the team needing to go and contact somebody. You're losing some really valuable insights about the things that stopped the work coming through the machine and the system. So I think we perhaps just need to do a bit of work on almost like the reputation of blockers that whilst the goal is to minimize and avoid them. you don't achieve that goal by just outlawing them, if that makes sense. We need to have a sensible collection of blockers to truly understand what does prevent any of the work products from coming through this machinery so that we can then seek to improve and drive those reasons So there's an interesting sort of tension there in some of the perceptions around blockers that we're working with at the moment. But think, yeah, think by and large people can see the value in trying to capture those reasons. I think in my experience and probably in your experience, leaders value that more because it gives them an understanding of what is stopping the flow of work. What is preventing delivery? Because by knowing that you can then be targeted in action. And so the point you made about, we don't know about law blockers. and it might seem like a taboo, but if we don't see them and we're not visualizing them, how can we do anything about it? Yeah. Yeah. And I think if one of your real issues is actually you need to speak to a different specialist team and you can't get hold of them, that is a piece of information that the system needs to reflect upon and try and improve. And so let's capture it. Let's make it transparent. And then you've got a chance of trying to do something about it. I'm gonna, I've been really interested in hearing your experience on this. And I think in your experience, you'll be not thrown into scenarios, but maybe as a last question, when you do enter a project and you're probably given the task to improve the knowledge flow to... you know, in part on others how to deliver more effectively and improve processes as well. What's the first thing that goes through your mind when you go into any project? What's the first thing that you go, this is me as Andy Barr, how I'm going to start off my approach? I think I always really value time to understand the current state access to people that are living here to try and get under their skin a bit so trying to do a bit of go look see and talking to people. I'm fortunate one of the benefits of sticking around so long as you have quite a good network of people that know you and trust you and are prepared to tell you kind of a fairly true current state picture. so working with that network both is great from getting insights about where the real problems lie, but also starts to create allies that are invested in trying to help improve it as well, which has been benefit from this sort of of people that we've taken through a training pathway as well is that the insights we gained from those folks being with us for some time was crucial. So yeah I think if you're trying to change an organisation then really you're trying to change how people work and behave and think about things so you absolutely have to engage with people. I think there's a lot for me to still learn on how to do that. I've seen different approaches from quite sort of, we've got the answers, here's how you do it, kind of coming from a slightly outside perspective. That's not really my natural style. So I think I tend to offer the more sort of, I mean, here with you, let's understand what's happening. I think somewhere, a bit of a mixture of the two can be really powerful actually, to sort of... engage with different styles that the individuals that you need to engage with will respond to. we were joking on the way down, I'm very good at spotting the things that are going to be difficult and sort of almost like early warning of, well, we're going to need to engage with these folks, or we're going to need to do this and kind of spotting those potential challenges, can come across as negative and other people will respond much better to a more positive, we've got the answers kind of approach. So I think trying to find that balance is really key. So actually allies is important, having other experts to try and consult with as well is really helpful in that context as well. Yeah, think persistence is a necessary characteristic for somebody who wants to change an organization, especially as those organizations are bigger, then I think you are likely to need a bit of time to get there. But it's also really rewarding to see changes, especially when they stick. And I think that perhaps the slightly longer times that I tend to spend working with a program hopefully lead to slightly longer lasting outcomes as well because you don't want to leave them for everything to then just stop. yeah, still very much learning though and trying to find a range of approaches for different contexts but it's certainly interesting every day is different. And some days you win and some days you maybe don't win so much. Well, I could tell you for one thing, we've won on this day where we've had the joy of you joining us in our offices in Derby. It's a really, really nice coincidence, Andy. And I really enjoyed our conversation. So thank you very much for joining us on the podcast. No, my pleasure, Tom. Thank you.
Tom: Thank you for listening to this episode of Flow by Design. If you would like to learn more about how we can help you improve knowledge flow within your organisation, contact us at info at p4learninglab.com. We hope you're enjoying Flow by Design. And if you are, please share the series within your network and join us for the next episode. See you there.
