-Understanding Challenges in Socio-Technical Change

Hello and welcome to CTO Lifeline, the live stream conversation dedicated to helping CTOs lead successful change. And today's topic, why is changing socio-technical systems hard? And with me to discuss this topic and more, we have Noah Cantor. It's always fun to do this show. I'm a tech leadership coach and CTO. I've been working in and around technology for more than 20 years. I've worked in organizations of all sizes from three-person startup to 165,000 people, enterprises, and across all aspects of technology. So service desk to backend, DevOps to leadership. And I've taken those lessons from the last 20 years and now I use them to help other people become the sorts of tech leaders that they want to be. And today we've got... Tiani Jones joining us. Do you want to tell us a little bit about yourself? Sure. My background is in engineering and I started off, my first role ever was as a flight simulator engineer, full flight simulator for United Airlines, which is a very niche job and coding in Fortran and assembly language and on VAX machines, like really old school technology. And I worked in many different environments. And over time, I noticed that I gravitated towards work that was in between spaces, like how the system's functioning to enable product delivery. I would get distracted from working on a product by problems that were enabling or not enabling or stopping a product from being developed or from people to collaborate effectively. And that's how I built expertise in. systems and complexity and organizations and like different techniques to solve problems and that kind of thing. And what else can I share? I'm based in Brooklyn, New York. Happy to be here today. Awesome. Welcome to the show, Tiani. And I'm Daniel Walters, co-host, former... CTO and CIO for SeekAsia, which was Southeast Asia's leading employment marketplace, or still is. And these days, I'm a CTO coach and tech strategy consultant. So, Tiani, we're really going to... be leaning quite heavily on you because we're talking about socio-technical change and for me I have engaged with it but I also have questions like is there a dash in writing socio-technical? or not we'll get into it yeah before we do that should we do a little housekeeping yeah let's go for it so we do this show live as you can tell and one of the reasons we do that is so that audience members can actually ask questions and make comments as we go that we can respond to so it's important to us that you feel free to ask questions and we'll do our best to answer them at an appropriate time in addition the recording for this show will be hosted on LinkedIn and will be available for viewing afterwards. Excellent. So I'm really looking forward to questions and comments. And when people put those in, we'll put the interesting ones and the challenging ones up on screen and it'll shape what we talk about. So let's frame today's topic. There's change and we know collectively that change can be really hard and there's socio-technical change. So maybe. Maybe, Noah, let's start with change and why that can be hard. So we've all heard about how hard change is and how resistant people are to change. We've all seen numerous examples of failed change programs in lots of organizations. Talk about change is met with a shrug, an eye roll. and quiet or even not so quiet skepticism. I'm sure we've all heard about failed agile transformations and organizational change. I spent 10 years working with tech leaders on those sorts of change programs. And I was pretty good at it. But the number that failed still outweighed the number that succeeded quite heavily. Even with the best intentions, big change programs fail. And the question that I've actually got, like they're closely connected, I think, the idea of change at work and socio-technical change. When we talk about change, Tiani, we talk about socio-technical change. What does socio-technical actually mean? Like when people see it, what should they think about? I usually refer to the white paper on the evolution of socio-technical systems because I like the way it frames the research that was done and how it explains what the socio-technical system is. The way it's described is that a socio-technical system, organizations which are socio-technical, they're directly dependent on their material means for and resources for their outputs and so their core interface has a human element and a technical non-human element. It's one system, but there's two elements together that are intertwined and entangled, and they mutually influence each other, if that makes sense. So a lot of times, if you go straight to looking at something from a technology perspective in an organization without looking at the social elements, the people elements, the ways of working, the collaboration, the communication, that kind of thing, you're missing the analysis of the problem. And the way that the analysis of the way Trist describes it in the white paper is from three angles, the whole system of the whole organization, the primary work system and the macro social phenomena. So those three lenses you can use as well to look at a socio technical system. So I'm hearing what might be hints about why change programs have a tendency to fail. Exactly. There's. Obviously, many different reasons, but it could be not looking at those different lenses, sometimes throwing better tools at a problem, like that fakes you out a little bit because you think better tools, that's great. But is it really solving the deeper issues? And then just sometimes forgetting the people element or thinking it's either or versus interventions being a system of approaches from different angles and different things that you'll tweak when it comes to changing something or improving something, stepping it forward to serve your needs better. Could we? Delve into some of our respective experiences of some of this coming to life, these issues with change being realised. What about you, Noah? Is there any that come to mind, really specific examples, where it was all about the tools and not about the people? So there's one that you and I talked about on LinkedIn recently, and that was the new executive lands. And the first thing they do is a restructure. And it's so common that I've spoken to a number of executives and they refer to it as the new. executive handbook. You come in and you make your mark on the system. And what almost every one of those does, and I've seen it at some large banks and large insurance companies, they come in and without understanding the technical systems and the way that those have to be managed and looked after and shaped, they then introduce new practices. I've seen it done as PI planning. We're going to get into a room and we're going to introduce big room planning and we're going to mark out all of the dependencies that we have. And what they very rapidly discover is that all of their dependencies mean that they can't run PI planning in independent units, like it's meant to be run. There are no kind of independent streams of work. Everything is interconnected. And so they've introduced this new practice that feels really good because you get all these people in a room together and it's buzzing and you get a social high from it. And actually having been part of it, it's... tons of fun. But at the end of the day, you've got all these interconnected pieces that can't work on their own. So nothing changes. You've just introduced two days of overhead that gets you nowhere. Yeah. What about you, Tiani? I thought about the first time I realized that I think about these things and maybe that makes me a bit weird. So I worked for a large satellite TV company. So there was the arm of the company that did all of the actual creation of the set-top box, loading code into the set-top boxes, testing the new versions and the new technologies. And I was a technical program manager. And I remember there was a situation happening between the developers who sat in a completely different building, which was newer, and they had all kinds of perks, and they were in a different building down the way. Let's just say down the way. You could get to it. We get to walk a little ways. And then this part of the other part of the organization where there were testers that sat behind these cages, little cages, and everything was chained up. And there's two different floors. And I went into my manager's room one day and into his office one day and I said, I think I figured out this problem. And I started drawing it on the board and it was like a crime scene. Like these people are on this floor and these people are on this floor behind the cages. And they're working in these tools. And then over here in this separate system that doesn't talk to that one, these people are working on this. And then they do planning on the code that's going out into the box, but they actually never involve these people. They're testing it and have a lot of expertise in how everything works. They never actually joined planning together. And they're in this building. And then I went back to my desk and I said, isn't that what he's supposed to be working on? And the leader's job is to find this kind of thing. fix that so that's when it just hit me in a ton of bricks and there was a there was tooling elements there was a collaborative activity there was what same process is used across when there were different appropriate methods for different types of work and for different teams some dependencies that needed to be unlocked some things that needed to be brought together and that's how i that's what i've seen and i've seen iterations of that in various organizations yeah you mentioned crime scene and That resonates. Charlie from Always Sunny in front of the board. what just came to mind for me. I want Daniel to have a chance to say something. But first, actually, that reminded me of the first time that I went through something similar. Like I was working in a much smaller environment than a big bank, like working at a company, there's about 150 of us. And we're, the IT team is getting some incredible stress and pressure from another individual. And it seemed like another individual to us, right? There are five of us in the team and someone else from another team has given us a lot of flack. And we numerous times told him how much of a problem this was and nothing changed. And it was around this time that I was learning about systems thinking and learning about kind of positive reinforcing loops and kind of homeostasis in systems. And that was when I took a step back and I looked at it and I found that actually the problem that we had wasn't with this guy. The reason it continued even after conversations was because his boss kept enabling it. And so once I. I had that figured out and I could map it. I went into our mutual boss's office and I drew it up on the wall, very similar to what you're describing. I'm like, here's what's going on and here's the impact it's having. And here's what we try and do. And it changes and it'll change for a day or two days. And then it goes back to the way it was. And so here's this loop that's happening. And every time a change happens, his boss comes along and changes it back. And I don't have the authority to talk to his boss, but you do. And so I got our mutual boss. boss to have a conversation with this guy. And then all of a sudden things got easier. That reminds me of joining a company where I was taken on a tour around the offices and I was like, this is where the engineers are. And I was like, oh, where's the product managers. And they're like, oh, they're on the floor above. And I was like, oh, why is that? He said, oh, I know what you're going to say. We tried having them on the same floor together and it didn't work. And so I was like, oh, we might try again and see what might. make that more conducive. Cool. We've got a few comments there in the chat. I put up one earlier from Dr. J. If there's any that you want to talk about, just let me know and I'll pull it up onto the screen. We've got one. from an anonymous LinkedIn user who's not actually anonymous. This is Don Smith actually said it. It's just not coming through for some reason. He's actually asking us if we can talk about, based on our collective experience, how to get on the front foot with the... impending socio-technical change. So you want to introduce a change and you want to talk to people about the impact it's going to have, if I've understood that correctly, Dawn, the fact that you have to deal with both the social systems and the technical systems so that when you actually come to making those changes, the people on the receiving end or the people participating aren't actually caught as much by surprise. Have I understood that correctly, Dawn? I'm going to assume I have until I see a comment saying something. So Tiani, do you want to start? Something that you said earlier, I guess we both shared that in our anecdotes. We all shared that a little bit in our anecdotes around this idea of mapping and storytelling about what's happening. So before we talk about what the change is, thinking, having some tools or developing tools for describing problems in a way that everyone can say, yeah, that's what's happening. So we can see and have that awareness, the things that can aid in that awareness. I also think that important for, it's kind of part of the idea of effective socio-technical systems is that where people closest to the work have the agency to solve the problems or be involved and participate in solving problems as much as possible and where it makes sense depending obviously we talk about different scales of change and that kind of thing but i think it's important to for that to be part of the way you approach change i'm going to quote jabe here we go i've been testing a lot of the ideas that he shared and around idealized design and this ideal present loop. It's good to know what you envision for the future, what's possible, what you want it to be. But you can be wrong about two different things. You don't know the conditions that will be in the future, and you don't actually know the interventions to get you there. So I would say stepping it forward into what can we do now? What can we do with our current tools, people, all that we have at our disposal? what can we do right now to step forward towards the future? And which opens this idea that we're proposing things. First, let's understand the situation. Let's make proposals. Let's try them and measure things and observe things and continually do that. And so it's like progressively building those muscles to do that kind of thing on the system, just like we would do with a product that's like not performing well. We would try to figure out why and then iterate to get it to. for better for the end users so that's how i think about it there are a couple of things you mentioned there i come back to idealized design in a minute but you're talking about kind of tools and thinking about things and one of the ones that i see getting spoken of more and more frequently that i really like is conway's law yeah it's starting to be more accepted it's not it doesn't quite seem to be understood everywhere but it's starting to be more accepted that the way that your systems are built and the way that communication happens in your organization are going to be connected. And so there's an inherent socio-technical aspect to it. And there's been some really interesting research that has Conway's law come up with 50 years ago. But there's been really interesting research that kind of validates it and backs it as a valid observation about how organizations and groups of people work. And so when we raise it and when we talk about it, just the fact that it's named allows people to go off and do some reading and some learning about it and come back and say, oh, I have structured things this way. And so the systems that I've ended up with are going to look like that. And so if I want to change those, they have to happen together. And that's a massive improvement over how. things were when I started working in this area like 15 years ago. A lot of people you'll say, what is it? The inverse Conway's maneuver. And they start shaking their head now. And I don't know if they've tried it ever, but they're like, yeah, that's the, but I think that's true. There's like more awareness and people are able to go out and research and learn. So the Conway's law, there's the mirroring hypothesis. Ah, there it is. Ah, the same time I said it, it dropped into the comments. It's an excellent white paper. It shows that through all these different industries, how often your product architecture is mirroring your communication and people structure and architecture. The other thing that I wanted to talk about was idealized design. Oh, yeah. We talked about because one of the things I loved about I and still love about idealized design is specifically it's about the present. You're not trying to plan for the future. You're trying to say with the knowledge that we have today, how would the system work if it worked? exactly the way we think it should. And then you try and bring about some of those changes and then you can go through the same process again and say, now that we know these things, how would it be? And so you're not trying to get on a roadmap that sets you on a strict path. That moves you. you from point a to whatever your north star is it's a constant process of how would it be if we knew what we if it worked the ideal way we can imagine today how would that be yes how do we get closer to that you just keep redoing that i've got a few visuals relating to that because when i was referring earlier to jay putting a tweet i have the tweet i have the evidence and it was just a mention on another thread but i was like i saw that line yeah and there's the drill in talking about concepts of gap thinking versus present thinking it was the description of gap thinking so i've worked in some larger organizations and that it was like yes that's exactly what happens we will go and do a thousand item audit and then we'll end up with this big list and then we'll have this big change program around we're doing all the stuff and you can successfully do all the stuff and then look around and go but we didn't didn't actually improve what we set out to do. We just did the list. So yeah. So the thing that strikes me is what you're doing or what you described in that last thread on the idealist design, you're doing more things to create new knowledge and new awareness about the system, new understanding. So that's epistemic actions versus action result and not taking a step back and challenging your assumptions about what's going on. What did we learn? what is our purpose and why are we doing this? Those kind of things. That kind of information is what you're trying to surface through those actions in the present. is how I think about it. Actions that create more knowledge, more understanding, more learning. And it reminds me, another white paper, white papers I find are like, that are well written, they're like my favorite thing because they get to the point. There's another one I really, and I quote it in my keynote that I recently gave, nobody gets credit for fixing problems that never happened. And it talks about this idea of the amount of continuous improvement activity that you do versus the amount of just production. They don't use the term feature because they're talking across any industry when you might say feature in software world. But he said the more continuous improvement you invest in, in your work mix, productivity output may seem slower in the beginning, but it's that learning that allows you to actually get the performance and build your capabilities over time. Whereas if you go straight to do and you don't have enough continuous improvement through the system and your processes and whatever it is that you need to improve, you get that rush of productivity and then performance at some point hits this peak and then starts to slow down. Things are going well and then all of a sudden red tape comes in, bureaucracy, methods are not used appropriately. There's not improvement or fit for purpose practice and tooling and it slows everything down and performance suffers. I'd love to go a next level deeper. So going back to Don's question, so you shared about mapping relationships and featuring that in some of your communications. What might be some examples of how we can map the current situation and also what any sort of change hypotheses we have? What are ways we could do that? So there's several techniques. The ones that I've been using of late, testing out and trying to, are obviously like the logical thinking process, like current reality tree kind of mapping, where you try to understand causes. I really enjoy that. It's not easy, but you have to iterate your way through it with the right people who are close to the situation. But that forces those conversations and that kind of, at some point, everyone can say, yeah, that's how it all works together. That's what we're currently dealing with. I've been doing... testing a lot of like flow engineering. It's like value stream mapping, but it's a little bit less of the quantitative element, a little bit more qualitative, like just to get a picture of like, how does things actually work? What are the sequence of events? Where are the handoffs? Where are the, where's the, how, what is the flow of the sub flows that are happening? And just so they can get a picture, what's the ground truth? What can we, in a complex system, you can't understand everything, but there's techniques for at least having those conversations. and getting some kind of conversation around it. Those are two or three that I've been playing with a lot. There's others too. Yeah, similar to current Reality Tree and future Reality Tree is Stacey Barr's results maps that we used. And they were great for the collaboration. We found we had to summarize them a bit more because they could be really quite dense for people who were... not part of the creation i've done i've done a lot of work current reality trees i think i've talked to both of you about them you've both seen them um and they're really effective at identifying the logical reasons that things happen But when I've tried to introduce change into organizations just based on a current reality tree, it almost always fails. And it wasn't until I worked with a friend of mine, Elon Sinai. He's in the UK and as a service designer. And we worked on a project together. And what he brought was storytelling. I've got all this data. I've got this map. I've got this visualization. It's very logically compelling. And I could intellectually convince him. anybody but i was not good at changing hearts which is then what's necessary to get behavior to change and he was amazing at it so we did some work together on a client make-a-wish uk where we use this logic and then together put together a story about how people were impacted how people on the ground were affected how because it's make-a-wish how children are affected how the wish granting process is in fact we tell this whole story and weave it together and All of a sudden, it makes sense. And it made such a massive difference. I was like, I don't know why I haven't been doing this the whole time. It obviously turned out that I didn't know what I was missing. But it was such a game changer for me. The power of stories was something I hadn't witnessed firsthand until then. Yeah, I agree. I think you need the storytelling element. It's really important. It fills in the blanks and also brings everything to life. And you can't get everyone in an organization mapping. A lot of it. times to where they're like, we all did this together, like hundreds of us. It's not likely that's going to happen. So I think that's really important. That's a great realization that you came to how, like how, what things to pair together. to spark interest and energy to change. Storytelling brings together a few different elements. So it's a form, it can be a form of feedback, it can be a distillation of learning, and it's quite clearly a form of communication. Yeah. So thinking in terms of practical applications for CTOs, an area that I highlight that is where investment in is having a system a systematic approach to communication so as a leader I found that really useful because it's a way to create opportunities for agency so people tell their stories, just about a town hall or your Slack or your email communications. It's about how all of those work together. Noah or Tiani, do you have other examples of ways communication and storytelling can be interlinked or brought inside? I was literally just reminded, as you said that, about something that you mentioned when the three of us were first getting together to talk about this, which is the hub and spoke model of communication. and how that then shapes team behaviors. So Daniel, I was wondering if you'd be willing to share your story that you talked about with us. Yeah. I will share a story. I've worked with quite a number of CTOs where the pattern of communication, where they are the hub and their direct reports or others in the organization, maybe spokes. But what I mean by that is it's predicated on a lot of one-to-one communication. And so they can be shared in understanding. between those two individuals, but no holistic understanding about how each of those parts fit together. And it's quite common, they might think of each individual as being a part of their function and therefore problems or systems get broken down functionally. And that's where socio-technical problems can start to arise. Right. I think there is, from a storytelling element, there is that's the case study that I shared. I didn't share that part with you guys when we were talking through this topic together. I worked with this team in an aerospace setting, and they were in the Research and Development Center, and they wanted to build an engine fan blade out of a new material. They had done some calculations and simulations, the chief scientist on it, and they wanted to get funding to demonstrate that they could. develop this in a new way. So it was one proof that it actually could be done, like the tech side of the problem solving, but then also in this organization can we work in a new way. They had a Gantt chart that went out like two years. This is all we're going to do. So he was a leader. I was in the CTO office. He wasn't the CTO, but he was over an entire division and trying to continually change how they approach product development. And he said, no, don't present that for funding because that's going to set expectations. That's how we're going to work, which is how we always work. So he just whiteboarded a session where they had three different experiments. I said, what are you trying to do? And they said, we're trying to prove we can insert this material into this engine aircraft, this fan blade assembly. I said, OK, how would you test that? They said, we would. There's a lab over here. We get it manufactured over here and we. bring it into the lab in our facility and just blast it and see, I said, make sure it doesn't crack, fall away, melt, whatever. I said, okay, write that down. That's test number one. And then test number two, I said, what would that be if that goes well? And it's things are looking pretty good. Everything we're measuring, it's looking good. So well, then we put a housing on it, like it was on an aircraft when you see it on the tube under the wing and it's like spinning. That's what we test second. And then I said, okay, then what do you do? What do you, what's left? And they said, we need to do modify this, modify that. refine the blades that would be test number three so that i said write that down and so where you're going to manufacture it here's the team here's what we need and they got funding and then i kicked off working with them they solved this in record time and then it was like blasted to the whole company like everyone on a stage presentations the team was there like a panel getting interviewed then it was like It was blasted to the whole organization as a storytelling hour kind of thing. And it was like, everyone was excited. And they're like, we have 12 more teams. Let's do this everywhere. What's the secret? So that was more than explaining all the ins and outs of the product and the results they got. That was great. But getting everyone together and having that moment of the storytelling actually was pretty powerful and got a lot of interest from there. I think something that story highlights. is the unspoken assumptions that people make about how things have to work and how those often constrain us in ways that we think of as being concrete but are really like flexible or even imaginary and it it reminds me of a story that I was in the UK, I was working with a different bank and we were trying to introduce modern development practices to the bank and the way that they had worked so far was that they had an outsource partner and the rules around engagement with this outsource partner were that everything had to be completely locked down. These people couldn't have phones, they couldn't have like control, they were very strictly monitored. This is a team in India and everything was locked down to the nth degree because they weren't willing to risk any data being lost. These are the conditions you have to work under and so we wanted obviously a more modern practice where there was more flexibility and they had more control and they had more ability. to engage and make decisions and even show up and bring their phones and use the internet to actually figure out how to solve problems. And the responses we got back from most people were, it's not going to be possible to do that. This is how this has to work. And so I asked, why does it have to work this way? Because security tells us to. Who in security? That guy right over there. Have you ever talked to him? No, we can't talk to him because the answer is no. There's no point in having that conversation because we know what's going on. it's going to happen. And because I was an external consultant and I got to play ignorant all the time, I went and I spoke with him. I said, hey, this is something we're trying to do. How could we make it work? And he said, with the current conditions, you can't make it work, but we should talk to risk because the policies we implement in security are based on the risks that are identified and the organization's appetite for risk. Who in risk should we be talking to? And so the three... of us like he pointed someone out and the three of us sat down together and we talked through what the goal was and they said let me get this straight you're doing mobile development and your mobile development doesn't require access to any customer data and it doesn't require access to the internal network because you're not doing anything internally it's all external it's all outward customer facing yeah not actually none of the people doing this work are sitting on internal systems which can access customer data no that's And they said, just do it. If you're not on our network, if you're not on the bank's network, there are literally no constraints about what you can do. And that set of conversations resulted in creating a completely new software development. And like they called it a mobile development center. 500 new people in India were spun up who could use the bathroom whenever they wanted. They could use their phones. They could bring them in. They could do software development. They had control over their product. ask questions and do things for themselves, which had never been possible before because the assumptions that they had that were just built into the way they thought about literally everything. Yeah. So that's actually assumptions, I think, are a core part of why socio-technical change is hard is because we don't even, most of the time, we don't even see them. That's true. Just to pick up on one part of that. So the one I see often talking about that team over there, marketing says we can't do this or security. says we can't do this and so it always feels like a chasm but what you demonstrated was getting specifically who are we talking about because then we can go have a conversation and then that lends that opportunity and then the second part you identified was you've got two goals of the system or two necessary conditions for the organization to succeed one around the safety of the organization the other around the what was going to drive the the business model and it's I'm not sure if this is what Jay means by joint optimization but it triggers the same ideas around asking what would need to be true for both of these things to be true because then that leads you to a different set of options. Excellent. Continuing down this track, I'm mindful our audience are CTOs. They're probably grappling with some of these. They may have attempted some change and got some surprising side effects. And so we've talked a bit about communication, storytelling and mapping. But the broader question, how can a CTO approach socio-technical change? What are more things that they can do if we distill this down? I think we've surfaced some of those things throughout the conversation. The one that comes to mind right away when you ask the question is just to learn about the systems and some of these. ways of thinking and ways of working that are around understanding the system. I think that's really important because it's not something that's really, we don't learn, like where is that taught? And the habits that we have, it's another thing that I've seen in so many different publications and writings and white papers, including the Sociotechnical Systems white paper, where they talk about the mixing like Taylorism. with some other ways of thinking around work and how that has become pervasive in just a lot of workplaces and those habits are deeply entrenched. It reminds me of what Noah said about the assumptions we might hold about how work actually has to happen, how it works in a little bit more macro level versus like in a specific context. Those assumptions that we hold are often informed by organizations that have that are like more bureaucratic or more hierarchical. how Western's typology describes like generative, bureaucratic, and like performance and mission centered organizations. So I think starting with that, understanding those kinds of things and digging into those topics is a starting point. Because from there, it opens up, oh, here's what was trying, here's some techniques I can apply, or here's how I get people together, like leadership to work on the system. And another thing, I worked recently with an SVP and his leadership team. A teammate and I were coaching that leadership team and they started to identify when they were working in the system versus on the system. So they started to recognize when they were just being really tactical versus stepping back and thinking about improving the system and improvement activities that they could do, experiments they can run, initiatives that they can spin up together to improve specific problems. So that could be another thing too, is bringing other leaders together. And having conversations specifically about system improvements. And for me, I think those are two things that come to mind. There's a bit about understanding oneself and your own, why you might reach for certain options. It's similar to understanding bias and things like that. The more you're aware of it, the more you might be able to change it. That's something that I actually talk to leaders about quite frequently is like Tiani. saying we have this history of how most of us experience management and leadership as we're coming up through organizations and we inherit a lot of those beliefs like we just we adopt them because the people who are successful or more successful than us do them and therefore we should do them. But it doesn't necessarily work and one of the things that I find really helpful is actually let's sit down and explore how you want to lead like how do you want to show up because for many of us and this includes myself I started long before I understood what drove me I became a manager and I copied what other people did and it yeah lots of it never quite felt right. but I didn't have any idea of what to do differently. And it wasn't until I was exposed to systems thinking, theory of constraints, and psychology that I started developing a different set of ideas about how organizations could be run and about how I could lead people differently and I could behave differently and that would get different results. And so there's this whole kind of assumptions about we work the way we do because work has to happen that way. But what... What if it didn't? What if you could do work however you wanted in whatever way worked really well for you? What would that look like? How would you behave? How would you show up? How would you do things? How would you then shape the system to behave? Yeah, those if you start right back at the beginning and you question the kind of basic, why am I showing up to work? Why do I do this thing? And you get different answers there. Then all the rest of what you do after that can change much more easily. Yeah. Yeah. Another thing that we, a teammate and I, and we actually worked on this with Jabe a few years ago, we used some ideas around like patterns, like the kind of pattern language and base patterns. There's an actual, another white paper called Base Patterns of Agility in the Agile Canon. And I like this idea of starting to recognize patterns in an organization, like developing that muscle. And also kind of what I like when it comes to change and thinking through the problem solving that's evolved with people is using some known good patterns or principles and sort of being fluent with those kinds of things like organizational, sociotechnical, good sociotechnical principles. I actually picked out a few that were from the sociotechnical systems white paper. One of them talked about how the work group was more central than the individual job holder. So if we think about that, we often over-index to individuals so much so that we then sub-optimize the system because we're optimizing for almost like one task, one individual, what they're doing versus how the system is performing. And this idea of internal regulation of the system by the group, the idea of leaders creating conditions so that the group in the right places can internally regulate and take advantage of information that they have that's readily available. So I like thinking of these kind of ideas in a way to say, do we live into that principle or not? What are we actually doing? So that's a little bit more like a next level down from that learning about systems, learning about oneself, one's biases, like how to be a good leader, starting point. This research was done in the 40s and 50s in coal mines. And we're still talking about the team as the base unit of value creation, distributed authority, aligned autonomy. We're still trying to figure those things out. And organizations, but that knowledge and know-how is there. But those patterns will be lived into in different ways in different contexts, but they're still good patterns to ponder. So I think that's a good thing for any leader to have in their toolkit. You're right. It's really out there. in terms of the papers and research. I found a paper by William Passmore, I think around 2018, and it had a set of principles, which I'll just bring up on the screen. You might have to go out and buy a new monitor. Yeah, I'll put a link to that one in the show notes. I've got a massive monitor, so it's no problem for me. That's a direct quote from the white paper, from Trist, actually that second principle on teams. You got it covered. So I think... I think those principles are very findable and a good resource. Yeah. We were getting into some of these sort of silver bullets that people reach for. So there's the change is hard, so let's do one really big change and get it all over and done with. What other examples have you seen of the silver bullets that people, you know, what can we look out for in ourselves? What might be a behavior where if we're doing it, we might have pause and go, maybe I shouldn't be doing this. There's one I can think of, and it relates back to what Tiani said about complex systems, which is if you think this change is the one that's going to fix everything, you should be holding up your own red flag. Yeah. Systems are like they're in many ways, they're predictable, but they are still complex. And so you can't be sure that any given intervention is going to say, solve the exact problem that you're having. That's right. It's very much a... let's do this and see what happens and make adjustments. So if you think you have the answer and it's definitely going to create the change that you think that you need, you're probably wrong. And that's not a reflection on your knowledge or your capabilities. It's a reflection on how people in large groups work together. That's right. I think I mentioned before throwing tools into the mix and saying that's a version of saying this will fix everything. They were developing model-based digital. thread. They have these like best in class tools that they could link together to create this. You could do all the design kind of digital twin, like all the analysis and everything and monitor something all the way through production. But then they realized in our context, we have a lot of older tools and we have a lot of homegrown processes. And so we can't just drop that in because nobody knows how to use it. And it was predicated on this idea of Almost like it's like CICD for cyber physical system. So if you think about CICD or good technical practices that enable continuous integration and deployment, it's a socio-technical problem. There's a people element and ways of working in collaboration to do it well. So I think that's another gotcha is the tool and not looking at the current context and stepping forward. What can we do now with what we know? Yeah, absolutely. So. I'm going to attempt to recap. We've covered a lot of ground. We're going to go for a lightning recap. Noah and Tiani, jump in and add some points of anything I missed. So people are working with technology more than ever, and so therefore change involves people and technology. and addressing one without the other or parts of the system can lead to side effects. The fact that things are interconnected and more interconnected, our biases can lead us to be selecting options. that are not very compatible with socio-technical change. There are the unchallenged assumptions that are hard to navigate. We mentioned a lot of theories in white papers, so there's a lot of wealth in the comments, but there's mentions of Senge from Dr. J. Bloom, plenty of mentions of Dr. J. himself, Deming, Goldratt, and Theory of Constraints. I mentioned some work from Stacey Barr. So there's he... for people to read about if they're feeling like they might be facing some of these socio-technical change problems. What did I miss? We talked a lot about ACOF because it provides a lot of the foundation for some of the stuff that Jave has done and some of the ideal present stuff is based a lot on his work and he's a fascinating guy to read about. Absolutely. So what can CTOs do next? So we talked about mapping the current situation, mapping the theory of how change is supposed to or is hypothesized to work, being continuous and assessing progress. And that means learning and feedback. And I mentioned about being deliberate about your communication systems, setting up systems that people, everyone can participate in and share stories of what's working, what they're learning, etc. I think we've done a fairly comprehensive job. So that might bring us to the end of an episode. Where can we find you, Noah? You can find me at noahcanto.com. If some of the stuff that we've talked about today... has resonated, you want some help figuring out your own assumptions and where you're starting from at a personal level so that you can then see how to shape the system differently, you can book a call with me using the code CTO Lifeline 6, which is the episode we're on now. Excellent. And Tiani, where can we find you? Yeah, you can find me at proper science.co and you can reach me there. I have a calendar set up so you can put time with me and learn about my case studies that I've worked on. Some of the techniques that I use to help teams solve problems and improve. Definitely encourage people to do that. There's a lot more depth to this conversation than we had time to get into. Absolutely. And I've been doing group coaching for CTOs based in Australia, and I'm launching group coaching for CTOs based in Australia. in Southeast Asia. So I've probably mentioned I spent a decade in Kuala Lumpur and so I'm really enjoying reconnecting with a lot of the community there. So you can find out more on that bit.ly link. Now, our next episode is not too far away. It is on the 17th of September, which will be the 16th. So for us in New Zealand, it's 7 a.m. I believe it's 3 p.m. Eastern Daylight Time and 8 p.m. British Standard Time. So Adam Horner is a CEO coach. And we thought we'd do something different. And that is have audience. provided questions and challenges and issues. So maybe you've had a socio-technical change that you're struggling with and you want some advice. So we're calling it three-point perspective. So you'll get perspective from myself, from Noah and from Adam. I'm going to leave you with this thought. If you're tackling change and people are asking questions, it's very easy to hear those as challenges to your thinking. Suppress that natural response and... And instead, try asking questions that help build your understanding. With that, thank you very much for your attention and your contributions. And this has been another CTO Lifeline.

