Your organization’s software development work probably hasn’t been done before. Even if you have features similar to a competitor’s feature, no one has done the work in your code base.
That doesn’t mean that every activity your team performs along the path to delivering that work has never been done before.
Unless you’re doing the very first commit of your product, you’ve likely deployed before, for example. If you have more than one team, each team has likely deployed before.
If you have some sort of a physical product, even one that has customization, the chances are that from one unit to the next, there is a great deal of similarity.
If you treat every single instance of this work as a novel situation, you’ll spend all your cycles repeating work that is largely already solved and dealing with the unique challenges that each unique instance of solving the same thing brings.
This won’t leave time for innovation and improvement.
I love the craft of software development, and the geek part of my brain lights up when my little electronic minions do my bidding the way I want them to. (Incidentally, that’s how you know Chat GPT isn’t generating these emails. No way it would produce a sentence like that—a sentence that will get it targeted in the upcoming robot uprising).
But my time and brain cycles are limited, so I want to spend them on the mission. It’s okay to standardize the rest. Your people won’t lose their developer cards if your org standardizes on how deployments are done.
You’ll need a feedback process, so that you can make sure your processes still make sense, but it’s the fact that you have standard processed that gives you something to improve.
So bring that passion, and bring that creativity. But bring it to bear on your customers’ problems and not on how you push code.
