In the last episode we jumped straight into automations and how they can sometimes make our life more difficult. This time we take a look at systems – all types of systems – and understand the human element that made them.
Since January 2022 I’ve been thinking long and hard about automation – but it was clear that automation was just a piece of what was making me think. Systems provide opportunities for automation but they can be manual or they can already be ‘automatic’ or built in IT. So how do we work with systems and understand those which already exist in our business?
” if you’re troubleshooting an issue, the best way to understand is to change something, note down the difference” RB
“This applies across the board, whether we’re multinational small company, an individual who’s looking at their Etsy shop or looking at their WordPress installation and saying, Okay, what can I do to make this better?” RB
“They all have been put together by somebody sitting down and thinking about it, writing down an idea and maybe sharing it with a colleague or a friend” RB
“Learn to understand and explore the systems that have been created for you, they are imperfect, they were created after all by humans, so don’t expect them to work the whole time“ RB
Sun, 3/27 4:48PM • 5:59
system, work, automation, idea, pieces, applying, built, salesforce, electronics, catalogue, troubleshooting, change, business, fix, implemented, episode, successful business person, week, few iterations, recycled
I'm Richard Bown. And this is automation for the nation. Last week was the first episode of this podcast, January has been very much a month about discovery. As you might have heard in the first episode, finding my way, in this new world where I've decided to become a consultant in a new sphere. So the name automation for the nation came about because I've been looking for a theme for my mission, which I can pursue through the content I create. Early on, I came up with the idea that this could be automation. Now it's moving a little bit more towards systems. And it's interesting, the more you think about it, the more ideas that you get about what are my core skills that I can bring to help people? So last week, I touched on a couple of subjects, but mainly it was around brittle systems, systems, which are made rigid, made difficult to change, are you applying extra layers of automation around them? And why is this a bad thing? Well, you get to a point with a system where you've implemented so many things around it, that when you make a change, or someone external makes a change to that system, for example, a provider of a system, then it can cause the automations to fail, it can cause the whole thing to either fail, or worse still, it can fail in an unpredictable way. This week, I'd like to change it up and say, well, rather than thinking about applying automation, why don't we think before we even apply system or even think about applying a system? This is probably closer to the mission that I have in mind. So it's taking things a step forward, perhaps for me. So why should we not think about implementing a system? Sometimes, we tend to jump to solution. It's a very human trait. Perhaps it's driven through the inputs that we see around us. We see other businesses running successfully with Salesforce, for example, Wordpress, who knows? And we say, well, okay, in order for me to be a successful business person to I need to Salesforce, we see the systems which support a business as somehow integral to the business itself, as if the business couldn't survive without the system. And in some cases, that can be true. But a lot of the times, there are choices. So in this episode, I want to take a step back and think about how we think about putting systems together to help our businesses. Growing up, I was what you might call an instinctive techie, I just looked at stuff, I tried to figure it out from the outside and well as a child, what you do is you usually break it to find out what's going on inside. So I did that alive to take things apart, because I was interested in how things worked, and how and then if they work, still, when I put them back together again. And in the 80s, you could look at a piece of electronics, you could get a circuit board out of their system or Music Centre. And without any real training or manual, work out a little bit of what the pieces did, even though you didn't know what they were. And of course, it wasn't the internet, there wasn't an easy way to teach yourself or the local libraries in the town that I grew up in, they didn't have any of these kind of books. So you'd have to get a catalogue. It was the Maplin catalogue, or the RS catalogue. And then you could browse that for maybe information on what components were and what they meant. But it was a difficult process to get to a point where you kind of make sense of the thing that you've taken apart, and maybe trying to fix, be able to fix stuff, the idea that something can be recycled, can be used again and can find another life or repurpose it into something else.
Sometimes when I take something apart, I couldn't really work out what needs to change. One thing you can do, and this is something that I've done a lot in my programming career is just take something out that you can understand a lot by swapping pieces out, maybe removing pieces, trying things around the other way, and just seeing what happens. But it's interesting for me to see how these things would behave under certain circumstances. And I saw this essentially, as part of my education. Sure, I did a lot of stuff in school around woodwork, and metalwork and electronics a little bit as well. But for the majority of the time I spent teaching myself how these things work. So this is a technique which I still use to this day, I will still work in a similar way with software systems, it doesn't matter if you're building them, plugging them together. Or if you're troubleshooting an issue, the best way to understand is to change something, note down the difference. It says taking a bit of scientific method to troubleshooting or debugging an issue. What's the point then of this little discussion, it's about how we think about our systems and how they're put together in the first place. Because when I'm looking at a system on what aspects of it could be that I'm working in my car, and I can't work out why the windscreen wipers at the back aren't working properly. I'm thinking about how these systems were put together in the first place. They all have been put together by somebody sitting down and thinking about it, writing down an idea and maybe sharing it with a colleague or a friend and then refining that idea and before it's built before the car is built. The system in the car is built before the system in our business is built. You'll go through a few iterations of making sure that it's the thing that we need We're not just building something because we think it's a great idea. And this is the first design. There's thought thought behind everything. And we should apply the same thought to our businesses when we're picking a system, either off the shelf, or having it built for us, or when we're having our systems integrated by a team or a project. This applies across the board, whether we're multinational small company, an individual who's looking at their Etsy shop or looking at their WordPress installation and saying, Okay, what can I do to make this better? Well, because we've seen it there, and it looks pretty cool. It doesn't necessarily mean it's going to fix our problems. Do we believe that these systems can fix our problems? Is that the question I should be asking? You have to build your system in a way that it's not so much of a problem. And ideally, you test it all out and before you even go live with it. You do tend to think that these things should just work out the box. However, they're not going to you have to put the hours and you've got to put the work in.
So to summarise, be more scientist. Learn to understand and explore the systems that have been created for you, they are imperfect, they were created after all by humans, so don’t expect them to work the whole time. Expect failure and be prepared for success. Until next time, this is Richard Bown saying goodbye and good luck.