It's always fun to do this show. I'm a tech leadership coach and CTO. I've been working in and around technology for more than 20 years.

I've worked in organizations of all sizes from three-person startup to 165,000 people, enterprises, and across all aspects of technology. So service desk to backend, DevOps to leadership. And I've taken those lessons from the last 20 years and now I use them to help other people become the sorts of tech leaders that they want to be.

And today we've got... Tiani Jones joining us. Do you want to tell us a little bit about yourself? Sure.

My background is in engineering and I started off, my first role ever was as a flight simulator engineer, full flight simulator for United Airlines, which is a very niche job and coding in Fortran and assembly language and on VAX machines, like really old school technology. And I worked in many different environments. And over time, I noticed that I gravitated towards work that was in between spaces, like how the system's functioning to enable product delivery. I would get distracted from working on a product by problems that were enabling or not enabling or stopping a product from being developed or from people to collaborate effectively. And that's how I built expertise in.

systems and complexity and organizations and like different techniques to solve problems and that kind of thing. And what else can I share? I'm based in Brooklyn, New York.

Happy to be here today. Awesome. Welcome to the show, Tiani. And I'm Daniel Walters, co-host, former... CTO and CIO for SeekAsia, which was Southeast Asia's leading employment marketplace, or still is.

And these days, I'm a CTO coach and tech strategy consultant. So, Tiani, we're really going to... be leaning quite heavily on you because we're talking about socio-technical change and for me I have engaged with it but I also have questions like is there a dash in writing socio-technical?

