People, like running water and electricity, tend to take the path of least resistance. The best processes are designed so that the most desired outcomes—the ‘right things’—are also the easiest to achieve. This is true across various fields, from retirement plan administration to software development to management.

A great example of this concept was when companies started to make retirement plans opt-out rather than opt-in. In other words, whereas the employees previously had to choose to participate in the retirement plan, employers are now allowed or required to automatically enroll them and have a percentage of their income put into the plan each pay period. By changing the process so that staying in the plan required less effort than leaving it—often involving nothing more than a simple button click—participation rates in retirement plans increased by 25% to 35%.

I first heard the concept, ‘make the right thing the easy thing’ from my friend, Andrew Clay Shafer. My company was having trouble making sure that software developers were following the coding standards. The reason was clear, the focus was on reliable code getting to the users and, in the name of timeliness, programmers would often cut corners on following the standards. This was a short-term gain as the users got new code but in the long term, it was making the code tougher to maintain and integrate with other code.

These coding standards were not meant to be strict, but more of a general outline of how things should be done so they could be handled consistently. We tried to get developers to adhere to the standards by creating a policy and putting some checking and enforcement behind it. We quickly ran into JoAnn’s Law; productivity dropped drastically as the many people already following the policy became extremely worried about following it to the letter, even when it didn’t make sense to do so.

At the same time, those violators whom the policy was aimed at did little to comply. In one case, the developer waited until close to when the customer was expecting the code to have it reviewed. When it failed utterly, the developer said ‘we can either deliver on time or I can go back and redo everything to follow the standards.’ With few other options, we let the code go out to the customer and later asked for revisions according to the standards, at which point they agreed but warned that their next deliverables would be delayed.

We had looked at this as a failure of management at the time; expectations should be clear and there should be accountability for not following the standards. While Andrew agreed that this was one way to look at it, another would be that this was a process problem. We said we wanted people to follow standards but, in truth, it was lower on the list than making good quality code and meeting the deadlines. Lastly, adherence to the standards was somewhat subjective; one person reviewing the code might think it was fine while others were sticklers for details.

The solution was to automate the code pipeline to check for standardization, with clear rules and immediate automatic feedback to anyone programming. In short, the system itself would not allow testing or production deployment until the code met the standards. This meant that the standards had to be very clearly defined so they could be automated.

The right thing, following standards, was now the easy thing. Not following standards would be difficult indeed, meaning figuring out how to circumvent the entire system. In contrast, every line of code was automatically checked in real time for the standards. This wasn’t without its problems, because figuring out how to automate the standard checking was a laborious affair that needed a lot of tweaking. Also, some people struggled to understand the standards (which explains why they weren’t following them in the first place) and took a small hit to productivity while they learned, but automating the standard checking did a good job of dealing with the problem.

A similar challenge arises when a single programmer or manager becomes viewed as the ‘one big expert’ (OBE). In such scenarios, all decisions and reviews must pass through this individual. While these experts are often highly knowledgeable and dependable, their central role can be efficient for smaller systems but turns into a significant bottleneck in larger operations. OBEs will inevitably stifle the decision-making abilities of other team members, compelling reliance on the OBE for even minor decisions.

The problem is even worse when OBEs are assertive and territorial, as many are. To fix this issue and promote more autonomous decision-making among staff, you likely will need to find alternative roles for them. Only then can you establish an environment where employees seek guidance only when truly needed, thus making the right thing the easy thing.

A similar concept is using metrics in business. The idea being that by giving people clear goals and a way to measure progress towards those goals, such as how many customers they must talk to per day, people are more motivated to do the ‘right’ thing. The problem, of course, is that you better be really sure that the metrics are the ‘right thing’, or your company will end up someplace other than where it wants to be. My observation is that few metrics are really driving the behavior companies are hoping for.

So, the next time you find something in your life or your work that you think should be done differently, think about how you could make it easier. Whether it’s streamlining processes, modifying guidelines, or changing the environment, small adjustments over time can lead to significant improvements. Remember, when the right choice becomes the easiest one, positive transformation becomes not just possible, but inevitable.