Sure there are places where consistency is the easiest way to achieve some other goal. But I’ve seen folks at companies somehow along the line lose the plot and let consistency itself become the goal. That doesn’t make sense, because consistency is not itself a first principle. It must be the “best idea we have” to move some other key metric or achieve some other goal.
This “not a first principle” issue pops up in UI sometimes. “This feature we’re building needs to be consistent with this other feature we already have” is a classic sentence you might hear. But actually, the root goal is to build something that works the way users expect. And yes, how our existing features work has trained users a bit on what to expect from our app. But, if you think harder, you’ll realize that a) this doesn’t help new users at all, and b) most users spend far more time on Instagram and sending text messages for example than our app. So if anything we should hew to what those apps & the OS have trained the user to expect . . . not some other feature we have.
A second example is “consistency across teams.” For example, you might get pressure to run your team the same way as a peer team “for consistency.” But why? Maybe there’s a root goal such as “folks from both teams should be able to read updates on each other’s work quickly.” And if consistency is the best idea you have, sure. But let’s please get to the root goal.
For a growing company like us, consistency has a cost. It forces other people (whether a feature team, another functional team) to do something they didn’t choose. I’d much rather be a place where people make their own decisions, have agency, and are accountable for the outcomes of their decisions. Consistency with some existing pattern is neither a reason to do something on its own, nor a defense when it doesn’t work in your situation or context.
P.S. To be comprehensive, “I want to do it differently” is also not a goal.