or not we'll get into it yeah before we do that should we do a little housekeeping yeah let's go for it so we do this show live as you can tell and one of the reasons we do that is so that audience members can actually ask questions and make comments as we go that we can respond to so it's important to us that you feel free to ask questions and we'll do our best to answer them at an appropriate time in addition the recording for this show will be hosted on LinkedIn and will be available for viewing afterwards. Excellent. So I'm really looking forward to questions and comments. And when people put those in, we'll put the interesting ones and the challenging ones up on screen and it'll shape what we talk about.

So let's frame today's topic. There's change and we know collectively that change can be really hard and there's socio-technical change. So maybe. Maybe, Noah, let's start with change and why that can be hard.

So we've all heard about how hard change is and how resistant people are to change. We've all seen numerous examples of failed change programs in lots of organizations. Talk about change is met with a shrug, an eye roll. and quiet or even not so quiet skepticism. I'm sure we've all heard about failed agile transformations and organizational change.

I spent 10 years working with tech leaders on those sorts of change programs. And I was pretty good at it. But the number that failed still outweighed the number that succeeded quite heavily.

Even with the best intentions, big change programs fail. And the question that I've actually got, like they're closely connected, I think, the idea of change at work and socio-technical change. When we talk about change, Tiani, we talk about socio-technical change.

