Governance and change
A diagram can be the difference between an organization of "petty kings" doing their own thing and having actionable plans built on a shared identity. What we need is some kind of governance.
When we've been indoctrinated with this fiery vision of how we can work, and we have all the tooling needed...then what? Well, I'd say we should proceed with formalizing how we want to work into a simple process. The process I will propose isn't very hard... Note that this is not a limitation, it's a feature!
I totally understand that most people find diagrams of processes—at best—tedious, but they are needed so that we can embody how we do things into something material. It's always better (not least, it's easier) to critique a process instead of a person.
High-level: The change process#
The very first thing we want to do is to draw our intended flow: Where it starts, what it can go through, and what its state or states can be.
It's certainly the case that very complex and distributed systems can have changes emanating from many sources, but these would require some way to consolidate or negotiate how they adopt changes, unless one is willing to have completely out-of-sync variants. Such factors of consolidation could be a review board, an open forum, or anything else that works with your culture and leadership model.
In our case, the typical unit of change could be that someone has identified the need for a new component or feature. Depending on your organization, this intake process will vary; let's just roll with the assumption that someone has identified a change and that it's considered valid from a business standpoint. You'll notice that in our case, we have five simple questions along our path:
Does the identified feature/component exist?
Do current use-cases cover new needs?
Has access been provided to implementors?
Is the feature/component built and pushed?
Is it reviewed and deemed satisfactory?
Each question needs to have one or more "owners" with full mandate to respond to them. Another way would be to decentralize some of these—like having an open design system so we know what already exists—so that we can make the current state into common knowledge. It's also advisable to have more than one person owning the review stage and being able to hand out permissions.
Individually, these steps should be low-overhead and have clear channels of communication, so no one is stopped dead in their tracks because they have to wait until someone has talked to that guy in Team So-and-So on floor seven on a Tuesday after a full moon, but only if he's wearing a white shirt.
I wish I was kidding, but some companies just love making things too complicated.
Okay, so we've also accepted three different general solutions, depending on where we end up answering these questions:
Buy a matching solution
Use existing component/solution
Publish a new component/solution
This page is a preview of The newline Guide to React Component Design Systems with Figmagic