Make the right way, the easy way
This post was originally published on CIO.com on October 23rd, 2019.
Background
A number of years ago, I had just started a new job in a leadership role, and I attended a senior leaders discussion, led by the Chief Information Security Office (CISO) of the company. There were various topics being covered, but one had to do with the configuration of the servers, which was a topic near and dear to my heart.
The CISO was talking about how they were going to demand compliance from all appropriate staff that the servers were to be configured in a certain way, with a certain version, etc. in order to have better security in the company. If anyone had a problem with that, then there were other places they could be employed. If necessary there would be mandatory training…you get the idea.
To the shock of many in the room, I put my hand up and asked a simple question: “What if we just made the right way, the easy way?”
Effecting Transformation
This notion of making the right way the easy way has come up time and time again when working with clients on their transformations. Almost always a transformation requires getting people to change the way they operate the business. A tool they often reach for is a stick.
The solution is often “We’ll get an executive to tell them they have to do it”.
But that ignores the Westrum Generative culture we are hoping to build in high performing organizations. We need to be able to trust that people will make the right decisions because they are closest to the information. Information that reaches the executive level is highly filtered and as a result suited to strategic decisions, not decisions made day to day on the front lines. If the specific configuration we specify does not meet the specific needs, even though it does not cause any security problems, then we can be hampering the performance of our own organization. In the best case, they will not be able to do their work without being delayed by starting down the long slow line of asking for an exception. In the worst case, they will bypass the new process, and hide the specific change they have made so that they can still get their job done and not have to jump through hoops.
If we make the right way the easy way, then almost anyone who is faced with one of these situations, will almost always choose the way that has been provided for them. There are very few humans who like to go out of their way to take on extra work if they can choose the easier way. In the case of the CISO above, if we simply provided pre-configured packaged software to the systems engineers, with all the appropriate versions and security configurations, there is very little reason they would have for trying to go out and do all that work from scratch when they could simply install a package. Today we would do this with containers, but the principle is the same. Why would I want to go and make my own secure (or performant, or whatever) container from scratch, if I could just use the one that suits my needs provided by the company? In the case it does not meet my needs, that is a problem that needs to be solved, as easily as is warranted.
In Practice
Because we often talk about DevOps in this column, we can look at some examples from different parts of the business where making the right way the easy way can have a big effect.
Dev
We have talked before about how important it is for Operations to facilitate the speed of developers moving software to market. We’ve talked about how Operations provides a platform.
The reason to have a platform is that it makes the right way the easy way. In Operations, we often talk about putting in guardrails. In one case, we can turn the developers loose on the AWS platform and allow them to spin up databases, virtual machines, queues, etc. In the platform case, we can give them tools to do these things.
If a developer needs an AWS Elastic Compute Cloud virtual machine instance, they could go find some virtual machine image, and set up some wide open security group rules, and open the instance to the Internet so they don’t have to worry about being blocked by firewall rules, and all the other possible mistakes, etc.
Or we can give them a tool to launch an instance with all the right settings configured correctly. With this tool, they only need to choose from a minimal set of requirements so they get exactly what they need. That’s making the right way, the easy way, and there are few developers who would sign up for the manual method.
Ops
This can also apply to Operations teams. If the correct way to configure an application is to put the configuration files in /directory/appname for every application, then we can build tools around that pattern to make it very easy. Have some brand new microservice to be deployed? No problem, just use this tool here and setup your configuration and we will make sure that part is deployed successfully. How many people would demand that the application configuration be placed under /somewhere/else?
This also helps the Operations staff to reason about applications either during normal operations, or during an outage. Because we’ve made the right way, the easy way, if it’s 3 a.m. and my SRE has just been woken up to a production site outage, if they want to know the configuration of an application, they don’t need to spend time trying to figure out where to look. It’s **always **under /directory/appname, regardless of the app. That means less time trying to remember things under stress, less time looking through runbooks trying to find the section on configuration, and much faster Time to Repair (TTR) for our production installation.
Business
Even our business operations folks can take advantage of this idea. If we have a tweet that has to go out in a specific format, at a specific time of day, would we like to spell out those instructions for someone in marketing to follow to the letter? What if they make a mistake? Should we fire them for being human?
Or can we make the right way the easy way and invest in a marketing automation tool that is designed to post tweets, from templates, with a scheduler? I would much rather schedule a tweet to go out at 2 a.m. during the afternoon marketing meeting, than I would like to get up at 1:58 a.m. and hope that I push the button correctly.
Does anyone believe that more training, or threatening people’s jobs will prevent problems at 2 a.m. for a process that can be done the right way and easily be handled by a computer?
Conclusion
When organizations are going through transformations especially, or even operating normally, there is often a tendency to want to specify exactly what people should do. Unfortunately, situations are varied, and there is rarely a one size fits all solution. This is not a problem exclusive to technology companies but affects aviation, medicine, and other professions as well.
If we put our employees in situations where the “approved” way is also they easiest way, and we make it so it fits their needs, then we will have a situation where people can move quickly and use their expertise to arrive at the most successful outcomes for the company.