What does socio-technical actually mean? Like when people see it, what should they think about? I usually refer to the white paper on the evolution of socio-technical systems because I like the way it frames the research that was done and how it explains what the socio-technical system is. The way it's described is that a socio-technical system, organizations which are socio-technical, they're directly dependent on their material means for and resources for their outputs and so their core interface has a human element and a technical non-human element. It's one system, but there's two elements together that are intertwined and entangled, and they mutually influence each other, if that makes sense.

So a lot of times, if you go straight to looking at something from a technology perspective in an organization without looking at the social elements, the people elements, the ways of working, the collaboration, the communication, that kind of thing, you're missing the analysis of the problem. And the way that the analysis of the way Trist describes it in the white paper is from three angles, the whole system of the whole organization, the primary work system and the macro social phenomena. So those three lenses you can use as well to look at a socio technical system. So I'm hearing what might be hints about why change programs have a tendency to fail. Exactly.

There's. Obviously, many different reasons, but it could be not looking at those different lenses, sometimes throwing better tools at a problem, like that fakes you out a little bit because you think better tools, that's great. But is it really solving the deeper issues?

And then just sometimes forgetting the people element or thinking it's either or versus interventions being a system of approaches from different angles and different things that you'll tweak when it comes to changing something or improving something, stepping it forward to serve your needs better. Could we? Delve into some of our respective experiences of some of this coming to life, these issues with change being realised.

