As someone who used 5-whys when I worked at Amazon, I love it and the criticisms here don't resonate. It's not about finding one path of causation, or finding everything you can point a finger out. It's about being willing to admit the actual causes and then do something about them.
"Why did our code break?" "Because we habitually ship things without thoroughly testing them."
"Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."
... which, and this is key, has to be followed by managers at all relevant levels changing their processes to fix this. If it's not fixed -- at an organizational level -- as a result of the analysis, fuck off with the 5 whys process, it's just a joke.
I tried to run an Amazon-style 5-whys at my new job and my boss said, oh that was very good, good analysis. Then we did none of the things suggested. Well, there's no point. Just quit. You're going to be mediocre forever until the management chain buys in.
The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.
I am quite sure that Google/Microsoft/etc do not have this quality in the same degree (or they would not have made many of their obvious mistakes). Not that Amazon doesn't make mistakes; they just make different kinds than a lot of other companies. And of course plenty of departments at Amazon don't do this well either; it's too big a company to be culturally uniform. But at least the norm is to do it well instead of badly, which is more than you can say about most larger-than-startup-sized companies.
I did a Five Whys for Amazon once. It had been an embarrassing incident for the team. We had put a huge new feature together over a few months, and when we turned it on...nothing happened. The whole feature had been entirely disabled by a typo I made in a configuration change. At the time, we had a test team that was tremendously overworked and tested things almost entirely manually. They asked for a couple extra weeks to test our new feature but eventually greenlit it. My Five Whys basically asked "how did this get to production if it didn't do anything?"
My manager handed it back to me and said "this takes the blame off of you for this mistake and puts it on the testing team. Ask different questions."
So I wrote another one that was 100% focused on me. "Why did this happen? Because the config was wrong." "Why was the config wrong? Because I made a typo." "Why didn't I notice the typo? Because I didn't run the feature after making the change." "Why didn't I try it out? Because the feature is very difficult to invoke or observe." "Why is the feature hard to invoke directly?" "Because <x,y,z>."
What I learned from that is that the problem with Five Whys is that there are many different branches of questions that are worth asking, but that design only allows for exactly one path. Choosing which one is an editorial decision on the part of the author. The outcome of a 5-Whys document is, by its nature, one change. But most of the time, outages at mature tech companies are the result of several different problems coincidentally lining up (if exactly one thing going wrong caused a major problem, that itself is the second problem), and a postmortem process really needs to examine each of the things that went wrong separately.
Yeah, I don't think blaming the typo is the right outcome for this. The right outcome would be identifying where your testing / review / launch / validation process failed. Evidently it failed, or nothing would have gone wrong even when you made a typo.
Usually the response to a good root-cause investigation isn't "I'll try to avoid making mistakes" (although sometimes it's just a mistake and no changes is required). The outcome should be a new rule or practice for the organization, some kind of decision that determines how things will be done going forward to make the error less likely. This almost always requires a leader at some level declaring by fiat that things will be done this way going forward; if your managers aren't doing that, they're not 'leading' at all.
This is not accurate. Im currently working on a "5 Whys". I am writing it in a nested bullet format which allows multiple branches. Example:
* Main Why?
* Why 1?
* Sub Why 1?
* More Whys
* Why 2?
* Sub Why 2?
Its totally fine to have more than one change or path. Theres nothing in the nature of the doc that requires one change or one path, thats just an assumption.
The "theory" of 5-whys is that with a proper mindset and the right questions (coming out of that mindset), you can find a root cause to anything in at most 5 linear steps.
You are certainly free to adapt it in whatever way you wish, but you don't call that "5 whys" anymore. TBH, your approach looks closer to fishbone diagrams instead.
>The "theory" of 5-whys is that with a proper mindset and the right questions (coming out of that mindset), you can find a root cause to anything in at most 5 linear steps.
I have never heard of this before. I had heard that the 5 why's was a way to force a person or team to be more than surface level about why a feature is needed or a problem happened.
And also, ONE way to represent the work was through a fishbone.
But part of the 5 why's is that multiple "why's" converge (e.g. why did this break? because we have no change control... why does X process suck? Also, because we have no change control)
My favorite feature of 5 why's is they push you into going deeper. If a process keeps failing, the 1st level reason for the failures can be different (X person changed the data, dates suck, the primary server crashed), but the 3rd or 4th reasons should show some similarities and ideas on how to prioritize (e.g. if we have automated unit tests, it would have prevented 25% of our outages!)
I don't think that's an issue per-say. You can't fix everything, but you can at least try to find the most likely path and do something about it. Even if it wasn't the biggest cause, you made progress towards improving some of the variables at play for the issue.
There's clearly something to learn and improve in your 5 why's. There was a hard to test feature, typos were allowed to pass through validation in the config, there was only one person making the config change and seemingly no one to review the change, etc.
Ok so all these seem like they'd contribute at least somewhat to why this issue occurred. Sure there might have been other deficiencies, like why didn't the test teams also forgot to test the feature or thought they did but didn't, etc. But you can't address everything.
So maybe you update the validation code for the config so it is more likely to catch such typo in the future. Maybe you make improvements to your config change management and enforce a 2-eye rule on config changes, and a 2 person review on the change. Maybe you make improvements to your testing capabilities so that such hard to trigger features become easier to write an automated test for. Maybe the leadership learns to inssist on planning more time for dev QA and writing tests when launching the next big feature, etc.
There are a plethora of tools that go into a problem analysis, six sigma, lean, or whatever labelled toolbox.
The important thing is being able to use the tool, not just do it, as the parent mentions in their comment:
It's easy for a manager to say "do a 5 whys". It's another to be able to support fixing what it finds out. Or if not your manager and just you or a small team with seemingly everything in your control to introspect and challenge assumptions or prior work that might need rethinking. That's the hard part.
Toyota's implementation of Five Why's actually doesn't stick to just one path, they can branch out or do multiple of them. But you're right about multiple causes and the need for alternative strategies to find and fix causes.
The problem with process is that most people follow it as prescribed rather than following the spirit of it.
> "Why didn't I try it out? Because the feature is very difficult to invoke or observe." "Why is the feature hard to invoke directly?" "Because <x,y,z>."
Now that's engineering.
Code or any feature that's hard to get in isolation and test is prone to fail in unexpected ways. And if the failure in prod is big enough that gives you the opportunity to show that it's cheaper to invest engineering time to make this part of the product better instead of picking up the pieces later on.
I has a similar experience where I had to 5 why a issue and... the gist of it was that the why was because I bungled it up. I just.. saw it as an issue while I wrote my stuff, added a TODO and then... just never did it. So then, after the first 2 why's I could only answer in the back of my head, "Because I'm fucking stupid, that's why!"
I get the idea with the why's but sometimes, it's just that simple, you can't really go deeper than that. I fucked up.
The question then becomes: what could you have done for the "system" to automatically prevent you from forgetting that? Would an end-to-end or smoketest prevented that? Would having a TODO-linter have stopped this? Would singing your country's anthem from the top of a hill prevented this (I dunno, maybe it's a really magic song)?
You are looking for improvements to your process that will help you protect yourself from yourself. :)
Exactly this. We have a saying in the GxP QA world - look at the process, not the person.
Anyone can make mistakes, and sometimes the naive 'why' of something is just that someone made a mistake. But if you focus your questions on the process, it becomes 'why did the process allow this mistake through'. Perhaps a checklist could have helped. Perhaps you need a QC [1] step in the process. Maybe the instructions aren't detailed enough.
[1] Though there are many sometimes subtle differences in how these terms are used across industries, generally the difference between Quality Control and Quality Assurance is that QC is part of the process (e.g. a built-in check in the system), while QA is a separate process making sure these checks and balances are working properly.
To bring in the car analogy, QC would be your tire pressure sensors, and QA would be your mechanic checking that the pressure sensors are working correctly.
Why did you fuck up? Because you didn't get enough sleep. Why didn't you get enough sleep? Because you were on-call at 3am. Why were you on-call at 3am? Because the apps keep crashing once a week. Why are the apps crashing once a week? Because nobody has prioritized fixing them. Why has nobody prioritized fixing them? Because the feature work is higher priority.
Or: Why did you fuck up? There was no validation of the change before applying it. Why was there no validation of the change? Because we've never prioritized validation. Why have we never prioritized validation? Because we don't think it's important. Why don't we think it's important? Because we never look back at our previous failures to see if there's a pattern of failures from lack of validation.
So even from "I fucked up" we find a number of problems and things we can start addressing.
Major cause of burnout and incidents, yet management will ignore this particular "why", because their promotions are based on features, mostly. Also why it sucks being an SRE unless the company empowers your team.
The hardest part is usually figuring out a reliable way to avoid making the same mistake in the future. "Don't make mistakes" is never a viable solution to that problem.
I think you can still usefully push past the "I just never did it."
If the problem is that you are overcommitted and things are starting to slip, that's a different problem than "I got distracted by something shiny and forgot." In the first case, it might make sense to try to grow the team, for instance.
"Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."
Does not sound like anything would change. I could chalk up a lot of failures, missed goals or mistakes to this culture of shipping the bare minimum because that's all the time you have. Sometimes it works well, others lead to tech debt that metastasizes because the engineers don't have to use what they built leading to instances like pricing errors that lost significant amounts of money.
Working at Amazon sometimes felt like everyone was gaming the system to hit impossible numbers/deadlines - Goodhart's law at scale.
Hah. I cannot count the number of times we made action items as a result of five COEs and the ultimate result was a SIM issue permanently sitting in our queue because there was always something more important to do.
It worked pretty well in my org (fulfillment/supply-chain) but maybe I just got lucky. As you might imagine that org was pretty functional, being the backbone of the retail business.
In my experience at Amazon, orgs which deal with physical things operate differently from orgs which deal solely with digital things. So the advertising org was more very "move fast and break things", while the Kindle org was more "if we ship a broken build then we brick millions of pieces of hardware, so we're going to manual verification on daily builds". Fulfillment having a healthy/diligent development culture fits that experience pretty well.
> "Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."
I find answers like this to be the real downfall of a five whys approach. Is it really true that product managers have "no concern about the code quality"? At best, that seems like a statement that the product managers will not accept, but even worse, it isn't directly actionable.
I'd prefer something like, "Because our teams are not given n days for quality assurance before feature delivery", or "because our estimate of 21 days to deliver was replaced with 14 days without our input".
If it isn't measurable, how can you make the needed changes? "Care more" isn't quantifiable.
I disagree so strongly with this. There's a pervasive fallacy in the industry that things that aren't quantifiable, or are hard to quantify, can't be real or true. It's just wrong: they can be very true, and often such things are deeply true but whole organizations are ignoring them because they haven't found a convenient way to shoehorn them into their KPIs / OKR framework / whatever.
Yes, it is often the case that product managers have no concern about the code quality. No, the problem is not that N days aren't given for QA. If the product managers talk to the engineers, they will get a sense of the problem. If they work as colleagues they will be in this sort of discussion all the time. When a product is implemented, they'll keep talking, and they'll be aware that the major corners are being cut, and they'll understand that that puts it at risk. Then they can make better decisions to avoid this.
If they have that information and still make the wrong decisions, then they have perverse incentivizes or are behaving maliciously to the business.
And if they try to reduce the intuition and professional opinions of their engineering team to some numbers -- estimates, QA lead times, bug counts -- which are pitched over the wall, badly summarizing actual expertise -- then they will fail, badly, over time, because that is a nonsensical way to work.
Good decision-making and leadership, imo, don't need you to have found ways to quantify things, and your time is often better spent doing good work than waiting for things to be put into numbers. Quantification helps, sometimes.
"If it isn't measurable, how can you make the needed changes? " Doesn't that question sound absurd? You make the needed changes! What does measurability have to do with it?
I'll take the opposite view here, mostly because I think it's an interesting issue and don't know where I fall on it.
If you can't measure the difference, how do you know you've helped? Or if you've made it worse?
> "If it isn't measurable, how can you make the needed changes? " Doesn't that question sound absurd?
No, because you're saying something is needed with no observable difference when it's changed.
If you can't in any way measure the difference between action and inaction, isn't that equivalent to saying "my action is indistinguishable from inaction"?
If someone said "I've fixed the bug, no tests changed and you won't see a difference in the reported issues but it's fixed" how confident would you be that they've actually fixed it?
There's a big difference between something being discernable and something being measurable. For instance -- suppose you join a company and you can tell the culture is messed up from day 1. You go to the CEO and tell them as much. Should they ask: "can you prove it? where's the data?" or should they say: "tell me more, help me understand."
.. Obviously the latter. If you can perceive it, it's a valid belief. Obviously it is _somewhat_ subjective, but even subjective things can be true, and from someone with good judgment, they usually are. You probably don't need to go run a survey or something to prove it -- just make a convincing case, in words.
Every case is like this one. You can make changes and see that you've had an impact without ever getting distracted by finding a way to put it into numbers, quantification, and measurement.
This is all hypothetical, but suppose it makes for happier staff. Do you think you can best discern the happiness of the staff by.. sending out a survey? Or maybe you'd be able to tell by the feeling of the room in the cafeteria, or the tone of your conversations, or the enthusiasm they seem to show at their jobs, or the messages they send you?
Indeed, the five Why's is just one of the starting points for introspection. Each person/team/department/org needs to find ways to generate consensus and actionable items out of that exercise. Reactionary phrases like "because x sucks" aren't very useful.
Talk to industrial engineers and they’ll tell you these exercises are just a starting point to try and understand the problem. We all like to pretend there are always simple solutions (if I had a nickel for every time somebody told me the root problem was ‘we just need more people’…) but I’m practice, process improvement is often messy and convoluted until you drill deep into the system
It sounds like "Because our teams are not given n days for quality assurance before feature delivery" is just a further Why down. I can see how this becomes a loop if someone isn't trying to get a real answer though.
> As someone who used 5-whys when I worked at Amazon, I love it and the criticisms here don't resonate. It's not about finding one path of causation, or finding everything you can point a finger out. It's about being willing to admit the actual causes and then do something about them.
You're right, of course. To do causal analysis at all, you have to do it respectfully and well. That's the first step.
When you have the first step down, there are other analysis methods that are not five whys that does this better. One of my favourites is Leveson's causal analysis based on systems theory (CAST).
These dig wider as well as deeper, and offer more interesting questions to ask along the way rather than just "what caused this?"
imo, the question "Why?" is really supposed to be more like "How could this have happened!??". It really makes a lot more sense that way.
[edit: to respond to the dead comment about what else "Why" could mean, the difference is the emotional valence. It's not asking the _factual_ question of how it happened; it's applying the appropriate outrage and embarrassment to the fact that it happened. "My god, we messed up! How can we ensure it never happens again, with urgency?".]
- What control mechanisms did we have in place to prevent that from happening? Have they prevented the constraint from being violated before? Why where those mechanisms insufficient this time?
- What control mechanisms didn't we have? Why not?
And so on. You get fan-out of much higher degree that way, but it also, in my experience, is a much more efficient way to search the causal network.
I don't really agree. The model you describe presupposes a functional framework for decision making -- constraints are in place and respected; controls exist, etc. Most of the time the result of the Whys process is, in my experience: "oh, we really need a framework for constraints/controls/etc around this".
I guess it looks very different depending on the business you're in and how codified everything already is. If you're investigating failures in, say, a manufacturing process, everything is pretty rigid already and you're finding problems with the rules you already have. If you're investigating failures in a hodgepodge software engineering organization, the problem is that there is no rigidity in the first place, and those processes need to be created from scratch.
I'm mostly familiar with the latter, and usually the result of whatever you come up with is a place where leadership ought to be directly applied.
(I'd hazard to claim that: if you do a 5-Whys in an organization and the leader of the organization doesn't see something that they can go fix directly -- not by delegating but by leading, themselves -- either you did it wrong, or they're a bad leader.)
While there are other techniques, one thing to think about is how often the analysis/review group is that particular group. In large organizations, if they particular issue being analyzed is with a group that hasn't gotten together before, a more accessible technique like five whys could be easier to use and mediate. If the group regularly gets together to do such analysis, or has a longer range time frame to complete the analysis, more involved techniques could get to deeper work.
>"Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."
If you want the 5-whys to not be a joke, you certainly shouldn't be arriving at such strong conclusions without an enormous amount of evidence. There's likely many other explanations.
A serious answer to a "why" question requires enough evidence that it could not be explained in any other way.
If we just want to arrive at strong conclusions that fit in with our priors, so be it, but at least be honest that you don't care about the truth.
When the 5 whys technique is used for actual process improvement, data collection is part of the process to measure improvement of refute a claim. The next steps usually test multiple theories (sometimes concurrently).
The Five Whys are a great as a tool for personal introspection, but in business it seems to become an exercise in chaotic story telling, with the final "answer" highly dependent on the initial assumptions.
Let's take this in a different direction:
> "Why did our code break?" "Because we habitually ship things without thoroughly testing them."
.... or "Because Bob didn't write proper tests for his patch, so the bug it introduced went undetected"
It obviously would suck to be Bob here, but the point is there is no single right answer to any of the whys and each choice along the way will lead us down very different narrative paths.
You can't achieve greater certainly simply by chaining multiple uncertain statements together.
The post in question is a good demonstration of how you can misuse the 5-whys, and it gets well deserved criticism for that. It's obviously not getting anywhere 5 levels deep, so it's asking the wrong questions, and honestly, giving very bad answers that don't lead anywhere: 5-whys require a specific mindset first. Thus, the final "root cause" is very suspect and there's one too many "feel" and "think" in there.
To illustrate, the answer to #2 of "Because I am constantly tempted to check my email, rather than work on important projects." is lacking in substance to answer "why are you getting distracted" (it says the same thing in slightly different words). You can go on-and-on in the same vein. "Because my email notifications pop up and I check them out", "Because when I check my email notifications out, I read the email and now I've lost my context and got immersed into the email topic instead"... That's not helpful at all.
As soon as you get to "I get easily distracted by email", that's already a problem worth solving ("root cause"). And it can have multiple solutions: 1. if you are a blocker for something, move that to an email list of people, a "board" or "forum" discussion; 2. if you are not a blocker, stop notifications and set checkpoints for when you'll read email during the day, and open a side-channel for urgencies if it's ever needed.
If that's not the root cause (it is actually expected of you to be responsive even if you are not a blocker to anything), only then is it worth digging deeper to find problems in the team that make this so.
Of course, I am working with the assumption that being extremely responsive to email is really hurting this person's work (they were not hired to be responsive to emails, eg. as a technical architect to support a development team).
> Then we did none of the things suggested. Well, there's no point. Just quit. You're going to be mediocre forever until the management chain buys in. The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.
There's a lot of cargo culting around Amazon, but having a strong engineering culture and technical leadership is almost never what companies choose to emulate.
True engineering orgs are quite rare (and will often ship disproportionately compared to their competitors. Just think of pre-merger Boeing for instance).
> I am quite sure that Google/Microsoft/etc do not have this quality in the same degree (or they would not have made many of their obvious mistakes). Not that Amazon doesn't make mistakes; they just make different kinds than a lot of other companies
I'm interested what are the obvious mistakes you are thinking about.
> The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.
Is comingling inventory among sellers long term thinking?
I actually worked on that project, and yes, it is. It was a good idea whose implications were not fully understood -- but Amazon will eventually get it right and it will stop causing problems, because they have a good 'make mistakes and fix things' loop. (I think this has already started happening but this moves very slowly.)
The main reason for commingling inventory is to be able to ship a product from the closest warehouse if it's the same as something in another warehouse (if you order it on the east coast and the nearest Amazon-owned inventory is on the west coast but an FBA seller has it on the east coast, ideally you could fulfill the order from the east coast).
The problem is, nobody anticipated the degree to which sellers began cheating this system when they figured it out. I don't think Amazon was ready to fully moderate the whole system against exploitation. They are no doubt working on it but it's a huge battle.
To me your message embodies the criticism of the five whys. You don't run a five whys analysis because it's not effective. You run a more open ended root cause analysis with the goal of understanding issues, which is effective.
I believe that what I'm talking about is what "five whys" _actually_ is, and what a lot of the critics think "five whys" is, which they are rightfully criticizing, is just not a thing at all -- it would be trivially useless and ineffective, and obviously is so to anyone who does it.
In particular 'five whys' when run correctly has neither a set number of whys, nor a particular linear structure, nor a fixation on assigning blame, and involves actually taking actions in response to the root causes, not just creating meaningless action items. If those don't apply, you're not doing five whys, you're doing some bizarre aberration of it.
To me that sounds pretty clearly like not the five whys: there aren't five whys, they aren't linear, and you're not asking "why" at every step. The history of the five whys and Toyoda make it clear that it's 5 linear whys. You're performing a root cause analysis, which I suspect is why you find it effective. VS the five whys are not an effective analysis tool. Maybe where we see things differently is you consider the non-five-whys analysis part of the five whys, and I consider it "root cause analysis". For me, an issue with still calling it the "five whys" is watching other folks less familiar with how to do root cause analysis using the low quality and awkward "five whys", without any clear direction that they shouldn't use that strategy because it's not effective.
Yeah, I guess what I'm describing is "the thing we did in the Amazon COE process that we called 5 whys". Whatever that was called, it's definitely better than what you're describing.
Management has to be rewarded by _their_ management for delivering on abstract improvements that make things less bad without necessarily pegging them to metrics and returns. Their management has to be rewarded by the managers above them, etc, all the way up to.. somebody. Ideally the CEO because the board ain't gonna do it. Bezos was great at this: it was always clear that fixing your shit was the first priority, because the C-suite understood that for a company that large to scale its labor, teams have to not be blocking / causing friction for each other. Hence being very forward-thinking about abstracting everything out into service-oriented architecture. (although it took like two decades to actually get there completely. My org, fulfillment, was one of the last to do it, and only finished after I left.)
Not for months at a time, which is what I wanted to do (and did). Also, no, remote work wasn't really a thing at the time anyway. But more importantly I don't believe in being continuously employed your whole adult life. It feels dumb and unhappy.
All of my personal 5 whys like the one in the article end the same way.
"I'm always busy but I don't feel productive with my time"
Why? "Because I get distracted by email, refactoring, slack, .."
Why? "Because I don't really want to be doing any of this, but I feel like I should be at my computer trying to force myself to do it."
Why? "Because I have a job and therefore some responsibilities, and I wasted a lot of time last week so I guess I need to get things done this week"
Why? "Because I'm sitting at a computer at home, surrounded by nobody, writing code for projects I don't really believe in, that are being mismanaged outside of my control, and what rewards there are (salary) are totally decoupled from the work, and I have lots of money saved up from doing this anyway but the modern world makes no sense and there's nothing I really want to be doing so I guess I'm working."
... ah, you say, you can't work because you're burnt-out and depressed. Yeah, probably. But I mention this to make the point that: if you can't focus, perhaps you just _don't want to be doing whatever you're doing_. It is sometimes hard to admit that in this modern world where you're supposed to be a hard-working adult. But you don't .. have.. to be employed, or working a 9-5, and for many people it's deeply unnatural, I think, to be doing this your whole life day-in and day-out.
> if you can't focus, perhaps you just _don't want to be doing whatever you're doing_
This is the thing that always gets me when reading things about productivity, how to get more done at work, etc. At first glance, the issue seemed to just be compensation—if you just pay us workers a fair wage we will be happy. But as software engineers we are generally fortunate with high salaries. So, what happens when that compensation comes and you still feel extremely unfulfilled? I don’t think the problem is the depressed workers, it seems like the whole entire system is built to slowly drain the life out of us.
I was talking to a coworker who said to me -- what do you think about asking for bonuses like my friend at FB gets, to get us to do more work? I said: I'm paid more than I know what to do with already. It's not a problem of money, it's a problem of managers who aren't leaders, and lack the ability to inspire anybody to do anything. It's no surprise we don't get much work done if nobody is inspired or proud of what they're doing.
She had apparently never thought of this, but agreed. I guess a lot of people think it's about the money and then wonder why they can't get much done. imo the money determines who works where, but has almost nothing to do with the amount of work that gets done.
This and your previous comment really resonate with me. Even if you're solving interesting problems, it's hard to stay motivated in the long term if you don't feel like you're providing a useful service to other humans and in some way making their lives better. Even though personally I certainly don't have more money than I know what to do with, a deeper purpose is much more valuable than doubling my salary.
Guys, what are we going to do? I have the exact same problem. I don't need the high salary anymore but I don't know what to switch to. I't doesn't help being in a country where nothing interesting is happening. How do we find something which feels worth fighting for? I want to work extra hours because it's somthing I believe in but it can't be a webshop backend or an ad optimization engine. Is there something people really need that programmers can help with from around the world? It feels like most issues are political or psychological
I joined a trade union, we're always doing lots of really valuable work, helping people who need help. I'm the union's IT officer now, daily work is just managing email lists and arguing with MS 365, ongoing projects are updating our website and dues payment system. Doing this work helps our activists, organisers, and retained lawyers do their extremely valuable work. I'm not paid, I do it in spare time around an unrelated full-time job. I feel good about it. If you've got any useful skills, or just some free time, you can support anyone you see out in the world doing good.
> perhaps you just _don't want to be doing whatever you're doing_
There’s a balancing act between doing things that need to get done and doing things that you want to do. Too much of the former is miserable for you. Too much of the latter is miserable for everybody else.
I’ve had to go to bat for people to work on things that maybe aren’t the absolute most efficient short term use of our resources because working on it will make them either happy or less unhappy. But only rarely can I state it so plainly, so I often wonder what takeaways people are coming to.
I've never understood where to stop a root cause analysis, and the "Five Whys" has never helped at all. What's the appropriate level of abstraction? Eventually you get down to:
...
"Because the sales targets for the enterprise are unrealistic"
"Why?"
"Because the Board of Directors can't attract investors with reasonable sales targets"
"Why?"
"Because investors are only interested in a company scaling at a certain rate"
"Why?"
"Because investors are greedy"
"Why?"
"Because when God first created Man, He also created Temptation..."
The concept of a "root" cause is silly, because the roots of a plant spread far and wide and have many different ends. In the analogy, if the plant is the "problem", and the root is a "cause", then there are hundreds of different roots (causes) that contribute to the plant (problem). People are always trying to assign a single "root" cause as if there is one. Many causes contribute to systemic failures, and often times fixing any one of the root causes would have delayed the failure for another cycle, without actually addressing the procedural risk. Your technician accidentally skipped a step, sure, but he skipped a step because he was in a rush, and he was in a rush because he was overworked, and he was overworked because of those damn sales targets, and...
If we're interested in "root" causes, then we need to end up with a list of several causes that combine to result in the problem. If we only want a single cause, we should call it a "seed" cause, as defined by "this problem (plant) is guaranteed to happen (grow) every time this cause (seed) occurs (is planted)".
I think you're taking the 5 whys to literally. The plan is not to ask why five times and replace the issue text with the fifth answer, but to take a moment to inspect what actually caused the issue instead of directly trying to fix the symptoms.
Sure, there's a chance that there is no root cause (although, at least in my experience, there usually is a major contributor) or that it's something that's not easy to fix right now, but at least is shows you what issues are brewing below and what you need to put on your roadmap. And, in the best case, you might actually be able to fix a bug higher up the chain directly and resolve future issues.
When we used 5Ys at Uber SRE I always like to say that you are looking for a tree of depth 5 but if it's width 1 you've not tried hard enough. "Root cause" or at least the idea there was a single factor that was the defining feature of an issue is hardly ever true.
There is quite often one symptom that is pivotal and cause a critically failure, but generally that symptom itself is a result of multiple inputs.
I'd simply say 5Ys should be a rule of thumb to get folks to be sufficiently inquisitive to keep asking follow-up questions about whatever they are investigating until they've hit around 5 questions per area.
Hard disagree, I would rather have multiple clear and singular RCAs than any 5Y exercise that is >1 width. Too much context to follow to accurately drill into each cause per an RCA, from my experience.
You end up looking for random causes to increase your tree width, instead of the actual analysis at hand.
As long as you prune branches that don't have action items, what's the problem?
5 why's presents a list of action items, and a justification for them. One action item could depend on two leaf nodes of the RCA, or solve multiple leaf nodes.
The appropriate level of abstraction is to find the deepest level at which your choices can have an impact. The purpose of the exercise in general is to make sure we aren't investing energy into solving a problem when that problem may manifest in different ways. To use the article's example, addressing the problem of "I get distracted by emails" is insufficient if the subject will just look for other ways to be responsive, thus reducing productivity. There's a deeper level at which they can impact the chain of events, so we want to discover that.
In your example, there's nothing we could really do about "when God first created Man, He also created Temptation..." or "investors are greedy". But we can impact "investors are only interested in a company scaling at a certain rate", since we can provide feedback about how the current processes impact scaling rates. That would be a good starting point.
> The concept of a "root" cause is silly, because the roots of a plant spread far and wide and have many different ends. In the analogy, if the plant is the "problem", and the root is a "cause", then there are hundreds of different roots (causes) that contribute to the plant (problem). People are always trying to assign a single "root" cause as if there is one. Many causes contribute to systemic failures, and often times fixing any one of the root causes would have delayed the failure for another cycle, without actually addressing the procedural risk. Your technician accidentally skipped a step, sure, but he skipped a step because he was in a rush, and he was in a rush because he was overworked, and he was overworked because of those damn sales targets, and...
>If we're interested in "root" causes, then we need to end up with a list of several causes that combine to result in the problem. If we only want a single cause, we should call it a "seed" cause, as defined by "this problem (plant) is guaranteed to happen (grow) every time this cause (seed) occurs (is planted)"
I understand what you're saying here, but I feel like you're focusing on the semantics of the argument rather than on its core message.
I think the reason Five Whys seems silly to a lot of engineers (or engineer-minded types) is because we naturally progress through the first few whys on our own. Our entire work is basically: "That didn't work—why? Because this function didn't get called—why? Because this if-else branch went the wrong way—why?"
Other fields don't immediately critique facts when presented to them. They're asked to update a model before the 12PM call and the get right on it. Five Whys gives them a framework for pausing, thinking, and critiquing their tasks before they set off on them.
I'll note that the engineer's default criticism isn't always positive: sometimes engineers overly-question and end up derailing the actual work. Critique is important, but sometimes executing according to the plan is more important.
That line of thinking is actually really valuable, here's some insights:
(1) The company has either a sales issue or a pitch issue, if reasonable sales targets can't attract investors.
(2) Investors aren't adequately informed on the space and may not be a good fit for the company, if they're only interested in the company if it scales faster.
(3) Alternatively, if investors are short-term greedy, they may be informed on the space but not see a long-term viable path (in which case, silly of them to be investors, but also, analyze why they're long-term bearish).
(4) What other measures could be indicative of success and worth showing to investors, instead of unreasonably high sales projections?
I think it's unknowable, but you have to make a guess.
It's exploration, so you don't know if your time investment will pay off. It's like exploring for natural resources: you may discover a lucrative deposit or you may discover nothing. You can't know without trying.
There's no way to tell in advance whether you should spend more effort looking. There's no formula or rule that can tell you the right amount of searching because that would require information you don't have yet.
> The concept of a "root" cause is silly
The concept of ONE SINGLE root cause is silly, but the lesson of looking for root causes isn't that there's exactly one of them. The lesson is that you shouldn't neglect to look.
Fixing the wrong thing is one type of error you can make. One possible cause of it is not looking at enough things. This error happens often enough that watching out for it is good advice.
A couple of ways to improve the 5 Why process that I've seen done in the manufacturing world.
1. Create why sessions with key people in the process. Sometimes answers to why are not always apparent. More people contributing can help illuminate
2. If meeting with a group have a facilitator that has done this before.
3. The group needs to have equal say and contribution. No one, including managers and leaders, can overrule or dissuade discource about the answers to why. Everyone's input is equally important.
You just did a 5 why lol. Interestingly enough, for the plant it took you a while to arrive at the fact that the seed is the true cause of all those plants growing where you don't want them. Next you'd ask why there were those seeds in the field in the first place, and you might realize they're being blown from some other field by the wind. Now you know what to address.
That said, you're right,maybe there are many sources of the seed coming to the field, and in a 5 why you can recognize that, but target the biggest bang for your buck first.
And in your other example:
> Because the sales targets for the enterprise are unrealistic"
> "Why?"
> "Because the Board of Directors can't attract investors with reasonable sales targets"
> "Why?"
> "Because investors are only interested in a company scaling at a certain rate"
> "Why?"
> "Because investors are greedy"
You're just not asking the correct question.
Yes "the sales targets for the enterprise are unrealistic", but why does that result in the issue that happened?
You would want to come out of it with, even when the sales target are unrealistic, our processes are resiliant to the issue that just occurred. So now ask the Why's that take you to this answer.
I essentially stop going down a level when I get to somewhere I can't really control. For example, I'd probably stop at your realization that "investors are only interested in a company scaling at a certain rate". I can't make even narrow changes to investment mentality, so there is no way I'll make such a broad one.
Unfortunately, this often means there is no resolution either.
At three Why’s the branching factor is down low enough that a quick person can guess what many of them are and compare them with the lunch conversation and water cooler gripes and the capabilities of the team and steer toward something - anything - that is actionable and will materially reduce the class of problem - not just the same problem, but ones with any similarity.
I think that’s the best you can do, but it has problems. One, it becomes a bit of smoke and mirrors for people new to the process. Two, this only works for people who have access and recall of all the near misses and any grumbling in the ranks. Optimists cannot do a 5W justice. Three, I don’t trust any Five Why’s that I’m not present for, because there’s a moment in every RCA meeting where if I don’t judo throw the conversation we end up with some milquetoast bullshit fix that doesn’t fix anything or just makes things worse, and writing code more onerous.
Yep, I'm on the same boat. I just don't see any resolution that I haven't really thought of by doing this exercise.
I'm not sure "Why" is the right question to ask all the time. Seems like "If the only tool you have is a hammer, you tend to see every problem as a nail."
Instead of root cause analysis as blame laying, look at this as more of an identification of diagnostically important reasons. The above example doesn't help anyone. If code was late, would you accept "our developer is incompetent" as a root cause? Of course not. It's possible that they are, but it's also possible that requirements were not clear or that they took toe long to clarify, which led to a reduced amount of time to do actual development.
In a bigger sense though, the exercise is to force you to take a moment to look beyond band-aid solution, not as an exercise to critique capitalism.
Another phenomenal manufacturing technique bastardised and ruined by mediocre software consultants.
It's a practical tool, not psychotherapy for engineers. You're not supposed to go namby-pamby hands-in-the-air "it's the culture!" after asking why five times. You are supposed to figure some automation to implement, some tool to build that will help fix a recurring problem for good.
Example:
Manager: Power costs at the plastics plant are way too high!
Engineer 1: Why are we using all that power?
Engineer 2: I figured out we have this press that eats a bunch of electricity all the time.
Engineer 1: Why's that one press so power-hungry?
Engineer 2: It needs to be operated at a super high temperature so it uses all that power to keep warm.
Engineer 1: Why's it wasting power to keep warm? Can't it keep temperature?
Engineer 2: The thing's out in the open and the building is air conditioned, so there's constant heat transfer to the environment. And I found an A/C vent pointed directly at it.
Manager: So we're wasting power on heat and cold! Good Lord! Can't we build a box around that press?
Engineer 1: Good point, George thought of that a while ago but no one's gotten to it I guess.
Manager (to now promoted Joint Chiefs of Ass-Kicking Question Making): Great! Get to it!
It's not rocket science. Everyone knows things stink and you can't get anything done at this stupid place etc etc. You either keep busy tending to the garden or you move on.
EDIT: To answer some other comments the original Toyota technique even included ways to explore multiple causes and other such complexities 50 years ago. It's ironic that lean software gurus can't even copy/paste properly. I would hope they read more books before writing their next one.
Five Whys is just a tool. It really only works if it is used as a tool for finding truth and improving process. It is really dangerous in the hands of people who wish to use a process failure for political gain.
I think the most helpful thing with five whys is that it counter acts blame-games within an organisation. Normally when something happens the natural reaction is to blame someone that did something which is counterproductive, it feels good for everybody else but it doesn’t change anything. But five whys is just a method, for it to work there needs to be a true will to actually change and improve things.
Counteracting blame game comes down to being careful not to ever use certain phrasing common to the enemy. We just had one I threatened to cancel because one of the lead developers was asking how a decision happened and using The Tone.
It’s not a matter of whose hands the hammer is in. Nobody gets to use it at all or everyone will.
Was about to say. Plenty of the examples in this topic seems to want to use it to assign blame and to find the ultimate culprit.. that is not the point. You most likely already know who/what the culprit is, so the 5 why's should be an introspective tool to figure out any unforeseen side effects.
Agreed. In constructive environment with high levels of trust you can often take a shortcut and simply ask: What problem are we actually trying to solve?
i'm currently the only developer on a project. i now have ... 3-5 'managers' (depending on how you count) involved in planning/direction. PM on "my" side, PM on "client's" side, PO on "client's side", and... some other 'higher ups' on each side that drop in now and then.
Recently, they've instituted formal RCA process with "5 whys" and... every 'why' ultimately ends up being my fault. Now... they're not saying 'fault' directly, but no matter how you cut it, I forgot to add another test, or I didn't document something clearly enough, or I forgot some error checking, or... I forgot to remind someone of something or... whatever.
"Oh, don't take it personally! It's not just you, we're a team". But.. I'm the only one doing the work that is breaking, and I'm the only one fixing it, and every documented RCA lives on, pointing out that I made mistakes, and each document is delivered to 12 stakeholders every time there's a mistake, and mine is the only name on it attached to the 'root cause'.
"What lessons can we learn from this?" That we can't sustain this pace, and adding more managers is not helping the situation in any way.
I've been saying for a while we're formalizing way too much stuff, and that most of the practices they're bringing in from other places all had the baseline of "more developers than managers" in a team environment. I'm a team of one, and processes designed for teams of 3-5-10 aren't appropriate, imo.
You’re not taking the why far enough… You need one more “why” about “why” you made the mistake:
“Why did you make the error?”
Was it a competency issue that training can fix? Resource constraint? Process problem? Do you just suck at your job (I say this in jest, but to highlight that you do want to ask the “why” that explains “why” you made the mistake, and not just stop at “Jacob messed up again”). That’s a broken 5 why process…
A proper root cause might be:
“I don’t have enough resources to properly get the job done, and need another developer on the project” or “I’m too time constrained due to overhead meetings to properly perform tests on code”.
I feel the current root cause for why everything is broken is:
“Jacob”
And you want to stop that immediately.
I've gone further in some of these, but sometimes it gets to "there's not enough time or people to do X".
There's been some cases where "I missed X - there's not enough time to check everything and I missed X". "Well, you should have told us X wasn't checked" or "you should have raised the alarm before". I've been raising it for ... 5-6 months. And the whole point of "I missed something" was... it's a mistake/oversight, not "I intentionally didn't check X".
There are rumors of other developers being interviewed, but no one has come on board. Assuming someone does, I suspect the thinking will be "let's double the previous workload - we have 2 people now".
I'm understanding of the situation, to some degree. Pretty much everyone on the project is 'overworked' in some sense, but they've been hiring and doubling up other positions, just not this one. I've been keeping this pace for 18 months. I scheduled one day off - 2 weeks in advance - because I had to drive someplace. That morning, someone noticed a financial bug that was preventing everything from working. 2 hrs later, from my hotel, I had to connect in and review and fix stuff. It was totally my fault - I missed stuff - but there's just... no getting away from it.
Adding in '5 whys' and other formal review processes on top of this situation borders on insulting.
> "I missed X - there's not enough time to check everything and I missed X". "Well, you should have told us X wasn't checked" or "you should have raised the alarm before"
You've probably thought of this, but if X is checkable, then perhaps the question to be asked, potentially outside 5 whys framework is why it's not automated. Or at the very least a checklist developed. Allowing an RCA to fall on 'human error' should be rare, not the default.
Another angle, if there is automated QA in place, is whether the go/no-go signals are good enough. Measures like code coverage can be a signal that your project is cutting QA short, and if it _is_ being tracked and shows green, that's a signal you need more advanced metrics.
In short, if management is shortchanging QA that should be in the causal path. We have an entire section on 'why metrics and tests missed the problem' outside the 5 whys just to prompt participants to discuss these perspectives.
> There are rumors of other developers being interviewed, but no one has come on board
Call me crazy, but if they're thinking about hiring another developer but not inviting you, the sole/lead developer to interview the candidates, then you're being replaced. But if they're asking you to work on vacations, then perhaps this is for the best. (Not that you're going to enjoy being laid off)
> Assuming someone does, I suspect the thinking will be "let's double the previous workload - we have 2 people now".
Well, yea. The alternative is probably to give you a pay cut. It sucks but you usually can't hire your way out of a budget crunch.
>I've been keeping this pace for 18 months. I scheduled one day off
Dude, wtf. I hope you're getting paid very well and/or equity in the company, because that's totally fubar'd. You should be looking around for other jobs.
I think your closing statement is very apt. Your points about tests et al works when there is a larger team so instead of accusing individuals for errors you’re blaming the process. But I can see that process blaming feeling a little more personal when there’s only one person writing the processes.
Yes. As more management layers/people are added, people are all wanting to be "more professional", and seeing "oh, we did formal written RCAs on production events at my last company, we need to do that here".
I did a 6 month gig at a company a few years ago. Team of... 6-8, with a dedicated PM and a good team lead. Company was around ... 80 or so at the time, and there were a couple other 'dev' teams (I think around 35-40 'dev' folks at all - it was growing so hard to pinpoint numbers).
I saw some of these types of processes there - I didn't always agree with 100% of everything done, but there was a team. 1 lead, one PO/PM, and... 5-6 devs and a couple testers - a self-contained unit. It worked pretty well, all things considered.
I'm currently in a situation where it's completely backwards, but they're trying to implement all the 'correct' and 'professional' techniques. Oh, and I'm part time - ~20 hrs per week. Pretty much everyone is part time, either overall, or part time on this project, and... the wrongness of trying to bring in techniques built for full time larger teams seems to be lost on everyone but me.
Unfortunately, there's many corporate environments where technical staff are managed by non-technical staff. This comment isn't debating the merits of that, but when the manager (or especially their manager) doesn't really intuitively understand the difficulty of your work or how much you've accomplished, they measure by other things like "responsiveness".
This is similar to how patients will rate doctors (lawyers, auto-mechanics, electricians) higher by things like waiting room design, ability to make small-talk, willingness to give antibiotics, etc. which are important but actually do not correlate with better care.
So I've found that optimizing for "responsiveness" is important in and of itself, and much easier than the alternative of "let me make sure non-technical senior management person X spends the time to understand my contributions at a deeper level".
Yep. Stuff like this is the reason that I moved from the technical side into management about 4 years ago. Seeing the dangers to my team from managers who don’t understand the challenges and constraints became a situation that I couldn’t take anymore.
Now, since going that route I’ve gotten deep into SAFe (Scaled Agile) because I believe that it truly solves so many problems. SAFe recommends using “5 whys” in certain situation and SAFe itself isn’t without valid criticisms either. IMO it’s still by far the best option for a long list of reasons.
Like anything in the wrong hands though, it can be co-opted. Everything revolves around good leadership.
Very brief summary: five whys techniques pretend complex systems are governed by simple chains of events, where each event undisputably causes the next and there's an objective "root cause" that sets the entire chain off.
In reality, complex systems are driven by networks of causal effects, where some form reinforcing and balancing feedback loops. There's no start or end to a causal pathway, there's just where we choose to look and what we choose to ignore. There is no root cause, there is a myriad of interlocking factors that together dynamically drive the system in certain directions.
Five whys type analyses tend to end up blaming whatever is convenient or culturally acceptable to blame, and leaves many branches of the causal network underexplored.
Five whys is easy to explain and humans love the narrative point of view promoted by a chain of events, but it's a very inefficient way to explore the causal structure of a system.
I like to simplify things and re-purpose an old Twister mat for a game I like to call, "Jump to Conclusions."
"Five Whys," is a variant of this game where you simply roll the dice five times.
If you want to put on a show and dance to let your management and colleagues know you care about quality and are doing something about it, then it's great. If you like false assurances and feeling like you've contributed to a system you cannot fathom or understand it will definitely give you warm tickles. And it makes you sound smart when you put on such an impressive display of initiative and critical thinking.
Example presented in the article uses 5 whys for introspective - there is no complex system to analyze, only author’s own reactions. Author already knew deep enough that reading emails is busywork, otherwise answering one of the Whys in that chain would have required research.
What 5 whys helps to do is to structure your existing knowledge. In my experience it is great when you want to analyze your own decisions, or structure team knowledge about particular issue down to a necessary level of detail.
For actual root cause analysis there are better tools, e.g. Ishikawa[1]
It does look more like a random walk through the Why's. Most worthwhile problems have multiple Why's, some of which you can do something about, some which you can't. The examples where Five Why's actually works are ones where the person doing it secretly knows what the problem is, and just picks a path that will terminate on their desired problem, I guess.
But could there still be some value to this sort of exercise? At least it terminates at something. If it is possible to get rid of that convenient or culturally acceptable blame attractor, at least one problem has be exorcised from the organization, right?
The other thing with five whys is many times the root cause is beyond your teams control. Unless the entire management chain from the top participates you'll not see the organizational change needed. And even then, upper management might just consider the reasons for the failure as a cost of doing business and won't want to change it.
That being said, the process at least forces the team to look at root causes beyond what is visible on the surface. It's a good start but it isn't perfect either.
I really like the five whys to get to the truth of what went wrong, but unfortunately, in practice you only take the whys so far.
For instance, where I work, if we have a large enough on-call issue, we have an RCA to figure out what went wrong. We use the five whys there to figure out what we could’ve done better. However, we usually only really go as far as the engineer’s actions that caused the issue. We usually don’t ask, why did the engineer choose to act in that manner instead of the correct one? Usually the takeaway is “We need a process to make sure engineer does right thing” and not “We need to make sure engineers don’t have too much work so that they have time and space to do the right thing.” I find it’s usually the latter is a better course of action but it’s hard to make those statements or requests, or if you do make those requests, management isn’t as open to taking action.
A very similar algorithm is the foundation for a certain very powerful psychological/spiritual technique called "Core Transformation"[1]. You start with a particular problem or issue that you want to work with and work your way up the chain of intentions recursively to reach a "core state" which then transforms the original issue.
It turns out that, seen through the lens of this process, human motivations form a kind of skein or lattice structure, which terminates (or originates) with a small set of "core states" that are transcendent: bliss, love, oneness, okayness, happiness.
The states are transcendent in the sense that they depend on nothing and are universally available at all times and in all places and conditions. They are intrinsically satisfying, and all actions and behaviors are ultimately aimed at restoring the presence of these states.
It follows that the vast majority of human activity is, in fact, yak shaving! Human history is the story of a massive, intricate indirection through layers of abstraction to attain goals that are already available.
I'm an indie hacker and kind of struggling with making any money with this new path I've taken, so I tried this technique:
[ ] I'm not making money
[ ] Why
[ ] Because i keep getting distracted doing new things instead of marketing
[ ] Why
[ ] Because marketing isn't as much fun as writing new code
[ ] Why
[ ] Because I'm a programmer not a marketer
[ ] Why
[ ] Because i love being left alone and avoid pitching to other people
[ ] Why
[ ] Because I'm just an introvert and sales and marketing feel like shilling and spamming
[ ] Why
[ ] Because i am not a businessman and i just suck sales tbh
I guess I can see my problem but really don't know what to do about it. So I just do it anyway until I develop more confidence and get good at it? Is that it?
Since you asked for advice, here's some that's free... Maybe partner with people who are good at what you are not?
On a more constructive note—and I mean this in the best way possible, speaking from experience, not just being a critic for the sake of criticizing—maybe reflect on whether you're "getting distracted" because you're really avoiding the discomfort of not doing marketing because at a more general level you have a tendency to stay in your comfort zone. So work on breaking that habit instead. I know I'm guilty of the very same thing.
IMHO there are several paths to take once you have brought a problem down to "I am not good at [skill X]":
* find One Weird Trick to work around your lack of X
* get advice/training from someone who is good at X and do X yourself
* find someone who is good at X and pay them to do X
* decide that even thinking about this problem is painful and go back to doing the stuff you're already good at
In general the first two are gonna cost less money than the third, but will probably cost orders of magnitude more time. The fourth path is obviously not going to change anything but to be quite honest it's mostly the one I take with regards to marketing my own art.
Have you tried hiring someone to do marketing for you? Or finding a cofounder? If you're not willing to try those then perhaps you care more about the building part than the making money part and are worried that making money will put unneeded stress and support load on your back when you'd instead like to be building.
The five whys also works well on people who hold irrational beliefs. Ask them why they believe what they do a few times and they will often eventually end up at a dead end or an obvious logical fallacy. It may not immediately change their mind, but it will make them question their beliefs, which is a first step.
> Because the universe is deterministic and the fact that this feature would exist and disappoint was determined 13 billion years ago. It really couldn't have gone any other way.
Exactly. If someone's in the meeting in genuinely bad faith, 5-whys isn't going to improve their attitude. But it can help re-frame things for folks that just hadn't taken the time to consider other viewpoints.
They lost me at "We all strive to be more productive".
Do we? It seems to me that many of us reach a point in our careers when we can maintain a high level of productivity (defined using whatever personal metric we choose (personal metric chosen over any external metric on the basis of our being seasoned professionals who can manage our own work)) for a long period. Sometimes at our cost.
Productivity isn't my issue. Stepping away often is. It's far too easy to devote most of a week of long days to fixing bugs and adding features and tell one's self that a few hours of downtime Friday and Saturday will be enough to spend part of Sunday working on the critical customer demo Monday.
Which went very well, thanks for asking! But how well it went isn't the point. My level of fatigue is the point.
Instead of 5 why's, I offer why nots: Why not step back and take the extra day? Why not give yourself permission to rest (at least a bit) more so that you can sustain this level of quality and quantity for longer?
"And of course, being productive means you can spend more time doing things you enjoy: like spending time with family and friends, honing a skill, enjoying a hobby, *or furthering your career.*"
So...be more productive so you can ... be more productive. Nice.
If your productivity declines, you can use the five Why's and come to the conclusion that you need more rest. I don't see what your "why not" methodology is adding here.
"5 whys" is more direct, but the goal of psychotherapy is to lead you to the root cause by practiced, skillful questioning. The goal is to cut through narratives we create to obscure the emotion. I use emotion intentionally: notice the very last why in this article is a feeling of shame.
We should stop using the Five Whys for root cause analysis, for this and especially for post mortems. The reasons are obvious. A “root cause” will almost never be exactly 5 whys down, there will almost never be only one root cause, and the reasons are a cyclic graph, not a line. The five whys are also random. They change based on on who does them and which why you randomly start on. If it feels like an awkward and difficult root cause analysis tool, that’s because it is.
That’s why it comes down to who is steering the conversation. And someone is even if it looks like nobody is.
A lot of circular reasons come down to human factors, like juggling three things at once is distracting. Adding on an extra thing doesn’t fix that. Making one or two of the three less distracting doesn’t fix it, but it makes it better, it makes progress, and it establishes precedent for policy changes. It’s an agenda you can hammer on every time something breaks until the problem only happens once in a great while.
It’s the fact that 5 Why’s develop their own epicycles that sticks with management. Of the last five three of them had the same kind of conclusion, I guess we’re spending time on that now.
What this technique is missing is how to get yourself out of the trap of self-delusion. It is easy to lie to yourself when answering any of the why questions because our brains will more likely choose a comfortable answer instead of the right one. Instead of getting to the root cause one can easily get to the trap.
I believe the actual technique should be like “break 5 layers of your confidence in a given problem and _question_ everything about it until you build the whole picture”.
In other words instead of asking why 5 times question everything and unwind the knot until you have a straight thread. Sometimes it is not just 5 layers deep.
And one should be brave enough to put their own beliefs and experience under doubt and reassess them from the ground up.
That’s the path that leads to some really interesting questions about yourself, the world around, about other people. That’s what ignites the thought process.
5 whys is an oversimplification of the actual reasoning process. And as with other ideas that get wrapped up in a fancy proverbial form it can be misleading and turns to a cargo cult.
Start with “why should I trust the 5 whys? Will it really lead me to right answers? How? What if the answer is no?”
A lot of these type of tricks try to reduce a problem that is not reducible, at least not in a general way. This sounds great when read to oneself, but the moment you actually think about it for more than a second you realize the bullshit that this type of advice really is.
Namely, there is never only one reason why something is the case at each of the 5 steps. It's usually a linear combination of various causes with different weights. Furthermore the reasons are not definitive, sometimes at best you can assign a vague probability to each. And finally there are unknown unknowns, the inexplicable. You may only have an intuition about something, but cannot put it into words. Remember often times intuition can be spot on and identify things that your conscious mind may not have access to.
I am a fan of linear, critical, singular lists of 5 whys.
I am not a fan of the matrix of whys that some companies have decided to begin implementing because of 1 blog post high up on Google searches that suggests to use matrices to organize multiple root causes.
They don’t need to be combined. I would rather see multiple RCAs each with a singular concrete cause, than a single RCA with a 5x5 matrix of intermingling causes. It makes it harder to address and dig through each issue accurately in context - you’re always reconciling the causes against each other to form a cohesive story, when there’s actually a good chance that there were separate, unrelated causes to your incident.
Five whys is a good technique if you are in a position to truly apply it. Most people are heavily incentivized not to ask the right questions. So it can become yet another kabuki process quite easily.
I think most of these techniques come down to the relationship between the management and employees. If everyone is honestly trying to solve the problem and earnestly listening to feedback from people above and below, than almost every troubleshooting process works. If the goal is to point blame to another team, then every process will fail.
On the other hand, stepping through a systematic process invented by Toyota and arriving at the answer "the root cause(s) are beyond our direct control" is a plausible way to (1) not waste time on futile ideas, and (2) get managers off your back.
Is there some significance to the number five? I assume that's just a rule of thumb of where the true root arises, but no one seems to be questioning this seemingly arbitrary number.
I think this is typically the number where one comes to the actual root/s of a problem. If you get there in 3, I don't think anyone would decree it as a violation of the technique.
This is fantastic and obviously not what I expected at all. Im totally going to file this under 'wisdom to remember for the rest of my life' thanks for posting!
Link at the bottom is to “the wheel” which I was expecting to be https://en.wikipedia.org/wiki/Breaking_wheel the torture device, instead it is a way to select the weekly component talk.
Nah, any technique that gets people thinking about root cause analysis is worthwhile, but like most lean techniques they require a level of psychological safety in the organization to be effectively used.
Exactly. No methodology can overcome a low enough baseline of trust. Over time, cynicism gets equally distributed and the justification for literally any process or technique becomes vapid corporate kool-aid. You're just left with thinly-disguised attempts to assert power met with toxic resentfulness.
The way I see it, there's a spectrum of trust that goes from one extreme where almost no process works well, and the other extreme where almost any process works well.
So there's the easy discussion of how your technique is supposed to work, and then the hard discussion of how much trust it requires of the people involved.
"Why did our code break?" "Because we habitually ship things without thoroughly testing them."
"Why?" "Because our culture has product managers demanding things with short deadlines and no concern about the code quality."
... which, and this is key, has to be followed by managers at all relevant levels changing their processes to fix this. If it's not fixed -- at an organizational level -- as a result of the analysis, fuck off with the 5 whys process, it's just a joke.
I tried to run an Amazon-style 5-whys at my new job and my boss said, oh that was very good, good analysis. Then we did none of the things suggested. Well, there's no point. Just quit. You're going to be mediocre forever until the management chain buys in.
The reason Amazon scales well and can do so many things is that that their management is incentivized to care about things other than shipping/deliverables/this quarter's returns. It's still about the business overall, but Bezos' long-term-thinking has infected the entire company with long-termism and it's very effective.
I am quite sure that Google/Microsoft/etc do not have this quality in the same degree (or they would not have made many of their obvious mistakes). Not that Amazon doesn't make mistakes; they just make different kinds than a lot of other companies. And of course plenty of departments at Amazon don't do this well either; it's too big a company to be culturally uniform. But at least the norm is to do it well instead of badly, which is more than you can say about most larger-than-startup-sized companies.