Standardisation — A tool not a goal
People and Interactions over Processes and tools… while we value the items on the right we value the items on the left more.
This is Agile and I’ll be basing much of this conversation on that simple principle.
To reframe it: A tool must support and promote better interactions, rather than replace them. A tool must free people rather than contain them.
The problem
Many people I have spoken to refer to Standardisation as a goal in and of itself. This is an understandable view point; we’ve all seen standardisation have a positive effect. I’m equally sure that we’ve all felt the pinch of standardisation that boxes us in and stifles our creativity.
Marty Cagan recently disparaged the Product Operations role as “process people”. I am going to write another blog post on process and what it can unlock. For now, as a person who holds the title “Product Operations” I’d like to say that I agree with Mr. Cagan on most of his points; Process for process sake is bad; replacing interactions is bad; there is no amount of process and standardisation that can replace good practice and better coaching.
This conversation is about listening to our better angels and only doing what matters.
The power of saying no (with feeling)
I used to be a Product Owner. I have also served in the capacity of Product Manager, Business Analyst and as the Team Lead manager (and coach) of 12 Product Owners. One of my favourite quotes that I used with my teams was the good old innovation is saying no to a thousand things — Steve Jobs. No is the most powerful word in the vocabulary of Product people. But you can’t just say “no”, you’ve have got to say no with empathy and reasoning.
In this new role I have many people in the organisation excitedly coming to me with ideas and requests for standardisation. I have found it equally as powerful to say “no” to unnecessary standardisation in this role as I have to unnecessary features in my past work life.
What I’ve struggled with is the vocabulary to accompany that “no” with the reasoning and empathy it requires.
This article is the result of a lot of poor conversations that I’m hoping others can learn from.
Creating a brittle system
What we want is for our RnD system to be robust and nimble in a way that enables individual creativity. If you over processise or if you over standardise you run the risk of introducing brittleness into an otherwise flexible system.
The goal is not to make a system less flexible! The goal is to make a system that rests on a solid foundation so it doesn’t fall over!
This means we have to really think before application. We have to think of Process and Standardisation as tools to solve problems rather than goals to work toward.
Standardisation as a Tool
Imagine if you walked into a wood workshop and all the carpenter had was a hammer. The carpenter says “Yeah, impressive right? I’ve figured out how to downsize all my tools into one simple lever system… Unfortunately I can only build things that require nails.”
One tool cannot solve all your problems.
If standardisation is a tool that means it needs to be fit for purpose.
So ask yourself; what is Standardisation good for? Humans have invented a lot of stuff but never without need; what need does standardisation satisfy?
I am prone to analogies (as anyone I’ve coached can attest to) and I’m going to use one now.
Shoe Shopping — the Analogy
Shoe sizes are a great example of standardisation. I can walk into any shoe store and I can say “I’m a size US 13” and they can tell me if they have the shoe or not (mostly not…). When I go to put the shoe on I can be fairly sure that it will fit me. Some are too tight and that’s fine I just don’t buy that shoe, I’m not forced to purchase something just because it’s technically my size.
- No standardisation (chaos): Imagine we didn’t have shoe sizes and manufacturers just got to make any size they wanted, got to package them in any way they wanted? How much harder would that make shoe shopping?
- Poor Standardisation (Discomfort): Imagine that the worlds shoe makers all get together. They gather measurements from every country for all ages and they determine that the average foot size is 17cm long and 7 cm wide. They decide to standardise and make every shoe that size.
- Worst Standardisation (Hobbling): Imagine that we all know that best practice is a 15 cm foot and to fit ourselves into that model we begin binding our feet.
- Missing the point entirely (Remove the possibility of individuality): Imagine they determine that colour that sells best is “black” and now every single shoe is black.
In shoe shopping standardisation has promoted better human interactions. What I want is to find a shoe I like, at a price I can afford, in my size and standardisation gets me to the point faster. It doesn’t make the decision for me. It doesn’t rob me of my individuality or my creativity, rather it enables me to focus my creativity more efficiently.
Standardisation — what is it good for?
Let’s ask the question again: what is standardisation for? Why did we invent it?
Standardisation is well applied to tasks that get in the way of creativity and with which multiple people interact. It smooths communication and can foster better understanding.
Standardisation can also enable a system with ‘replaceable’ parts. In other words if you want to ensure that team members can move between teams with minimal friction create systems that foster joint understanding.
An example: Kanban boards. If you have standardised Kanban construction you can foster better conversations. Rather than “what are you doing” you can get straight to “why are you doing”.
Another example is a standard clause in a definition of Done: I would never create a standard definition of Done, but I would ask the teams to include a standard clause.
If every team agrees that, at a minimum done is “in production” then no matter what, when a team says “we are done” everyone knows what that means. To standardise the whole definition would be to ignore that different teams take pride in different things. Difference is the bedrock on which creativity is founded. Application of the tool only where appropriate.
Back to my analogy, when I walk up to the shoe salesperson and say “I’d like a US 13” they don’t say “13 what?”; foster better interactions, get them to the good part faster, foster joint understanding to get people (real, honest to god people) to collaboration faster. That’s the goal.
Trying to shoehorn (haha) standardisation into a system for any other reason threatens the creativity of individuals and creates a point of brittleness in a system you want to be robust.
Thus if you are approaching your RnD system with the intention of creating efficiency: think and be purposeful about what you fix and how you fix it. Fix the wrong thing, or fix the right thing in the wrong way and you may be doing more harm than good.