What about you, Noah? Is there any that come to mind, really specific examples, where it was all about the tools and not about the people? So there's one that you and I talked about on LinkedIn recently, and that was the new executive lands. And the first thing they do is a restructure. And it's so common that I've spoken to a number of executives and they refer to it as the new.

executive handbook. You come in and you make your mark on the system. And what almost every one of those does, and I've seen it at some large banks and large insurance companies, they come in and without understanding the technical systems and the way that those have to be managed and looked after and shaped, they then introduce new practices. I've seen it done as PI planning.

We're going to get into a room and we're going to introduce big room planning and we're going to mark out all of the dependencies that we have. And what they very rapidly discover is that all of their dependencies mean that they can't run PI planning in independent units, like it's meant to be run. There are no kind of independent streams of work.

Everything is interconnected. And so they've introduced this new practice that feels really good because you get all these people in a room together and it's buzzing and you get a social high from it. And actually having been part of it, it's... tons of fun.

But at the end of the day, you've got all these interconnected pieces that can't work on their own. So nothing changes. You've just introduced two days of overhead that gets you nowhere.

Yeah. What about you, Tiani? I thought about the first time I realized that I think about these things and maybe that makes me a bit weird. So I worked for a large satellite TV company. So there was the arm of the company that did all of the actual creation of the set-top box, loading code into the set-top boxes, testing the new versions and the new technologies.

And I was a technical program manager. And I remember there was a situation happening between the developers who sat in a completely different building, which was newer, and they had all kinds of perks, and they were in a different building down the way. Let's just say down the way.

You could get to it. We get to walk a little ways. And then this part of the other part of the organization where there were testers that sat behind these cages, little cages, and everything was chained up.

And there's two different floors. And I went into my manager's room one day and into his office one day and I said, I think I figured out this problem. And I started drawing it on the board and it was like a crime scene.

Like these people are on this floor and these people are on this floor behind the cages. And they're working in these tools. And then over here in this separate system that doesn't talk to that one, these people are working on this.

And then they do planning on the code that's going out into the box, but they actually never involve these people. They're testing it and have a lot of expertise in how everything works. They never actually joined planning together.

And they're in this building. And then I went back to my desk and I said, isn't that what he's supposed to be working on? And the leader's job is to find this kind of thing. fix that so that's when it just hit me in a ton of bricks and there was a there was tooling elements there was a collaborative activity there was what same process is used across when there were different appropriate methods for different types of work and for different teams some dependencies that needed to be unlocked some things that needed to be brought together and that's how i that's what i've seen and i've seen iterations of that in various organizations yeah you mentioned crime scene and That resonates. Charlie from Always Sunny in front of the board.

what just came to mind for me. I want Daniel to have a chance to say something. But first, actually, that reminded me of the first time that I went through something similar. Like I was working in a much smaller environment than a big bank, like working at a company, there's about 150 of us. And we're, the IT team is getting some incredible stress and pressure from another individual.

And it seemed like another individual to us, right? There are five of us in the team and someone else from another team has given us a lot of flack. And we numerous times told him how much of a problem this was and nothing changed. And it was around this time that I was learning about systems thinking and learning about kind of positive reinforcing loops and kind of homeostasis in systems. And that was when I took a step back and I looked at it and I found that actually the problem that we had wasn't with this guy.

The reason it continued even after conversations was because his boss kept enabling it. And so once I. I had that figured out and I could map it.

I went into our mutual boss's office and I drew it up on the wall, very similar to what you're describing. I'm like, here's what's going on and here's the impact it's having. And here's what we try and do.

And it changes and it'll change for a day or two days. And then it goes back to the way it was. And so here's this loop that's happening.

And every time a change happens, his boss comes along and changes it back. And I don't have the authority to talk to his boss, but you do. And so I got our mutual boss.

boss to have a conversation with this guy. And then all of a sudden things got easier. That reminds me of joining a company where I was taken on a tour around the offices and I was like, this is where the engineers are.

And I was like, oh, where's the product managers. And they're like, oh, they're on the floor above. And I was like, oh, why is that?

He said, oh, I know what you're going to say. We tried having them on the same floor together and it didn't work. And so I was like, oh, we might try again and see what might. make that more conducive.

