If you think about it, very few truly big things don't follow a standard. That standard could be of human design, like the ISO standards. Or the collaborative standards of the W3C that allow our web to work. Or the 23 pairs of chromosomes that support the replication of human life. Or the particular RGB color values specified for your company's logo. Standards and patterns are all over our world. They are what allow us to be and to take action.
Still, in the creative world and in for digital makers, we sometimes think of standards as a negative, as anti-creative constraints. And conversely, we equate a lack of standards with freedom and creativity. We tacitly believe that not having a standard will lead to a better and more innovative result. Maybe. But, even then, only for a moment. Openness to new ideas, invention, and the freedom to think outside the box are essential components of innovation. Still, at some point, we will want to bring our incredible innovation to scale. At this moment, standards come into play.
From where I sit, the question isn't whether you should have standards but when to have standards. And the answer to that question is somewhere between when you have designed (and by designing, I mean experience, content, visual, code—all of it) what you want to build and when you bring it to scale. Some factors influence this decision. Some of them might have to do with the product's impact on the people who use it. Some standards might be regulatory, so they are imposed upon you from outside and inside your organization. Designers establish design standards through style guides and pattern libraries. There are coding norms and standards.
As a digital leader, you must consider the standards needed to build your product or feature effectively for the business and safely for the people that use it. It is preferable to have this conversation before you hand off the development and roll-out of a new product or feature. Sometimes, the coming together of multiple design aspects (content, visual design, and code) leads to unexpected and potentially harmful outcomes. The process of talking about standards provides a forum to understand, in a complete way, the impact of what you are building. It also helps you know where it's OK for team members to work freely and where the standard must hold.
Without standards, individuals will do things in different ways. That's just how we are. And, the larger and more decentralized your team, the more important it is to have a conversation about standards and set appropriate boundaries. It will be challenging to get things back on the rails once products and features are deployed and bringing in revenue.
Are you clear about where team members have the freedom to innovate on the spot and where they need to follow a standard?