"Popping the Why Stack" Revisited
As best as I can tell, "popping the why stack," or continually asking why something is done a particular way has its origin at ThoughtWorks in 2007 (as a software building technique anyways, as 6 year olds seem to have this intuition innately whereas management consultants have to learn it at B-School).
This can be used to focus on inefficiencies. The example given in the above linked article is one where a process required printing data and then reentering it manually, instead of transferring it digitally. By asking why enough, they found a way to make the process more composable.
In the above diagram, you can see what category theorists and functional programmers would call composition. Basically X has to get to Z. If you take the f path, you land on Y first. If you can "compose" f and g together, you get a straight shot. The direct line from X to Z gets an awkward "g after f" name, but you could call it "h" and that would be fine. Or you could draw a new single arrow and call it "h." Either way is fine.
This is a good reason to ask why: Why do we need to go to "Y" before "Z"? For some processes the answer is "because switching will be annoying/expensive." Then the question is "why will it be annoying/expensive?" I guess. And on it goes with eventually hitting some kind of budget/personnel/political limit. By the way, this is one of the main purpose of consultants. They can poke at all these limits, act as budget sinks/winfalls and realign relationships... which is a lot of times disruptive. A team that can probe this deeply within themselves probably indicates a decent level of trust, but could also mean a lack of unity. Who knows?
The predecessor of the "popping the why stack" technique was the "5 whys," developed by the creator of "Toyoda Automatic Loom Works," Sakichi Toyoda (his son built the automobile manufacturer "Toyota.") It's been adopted by a few management/manufacturing groups. The criticisms of it are in the Wikipedia article, but I'd like to add two. The first is structural, and the second more related to a particular application of it.
I don't think this is a bad tool, but 5 may not be enough. Not only that, but at each level, there are likely numerous answers. It's a nice idea that we can "pop the stack" (like a pez dispenser) and get increasingly interesting flavors of answers, but the structurally, we have a tree.
So even if there are only 2 answers to each "why", that's 2^5 (32 possible "deep" motivations). So it's not really a "stack" (pez dispenser) at all. And there is something curious about thinking that asking questions leads us to a singular answer. In my experience, the reward for asking questions is the ability to ask more interesting (either specific or general) questions, with the occasional usable but incomplete answer thrown in.
Anyways, the second quibble is that I have seen "5 whys" and "popping the why stack" concepts used not just for processes or the "root cause analysis" for failures, but for motivations. Specifically, I've heard an engineering manager say that after popping the why stack five times, they should arrive at a particular goal of the company (probably a "KPI," "QBR," or business metric of some kind).
This can be a useful technique if we don't think of the "should" we need as being a core business concern. Does this empower people? Does this help inequality? Does this help the environment? Does this serve as a check on fascism? Racism? Misogyny? Oppression in general?
It's too often the case that stopping at 5 or a business goal will stop us from getting to any of these motivations, and when a business goal is in conflict with how we can survive on a planet together, we really need to keep asking why.
If you're concerned about the conflict between how industry (especially tech) works in opposition to human/civil rights, I'd love to hear from you at evan@novc.org. If you're a techie looking for a better path, please consider checking out the "Social Impact" tab at jobboardboard.com or visiting these job boards directly: