One of my favorite Process Engineering tools is the Five Whys. The basic principle is to consider a problem or imperfection, ask why it’s the way it is, and then ask why that explanation is so. We keep digging (as the title suggests, five times, but your mileage may vary) until we’ve uncovered the true root cause of an issue. The idea here is to work toward better understanding what’s behind a problem rather than simply fixing the facial, obvious symptoms. This aids in efficiency as we’re less prone to waste our time simply swatting at proverbial flies but rather identifying an underlying failure, fixing it, and thereby avoiding further deficiencies.
Now, as with any tool, it can be overused or misapplied. Some folks will barge into a problem-solving situation, claim to ask “Why?” five times, and call themselves heroes for having broken through the “it’s how we’ve always done it” mentality. Nice try, but the Five Whys is more than just seeming to be an iconoclast or dynamic thinker. If you’re only asking “Why” rhetorically or just to be snarky or look like the smartest person in the room, it’s likely you’ll miss the whole point. The purpose of asking “Why” is actually two-fold: to search earnestly for the root cause, but also to better understand the systems that are currently in place and, well, why they’re there (the jobs they were intended to accomplish).
Which brings me to Chesterton’s Gate (or, also known as Chesterton’s Fence). The long and short of this philosophy is that we shouldn’t remove (or drastically change) something in our process or system without first acknowledging and understanding why it’s there in the first place. The parable Chesterton tells is that of a traveler comes across a gate closed across his path and, looking long into the distance on each side sees no real purpose for it. So he declares it to be taken down. A wise dude sitting nearby admonishes him that, precisely for the reason that he can’t tell why it’s there, he is forbidden from disturbing it. It’s only in knowing (or at least having done due diligence to discern) what would be lost in the absence of this (to him) obstacle that he’s in the clear to move it out of his way.
I’ve known a few process engineers with enough hubris to figure that, since they’ve been called in to ‘fix’ someone’s processes and make them more smoothly-running, they’ve got all the answers (and, frankly in some cases, don’t need to ask any questions in the first place). But surely this is the greatest trap into which a PE practitioner can fall.
The military, for example, is rife with complex systems and processes…everything has a checklist, it seems. And we follow them sometimes quite blindly and mindlessly, not even considering what the purpose of some steps are. Someone with an eye of leaning out these processes may come along and, seeing ‘no good reason’ for some requirements, simply dictate that certain things cease. But for sure, simply removing things for which we don’t see a purpose is just as reckless as following procedures blindly, and for the same reason: both approaches are short-sighted and don’t take into account the overall goal of the system in the first place.
On one of my deployments, I worked in an analysis organization supporting the combined allied air commander for the Middle East. Our team cranked out tons of reports, some of them incredibly manual in nature, a lot of them redundant. In order to lighten our load and therefore free the analysts to perform more complicated (and useful) analytical work, I convinced my boss to let us conduct an experiment: Stop sending certain reports out altogether…no announcement, no safety net, no warning. Just see who yelps, I reasoned, and then we’ll see if anybody really is using the reports in question, and therefore know which ones were even needed in the first place. Now, my boss was smarter than I was at the time (I like to think I learned a lot from him) and, knowing the work that goes into these reports (they took a day or two apiece to put together), and not wanting to be caught flat-footed if a recipient of any one of them blew a gasket, he recommended we do the reports, just not send them out (and continue for a few weeks, just in case someone didn’t notice right away). That way, we could have it on hand and immediately get a report to someone in case they actually did need it, but if they didn’t say anything about it after a few iterations went by without receiving it, then we’d know they weren’t missing it.
It’s a good thing we took that approach of completing the work but holding it back because we did get a couple of folks pinging us about where this or that report went and why they didn’t get it. In those couple instances, we were able to immediately send along the report (since we’d done it), so our Customers weren’t without the support they needed.
What was even better is that, without having even intended to do so, I delved into the Five Whys: You see, since there were only a few people who really did need the reports (and believe me, there were a lot more who never even noticed them gone), engaging with each Customer who was using our analysis was scalable and I was able to sit down with each of them and ask, “why” (and “how”) they needed what we’d been providing. In some instances, I was able to point them directly to the source of information (a win-win by their bypassing having to wait for us to synthesize it for them, and taking them off our to-do list altogether), and in a couple of instances, it turned out that what we were giving them wasn’t even answering the questions they had…they’d been taking the reports we were giving them and, thinking it was crunching numbers a certain way when it wasn’t, weren’t even getting the best insights for their purposes. We were able to take that feedback and better deliver for those Customers what they needed. This experience has helped me in reflection many times as a CX professional.
Had we just torn down Chesterton’s Fence—had we simply stopped doing the analysis—two things would have happed. First, we’d have been caught completely in a lurch when our Customers yelled, “Where’s our stuff?” We’d have had to scramble and spent tons of effort to throw together work that normally takes a lot of time to accomplish, potentially causing errors and definitely delivering quite late. Additionally, all that disruption would have cost us not just that time and effort, but also credibility with our Customers. In contrast, by taking the opportunity to learn why they were using what we were sending to them, we were able to better serve them (and move some of them to self-serve) and not lose a step along the way.
If you’re looking at parts of your process and wondering, “Why are we even doing this?”, then good for you for not settling! If coming up empty when you ask that question leads you directly and immediately to the conclusion that there must be no purpose and you’ll simply stop doing it, hang on a second…learn to ask “Why?” in a genuine and curious way, seeking to understand. It’s through that understanding of the problem your Customer is seeking to solve that you’ll do a better job of meeting those needs.
