Just doing work without an eye on the big picture rarely satisfies anyone. We want to know what we’re doing matters and that means knowing why we’re doing it. This is true in all walks of life and certainly so in software development.
If you simply ask a programmer to implement a feature, but fail to share the purpose or the justification for said feature, all you get is a code monkey. Code monkeys merely translate requirements into code verbatim. There’s no room to trade concessions with the designers if I don’t know what you’re trying to do.
So not only is it demotivating not to know why, it’s also bad for productivity. Figuring out what the problem really is is how good programmers judo the problem: “Yes, what you’re proposing is one way to solve it, and that’ll take 50 hours. But we can solve the same underlying problem by doing this instead and that’ll only take 8 hours. How about it?”
Sharing the context shares ownership. Now we’re all working on solving the problem the best way we can. Not just laying the bricks in the order the big man tells us to.
Eric
on 10 Jan 13Your Amazon link is broken. Great article.
Kathy Sierra
on 10 Jan 13When I taught programming at Sun (RIP), we called it the Why-Who Cares-So What? rule (a variation on the Five Why’s). You imagine the most skeptical coder challenging you after you describe a feature, approach, API, etc. but they don’t just stop with the first “why”. You answer it, and then they ask, “Who Cares?”, and when you answer THAT, they ask, “so what?”. When you have finished imagining this chain, you usually have a much more powerful and motivating reason (or, you realize there IS no compelling reason or use case because you could not come up with answers for all three challenges). We now suggest that technical authors constantly run through the who-who cares-so what when writing, and it works quite powerfully for those writing marketing copy as well. Way too often, people stop at the first why (or sooner), but that thing they finally say in exasperation with the final “so?” yeah, THAT’s where you get to the meaty core of the why, and usually it’s more motivating and powerful. Regardless, it’s surprising how little the true “why” is even given a nod whether in technical docs or marketing. Yet it’s not just necessary for motivation; it is also what gets the brain to understand and remember.
Brian Goff
on 10 Jan 13Kathy, I think I’m going to have to read that a few more times
Eric Anderson
on 10 Jan 13As a software consultant I often get crazy requests from clients who know very little about software development. Whenever I get one of those request my first response back is “What are you trying to accomlish?”. This question often reduces a complex task into something simple.
Bryan Smith
on 10 Jan 13I agree, ideas should be challenged. Sometimes an idea is not grounded, sometimes it is excellent. More importantly the process of proving an idea/feature/concept is that it shares that vision and can hone it even more.
Jeffrey Boardman
on 10 Jan 13Relating to non-techies through Feature – Advantage – Benefit has usually worked for me. All too often requests are made for a feature, without consideration for the benefit that ultimately should drive the prioritization. I found an article with some good examples. http://www.boxonline.com/wp/suggestions/features-advantages-and-benefits-462
Gavin Miller
on 10 Jan 13My natural inclination is to miss the human aspect when asking “why.” Directly asking someone “why” will put them on the defensive. Eric phrased it better: “What are you trying to accomplish?” It is a much more relational way to ask “why”.
Eric
on 10 Jan 13Simon Sinek has a TED Talk and a book on this subject, or at least along the same lines. Worth a watch and a read. My company also did an interview with him as part of our Inspiration series. He talks more from a company perspective than a programmer’s perspective, but the theme is there.
Scott
on 10 Jan 13I agree, but from the designer’s perspective it is often frustrating to have every design decision met with pushback and stripping-down from developers who are often looking for the easiest/fastest way to code something, not what’s best for the product/customer. I have found that involving developers early on in the design decisions avoids these “challenge” moments.
Trystan Spangler
on 10 Jan 13I agree from a programmer’s or designer’s standpoint but I don’t think that all clients or product owners actually want to hear alternatives or “waste time” discussing these things. They’re paying you to implement their exact implementation details – no questions asked – and they want it by the end of the day. Sure, you could do better with far less effort, but if they’re not concerned with usability, simplicity, whether it will actually be used, or whether it will actually work, then it’s just going to waste everyone’s time because that’s not what they want. Bossman says it, you do it. That’s what they want.
scott golas
on 10 Jan 13I’d add a slight twist to the above and it’s a line of questioning I’ve used from from consulting with clients to internal staff who are trying to act upon an idea. Along with asking Q’s (e.g. 5-W’s) to truly understand a problem at its root (versus addressing just symptoms) I’ve found it helpful to ask people/teams not only what the problem is they are trying to solve but also…what benefits they’re trying to achieve? Likewise, asking those questions (especially early in a project/idea lifecycle) to multiple peeps on the same team can often highlight inconsistency in thinking or more important, purpose.
James Holwell
on 10 Jan 13Well trolled, Trystan.
When I was consulting on software, my favourite piece of insight was from a product owner: “so often, programmers will implement exactly what you have asked for, even if you didn’t know what that was. Wouldn’t it be refreshing if they worked with you to work out the right answer?”
As a technologist, I think the onus is always on the programmer to ask clarifying questions and propose alternatives, after all, isn’t that what agile was all about?
Matt Henderson
on 11 Jan 13David,
I saw your twitter exchange about government intervention in “protecting kids” from certain content, exposure, etc.
Twitter was too brief to reply, and this article seemed relevant, in the sense that kids are also people who need to know, “why?”
In my experience, explaining the why behind your policies to your kids and really respecting their capability of understanding (not just pretending; kids can tell the difference) is very effective, even against peer pressures.
Of course, you have to have well-considered answers to the “why?” question in the first place. “Because I said so” ain’t an option.
Marc
on 11 Jan 13This reminds me about a poster I saw on despair.com (a site that has slogans that satirize the motivational posters) which said…
“Consulting, if you are not part of the solution, there is good money to be made pro-longing the problem.”
While funny, I fear it is far to often true. Like in David’s example, I see many consultants out there doing the 50 hours directed work instead of asking what the problem is and offering an 8 hour solution.
Tim
on 12 Jan 13Goddammit DHH/JF hire Kathy Fn Sierra to just write on your site. I miss her so damned much.
Kathy – I wish you could start a mailing list. No website. No trolling.
denise lee yohn
on 14 Jan 13there’s also usually a benefit to the person having to explain why - through the explanation, new ideas often arise - denise lee yohn
Ricco
on 16 Jan 13I think this is true for many other things than just software development. I can relate to getting help from my much more crafts-savvy father-in-law for fixing/building stuff on my house. He has 40+ years of experience and I know nothing and it can be really frustrating to be told to “put a nail there,” hold this here.” Being informed about the reason we do things the way we do (“hold this here, so that…”) makes the job much more interesting and I’m more likely to learn a thing or two.
This discussion is closed.