Cool. We've got a few comments there in the chat. I put up one earlier from Dr. J. If there's any that you want to talk about, just let me know and I'll pull it up onto the screen. We've got one. from an anonymous LinkedIn user who's not actually anonymous.

This is Don Smith actually said it. It's just not coming through for some reason. He's actually asking us if we can talk about, based on our collective experience, how to get on the front foot with the... impending socio-technical change.

So you want to introduce a change and you want to talk to people about the impact it's going to have, if I've understood that correctly, Dawn, the fact that you have to deal with both the social systems and the technical systems so that when you actually come to making those changes, the people on the receiving end or the people participating aren't actually caught as much by surprise. Have I understood that correctly, Dawn? I'm going to assume I have until I see a comment saying something.

So Tiani, do you want to start? Something that you said earlier, I guess we both shared that in our anecdotes. We all shared that a little bit in our anecdotes around this idea of mapping and storytelling about what's happening. So before we talk about what the change is, thinking, having some tools or developing tools for describing problems in a way that everyone can say, yeah, that's what's happening.

So we can see and have that awareness, the things that can aid in that awareness. I also think that important for, it's kind of part of the idea of effective socio-technical systems is that where people closest to the work have the agency to solve the problems or be involved and participate in solving problems as much as possible and where it makes sense depending obviously we talk about different scales of change and that kind of thing but i think it's important to for that to be part of the way you approach change i'm going to quote jabe here we go i've been testing a lot of the ideas that he shared and around idealized design and this ideal present loop. It's good to know what you envision for the future, what's possible, what you want it to be. But you can be wrong about two different things. You don't know the conditions that will be in the future, and you don't actually know the interventions to get you there.

So I would say stepping it forward into what can we do now? What can we do with our current tools, people, all that we have at our disposal? what can we do right now to step forward towards the future?

And which opens this idea that we're proposing things. First, let's understand the situation. Let's make proposals.

Let's try them and measure things and observe things and continually do that. And so it's like progressively building those muscles to do that kind of thing on the system, just like we would do with a product that's like not performing well. We would try to figure out why and then iterate to get it to. for better for the end users so that's how i think about it there are a couple of things you mentioned there i come back to idealized design in a minute but you're talking about kind of tools and thinking about things and one of the ones that i see getting spoken of more and more frequently that i really like is conway's law yeah it's starting to be more accepted it's not it doesn't quite seem to be understood everywhere but it's starting to be more accepted that the way that your systems are built and the way that communication happens in your organization are going to be connected.

And so there's an inherent socio-technical aspect to it. And there's been some really interesting research that has Conway's law come up with 50 years ago. But there's been really interesting research that kind of validates it and backs it as a valid observation about how organizations and groups of people work. And so when we raise it and when we talk about it, just the fact that it's named allows people to go off and do some reading and some learning about it and come back and say, oh, I have structured things this way.

And so the systems that I've ended up with are going to look like that. And so if I want to change those, they have to happen together. And that's a massive improvement over how. things were when I started working in this area like 15 years ago. A lot of people you'll say, what is it?

The inverse Conway's maneuver. And they start shaking their head now. And I don't know if they've tried it ever, but they're like, yeah, that's the, but I think that's true. There's like more awareness and people are able to go out and research and learn.

So the Conway's law, there's the mirroring hypothesis. Ah, there it is. Ah, the same time I said it, it dropped into the comments.

It's an excellent white paper. It shows that through all these different industries, how often your product architecture is mirroring your communication and people structure and architecture. The other thing that I wanted to talk about was idealized design. Oh, yeah. We talked about because one of the things I loved about I and still love about idealized design is specifically it's about the present.

You're not trying to plan for the future. You're trying to say with the knowledge that we have today, how would the system work if it worked? exactly the way we think it should. And then you try and bring about some of those changes and then you can go through the same process again and say, now that we know these things, how would it be?

And so you're not trying to get on a roadmap that sets you on a strict path. That moves you. you from point a to whatever your north star is it's a constant process of how would it be if we knew what we if it worked the ideal way we can imagine today how would that be yes how do we get closer to that you just keep redoing that i've got a few visuals relating to that because when i was referring earlier to jay putting a tweet i have the tweet i have the evidence and it was just a mention on another thread but i was like i saw that line yeah and there's the drill in talking about concepts of gap thinking versus present thinking it was the description of gap thinking so i've worked in some larger organizations and that it was like yes that's exactly what happens we will go and do a thousand item audit and then we'll end up with this big list and then we'll have this big change program around we're doing all the stuff and you can successfully do all the stuff and then look around and go but we didn't didn't actually improve what we set out to do. We just did the list. So yeah.

So the thing that strikes me is what you're doing or what you described in that last thread on the idealist design, you're doing more things to create new knowledge and new awareness about the system, new understanding. So that's epistemic actions versus action result and not taking a step back and challenging your assumptions about what's going on. What did we learn?

what is our purpose and why are we doing this? Those kind of things. That kind of information is what you're trying to surface through those actions in the present. is how I think about it.

Actions that create more knowledge, more understanding, more learning. And it reminds me, another white paper, white papers I find are like, that are well written, they're like my favorite thing because they get to the point. There's another one I really, and I quote it in my keynote that I recently gave, nobody gets credit for fixing problems that never happened. And it talks about this idea of the amount of continuous improvement activity that you do versus the amount of just production. They don't use the term feature because they're talking across any industry when you might say feature in software world.

But he said the more continuous improvement you invest in, in your work mix, productivity output may seem slower in the beginning, but it's that learning that allows you to actually get the performance and build your capabilities over time. Whereas if you go straight to do and you don't have enough continuous improvement through the system and your processes and whatever it is that you need to improve, you get that rush of productivity and then performance at some point hits this peak and then starts to slow down. Things are going well and then all of a sudden red tape comes in, bureaucracy, methods are not used appropriately.

There's not improvement or fit for purpose practice and tooling and it slows everything down and performance suffers. I'd love to go a next level deeper. So going back to Don's question, so you shared about mapping relationships and featuring that in some of your communications. What might be some examples of how we can map the current situation and also what any sort of change hypotheses we have?

What are ways we could do that? So there's several techniques. The ones that I've been using of late, testing out and trying to, are obviously like the logical thinking process, like current reality tree kind of mapping, where you try to understand causes.

I really enjoy that. It's not easy, but you have to iterate your way through it with the right people who are close to the situation. But that forces those conversations and that kind of, at some point, everyone can say, yeah, that's how it all works together. That's what we're currently dealing with.

I've been doing... testing a lot of like flow engineering. It's like value stream mapping, but it's a little bit less of the quantitative element, a little bit more qualitative, like just to get a picture of like, how does things actually work? What are the sequence of events?

Where are the handoffs? Where are the, where's the, how, what is the flow of the sub flows that are happening? And just so they can get a picture, what's the ground truth?

What can we, in a complex system, you can't understand everything, but there's techniques for at least having those conversations. and getting some kind of conversation around it. Those are two or three that I've been playing with a lot. There's others too.

Yeah, similar to current Reality Tree and future Reality Tree is Stacey Barr's results maps that we used. And they were great for the collaboration. We found we had to summarize them a bit more because they could be really quite dense for people who were...

not part of the creation i've done i've done a lot of work current reality trees i think i've talked to both of you about them you've both seen them um and they're really effective at identifying the logical reasons that things happen But when I've tried to introduce change into organizations just based on a current reality tree, it almost always fails. And it wasn't until I worked with a friend of mine, Elon Sinai. He's in the UK and as a service designer. And we worked on a project together. And what he brought was storytelling.

I've got all this data. I've got this map. I've got this visualization. It's very logically compelling.

And I could intellectually convince him. anybody but i was not good at changing hearts which is then what's necessary to get behavior to change and he was amazing at it so we did some work together on a client make-a-wish uk where we use this logic and then together put together a story about how people were impacted how people on the ground were affected how because it's make-a-wish how children are affected how the wish granting process is in fact we tell this whole story and weave it together and All of a sudden, it makes sense. And it made such a massive difference. I was like, I don't know why I haven't been doing this the whole time. It obviously turned out that I didn't know what I was missing.

But it was such a game changer for me. The power of stories was something I hadn't witnessed firsthand until then. Yeah, I agree. I think you need the storytelling element. It's really important.

It fills in the blanks and also brings everything to life. And you can't get everyone in an organization mapping. A lot of it. times to where they're like, we all did this together, like hundreds of us.

It's not likely that's going to happen. So I think that's really important. That's a great realization that you came to how, like how, what things to pair together. to spark interest and energy to change.

Storytelling brings together a few different elements. So it's a form, it can be a form of feedback, it can be a distillation of learning, and it's quite clearly a form of communication. Yeah.

So thinking in terms of practical applications for CTOs, an area that I highlight that is where investment in is having a system a systematic approach to communication so as a leader I found that really useful because it's a way to create opportunities for agency so people tell their stories, just about a town hall or your Slack or your email communications. It's about how all of those work together. Noah or Tiani, do you have other examples of ways communication and storytelling can be interlinked or brought inside?

I was literally just reminded, as you said that, about something that you mentioned when the three of us were first getting together to talk about this, which is the hub and spoke model of communication. and how that then shapes team behaviors. So Daniel, I was wondering if you'd be willing to share your story that you talked about with us.

Yeah. I will share a story. I've worked with quite a number of CTOs where the pattern of communication, where they are the hub and their direct reports or others in the organization, maybe spokes. But what I mean by that is it's predicated on a lot of one-to-one communication.

And so they can be shared in understanding. between those two individuals, but no holistic understanding about how each of those parts fit together. And it's quite common, they might think of each individual as being a part of their function and therefore problems or systems get broken down functionally. And that's where socio-technical problems can start to arise. Right.

I think there is, from a storytelling element, there is that's the case study that I shared. I didn't share that part with you guys when we were talking through this topic together. I worked with this team in an aerospace setting, and they were in the Research and Development Center, and they wanted to build an engine fan blade out of a new material.

They had done some calculations and simulations, the chief scientist on it, and they wanted to get funding to demonstrate that they could. develop this in a new way. So it was one proof that it actually could be done, like the tech side of the problem solving, but then also in this organization can we work in a new way. They had a Gantt chart that went out like two years. This is all we're going to do.

So he was a leader. I was in the CTO office. He wasn't the CTO, but he was over an entire division and trying to continually change how they approach product development. And he said, no, don't present that for funding because that's going to set expectations.

That's how we're going to work, which is how we always work. So he just whiteboarded a session where they had three different experiments. I said, what are you trying to do?

And they said, we're trying to prove we can insert this material into this engine aircraft, this fan blade assembly. I said, OK, how would you test that? They said, we would.

There's a lab over here. We get it manufactured over here and we. bring it into the lab in our facility and just blast it and see, I said, make sure it doesn't crack, fall away, melt, whatever. I said, okay, write that down.

That's test number one. And then test number two, I said, what would that be if that goes well? And it's things are looking pretty good.

Everything we're measuring, it's looking good. So well, then we put a housing on it, like it was on an aircraft when you see it on the tube under the wing and it's like spinning. That's what we test second.

And then I said, okay, then what do you do? What do you, what's left? And they said, we need to do modify this, modify that. refine the blades that would be test number three so that i said write that down and so where you're going to manufacture it here's the team here's what we need and they got funding and then i kicked off working with them they solved this in record time and then it was like blasted to the whole company like everyone on a stage presentations the team was there like a panel getting interviewed then it was like It was blasted to the whole organization as a storytelling hour kind of thing.

And it was like, everyone was excited. And they're like, we have 12 more teams. Let's do this everywhere.

What's the secret? So that was more than explaining all the ins and outs of the product and the results they got. That was great.

But getting everyone together and having that moment of the storytelling actually was pretty powerful and got a lot of interest from there. I think something that story highlights. is the unspoken assumptions that people make about how things have to work and how those often constrain us in ways that we think of as being concrete but are really like flexible or even imaginary and it it reminds me of a story that I was in the UK, I was working with a different bank and we were trying to introduce modern development practices to the bank and the way that they had worked so far was that they had an outsource partner and the rules around engagement with this outsource partner were that everything had to be completely locked down. These people couldn't have phones, they couldn't have like control, they were very strictly monitored.

This is a team in India and everything was locked down to the nth degree because they weren't willing to risk any data being lost. These are the conditions you have to work under and so we wanted obviously a more modern practice where there was more flexibility and they had more control and they had more ability. to engage and make decisions and even show up and bring their phones and use the internet to actually figure out how to solve problems.

And the responses we got back from most people were, it's not going to be possible to do that. This is how this has to work. And so I asked, why does it have to work this way? Because security tells us to. Who in security?

That guy right over there. Have you ever talked to him? No, we can't talk to him because the answer is no. There's no point in having that conversation because we know what's going on. it's going to happen.

And because I was an external consultant and I got to play ignorant all the time, I went and I spoke with him. I said, hey, this is something we're trying to do. How could we make it work? And he said, with the current conditions, you can't make it work, but we should talk to risk because the policies we implement in security are based on the risks that are identified and the organization's appetite for risk. Who in risk should we be talking to?

And so the three... of us like he pointed someone out and the three of us sat down together and we talked through what the goal was and they said let me get this straight you're doing mobile development and your mobile development doesn't require access to any customer data and it doesn't require access to the internal network because you're not doing anything internally it's all external it's all outward customer facing yeah not actually none of the people doing this work are sitting on internal systems which can access customer data no that's And they said, just do it. If you're not on our network, if you're not on the bank's network, there are literally no constraints about what you can do. And that set of conversations resulted in creating a completely new software development.

And like they called it a mobile development center. 500 new people in India were spun up who could use the bathroom whenever they wanted. They could use their phones. They could bring them in.

They could do software development. They had control over their product. ask questions and do things for themselves, which had never been possible before because the assumptions that they had that were just built into the way they thought about literally everything.

Yeah. So that's actually assumptions, I think, are a core part of why socio-technical change is hard is because we don't even, most of the time, we don't even see them. That's true. Just to pick up on one part of that.

So the one I see often talking about that team over there, marketing says we can't do this or security. says we can't do this and so it always feels like a chasm but what you demonstrated was getting specifically who are we talking about because then we can go have a conversation and then that lends that opportunity and then the second part you identified was you've got two goals of the system or two necessary conditions for the organization to succeed one around the safety of the organization the other around the what was going to drive the the business model and it's I'm not sure if this is what Jay means by joint optimization but it triggers the same ideas around asking what would need to be true for both of these things to be true because then that leads you to a different set of options. Excellent.

Continuing down this track, I'm mindful our audience are CTOs. They're probably grappling with some of these. They may have attempted some change and got some surprising side effects. And so we've talked a bit about communication, storytelling and mapping.

But the broader question, how can a CTO approach socio-technical change? What are more things that they can do if we distill this down? I think we've surfaced some of those things throughout the conversation. The one that comes to mind right away when you ask the question is just to learn about the systems and some of these.

ways of thinking and ways of working that are around understanding the system. I think that's really important because it's not something that's really, we don't learn, like where is that taught? And the habits that we have, it's another thing that I've seen in so many different publications and writings and white papers, including the Sociotechnical Systems white paper, where they talk about the mixing like Taylorism.

with some other ways of thinking around work and how that has become pervasive in just a lot of workplaces and those habits are deeply entrenched. It reminds me of what Noah said about the assumptions we might hold about how work actually has to happen, how it works in a little bit more macro level versus like in a specific context. Those assumptions that we hold are often informed by organizations that have that are like more bureaucratic or more hierarchical.

how Western's typology describes like generative, bureaucratic, and like performance and mission centered organizations. So I think starting with that, understanding those kinds of things and digging into those topics is a starting point. Because from there, it opens up, oh, here's what was trying, here's some techniques I can apply, or here's how I get people together, like leadership to work on the system. And another thing, I worked recently with an SVP and his leadership team. A teammate and I were coaching that leadership team and they started to identify when they were working in the system versus on the system.

So they started to recognize when they were just being really tactical versus stepping back and thinking about improving the system and improvement activities that they could do, experiments they can run, initiatives that they can spin up together to improve specific problems. So that could be another thing too, is bringing other leaders together. And having conversations specifically about system improvements.

And for me, I think those are two things that come to mind. There's a bit about understanding oneself and your own, why you might reach for certain options. It's similar to understanding bias and things like that.

The more you're aware of it, the more you might be able to change it. That's something that I actually talk to leaders about quite frequently is like Tiani. saying we have this history of how most of us experience management and leadership as we're coming up through organizations and we inherit a lot of those beliefs like we just we adopt them because the people who are successful or more successful than us do them and therefore we should do them. But it doesn't necessarily work and one of the things that I find really helpful is actually let's sit down and explore how you want to lead like how do you want to show up because for many of us and this includes myself I started long before I understood what drove me I became a manager and I copied what other people did and it yeah lots of it never quite felt right. but I didn't have any idea of what to do differently.

And it wasn't until I was exposed to systems thinking, theory of constraints, and psychology that I started developing a different set of ideas about how organizations could be run and about how I could lead people differently and I could behave differently and that would get different results. And so there's this whole kind of assumptions about we work the way we do because work has to happen that way. But what...

What if it didn't? What if you could do work however you wanted in whatever way worked really well for you? What would that look like? How would you behave? How would you show up?

How would you do things? How would you then shape the system to behave? Yeah, those if you start right back at the beginning and you question the kind of basic, why am I showing up to work? Why do I do this thing? And you get different answers there.

Then all the rest of what you do after that can change much more easily. Yeah. Yeah.

Another thing that we, a teammate and I, and we actually worked on this with Jabe a few years ago, we used some ideas around like patterns, like the kind of pattern language and base patterns. There's an actual, another white paper called Base Patterns of Agility in the Agile Canon. And I like this idea of starting to recognize patterns in an organization, like developing that muscle.

And also kind of what I like when it comes to change and thinking through the problem solving that's evolved with people is using some known good patterns or principles and sort of being fluent with those kinds of things like organizational, sociotechnical, good sociotechnical principles. I actually picked out a few that were from the sociotechnical systems white paper. One of them talked about how the work group was more central than the individual job holder.

So if we think about that, we often over-index to individuals so much so that we then sub-optimize the system because we're optimizing for almost like one task, one individual, what they're doing versus how the system is performing. And this idea of internal regulation of the system by the group, the idea of leaders creating conditions so that the group in the right places can internally regulate and take advantage of information that they have that's readily available. So I like thinking of these kind of ideas in a way to say, do we live into that principle or not? What are we actually doing? So that's a little bit more like a next level down from that learning about systems, learning about oneself, one's biases, like how to be a good leader, starting point.

This research was done in the 40s and 50s in coal mines. And we're still talking about the team as the base unit of value creation, distributed authority, aligned autonomy. We're still trying to figure those things out. And organizations, but that knowledge and know-how is there.

But those patterns will be lived into in different ways in different contexts, but they're still good patterns to ponder. So I think that's a good thing for any leader to have in their toolkit. You're right. It's really out there. in terms of the papers and research.

I found a paper by William Passmore, I think around 2018, and it had a set of principles, which I'll just bring up on the screen. You might have to go out and buy a new monitor. Yeah, I'll put a link to that one in the show notes. I've got a massive monitor, so it's no problem for me.

That's a direct quote from the white paper, from Trist, actually that second principle on teams. You got it covered. So I think...

I think those principles are very findable and a good resource. Yeah. We were getting into some of these sort of silver bullets that people reach for. So there's the change is hard, so let's do one really big change and get it all over and done with.

What other examples have you seen of the silver bullets that people, you know, what can we look out for in ourselves? What might be a behavior where if we're doing it, we might have pause and go, maybe I shouldn't be doing this. There's one I can think of, and it relates back to what Tiani said about complex systems, which is if you think this change is the one that's going to fix everything, you should be holding up your own red flag.

Yeah. Systems are like they're in many ways, they're predictable, but they are still complex. And so you can't be sure that any given intervention is going to say, solve the exact problem that you're having.

That's right. It's very much a... let's do this and see what happens and make adjustments. So if you think you have the answer and it's definitely going to create the change that you think that you need, you're probably wrong.

And that's not a reflection on your knowledge or your capabilities. It's a reflection on how people in large groups work together. That's right.

I think I mentioned before throwing tools into the mix and saying that's a version of saying this will fix everything. They were developing model-based digital. thread. They have these like best in class tools that they could link together to create this. You could do all the design kind of digital twin, like all the analysis and everything and monitor something all the way through production.

But then they realized in our context, we have a lot of older tools and we have a lot of homegrown processes. And so we can't just drop that in because nobody knows how to use it. And it was predicated on this idea of Almost like it's like CICD for cyber physical system. So if you think about CICD or good technical practices that enable continuous integration and deployment, it's a socio-technical problem.

There's a people element and ways of working in collaboration to do it well. So I think that's another gotcha is the tool and not looking at the current context and stepping forward. What can we do now with what we know? Yeah, absolutely. So.

I'm going to attempt to recap. We've covered a lot of ground. We're going to go for a lightning recap. Noah and Tiani, jump in and add some points of anything I missed. So people are working with technology more than ever, and so therefore change involves people and technology.

and addressing one without the other or parts of the system can lead to side effects. The fact that things are interconnected and more interconnected, our biases can lead us to be selecting options. that are not very compatible with socio-technical change.

There are the unchallenged assumptions that are hard to navigate. We mentioned a lot of theories in white papers, so there's a lot of wealth in the comments, but there's mentions of Senge from Dr. J. Bloom, plenty of mentions of Dr. J. himself, Deming, Goldratt, and Theory of Constraints.

I mentioned some work from Stacey Barr. So there's he... for people to read about if they're feeling like they might be facing some of these socio-technical change problems.

What did I miss? We talked a lot about ACOF because it provides a lot of the foundation for some of the stuff that Jave has done and some of the ideal present stuff is based a lot on his work and he's a fascinating guy to read about. Absolutely.

So what can CTOs do next? So we talked about mapping the current situation, mapping the theory of how change is supposed to or is hypothesized to work, being continuous and assessing progress. And that means learning and feedback. And I mentioned about being deliberate about your communication systems, setting up systems that people, everyone can participate in and share stories of what's working, what they're learning, etc.

I think we've done a fairly comprehensive job. So that might bring us to the end of an episode. Where can we find you, Noah? You can find me at noahcanto.com.

If some of the stuff that we've talked about today... has resonated, you want some help figuring out your own assumptions and where you're starting from at a personal level so that you can then see how to shape the system differently, you can book a call with me using the code CTO Lifeline 6, which is the episode we're on now. Excellent. And Tiani, where can we find you?

Yeah, you can find me at proper science.co and you can reach me there. I have a calendar set up so you can put time with me and learn about my case studies that I've worked on. Some of the techniques that I use to help teams solve problems and improve.

Definitely encourage people to do that. There's a lot more depth to this conversation than we had time to get into. Absolutely. And I've been doing group coaching for CTOs based in Australia, and I'm launching group coaching for CTOs based in Australia. in Southeast Asia.

So I've probably mentioned I spent a decade in Kuala Lumpur and so I'm really enjoying reconnecting with a lot of the community there. So you can find out more on that bit.ly link. Now, our next episode is not too far away. It is on the 17th of September, which will be the 16th. So for us in New Zealand, it's 7 a.m.

I believe it's 3 p.m. Eastern Daylight Time and 8 p.m. British Standard Time. So Adam Horner is a CEO coach.

And we thought we'd do something different. And that is have audience. provided questions and challenges and issues. So maybe you've had a socio-technical change that you're struggling with and you want some advice.

So we're calling it three-point perspective. So you'll get perspective from myself, from Noah and from Adam. I'm going to leave you with this thought.

If you're tackling change and people are asking questions, it's very easy to hear those as challenges to your thinking. Suppress that natural response and... And instead, try asking questions that help build your understanding.

With that, thank you very much for your attention and your contributions. And this has been another CTO Lifeline.

Transcript for:-Understanding Challenges in Socio-Technical Change

Transcript for:
-Understanding Challenges in Socio-Technical Change