BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts People Matter Most in Organisational Change

People Matter Most in Organisational Change

Bookmarks

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Simon Powers about why organisational change is hard, putting people first, the need for emergence rather than recipes and his new book Change: A practitioners guide to Enterprise Agile Coaching

Key Takeaways

  • Organisations are complex places and they need to be able to adapt to the changing environment in which they operate
  • People are both the agents of change and the recipients of those changes
  • Leadership challenges are similar across all industries and leaders need to adapt to ever evolving context they find themselves in
  • Organisation design impacts product and code quality
  • Organisation change needs to be adaptive and emergent – there is no single recipe and what works in one part of an organisation will probably not work elsewhere

Transcript

Shane Hastie: Hey folks, QCon London is just around the corner. We'll be back in person in London from March 27 to 29. Join senior software leaders at early adopter companies as they share how they've implemented emerging trends and best practices. You'll learn from their experiences, practical techniques and pitfalls to avoid, so you get assurance you're adopting the right patterns and practices. Learn more at qconlondon.com. We hope to see you there.

Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I'm sitting down across the world, literally 12 hours behind or ahead with Simon Powers. Simon is the Founder and Chief Executive of Adventures with Agile and author of a recently published book, Change. Simon, welcome. Thanks for taking the time to talk to us today.

Simon Powers: Good to see you and hear you, Shane. It's a pleasure to be here. Thank you for having me.

Shane Hastie: Now, you and I know each other pretty well, but for the benefit of our audience, who's Simon?

Introductions [01:09]

Simon Powers: Well, thank you for asking. We have known each other for a good few years. I started my career, it seems very long time ago now, over 20 years ago, and I'm a programmer by trade and went into enterprise architecture and was very frustrated with the organization's ability to deliver some of the amazing things which we were developing and designing. And so, I sort of swapped into, I guess, people design and organizational design to try to make organizations better places so that we can deliver easier, better, and more satisfactory products from that big enterprise space. I guess I've spent the last 8 or 9 years, maybe a bit longer than that, I guess maybe 10, 11 years working with organizations at the leadership scope, hoping to make organizations be able to deliver and be better places to work. I guess I'm an organizational coach as well these days.

Shane Hastie: When we were chatting earlier, the similarities between organizational architecture and software architecture comes up, and of course, Conway's law comes into everything today, but what are your thoughts on that?

Organisation design and software architecture [02:20]

Simon Powers: The ideas around complexity of emergence and combining different elements together and finding that new things emerge, which we didn't think would happen, is something very common in software. The whole agile movement as it were, was to take advantage of this idea that as we build software, as we create even large-scale enterprise software, new patterns emerge, things come about, which we didn't expect at the outset, and we can leverage and take advantage of those so that our software and architecture can be so much better than what we even envisioned in the outset.

Of course, sometimes we come across problems and challenges which slow us down or change direction, especially when we start interacting and sharing things with our customers. And so, that feedback that we get is really, really important information that we can then use in our architecture designs for software and products to iterate and roll forwards so that we can get better and better designs and better products, which are fit for purpose.

Organisations are complex systems [03:21]

The same thing is true with our organizations. Organizations are complex places and what we're doing is we're merging different teams, different skill sets, different ways of working, getting rid of some of these old processes which have enormous amount of delay and handoffs and really stop us as software engineers and architects from actually being in contact with the customers. Organizational design sometimes inhibits our ability to get that feedback to build better software. And so, what we're really looking to do is to optimize that so that the right people are in front of customers are getting the feedback so that we can get that information back and build better software and we don't want the organizational structure to inhibit that process.

There's the parallel. We can do software development in an agile, iterative and emergent way, but we can also change organizations in an agile, iterative and emergent manner, including all of the information which is inside people's heads. That's really what the book is about as well, it's about inclusion of all that knowledge which is stored in all of our heads so we don't get silly decisions made somewhere else.

Shane Hastie: Let's delve into the book. It's called Change. Enterprise coaching. Leading organizations on this journey. Why?

Change is the one constant in the world today [04:34]

Simon Powers: One of the things which and any person working in knowledge work or engineering or in any type of organization where we're building anything from software really to any type of product, there's one constant and that is always change. Probably the biggest constant is change. We are changing the way we see ourselves in the workplace with the new generations coming in. We're seeing the change in products and the technologies that we're using to build the products, the ways that we're using those technologies. I mean, AI now is starting to be used. We're looking at code and the way that code is being written and built. We're looking at change in leadership styles, the way that leaders are creating the spaces for people to emerge their solutions. We're looking at different ways in organizations are seeing themselves in terms of climate change, in terms of the political landscapes that are happening, and of course, huge change in the way that we are working based upon the pandemic and lockdowns and other macro factors which are affecting every single one of us.

And so, how do we make sense of all of this continual turmoil and change that's going on? What can we do to take advantage of that both from a technical standpoint and an organizational design standpoint, so that instead of being thrown about on a stormy sea, we can leverage this and thrive and become better in the face of this change? What key things are there that we need to hold onto and what key things do we need to let go of? This is what the book is about. It's about a heuristic and complex way that includes people first, a people-led approach to making the most of these difficult and sometimes challenging times that we face in because of this relentless and constant change we find ourselves in. It's really a guide to help people to navigate those stormy seas.

Shane Hastie: Drawing I'm sure from lots of experiences working with organizations as I know that you have worked with many different organizations, what are some of the stories that have prompted your writing this book?

Leadership challenges are similar across all industries [06:43]

Simon Powers: As you rightly say, I have worked with a lot of organizations. I've been in a very privileged position to work across many different sectors, everything from public to private, from banking to charity, from local governments to centralized government systems to retail, from hardware, software. It's an enormous range of businesses out there with all sorts of different combinations, but there's one constant across every single one of them, and that is that they all are run by people.

And so, when we look at how people behave, how people interact with each other, the relationships that they have, there's common elements which we can leverage in any industry. And so, the different stories from the different industries have incredible parallels. I'm seeing continually the challenge that leaders have. I see this in banking, I see this in retail, in government, the challenge that leaders have embracing this complex and changing world versus needing predictability and reportability on their progress and their ability or what's the thought of as their competency to lead.

For example, in banking, we are seeing shareholder reporting, regulatory reporting, things that need a certain level of predictability of what's coming up so that people know what to do, what to expect, and yet when they're building the systems, there's an inherent level of unpredictability and complexity. This creates certain leadership behaviors across almost every sector. Some leaders embrace this and create environments where they can thrive and get that information about what's emerging and have this constant short-term reporting to enable emergence to happen.

Other leaders are trying desperately to cling on to some sense of control and predict and control what's happening, which is causing an enormous amount of tension when people are trying to deliver software from asking upfront for incredibly accurate estimates to getting even angry and cross when things are not delivered as was built into a plan several months or even several years ago. And so, I'm still seeing these leadership behaviors or leaders struggling with this concept of constant change. There's a story about leadership here in the book, and I think that everyone in every organization needs to constantly reassess what's happening with leadership.

There are definitely stories around code ownership is something else, which is a big challenge that many organizations face. You mentioned Conway's Law earlier on, how organizations... and it works both ways. Organizations build their architecture around the organizational structure, but then the organizational structure also ends up being built around existing legacy architecture. And so, I see this two-way function, which locks an organization often into poor delivery flow with huge amounts of handoff and delay with many developers, many architects never actually speaking or seeing or hearing from customers and the value they're creating. And so, code ownership is a huge challenge for organizations where developers own a specific piece of code that no one else is allowed to touch because this locks that developer or that team of developers into that piece of code, which is a way of creating a silo, which is a non-customer value producing team, which then automatically creates handoffs and delays.

Organisation design impacts product and code quality [10:21]

This is the reason why I got into the whole organizational design is to look at some of these elements around how do developers work on different pieces of code but still maintain that quality and deep expertise. This is the type of challenge which we're facing in terms of creating the right customer flow and value versus the quality and this sense of identity that developers often form around a specific part of the application or architecture.

I think this concept of identity as well is a key theme in the book. This idea of the narrative, what we tell ourselves, the nature of reality in a way. When we turn up and we say things like, "I am a JavaScript developer," we have taken this concept of being a developer as a form of our identity. What actually needs to happen to create the organizations of tomorrow, and indeed perhaps even the organizations of today, is this concept of I am a software developer, or even better, I am whatever product it is that you are building developer. We are all great problem solvers, but we're problem-solving in too smaller scope often, and this leads to bad handoffs and delays.

If we can problem-solve at the product level and see ourselves at that product level as developers and architects, then this creates a whole new level of collaboration across developers and architects and system designers and UI and UX people, and we end up with a much better collaboration and a much better product and much better ownership of the whole product rather than thinking of ourselves as I'm the search developer, I'm a JavaScript developer. The book talks about this sense of identity and narrative and how that actually changes organizational structure far more effectively than a centralized team reorganization.

And so, these are the themes in the book, really looking deeply into who we are and how we see ourselves as much as the very technical elements of how to do a continuous improvement or integration. It doesn't go into that technical level of that. It looks at how we as the workers are seeing ourselves and can reorganize ourselves to leverage the power of having those tools.

Shane Hastie: The regular listeners will know that this aligns well with my thinking and the value streams and #NoProjects. One of the things that intrigued me on reading the book, well a couple of chapters, one of them about experiments. Aren't experiments scary?

Experiments enable us to learn and adapt [12:49]

Simon Powers: Brilliant question. The nature of experts also is something which is very challenging. There are certain words within the agile space which do either strike fear into the hearts of everyone or they inspire action and movement. Transformation is one of those words. As you rightly say, estimates or projects is also one of those words. Agile itself I think is one of those words. An experiment belongs in this category. What we're really talking about with experiments is the ability to take advantage of emergence. In the complex space, an experiment isn't a repeatable process. We're not looking for repeatability. That happens in a very complicated and predictable environment. For example, science, the world around us, we're looking for predictability, to repeat things again and again so that we can learn about the world and what is.

Experiments in software are not about predictability and having the same thing happen again, but experiments in complexity are about taking advantage of the fact that we don't know exactly how things are going to be. How can we position ourselves in a way to run this experiment or this new change or this new feature and see what emerges knowing that something new is going to happen that perhaps we didn't expect and be ready for that so that we can leverage that power of whatever new is happening quickly and effectively and continue to iterate onto the best value possible. And so, when we phrase it like that, we're actually seeing that this isn't something that may go wrong, we may get something wrong. It's actually just about leveraging emergence. That's at the heart of a complex experiment. How do we leverage emergence?

Shane Hastie: Another thing that intrigued me in that chapter was do not do pilots and trials when experimenting with organizational change. But isn't that the way we do it, we do a pilot program at work and then we repeat it?

Organisation change needs to be adaptive and emergent [14:48]

Simon Powers: Yes, unfortunately. If we think about what a pilot is, it's literally going back to the sense of this experiment being a repeatable exercise. We know with emergence and complexity, things don't repeat, at least not exactly in the same way. Running a trial or a pilot in one area, you're going to get certain results. They may be good, they may not be, we don't know, but you're going to get certain results. If we then do exactly the same thing in a different part of the organization, we'll get wildly different results. The reason for this is quite simply that people are different. The work is different. Knowledge work is different. We don't have the same lean manufacturing ideas of consistency where every single thing that we do is the same as the last widget on the line.

In software and architecture, everything is different. Nothing is done again. And so, we have huge levels of variability both in the products and of course within each human being. And so, every manager runs things differently. Every leader has a different approach. Every relationship is unique. And so, thinking that we can run a pilot and then crank the handle and roll out this agile initiative or this change of way we're doing or DevOps or whatever it is that we're doing, we crank that handle and we're expecting another widget coming out on the line, then we've completely and utterly misunderstood the nature of human beings and complexity and emergence.

And so, what we're really looking to do is run multiple experiments or multiple exercises of change, iterative change with the idea of leveraging what comes out of each of those different change areas, sharing as much information as possible so that we can take that information and try the next iteration just like we would in software development. This is deeply respectful of individual's autonomy and the way that they show up to work. We know developers know what they're doing. We know architects know what they're doing. They don't need to be reorganized so that they can be told how they're going to work together.

What we do need though, is a safe space. We need a place where we can try things and emerge things and see what the right combinations are. And so, really, the idea of a pilot rolling things out across the organization is purely the idea of cost savings. How can we do this once and then roll it out with no changes? It totally works if you'll say putting a patch on a server. You might try on a banker server, see what happens, and then roll it out across the estate. That makes sense. Human beings are not servers. Why would we try to patch a human being with a particular process and then roll it out across all the other human beings? It just doesn't make logical sense to treat human beings like machines. And so, what we actually need are multiple parallel experiments iterating forward with lots of information sharing so that everybody's autonomy is respected at the same time as consistency moving forwards.

