Laggy Snake - a small experience of delay in steering
At work, we live with delays of various kinds. As the time between action and outcome grows, our ability to steer effectively deteriorates. Or, said differently: how well we can steer is bounded by how well our feedback loops work.
A major change is implemented, but then it takes months before we see what it actually resulted in. A customer is unhappy right now, but we don't see it until we read their angry email — by which point they've already moved on. When feedback is delayed, steering becomes harder. To get a feel for what that's like, you can play the game below. It's a small system where the consequences of delayed feedback become tangible quickly.
Checklist for snake pilots
Confirm you've understood the rules:
Rapid Response
In this round, there was no significant delay in control. When you pressed a key to turn, the snake turned as fast as it possibly could.
That rarely happens at work. For all sorts of reasons, it takes time before the consequences of our decisions become visible.
In the next round, you'll start to get a feel for what it's like when delay is introduced to the steering. Play again, this time with a 200 ms delay between pressing a key and the snake turning.
Delays Affect Tactics
200 ms really isn't a long time. But even here you might start to notice it affecting your results. You need to think a little further ahead. Sometimes you turn a fraction too late and miss. Sometimes you overcorrect and turn too early.
This mirrors what happens at work. Because we know things take time, we start thinking ahead and guessing at what we think will need to be done. Plans are made to compensate for the inability to get real-time feedback. Sometimes the plans are right — sometimes they cause us to miss the mark. And sometimes, delayed feedback on our actions cause us to give up prematurely, because it looks like what we're doing isn't working.
In the next round, the delay is 500 ms. Try it and see what happens.
Targets Tend to Move
500 ms delay is difficult here. At the same time, its a bit of a cheat that the apple sits still. At work, goals shifts as we learn more and as priorities shift. We can commit to a direction, and by the time we arrive, the goal has relocated. In the next round, you still have the 500 ms delay - but the apple moves about a bit. Good luck.
Risk Appetite
When out steering isn't rapid (because feedback is delayed) taking risks is pretty scary. This could lead us to choose safer, but also less valuable, courses of action.
This round has a new kind of apple. This special apple is super-valuable, but only appears on the edges of the field. It's worth a lot more, but only if you capture it before it escapes. A regular red apple is always available if that seems like a smarter way to go. You still have the 500 ms delay. With 15 points to collect, notice how the delay affects your willingness to take risks.
If it turns out to be too hard, you could always choose to slow down your speed ...
Predictable vs. Unpredictable
Long delay is harder to work with. But up until now it's been consistent. Play enough rounds, and you'll learn how to play well even with the 500 ms delay. It's predictably bad, and we can adapt to that.
In this final round the delay will vary over time, between 0 ms and 500 ms. How does this affect your ability to score points? How do you feel about it?
So What?
Slowness is pretty tricky at first, but with time we might learn to deal with it. A person who works in a slow organization will learn that's how it works, and adapt accordingly. Now imagine bringing in a person who is used to fast feedback loops, to that slow organization. Talk about culture clash!
When it comes to the last round of this game, that's just awful. It can feel almost impossible to do the right thing when the repsonse time keeps changing. A source of stress and frustration, for sure.
Now, as a thought experiment, imagine a world where we could respond infinitely quickly and effectively to whatever happens. In that imaginary world, the need for forward planning would be minimised. In reality, we'll never get there - but we can try to move in that direction.
In software development, specifically, we've landed on the idea that an effective way to handle uncertainty is to increase our ability to change course safely and quickly - to be agile.
This explains the constant drive to shorten delivery and learning cycles in software development. The faster we can learn about the consequences of our most recent decisions, the more quickly we can act wisely in the next step.
Of course, just shipping faster won't fix the most important feedback loop of all: the one that helps us see if we are delivering the right thing. There are many reasons why feedback from the field will be delayed, sometimes for very long, as when a bug lies undetected in an otherwise well-working system for years, or when a client needs time to use new functionality for a longer time before they are ready to share feedback on it.
Because this kind of "external feedback" is slower than the "internal feedback" we can generate ourselves, there is always a rational tendency to build our feedback loops around what we can control. So, we build a strong and fast feedback loop around doing activities and shipping deliverables. And it is fast feedback, but it's also a small feedback loop - one which cannot generate enough valuable information about whether we are really making a difference, or just doing work.
If we fail to notice this, we create an illusion of speed and learning. As with all illusions, it works until it no longer doesn't. So, in the end, the challenge we often face is not just to make sure we have fast feedback, but that we have fast and big feedbackloops, that reach all the way out to real customers and users.
Reflection questions
- In your work: where is the delay between action and result too long today?
- What are the consequences of that delay? Who suffers from it? How?
- How would people benefit from a faster response time?
- What would need to happen to reduce the delay somewhat?
- What would it take to minimize the delay? Would it be worth it?
- When is slowing down a good way to regain control? When is it counter productive?