Releasing code to production is a process. The process has to be quick, simple, and repeatable. If that process is slow, or wrought with problems and caveats people aren’t going to want to do it. Just like water follows the path of least resistance—so do people. If it is easier to not release something it won’t be released.
Releasing code to production is also a muscle. If you stop exercising it will atrophy. Your ability to create production code will suffer.
Code that isn’t in production is not producing value for your customers, and thus your company/organization. Production is the only environment that matters (this is why we also “test in prod”).
Increasing your mean-time-to-release means shipping code faster and more often. If this muscle is strong the world is your oyster. Once you identify opportunities you can move on them, because your shipping muscle is strong. Once you identify problems you can fix them, because your shipping muscle is strong.
Shipping small pieces quickly is also a de-risk strategy. Making small changes reduces the surface area for problems. If you ship one small piece, and something breaks you know precisely where to look for causes. It doesn’t even have to break—if behavior changes in your system, or even your users, you know what caused it. Because you shipped a small change.
If you ship a giant overhaul, and something breaks—good luck finding it quickly and fixing it quickly. The risk of large changes is larger than just the size of the change. Thanks, network effect.
This is not about “being fast”, or “being faster than the competition.” MMTR is a process and a muscle. It sharpens your ability to write production-ready code, because you’re going to ship it right away. It de-risks problems by observing what happens in your systems after each small change ships. It allows you to be nimble and respond by creating value for your customers. After all, it is about what you can do for them.
Read more: MTTR is the Most Valuable Piece
This is my favorite aphorism. There are so many important things that need doing to deliver value to users. Commits don’t matter, especially when they’re the wrong commits!
It is an unfortunate trend to try and capture productivity levels of engineers. Lots of companies are trying very hard to create a new Fordist movement for knowledge workers. It’s not going to work (not currently anyway).
More and more of engineers time these days is required to be spent on non-coding activities. Make sure your organizations recognize your effort here. Make sure they reward your effort. Push to get those on your career ladder/promotion evaluations.
The purely head-down programmer who isn’t looking at the broader picture is not going to be very successful going forward. There is too much to learn—one person cannot know it all. Things are changing too quickly. And users are becoming more sophisticated, and demanding.
The tech industry is healthier when people are buying their software. Not our current VC-funded where the users are the product and engineers live in silos separated from the population. But in order to get back to a place where people buy software we have to have our eyes up.
It is my opinion that if an engineer is unable to value the efforts of other engineers to “be the glue that keeps projects going”, there is no way they’re going to be able to value their users and look them in the eye.
Read more: Valuing Glue & Eyes Up