How do we manage change? Assessing urgency and what does it mean when no-one is owning a (technical) systems problem? I talk about this common problem with projects and systems and how we can resolve it, touching on Incident Management and Product Ownership.

Secondly, I spend a few minutes talking about the book “Thinking in Systems: A Primer”. This is a classic text which describes in simple terms how interactions between systems can get so complicated. Great for those who've not thought about systems interactions before and need a basis for understanding how complexity can appear very quickly.

NOTES

Brief review of "Thinking In Systems: A Primer":

https://kislayverma.com/books/book-review-thinking-in-systems-a-primer/

Resources for understanding Change Management (ITIL) and Product Ownership (Scrum)

Change Management and the IT Infrastructure Library (ITIL):

https://en.wikipedia.org/wiki/ITIL

IT Service Management:

https://en.wikipedia.org/wiki/IT_service_management

and within that, IT Incident Managment:

https://en.wikipedia.org/wiki/Incident_management_(ITSM)

What is a Product Owner?

https://www.scrum.org/resources/what-is-a-product-owner

QUOTES

"Now, when I speak to those who tell me that they have a ‘systems problem’ it’s like they’ve almost self-diagnosed. They know that they have a problem but they also seem to be able to tell me almost how I can help them fix it for them. " [RB]

"Don't assume that a change to any system will fix a given problem without causing another problem, too. Don't assume that things work like they say they're going to work" [RB]

"Incident Management is a process whereby you can get your systems back on track with respect to a situation with any given system" [RB]

"the very act of fixing systems in itself requires a system and a process" [RB]

SUMMARY KEYWORDS

systems, problem, severity, fix, richard, book, automation, primer, incident management, technology, organisation, incident, resolve, customers, subjects, impact, business, change, complex, process

Richard Bown 0:00

Welcome to automation for the nation. I'm your host Richard Bown. Now, this podcast has been missing a tagline. And this morning I woke up early with it in my head. So let me introduce myself again. Welcome to automation for the nation, from Agile to bpm, CRM to DevOps. How automation and systems enable better products and businesses. A successful business is more than just people process and technology. Understanding the human element of our business systems helps us achieve more through knowing what's slowing us down, and what's holding us back. In automation for the nation, we discuss systems, processes, techniques, strategy and ideas. With technology and business leaders, we look as a way of working that is enabled and enhanced by use of technology and automation, but not dominated by it. Touching on subjects such as agile and DevOps Systems Thinking systems mapping, digital language, how projects get difficult organisational culture, and the impact of systems and change. And also occasionally, of course, the technology itself. This time, I'm talking about two subjects. First of all, I will talk about a common problem with projects and systems and how to resolve it. Secondly, I'm going to spend a few minutes talking about the book, Thinking in systems a primer. This is something of a classic text, which describes in simple terms, how interactions between systems can get so complicated. Before I do that, though, I want to talk about systems problems, to frame the book and our learnings a little. Now, when I speak to those who tell me that they have a systems problem, it's like they've almost self diagnosed, they know that they have a problem. But they also seem to be able to tell me almost how I can help them fix it for them. This is encouraging in some ways, but also strikes me as a little odd. If you know that you have a problem, and you know how to fix it, then why don't you just do it? Why am I in that conversation? My guess is the real problem that they're asking me is this. We have a problem. But we as a team can't agree on a solution. Or we can't convince someone else there is a problem. Can you help us move forward? This is much more common. There is a lack of accountability. The team doesn't want to take responsibility or make a change. Perhaps there is no one who is responsible or accountable for the system. Perhaps there is a lack of agreement in how to fix the problem. Or perhaps there's a lack of agreement that that even is a problem. No one wants to make the call. And also no one agrees on the solution, or even if there is a problem in the first place. So what's going on? Decisions are easy enough. Living with the repercussions of decisions is way more difficult. But if there's no one responsible in the first place, and how do decisions get made. So what would you do? How would you want to take the situation and make everyone happy again, before we get to that, I'd like to turn to the subject of the book Thinking in systems by Donella Meadows. This book is called a primer. And indeed, it really only covers a few topics, which however, are key to understanding how complex things are truly complex. If like me, you've studied physics or engineering, then none of this will be a surprise to you. However, if you haven't studied physics or engineering, then it may be worth checking out this book, just to get a few key concepts in your head. It might help you with working with systems. physical systems are complex period. What is fascinating is how human systems also act like physical systems sometimes. And that's what this book really kind of explores in some detail. I won't go into the detail of the book here. But in the shownotes. I'll link a detailed review, which provides an excellent summary. What I find interesting is applying what we can learn from thinking in systems the book to the systems we see in our businesses. So what are the key takeaways from thinking in systems a primer? For me, it's these one. Don't assume that a change to any system will fix a given problem without causing another problem,

