I’ve written a lot about change. It’s made me think extensively about why change is so difficult for most of us. A lot of us would like to change things about our lives. Our minds know it, but our bodies reject it. It’s all about habits.

Let’s take the example of getting software into production. If you’ve been in a large corporate for a long time, you’ll understand this process in quite a specific way. That way will include all sorts of manual ‘quality gates’ that you will need to pass through on your path to the final step of getting your code into production and into the hands of your customers. These gates are controlled by various committees or boards, each of these committees requiring reams of documentation to prove to the gatekeepers that certain standards have been met before the gate will be opened and your code will be allowed to sail through the gates into the next environment. The process is generally very slow, drowning in bureaucracy and filled with arcane rules and policies that have accumulated over the years or decades, each building on the last set of rules, trying to address risk and maintain the highest quality possible. Because of the imposing bureaucracy, teams generally tend to slow down their release schedules to only a few a year, to minimize the pain of having to jump through all the hurdles that a release entails. Software gets released less often to customers and the chance of delivering the wrong thing (or indeed the right thing, but just too late) gets greater. An average release into production can take anything from 6 months to a number of years. Sometimes the software becomes redundant before it’s even released and it never sees the light of day.

If your experience is in a tech startup, getting your software into production looks very different to you. You spin up a virtual server on a cloud platform somewhere and configure it as you need for development purposes, no length procurement process is necessary. You write your tests first before you write your code so that when you check in your code to your source control repository, the continuous integration (CI) server runs through your code and checks it against the tests and tells you immediately if your code is working according to the required functionality and quality standards. If the code passes the tests, your CI server automatically sends the code to the next virtual environment, usually some sort of integrated environment, where another set of tests will be run checking if your new code plays nicely with other systems that it has to co-exist with. If it doesn’t, the code is removed from that environment and you get immediate feedback of what went wrong. So you fix it and try again. When the tests are run again and it now passes, the CI server automatically promotes the code to the final production environment and your customer gets to play with the new software and you can get feedback on it. The release time into production in this scenario is anything from a few hours to a few weeks.

Both these methods have at their heart the noble goals of solving the problem of ensuring quality code gets into production and that any risk to the business is minimized. The difference is in the way the problems are solved, and this is where the change part comes in. If you’ve been doing software development in a large corporate for a long time and your only point of reference is scenario 1, you will struggle to understand that there are other ways of solving the problem. Even if you do realize that there are other ways, you will often try to shoehorn some of these new methods into your old process because it’s so familiar to you. You try to have the ‘new’ and keep the ‘old’. What’s really going to bake your noodle is that you have to give up entirely the old ways if you want to embrace the new.

Let go, and wake up in a new world.