I finished 2019 with a short holiday. I used the time to reflect on the journey past year. In December, I was at the “AWS re:Invent” conference. Amongst many sessions, I particularly enjoyed those that focused on Software Engineering processes and practices. During one of the presentations, the speaker said a sentence which very much engraved itself into my mind:
“The most productive and creative work happens in environments where it’s safe to experiment. To get most out of your Engineers, create safety instead of restricting freedom by introducing draconian rules and policies.”
Working for many years in tightly controlled environments, I realised the importance of the above statements. I also realised the many dimensions of safety to which the speaker was referring.
Impact of tight rules and policies
Many organisations, specifically large organisations, introduce regulations and procedures to prevent undesired situations from happening. In my experience as a software engineer, I had to deal with tight controls of Internet access, permissions of my development environment, access to test environments, curated list of software and dependencies.
Those rules were not only frustrating and inconvenient for other developers and me, but were also preventing us from trying new things, improving existing solutions and slowing down the delivery process.
The frustration resulting from the blockers, caused me and my colleagues to find creative ways to work around the restrictions, by “hacking” processes. We wasted our creative efforts on the wrong outcomes.
The sad truth is that regardless of the rules and policies undesired situations happened. Back in the days, you could hear about security mishaps and performance issues on the BBC.
When I think about the quote from the beginning of the post, I know that fruits of my work might have been more creative and take much less time if I would have the freedom to experiment and progress safely.
Safety comes in different shapes and sizes.
As a software engineer, when I talk about safety, I immediately think about safe development environments where I will cause no harm to the production systems. However, there is another dimension to it: a safe environment in a company, where:
- it’s fine to voice opinions and raise concerns
- there is no prejudice, bias or harassment
- no blame is assigned.
No amount of technical solutions will make a difference in your organisation unless you make people feel safe to express their thoughts honestly and openly.
How to create safety
As leaders and managers, we create a safe environment by being transparent and open. When our people realise they don’t have to worry about speaking their mind and challenging current approaches, they would have time to focus on existing work and bring ideas for improvements.
Safety is a feeling, and different people might feel it differently. It might take time, and a different approach before people in your team feel safe. Start by asking yourself, what would/is making you feel safe at work? Adopt it as your behaviour towards others and iterate on the approach. I find it useful to get feedback on my methods during 1-2-1s.
When it comes to technical solutions, the following are some ideas on safety for experimentation:
- Managed developer desktops, with no access to the corporate network, with permissions to add additional software at will
- Sandboxed dev environments with no connection to delivery pipelines
- Separate Internet access without restrictions on the development resources
- Production-like data for experiments
Following ideas are for safety in the delivery work, as a part of development practices :
- Automated functional and non-functional testing
- An automatic, no-human-touch deployment pipeline
- Reproducible environments
- Configuration as code
I know that the last few points are essential DevOps practices. It’s not coincidental as they are designed for safety due to the fast-paced nature and the elimination of human error.
Remember, keep your workplace “safe”!
Greg Gigon's wEbLOG 