too. Don't assume that things work like they say they're going to work. Ie don't trust software salesman. Three. Don't underestimate any system or projects you take on fall. Don't forget to remove redundant systems as soon as they've stopped being useful. Bearing in mind point one above, even removing a system will have an impact on the rest. These are truths that good project managers, good software engineers, developers and system administrators alike deal with every day. A change will cause something to break. These are the facts of life. If something goes right first time, look for the evidence that shows that it's secretly failed. It may sound a little bit pessimistic to say this however, this is 25 years plus of professional software you Software Development speaking for you. What Donella Meadows book will show you, however, is why this happens. In brief, the book is laid out in four sections. It starts with some definitions of functions, stocks purposes and flows. Part one is around system structure and behaviour. There's a good one on page 16. Here's a quote, you can understand the relative importance of a systems elements interconnections and purposes by imagining them changed one by one. Part two, is a brief visit to the system Zoo. These are collections and patterns of systems that you might say. Part three is why systems work so well. And there's a great quote on page 76. In the edition that I have, which I will pull out and put into the show notes. In chapter three, we also have some properties of complex systems, resilience, self organisation, and hierarchy. And in chapter four, part four, why systems surprise us? Finally, there's some advice on how to work with systems effectively. And it does get a bit woowoo. At this point, there are things like, get the beat of the system, mental flexibility, honour, respect and distribute information. It finishes with some generic advice, which to be honest, I don't find it a whole lot of help. However, if you've learned of the complexity of systems, and that's the only thing you take away from this book, then it's done. Its job systems are complex, get used to it. So going back to our earlier example, we have a stalemate in our company. Some people think a system should change because there's a problem. Some people don't see a problem. Some are against the change, some don't care, no one seemingly is in charge. How can we make this a more pleasant experience for everyone? How can we resolve this situation? Moreover, how can we get a solution that everyone thinks is acceptable? Firstly, we have to characterise the problem the system is exhibiting is it crucial? Is it a large failure? Or could it cause us to have a large failure in the future? How many people will this problem affect? How much will it cost us? If we don't repair it? How much will it cost us? If we do repair it? How much reputational damage could it do to us or our customers? And finally, how urgent is it that we do something about this. And suddenly, we're in a world of incident management. When software companies have a problem, or it two departments experience an outage, there are at least there should be procedures in place to ensure that the situation gets resolved in a repeatable and controlled manner. Alongside this, there should be appropriate communication with all the relevant parties who are affected and involved. This could involve customers, but it will always involve members of staff. Incident Management is a process whereby you can get your systems back on track with respect to a situation with any given system. However, it's also a great way to start structuring your thinking around the severity of any problem when it comes to systems. So first of all, you can triage any problem into buckets. Typically, there are severity levels, which can help work out the urgency. For example, borrowing from Atlassian website, there are the following definitions severity one, a critical incident with very high impact. For example, a customer facing service confidentiality or privacy is breached. Customer Data Loss severity two could be a major incident with significant impact. For example, a customer facing service is available to some customers, all core functionality is impacted. Severity three, a minor incident with low impact, a minor inconvenience to customers with a workaround available, or some performance degradation, which is non critical. If your problem doesn't fall into any of these three categories, then it's likely not an incident. So you do not have to fix it urgently. However, how can we ensure that it's still owned and fixed?

Simple answer is there needs to be an owner in the organisation, someone who's responsible for taking care of a problem that has agreed to be a problem. Therefore, you can make an owner both, for instance, an incident manager and someone who is owning less pressing issues, say an IT manager or product owner in your organisation, then allow them to own and drive issues forward. It could even be the same person, you could have someone who's the incident manager, who's also the product owner or IT manager and they will own issues both for incidents with a high priority and need to be fixed straightaway. And also for longer term things that need to be fixed maybe with a vendor or with a developer. So what you see is the very act of fixing systems in itself requires a system and a process. Therefore, we see the complexity of systems both human and technological nesting inside and next to each other in your business. So to summarise, find an owner for whatever problem that you have, find someone Who's gonna own it. And if you can't get anyone to own it, then talk to the boss. Incident Management, product ownership, two sides of the same coin. Ensure that you get a loaner for all your systems. And then there's a way that you can escalate stuff, then there's a way that you can get stuff fixed. Still not feeling confident that you can make this work. Well, then just feel free to reach out to me, and I'll be happy to point you in the right direction. You can reach me at Richard W Bown on Twitter. That's Bown. Or at richardwbown.com. Or one word richardw bown.com. Or you can email me, me@richardwbown.com. Until next time, on automation for the nation, from Agile to bpm, CRM to DevOps. How automation and systems enable better products and businesses. This is Richard Bown, saying Goodbye and good luck.