Fork it, I Disagree

Our team gets together and experiments on a new process together weekly. We pick something we think could be improved and go through our data, experiment, then rapidly build a new process together. 

If the new process is better, then it becomes the new baseline for us; otherwise, the existing process remains untouched. Unless the solution is clear and not risky, we will always opt for constant improvement.

For firms not doing this, the impact is large because there is so many low hanging fruit that tends not to be prioritized over larger, more visible projects. So like a person going to the gym for the first time, you get great results very quickly.

As the company sheds legacy processes, and processes get updated, it becomes harder and harder to get results. A practical way to think about this is, reducing a customer form from 30 pages down to 10 could be easy and clear when you think in first principles, but cutting a 2-page form to half a page becomes much harder - thank you law of diminishing returns!

That's where we were, and this is the area where disagreements happen because of the multiple perspectives to get the goal.

So who decides at this point?

1. The more senior ranking person?
2. The person with the longest tenure at the firm?
3. The newest person?
4. Outside consultant?
5. The winner of rock, paper, scissors game? (what problem can't be solved with rock/paper/scissors?)

When reading this, all solutions seem not optimal, but I'd argue most firms and groups are using one of these variations. 

The answer, the truth should win, but how can we get there? The solution is to fork the solution.

Wait. Pause. Rewind. Let's get a bit of background on how code improves, collaboration occurs, and ideas evolve within software communities/firms all over the world. 

1. Person A creates a project and adds codes to it.
2. Person B makes a copy of the project (Forks it)
3. Person B makes some changes to their version
4. Person B submits a pull request, which is a request to have their code merged back with Person A's code
5. Person A reviews pull requests and either accepts or declines. 

This process happens hundreds of thousands a times a day and is one of the reasons for the advances in software today.

The concept of forking/pull requests is not unique to code; it has been applied to books, research papers, art, and even processes! Code is simply an expression of our ideas, just like our processes.

Unpause. Back to today. 

We took our process and approach then forked it. Everyone who disagreed at that point took less than half an hour to "prove" their proposed solution. We have our KPI and an existing process, so the focus is to put something together that is better than the current process then compare which person's approach has a better KPI. 

My proposed process saves 2 minutes compared to the other person's process saves 20 minutes, but as the most senior person in the room, my solution would have won when it shouldn't have, and because we took this approach, I'm happy to say it didn't win. As the process owner I accepted the better process and it elevated everyone.

In the end, the winner or loser does not matter; we came out with a better process that beat the previous process and is now our new baseline...until we figure a way even better way. 

(Originally posted @ www.15Rock.com )