Standardize to Innovate
Above image: Standards by Nick Youngson CC BY-SA 3.0 Alpha Stock Images
Disclaimer
I often like to say I have strong opinions, loosely held because I’m probably wrong. I explicitly add the “I’m probably wrong” bit to remind myself.
Embracing standards is a relatively new thing for me. For most of my career I was convinced I knew better than any standard. So, if we’ve spoken about this in the past, well, my position has likely changed since then. I was wrong.
I used to actively dislike standards. I equated them to the lowest common denominator. Early in my career, standards hadn’t really mattered, not to me. I was ridiculously lucky to start in rapid research and development. Everything was new, not just to me, but to most everyone. It was awesome.
So, I didn’t really consider standards until I was already established in my career. I had a leader who liked the phrase, “why have two when one will do?” I sat with that… longer than I’d like to admit. I will sometimes try new things simply because they’re new. Could I push for standardizing on a single solution?
I could. I did. I do.
Now, I’m not going to lie. I might have an easier time accepting standards now I’m senior enough to be the one setting them, or at least to have a say. Even so, I think I could convince a younger, more junior, me standards are better for the business. Could I take the argument a big step further? Yeah, it’s better for the business, but standardizing also gives you room to innovate.
What is a standard?
First, let’s start with what a standard is not. A standard is not a hard requirement.
Okay, with that out of the way, what is a standard? A standard is a default, a choice without having to make a choice, a way we’re going to do things when we don’t have a specific reason to do something different.
Choice without making a choice?
Yeah, see, this is awesome. As you become more senior, you’ll often find you have a lot of choices. You can pick and choose lots of things, but maybe you shouldn’t have to, not all the time. Let’s look at a concrete example.
What programming language are you going to use? You could consider any number of languages, from the popular to the obscure. You could make this choice every time you start a new project. You could do that, but I don’t think you should.
I don’t know if decision fatigue is real or not. Regardless, the choice is still yet another thing you have to do, maybe alone, maybe as a team, but yet another thing to do. There might even be occasions when it makes sense to have a conversation about the right language for a project, but that’s probably the exception, not the rule. Just getting to work can be amazing, freeing.
Maybe you don’t agree with that logic. Okay, but let’s play it out for a bit. Let’s say you do have a default programming language for your company/business unit/team/whatever. What else do you get? Well, you get to build expertise with that language’s ecosystem. Maybe you develop or have experts on the language or key frameworks. Maybe you know the sharp edges and dark corners to avoid. Maybe you have homegrown libraries and tools to help. Maybe you can just go faster. I’m going to guess you’ll grant me that much. There’s a lot of value there. Speed cures a whole lot.
Evolving your standards…
I must admit to loving to try new things. (Like, I might have a bit of a problem, drives-my-wife-insane kind of problem.) So, I’m always happy to look for the next, new, best thing ever. So, revisiting standards comes naturally to me. I also know not everyone feels that way. Guess what? That’s awesome, too!
Most people will be happy to just keep using the standard. “It’s how we’ve always done things.” (If you know me, you probably know I very-dislike that phrase, but here, for this specific use, maybe it’s okay.)
But every once in a while, someone will challenge the standard. Great, let them. Most people won’t care enough to challenge the standards, but some few, brave folks will believe they can do better. They might be right. Some people are wired different and will put in significant effort to make things better or just to prove they’re right. Then… well, then everyone gets to benefit. The standard will have evolved, and for folks happy to just follow the standard, things got better with little to no effort on their parts.
Wait, really!?
Well… maybe. I also like to say, “all code is debt.” Well, standards are going to be debt, too. Maybe no brave souls come along to challenge the status quo and now some team is left maintaining the standard. In net, I believe this is still worth it. The alternative isn’t no debt, it’s debt spread out across the organization. Better to consolidate.
Okay, fine, whatever, but where’s the innovation?
Okay, I titled this post Standardize to Innovate. Yes, I did. Aside from the expertise development I mentioned above, now’s a good time to discuss innovation budget. I think this post is the first place I heard about something like an innovation budget, here innovation tokens. (If you do read it, please keep in mind it was written in 2015, so any specific callouts should be seen in that light.) So now, if we have a standard, if we’re not reinventing the wheel with every project, we can be free to focus on something else. When we’re not busy learning the latest and greatest programming language or framework for the 13th time this year, we are better positioned to push the bounds in other dimensions. Hopefully, those dimensions can be things that move the business or the project in a meaningful dimension. Imagine if you have a few minutes here, an hour there, because you’re not RTFMing, web searching, or asking your favorite LLM. That’s time you could be building that one extra feature, fixing that one other annoyance, or maybe finally finding product market fit.
That’s it. There’s no great mystery, no secret. The simple truth is when you aren’t doing one thing, you are free to do something else, basic opportunity cost. Crazy right? I think when you hear it (or read it), it’s pretty easy to see. I’m a little ashamed it took me so long to see.