Comfort, safe, and safety zones are different concepts. They have some commonality regarding what can influence them but differ greatly in the power those influences can exert.
- Comfort zones are internal, encompassing areas we regularly explore, influenced by strong or frequent exposure to different experiences.
- Safety zones are also internal, covering those areas we explore infrequently and are more easily influenced, both positively and negatively.
- Safe zones are external spaces: the environment, be that physical, cultural or other, where you find yourself. How much you can influence them, if at all, is dependent on the situation.
Interaction between these zones is an area of interest: what happens when you find out that your comfort zone is no longer safe? How can you move an unsafe comfort zone if the safe zone isn’t inside your safety zone? Does your safety zone shrink? If so, how small can it become?
In my head, each of these zones is a bubble, surrounding us but not quite touching. They can surround and pass through each other, and the safe zone could be completely disconnected from me.
That might just be me.
Working in the safety zone
Joel is a Java programmer, he’s not got a lot of experience, but he knows his way around the web application he works on pretty well. At the moment, he is working on a new page and is well within his comfort zone. He is relatively calm and stress-free. In control of himself and his surroundings.
While working on the application, Joel notices that he needs to drop down into the server-side code, a nasty, dark legacy system that is normally hidden behind a nice abstraction layer. Not somewhere he’s been before.
He looks around, forlornly, hoping to catch a senior coder’s eye. No one notices.
Holding his breath, Joel takes the first tentative step into the behemoth. He feels apprehensive and unsure but still able to work.
Slowly he moves through the code, making small changes and checking everything passes as he goes.
Finally, with a great sigh of relief, Joel reaches the end. He’s finished. Nothing has gone wrong. The build server is still happy with him.
Next time Joel has to open that legacy code, he’s going to feel more confident that he’ll come out alive. His comfort zone has grown slightly in respect to it.
Maybe his safety zone is slightly larger, but he’s willing to tackle other areas of the legacy system. He’ll keep up his cautious approach but is now willing to try.
All’s well that ends well…
Unfortunately, it doesn’t always go to plan. The next morning Joel arrives at his desk to find an irate manager. The code he released yesterday. The code in the legacy system he’d never touched before. It has a bug. A big bug.
The system now accepts all sorts of traffic it didn’t before. Security is shot to pieces. No, don’t bother fixing it. That’s already been done.
It is easy to see that he will be hesitant the next time Joel needs to make a change. Not only will he be worried about the consequences of touching the legacy system, but potentially any other system. His comfort zone has decreased. Before, he was willing to try, but now he isn’t.
Interestingly his safety zone, the area in which he will cope if needed, is not necessarily reduced at the same time. He may go back into the area, but even the edges where he was comfortable now are a cause for concern.
Hopefully, the next thoughts on this won’t take 18 months for me to get into an understandable shape.
What’s next? Read our article on Acceptance Testing
Want some training on Scrum Basics? Take a look at our Introduction to Agile & Scrum course
Get in touch using the link below to see how we can support you.