Why is a systems lag time important?

Why is a systems lag time important? Let's start off by talking about well, what is the system's lag time.

And what I mean by this is how long does it take for you to get the results of that system.

So a system's got some inputs, it's got some kind of raw materials, or whether that's ideas or literal physical raw materials, but they go in a bunch of stuff happens to it, and outcomes a result.

And the system lag time essentially refers to how long does it take to go from the beginning of the system through to getting that result, many systems will be fast, there'll be very quick, it might be measured in minutes or hours.

But some big systems, some complex systems may have months or years before you see the actual results.

This is important because it means that any changes that you make to how the system is done, may not show up for a long time that if a system has a lag time of 10 minutes, I can make a change and 10 minutes later, I will know whether that change had an impact on the results.

But if that system has a three-month lag time, and I make a change, I won't know whether that change had an effect for three months.

This is a problem.

If you're trying to work out or troubleshoot a system that's not working so well, you actually have to document very carefully the change that we've made to that particular run of the system and ensure that no other changes are made to that system.

Otherwise, you'll have confounding factors, if you do want to speed up the testing process.

So let's say that you're unhappy with making one change every three months.

And instead, you wanted to make multiple changes during that timeframe and then get the results over a period of time, then you're going to need to track those separately separated systems very carefully.

And only one change gets made each time you got to document which work had the one change and what the result was for each of those times.

Let's say that system runs every two weeks.

But it takes three months to get the results through, you need to be on point because if you don't track that stuff, you will be confused.

At the end of that time of what did what changes were made, what outcomes were made.

Another way to do this, instead of trying to run concurrent experiments is that you run multiple systems at once have variations of that same system.

So one system has changed, another system has a different change.

A third system has a third change.

But they're all essentially the same system just with three different changes, you could then run this and three months later, you will have three separate results.

And this is logistically kid may be quite a bit easier.

Because it's relatively clean.

He's a system, one would change one He system with change to his system, which changed three and he's the outcomes that three months you can look at them and make changes from there, the downside will you need to have the capacity to run three variants of that same system at the same time, this might be physically very difficult if we're talking about a large production line actually duplicating or in this case, trip locating if that's the right word.

I know if it's the right word, triplicate, making the system in triplicate could be very expensive if you're talking about large, complex systems.

So more likely, you're going to be dealing with the first variable or the first way of doing the testing, which is you set a test and you track it for three months, but you then make an additional change in the system and then track those results.

So every two weeks, there's a different one coming through.

If you want to do this, my suggestion is that you make the changes for the first one late in the system, and then bring it back.

You see if you make the change early in the system, it's going to be very hard, you got to then move that one back to make a different one.

But you need to plan this out.

There is no doubt that this is something that should not be done in your head.

If you don't write this stuff down.

If you don't document the changes, document the testing, then you will lose track of it and the entire experiment will be lost and you will be unable to tell what changes were made and what results they gave because the system has such a long lag time.

The other trap that I want to bring your awareness to is that systems with a long lag time can give you the illusion, that work that's not done, or failures in the system do not have any consequences.

You see on that three-month system, let's say that, for whatever reason, you don't realize that but work stops two weeks in.

But you don't see the consequences of that for 10 weeks later.

And so for 10 weeks, you're thinking, everything is fine, the whole system appears to be working.

But suddenly, at 10 weeks, the system fails.

And this was obvious, it just was not noticed.

If you had the ability to look, you'd be like, hey, that system is broken.

And your team might say no, it's not, we're still getting the results from that system.

This is a major trap.

That can happen when you're not thinking about systems, we're not paying attention to all of the processes that must happen to get you the results of that system.

If this is a 10 Minute system, no big deal in 10 minutes, you know that system's broken, it's immediate feedback.

It's not immediate, obviously a 10 minute lag time.

But it's pretty quick in terms of human time, it's like, oh, wow, there's a problem, let's take care of it.

Even in a system with a lag time of two days, you're going to be brought awareness pretty quickly.

But a system of three months, 12 months, perhaps there might even be complex systems that have very long lead times or lag times in terms of their results.

And you don't notice anything because the system is so complex.

But suddenly, you are dealing with a nightmare situation.

Because depending on when that system broke, you now have that amount of lag time to catch up on.

And as we have previously discussed on the podcast or on these videos, that catching up is very difficult.

Catching up requires you to run at 120% 150% 200% of your previous production to catch up.

You see if you just start working at 100%.

Again, let's say you immediately recognize the problem and get back to 100% production, you will always have that gap, it's going to be very difficult to catch up.

So knowing your system's lag times is important.

This is something that you should document when you're looking at your system documentation.

How long does this system take to run? Because that's going to give you an awareness of how much time you have before you realize that there's a problem.

It's going to show you how long it's going to take to make a change to that system and get the results from the change this information is important.

So think about where do you document the system, execution time, the system lag time, the time that it takes to run the whole system? Is it 10 minutes? Is it two days? Is it three months? Where is it documented? And this should come into your thinking when you're addressing, troubleshooting, and improving, but also help you if there is a disaster and you're like whoa, what's going on by knowing about assistance lag time, you can adjust and think about how you are going to rectify that situation and limit the damage that it causes to your business.

So that's all I got for you today.

I hope you found this discussion helpful, a little bit of a complex topic, but something that is very important and may become more critical as we head into possible continuing difficulties in the system.

That is our society at least here in the West.

Alright, look forward to seeing you on the next episodes we continue this journey into the power of systems to create results.

Look forward to seeing you then.