What are the simple principles for making systems? Let's start off and say that a lot of people struggle with the idea of systems, they have been told that they are the solution, the key to having their business run without them to run profitably, to allow their team to do consistent work.
And yet, often people really struggle with the mechanics, the principles of how to think about a system, how to build systems.
So I want to cover that because when you get there, suddenly, your ability to help your team actually get systems that work, work for them, work for your business.
And that is going to allow you to approach your business in a very different way, instead of having to do everything, the first time as you work out what to do, and your team problem solves how to get stuff done.
Instead, you start leveraging the solutions that you've already created.
Systems at some level represent this, all of the problem solving that's been done in past, but most businesses just allow this problem solving to fall by the wayside.
It's not documented, it's not written down.
And that makes it very hard to analyze and approve.
So each day, they come in and say, sell solve the same problems over and over.
But people being people do it slightly different each time.
And so the results of that work become slightly different each time.
Now, this may not be a problem.
But it also can cause significant problems, which means you as the business owner are dealing with fires, or dealing with teams that are unhappy, that the productivity that you get out of your teams is very low, or coming down to a significant loss of profit.
And that's why your business actually insists it's not to do anything.
Unfortunately, other than to bring you a profit.
This is the purpose of a business.
So let's have a look at what are these principles? When I'm thinking through systems, the first thing that I want to know is what are the results that I'm after this is critical.
Like if you are trying to build a system without a target, then you will struggle.
And that target to aim for is the results that the system produces.
Now those results may be tangible.
It might be a physical item, it might be a completed document, or it might be intangible.
So for instance, the money has been paid to your team, that would be an intangible result.
But you can see that the work got done.
But that result is your first requirement for what you must know when you are building a system.
Once you've got that now, you have the ability to assess whether your system works without defining first what that result is that the system is meant to be doing.
You will not know whether it works or not, you'll be like, Ah, I got this result, it's pretty good.
But is it the result that the system was meant to do? If it is great, you've got a system that works.
If it is not, then you've got problems somewhere in your system.
Now having the results done, leaves you with the second principle of building a system.
And that is there is some kind of work, there's some kind of steps, there's something that has to be done in order to create those results.
This is typically located in your head and your team said and not documented, but nonetheless, exists already.
It just has to be written down.
And do not be too concerned about the level of detail.
Often when people are approaching the system, they'll oh my goodness, I've got to write that in your every fine manushi That might happen over the long term when you know that your system works.
And that it is very useful for someone who's never run that system before but your team who are already doing this work will not be delighted by having every right click and every single step document and what they need instead is just the big headings.
And so if you structured the work in terms of both big headings and detail, this allows your new staff to work through step by step by step detail by detail by detail and those who are experienced to just use the headings and just use them as reminders go.
Yep, did that you did that.
If you happen to require a high level of compliance to check that everything got done then you will need to move from a Word document or a Google document through to some kind of standard operating procedure software.
This will allow your team to track the steps that they did the work that they did and you can check and say, Hey, did you do the work? And they're like, Yeah, I did the work.
And then you can look and say, well, the result that this was meant to give the result that we know, doing this work it was wasn't created, what's going on? And they might go back.
No, I actually, you know what, I skipped that step.
And therefore, you can help them say, Okay, this is important.
If we don't do that one step, then we end up with a very different result.
Now, some systems have a lot of flexibility, you can do steps in different orders, you can do steps, not in a specified order at all.
And you'll still get the same result some systems are not, some systems must be done in specific orders with specific timeframes in order to create those results.
And that needs to be written down for the more specific instructions, that's got to be documented to say, hey, this has to be done within 10 minutes, just like a recipe for a chocolate cake.
Or if you're trying to build a Heston Blumenthal cake, then you're probably going to have to be very specific in following the instructions.
If you are to get the same product that He gets, if you are not, you will not get it.
If you're building a simple chocolate cake out of a recipe book that's relatively simple.
Hey, you know, if you put the milk in first or the eggs in first, it's not really going to matter, you're going to come out with a very similar result.
So you need to be aware of this.
Some systems need to be documented very carefully, some do not.
But the overall principle that I want you to grasp is that the results are coming from work that is done and your processes are the documentation of that work.
And finally, the system itself, what
is a system? Well, a system is nothing more than the completion of those processes that leads to those specific results, that processes are part of a system that the results are part of the system, and that those two combined together, make up the system.
This stuff is challenging.
But if you get the principles that the fundamental thing to focus on when you're documenting your systems is, first of all, what results is the system meant to do? Secondly, Hey, what are the instructions or the processes that are going to give those results? And number three, how do you document that so that your team can actually use them and get the work done using those systems if you want some help with that.
If you'd like to know how to build consistent systems that your team can use, then head over to systemio.dev, where we help businesses build systems that a team loves to use.
Thanks for joining me today.
I look forward to seeing our next episodes.
We continue this journey into the power system scraped results.
See you then.
