[HN Gopher] The "five whys" productivity technique
___________________________________________________________________
The "five whys" productivity technique
Author : alecsandra
Score : 209 points
Date : 2021-12-06 14:11 UTC (8 hours ago)
(HTM) web link (blog.superhuman.com)
(TXT) w3m dump (blog.superhuman.com)
| padastra wrote:
| 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".
| brightball wrote:
| 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.
| indymike wrote:
| 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.
| Puts wrote:
| 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.
| hinkley wrote:
| 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.
| mrweasel wrote:
| 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?
| quacked wrote:
| 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)".
| SavantIdiot wrote:
| ...or this:
|
| "I feel pressured to do a job that is impossible and it damages
| my self worth."
|
| Which means GTFO and get a healthier job.
| hinkley wrote:
| 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.
| maximedupre wrote:
| 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."
| ysavir wrote:
| > What's the appropriate level of abstraction?
|
| 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.
| tailspin2019 wrote:
| > The appropriate level of abstraction is to find the deepest
| level at which your choices can have an impact.
|
| This is a brilliant insight and immediately gave me an "aha"
| moment on how best to use the 5 Whys approach!
| adrianmonk wrote:
| > _What 's the appropriate level of abstraction?_
|
| 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.
| larrydag wrote:
| 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.
| lowkey_ wrote:
| 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?
| didibus wrote:
| 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.
| sanedigital wrote:
| 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.
| mindtricks wrote:
| 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.
| Sebb767 wrote:
| 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.
| sh1mmer wrote:
| 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.
| throwaway413 wrote:
| 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.
| kamaal wrote:
| There is also the concept of ownership, that you are really
| in total ownership of any situation.
|
| I think the 5 why's should arrive to what part in your
| circle of ownership does the issue lie.
| sidewndr46 wrote:
| 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.
| bootstrapsite wrote:
| 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?
|
| Anybody got any advice for me?
| egypturnash wrote:
| 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.
| airstrike wrote:
| 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.
| xmprt wrote:
| 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.
| TheOtherHobbes wrote:
| This works up to a point. Unless the problems are political and
| can't be fixed at the level at which the questioner is operating.
|
| Then it becomes an exercise in "Because there are things I can do
| nothing about without leaving and/or starting a revolution."
|
| This is not an answer most people want.
| EForEndeavour wrote:
| 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.
| sokoloff wrote:
| We would frequently (half-) joke that "the fourth why is 'because
| we were lazy'"
| flerchin wrote:
| It's such a childish game. You just choose the problem you want
| to solve, and work it back from the whys and start at the
| beginning.
|
| When I worked SAFe, I was able to point every single outage at
| the SAFe baloney using this technique. They stopped making us use
| SAFe.
| stakkur wrote:
| A quicker explanation, with some background of the technique and
| criticisms: https://en.wikipedia.org/wiki/Five_whys
|
| Personally, despite the popularity of this technique in the
| Lean/Agile crowd, I've never found it useful for meaningful
| problems.
| maxbaines wrote:
| This is a great summary/reminder of a few techniques good to
| read.
| [deleted]
| jacobyoder wrote:
| 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.
| mlac wrote:
| 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.
| jacobyoder wrote:
| 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.
| mlac wrote:
| Fair points. Sorry you're dealing with it.
| jldugger wrote:
| > "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.
| bdavisx wrote:
| >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.
| laumars wrote:
| 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.
| jacobyoder wrote:
| 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.
| IAmGraydon wrote:
| 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.
| criddell wrote:
| I think I know some people where this question:
|
| > Why did feature X fail?
|
| Would garner this response:
|
| > 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.
| sjostrom7 wrote:
| 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.
| ajkjk wrote:
| 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.
|
| Related, this article about writer's block that was posted on HN
| a few weeks ago: https://sashachapin.substack.com/p/if-you-have-
| writers-block...
| np- wrote:
| > 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.
| ajkjk wrote:
| 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.
|
| ... so yeah, I agree.
| hallway_monitor wrote:
| 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.
| [deleted]
| brainzap wrote:
| time is life
| hinkley wrote:
| > 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.
| 5tefan wrote:
| Enough of literature around to learn and train critical thinking.
| That would be worthwhile and gets the job done in the end.
| asmos7 wrote:
| sadly I've always seen this technique used to assign blame
| gonzo41 wrote:
| And, Why do you think that is?
|
| 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.
| liveoneggs wrote:
| Because you single out a person -> ask them for the
| explanation -> turn the knife four additional times?
| allemagne wrote:
| 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.
| Techbrunch wrote:
| How to solve why the server crashed using the 5 Whys:
| https://vooza.com/videos/the-5-whys/
| pkdpic wrote:
| 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!
| ajkjk wrote:
| 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.
| aflag wrote:
| Why did you leave Amazon?
| CobrastanJorji wrote:
| 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.
| kevinsundar wrote:
| 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.
| necovek wrote:
| 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.
| 908B64B197 wrote:
| > "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.
| didibus wrote:
| 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.
| throwaway984393 wrote:
| 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.
| ajkjk wrote:
| 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.
| RealityVoid wrote:
| 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.
| chucksmash wrote:
| 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.
| usefulcat wrote:
| 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.
| throwaway984393 wrote:
| You can always go deeper.
|
| 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.
| necovek wrote:
| 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. :)
| freetinker wrote:
| A better way of doing this would be the Ishikawa diagram.
|
| https://en.wikipedia.org/wiki/Ishikawa_diagram
| jsight wrote:
| > "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.
| muzani wrote:
| 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.
| ajkjk wrote:
| 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?
| freetinker wrote:
| Strongly agree. Another issue with the measurement cult:
| Goodhart's Law.
|
| https://en.wikipedia.org/wiki/Goodhart%27s_law
| lkrubner wrote:
| I strongly agree. I wrote something similar here:
|
| https://demodexio.substack.com/p/a-master-craftsman-will-
| hav...
| passivate wrote:
| 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.
| stefan_ wrote:
| Oh good, we have arrived at the _no true scotsman_ phase.
| It 's not that scrum and agile aren't working, your team
| just hasn't introspected enough!
| bumby wrote:
| 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
| passivate wrote:
| If we knew of a perfect system without flaws, we'd
| already be using it.
| RealityVoid wrote:
| At that point, it's not actionable either, it's just blame
| shifting.
| snthd wrote:
| >management is incentivized to care about things other than
| shipping/deliverables/this quarter's returns.
|
| Could someone elaborate on how that's done?
| stevebmark wrote:
| 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.
| ajkjk wrote:
| 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.
| stevebmark wrote:
| 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.
| ajkjk wrote:
| 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.
| kqr wrote:
| > 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?"
| digikata wrote:
| 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.
| ajkjk wrote:
| 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?".]
| alisonkisk wrote:
| What else does "why" mean?
| kqr wrote:
| Sure, but even better is to be more explicit:
|
| - Which business constraint was violated?
|
| - Why is that an important constraint?
|
| - 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.
| ajkjk wrote:
| 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.)
| adamsmark wrote:
| I worked at Amazon too. This outcome of a 5 why,
|
| "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.
| shepherdjerred wrote:
| 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.
| alisonkisk wrote:
| Amazon has the most serious "business operations" of the
| FAANGish companies. probably from their roots as low margin
| retailer like Walmart.
|
| Google is creative and technically smart, but always was
| drowning in ad revenue so had plenty of room for slack
| everywhere.
|
| Apple had the creativity and attention to detail in the
| experience.
|
| MS could do everything -- product, engineering and legal
| department -- good enough to protect their monopoly moat.
| ajkjk wrote:
| 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.
| delecti wrote:
| 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.
| necovek wrote:
| Like any tool, it can easily be misused.
|
| 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).
| beebmam wrote:
| >"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.
| bumby wrote:
| 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).
| hkon wrote:
| Having played this game a few times, I have noticed that it is a
| very effective tool for shifting the blame onto people not
| participating.
| joemaller1 wrote:
| There are seven trees.
| ivanstojic wrote:
| If you've never seen the "five whys" technique before, then you
| are probably unfamiliar with its criticisms as well.
|
| This shows a broad spectrum of proponents and critics of the
| approach:
| https://www.google.com/search?q=five+whys+site%3Anews.ycombi...
| mgkimsal wrote:
| And... the top link I get in google is this hacker news
| thread...
|
| Edit: oh, because the link actually has hacker news in the
| query filter... duh...
| hpoe wrote:
| And if you want the non-Google version
| https://duckduckgo.com/?q=five+whys+site%3Anews.ycombinator....
| mynameismon wrote:
| Or if you prefer Algolia: https://hn.algolia.com/?q=five+whys
| kqr wrote:
| 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.
| agentultra wrote:
| 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.
| elteto wrote:
| Ah! A fellow Initech employee...
| bee_rider wrote:
| 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?
| spookthesunset wrote:
| 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.
| smugglerFlynn wrote:
| 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]
|
| 1 - https://en.wikipedia.org/wiki/Ishikawa_diagram
| dsizzle wrote:
| 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.
| mym1990 wrote:
| 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.
| tuan wrote:
| is this just a fancy name for debugging process that SWE do
| everyday, no ? It's basically walking up a call stack until you
| find the bug.
| throwaway413 wrote:
| 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.
| PeterWhittaker wrote:
| 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?
|
| Why not indeed....
| passivate wrote:
| 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.
| imwillofficial wrote:
| ::reads 5 whys::
|
| ::shudders in COE::
|
| Reference: https://wa.aws.amazon.com/wat.concept.coe.en.html
| cwilkes wrote:
| 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.
| BBC-vs-neolibs wrote:
| Not entirely dissimilar, depending on the org.
| manmal wrote:
| This looks like a useful implementation of the Socratic Method
| [1] of asking ,,Why?" until you get to the bottom of things.
|
| 1: https://en.m.wikipedia.org/wiki/Socratic_method
| SavantIdiot wrote:
| "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.
| stevebmark wrote:
| 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.
| hinkley wrote:
| 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.
| tyingq wrote:
| 1 - Why do we think there's a trivial shortcut to analyzing
| problems?
|
| 2 - ...
| itsmemattchung wrote:
| Loved the five Whys as an ex-Amazonian but could easily see how
| the framework can snowball into a blame game.
| zemvpferreira wrote:
| 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.
| freetinker wrote:
| Thank you for this comment. As a manufacturing engineer, I
| really appreciate it.
| allenu wrote:
| 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.
___________________________________________________________________
(page generated 2021-12-06 23:00 UTC)