After I sent my Krehbiel Report on how Krehbiel’s Razor can help smooth your operations, I realized I was basically saying “go thou and think properly” — which is not very helpful for practical operations in a business.
If I may draw a lesson from my seminary training, the law is made for the sinner. In other words, good people don’t need a law that says “don’t break people’s arms,” because good people don’t go around breaking arms. We need laws for people who don’t naturally do what they should do.
You might think, “Right. I agree with Krehbiel’s Razor, and from now on I will only hire people who know to look at things from the other person’s point of view.”
That’s not very practical.
If you want something like this to work, you have to create structures, processes, forms, and whatnot that force people to think this way.
To give an example of this kind of process, it’s useful to have a template for something like a mission statement, or a use case.
Mission statement template: “We help [target market] to [solve such and so problem] by [service we offer].”
Use case template: “As a [role], I want to [action] so [result].”
In both cases, the template forces you to think about important details. Who do you serve? What problem are you solving? Etc.
In the same way, if you want your staff to start thinking about the perspective of the people in other departments, you’re going to have to create procedures that encourage that kind of thinking.
Yes, I realize this is a pain in the rear! Nobody wants another form, but they can be necessary.
When I was a young editor, we had to fill out a “Production Workform” before we could submit anything to the production department. It was irritating, especially for an arrogant 24-year-old.
Editor: Why can’t you just fix that sentence right there? Just pull up the file. Change it. Done.
Production specialist: Because the world doesn’t revolve around your publication, and I can’t drop everything to fix this right now. Also, your job will go into a queue, and I won’t necessarily be the one to work on it. So you have to write down the details you just explained to me so we don’t mess things up!
The question then, is how do you operationalize Krehbiel’s Razor? Here are some ideas.
Use Templates
Communications experts say it’s a good idea to repeat back what someone is saying to ensure you’ve understood it properly. E.g.,
Wife: “Would you quit doing that?”
Husband: “What I hear you saying is that you’d like me to quit putting my feet on the coffee table? Is that right?”
Wife: “No, I meant the way you jab me with your elbow when you get off the couch. But yes, also get your feet off the table.”
In a similar way, you can create templates in your ticketing system for how requests and responses are worded to make sure both the what and the why are communicated properly. E.g.,
Request: “I would like to [requested action] so that [expected result].” (Including the expected result gives context to the request.)
Affirmative reply: “I can [explain the request in your own words], which will [have the following effects on other systems / not affect anything else]. [Optional] Another possible approach to consider that will achieve the same result is [Y].”
Negative reply: “I recommend against [explain the request in your own words] because it will [have such and so effect on other systems / take too much time / use up too many server resources, etc.] [Optional] Another possible approach to achieve the same goal would be [Y].”
Precise language requires precise thinking. Insisting that people word things a particular way helps them to look at the issue the way you want them to look at it.
Incorporate Krehbiel’s Razor into one-on-ones
Train your managers to enforce Krehbiel’s Razor in one-on-ones with their direct reports. For example, when someone says “Marketing is giving me resistance on this project,” ask them to explain the objection from marketing’s point of view. If the manager doesn’t believe the explanation is accurate or complete, call the guy from marketing during the one-on-one and ask him.
The point is to get people to expect that they’ll have to strongman any objections to their proposal.
Build projects in stages
Before you write a long requirements document on how to add such and so widget to the website, insist on a preliminary statement of the problem and get the other people involved to sign off on it, or to express their reservations. The project can’t move to the requirements document until everyone signs off on the broad outline.
Nobody likes operations
I know this all sounds stodgy and officious. People hate jumping through hoops, and they hate filling out forms. But my father used to say, “We’re in a great big hurry, so slow down and do it right the first time.”
Following procedures and filling out forms is annoying, and it does slow things down, but it doesn’t slow things down nearly so much as doing something stupid that you have to undo because you forgot to consider somebody else’s perspective.
I love sage axioms: kudos to your Dad.
…But my father used to say, “We’re in a great big hurry, so slow down and do it right the first time.”