EPISODE SUMMARY
I look at the organisation and its impact on your systems – remember that systems are not just what you build or have built for you, it’s also the people. Conway’s Law and continuous learning can help us make sense of digital transformation.
EPISODE NOTES
Understand that your business needs are met not as a whole, but by individuals and departments. Those individuals and departments shape the systems they use – they create them all the time. Your IT systems and your IT systems change process had better recognise this.
QUOTES
I quote Melvin Conway: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
“the most important thing you can do before taking on a new software or IT project as an organisation is to zoom out” RB
Transcript
SUMMARY KEYWORDS
systems, work, organisation, project, conway, contractor, understand, structure, software, zoom, written, build, provide, consultant, consultancy, february, ensure, support, transformational change, design
Hello, and welcome to automation for the nation. My name is Richard Bell. This is episode three, and I've set up it's zooming out. Back in January, I came up with an idea. I wrote 30,000 words, and I started this podcast. And there's been a bit of a gap between writing it and recording anything else. February, March, I spent working in my business with two clients getting my consultancy off the ground in concept and as much as action, and it was all action. So during this month, I've come back to the words I've written in January. And the recordings I've made in the end of January, early February, I've reassessed them, and I've edited them a bit, and I'm finally kind of releasing them. My purpose has become slightly more focused in the last six weeks, and there is a structure starting to appear, which I hope will become obvious soon. With this episode, then I want to zoom out a bit further. In the first episode, I talked about automation. And the second one a bit more about systems taking a step back from automation and understanding how systems can enable that. And then I want to understand further context for the systems with this episode. So zooming out even further than why we have systems in the first place. And in fact, what they are. So my background is in it and billing systems software development. And I've worked with a lot of large companies over 25 years mainly as an external contractor or consultant. And the difference between those two I think is good to discuss quickly, a consultant will provide their consultancy advisory a lot of the time and just advise the company how things should go forward, the contractor is more hands on, and they will do the work. Just like when you build a house, you may hire a contractor to create the building for you. But you'd hire a consultant in the form of an architect to provide the design and get some advice. You might get some advice from the contractor to but that's not the main reason they're there. They're there to build the stuff. And for many years I was there to to build the stuff, I would work with a user of a system we would decide together what needs to be built. And I would work out how that would be built. And then I would go and build it or like come back to them for more information. And we'd have an iterative way of working perhaps. But systems particularly since the advent of ubiquitous internet don't live in a vacuum. They have connections, they are networked. So when we start to think of our systems as having a life of their own, contributed to by everyone who interacts with them, everyone who created them, we get closer to an understanding of something that's important to the way I understand how systems work. And that is Conway's Law. Conway's Law states. Any organisation that designs a system brackets defined broadly will produce a design whose structure is a copy of the organization's communication structure. This was written by Melvin Conway in 1967. As part of a I think it was a doctoral thesis he was doing at the time. And he was in study as a software engineer. And Conway's Law is important because it really helps us understand what systems we have in our business and how they got to the state they're in currently. Perhaps an example can explain this a little more clearly, an organisation will draw the world as it sees it from its own perspective. Likewise, any functional department within that organisation will also draw the world as it sees it from from its own perspective. Like those ideas, those drawings are built into software systems that can help individuals or departments with their jobs. So for example, a finance department will only see their world of finance, and they want their systems to work with them in something that means something for their jobs, the quarter end or year end process, that's their world. That's their perspective, their systems want to support those perspectives, the way they work, ultimately will have to work with each other because like an organisation systems don't work in isolation, they have to work together. So an organisation will draw the world as it sees it from its own perspective. And likewise, any functional department in an organisation will also draw the world as it sees it, those ideas built into the software systems. And inevitably, you will end up with a set of IT and software systems which mimic the way the organisation works at a human level. This seems logical and simple enough, but the implications are profound. Because when you implement a new system, or a new project, usually at great expense, you're doing it to improve your way of working and not to reinforce what you were doing before, very unlikely that you're making a change to a system because you're happy with how things are or you see a risk in the way things currently work. Therefore, the most important thing you can do before taking on a new software or IT project as an organisation is to zoom out and understand why you're doing the things the way you do things. It doesn't need to stay that way. Are you just building your current way of working into the new system? If so, what value does that bring? So as an organisation, you should ask yourself, why are we doing this without going through this process, you are pretty much doomed to re implement exactly what you have already.
This year, I've been feeling a lot of emotions through connecting to certain projects. And these are the only true measures of success, I would say of your system or IT projects if users can achieve But they want to achieve with less effort than they would normally put through a manual process, then you've got something that works as a system. That's great. As I said, in the last episode, the system, whether it be an IT system or paper system, a manual system is inherently always a human system. It has been created by some developers or person or persons, then it's up to the operators, people who use the system to make sense of it and start working with it. Usually systems don't get used as intended by the developers. However, the workarounds that the users put in become part of the way it works going forward. That is now the system. Thinking about this in the context of what I rent to date, in combination with the real world experiences I've seen around me, and some of my most recent experiences, has underlined my belief in two fundamental principles which define the relationship of humans and their software IT systems. Firstly, that Conway's law applies in all circumstances. And secondly, in our increasingly automated and systematised world, the most effective way a user or system can feel comfortable, truly comfortable with the system is to develop their own strategies to survive and prosper with that system. Understanding a little bit more about what Conway's Law has to do with IT systems change. It's very rare for an organisation to really design a system for optimal usefulness or utility. In a company. Good enough is good enough, imperfect is good enough. And we don't go into a typical transformation project and accompany with the idea that we're going to redesign the way we work. As we are familiar with projects, or run a project to replace the websites, or run a project to implement a new CRM or a data warehouse or people management system. These are projects and they fit into our mental model of how a piece of work should look. However, projects essentially changes to it landscape, never run in a vacuum. They run with people in your organisation, they connect to other systems, they potentially replace other systems. So when you consider a project, consider not just the business value, which deliver but also the impact it has on your existing systems. To support that, it's vital to ensure that your team has the tools to work with transformational change. So some strategies for working in 21st century can include digital language, understanding the technology that's been deployed, how to talk about organisational culture and how to be involved in a project. A good project manager will ensure that the right people are at the table, but they are not responsible for the level of comfort these people have with what has been discussed, neither should they be the employer should support those people and enable them to interact effectively in a project structure and to understand what their contribution should be. These two aspects of transformational change it projects provide the key to democratising systems change, and ensuring that you get more value out of your IT spend. So the next time you're considering it or systems project, just stop for a moment and consider what this means to your systems as well as what it means to your staff. How can you make sure that everyone is on the same page and you get the most value out of this change? And this is what I'll be pursuing in the next episode of automation for the nation. This is Richard Bown, wishing you Goodbye and good luck.