Shane Hastie: This is completely counter to the most common rollout of pick your framework and stamp it on top of the organization.

Adopting a single framework and stamping it on an organisation is a recipe for failure [17:54]

Simon Powers: It absolutely is. There's enough data now in the world, and I certainly have enough experience now to see that I'm not going to mention any names, but the big frameworks, I think we know the ones we're talking about, the big frameworks, rolling them out, stamping them on top of organizations simply doesn't work. Many, many organizations are reporting a failed agile transformation, and this is a terrible shame now. In the early days, absolutely, we tried some things, it didn't work as well as we planned. That's human beings working out how to move forwards. To keep trying the same experiment and it keep failing is really unforgivable. The amount of energy and money lost in trying to force people to work in predefined ways is really shocking and negligent I think in today's organizational space. There's absolutely no reason to keep doing the same thing and getting the same poor results.

I hope that this book explains in clear enough detail an alternative that is tangible and practical and where you can go step by step, even if it isn't a circular pattern, you can go step by step with clear objectives moving forwards without having to buy or use some of these big frameworks, which were designed for one company in the past that worked really well for them. The case studies came out absolutely fantastic, and then we're rolling it out, stamping it on top of every other organization as if every organization is a machine and we're seeing the same poor results.

You might get lucky, you roll the dice, your organization may be just about similar and you may get something beneficial out of it, but it's still deeply disrespectful to knowledge workers and problem solvers to think that some centralized group of consultants or managers or coaches are going to come in and know your job better than you do. That's something which I think the respect there needs to improve. Hopefully, this book gives that approach, deep respect for people who, like myself, have come from a technical background, who know how they want to be organized and know how they're going to get things done. This book gives some guidelines, some steps and some approaches to allow that to actually emerge and happen naturally.

Shane Hastie: Another topic that is dear to my heart, and I was happy to see in the book, ethics. What is the exploration of ethics in this change?

Ethics of organisational change [20:20]

Simon Powers: I thought you might pick up on that one, Shane, and you have done some fantastic work in that field, as have I and I think that this is a great topic to bring up. It's something which many software developers have innately inside themselves. We're a quite principled bunch I think from the technical background. We have our principles of quality. Many of us really believe that there are the ways to do things about creating the right products and the right ways of working, the right relationships and all those kind of things. And so, ethics is really an extension of those good principles and practices that we know to be true within ourselves and really sharing that in a wider forum to create what I consider the guardrails and the optimizations for success. We're looking for some guardrails so that we can sleep at night.

If we know that we are within those guardrails, we get a good night's sleep. If we start going over those guardrails, then we start getting worried. And if we're consistently going over these guardrails, if we're consistently challenging what we know to be right, something's going to go wrong. That may be that people leave the organization. It may be that the product hardware, software fails. It may be that we're just doing damage in the world. What we want is organizations where we're not doing damage in the world, where we can sleep at night, where we are building the right thing. Ethics are a great way to codify that good behavior so that we know that we can go about our day-to-day business within the guardrails of decent behavior. I believe that they maximize our chance of success because they allow us to focus on the right things.

What's also interesting about ethics, and it's something which I've put a lot of thought into, is the emergence of ethics. If we are in a constant changing world of emergence and complexity, how can a static list of behaviors fit? Because there are always going to be examples and challenges which no one's faced before, and that we don't have an ethic for. Not only do we need to have a set of background, codified, sort of static list ethics, we also need to have a framework for being able to build sensible ethics rapidly and iteratively for the new challenges that we face that we haven't come across.

And so, in the book, it's discussed not only what ethics are and why we should have them, but a way of actually emerging ethics in a sensible way for any given moment or challenge that we're facing at that time. I think that that's going to be a very big developing field for all of us in terms of emergence of ethics rather than people getting together, creating a list, and then people adhering to that list, which is really the common way at the moment. Yes, there's a lot to this and I think that in the end, it's going to make us all a lot better off and we're going to be able to deliver a lot better in our organizations.

Shane Hastie: You end the book with a chapter on what the future holds with a number of predictions. Can we explore some of those points?

Simon Powers: Yeah, absolutely. This was my fun chapter. I really had fun with this and, of course, I caveat it with, as Lenon Cohen says, I don't have a secret chart to get to the heart of this or any other matter. Really, he or she who controls the narrative, controls our destiny. It is a great warning of caution in this chapter about handing over the privilege of those who create the narratives around us. The stories which define our reality and those who create the mainstream narrative are those who have the privilege. And so, all around us, we see privilege everywhere and we see those who are marginalized, those who are cut out, those who don't have a voice. This is how that happens by somebody somewhere creating a narrative. This chapter is a cautionary tale in some ways at the beginning anyway, at least, about handing me the narrative for the future.

It's a bit tongue in cheek in some ways because the book is really about creating a shared narrative about creating equality and equity by really building spaces where everybody is a part of that narrative and has that equal voice enabling a narrative to move forwards with all of us to flatten the playing field. Any predictions that I have are given with this warning about taking anybody else's narrative.

Predictions for the future [24:37]

Having said that, again, within this framework of fun, I would say, about predicting the future, one of the things that I do believe is that the things that we have learned inside of organizations, the very concept of balancing out the playing field, leveling the playing field, and taking this idea of emergence outside of our organizations into the social world, into politics, into healthcare, into education, into foreign policy, and really tackling some of the large problems that we have in the world from terrorism to pandemics to climate change, and using the things that we've learned that we've proven at the small level, and how do we then take that and make that work at a societal level, which is a huge step-up.

Imagine, we are just about coping with several thousand people working together in an organization and even large organizations of 100,000 or more, it's a drop in the ocean when we come to the tens or hundreds of millions of people in any country or even billions on the planet. How does nature scale?

One of the predictions in the last chapter is looking at using fractal geometry, fractal patterns of simple repeating rules that can then be scaled up to the multiple millions of how society could perhaps leverage some of these safe spaces to really explore how we're feeling and level some of these marginalized views so that we can really leverage the power of everybody to solve some of these larger scale problems. Yes, this is absolutely theory at the moment, but it is extrapolating out of a fractal pattern, which we've proved the first few scales of that pattern. That's one of them. And Or the others, I guess, you'd have to get the book. Unless there's a specific thing that you would like to ask about, Shane, of course.

Shane Hastie: Diction three, we will become more diverse and tolerant.

Simon Powers: I'm really glad you asked about that because when we read the news, especially say for example with American politics, you're seeing it in Europe as well, there seems to always be this move to conflict. When you look at the Ukraine situation, sometimes we worry about what's happening in many parts of the world in Taiwan and China and the US getting involved. Then we look at things like the challenge with the abortion laws in the US and the different opinions there. We are seeing challenge and problems everywhere.

One may mistake this for us falling apart or that we're getting more angry or more divisive in our nature, but actually, what I think is happening is that the nature of the dialogues, the very nature of conversations, the way that we are exploring these problems is no longer fit for purpose. And so, this looks like we disagree. Disagreement can be healthy, disagreement about the way we run our countries from China to the US can be healthy. China has some amazing things with the way they run their culture and they have some terrible things, exactly the same as the US, the UK, New Zealand, or anywhere else. Wouldn't it be amazing if we could somehow have a dialogue where we leverage the best of what we all have to offer? This is what's lacking, not difference of opinion and divisiveness, but our ability to navigate those changes and come out on top.

That's really what the book is about at a bit of a smaller scale than the country level, but it's about finding new ways to leverage that difference, and then we can accept difference, not only accept it or tolerate it, but leverage it and all benefit by it. What new truth is about to emerge from that conflict? If we can get to that point, then we'll embrace diversity and difference rather than fear it. That's really the message here. Don't worry about divisiveness, let's look for a way to have the conversation.

Shane Hastie: Simon, I've certainly enjoyed our conversation. If our listeners want to continue this conversation, where do they find you?

Simon Powers :I'm on LinkedIn. That's always a good place to find me. Simon Powers, it's Si Powers, S-I Powers is the thing on LinkedIn. That's probably the easiest place to find me. Of course, you can email me as well, simon@adventureswithagile.com. I guess through the website or LinkedIn, that's probably the best way.

Shane Hastie: Wonderful. Thank you so much.

Simon Powers: Brilliant. Thank you, Shane. It's been an absolute pleasure. Really good to have this conversation with you. Thank you.

Mentioned:

About the Author

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT