By forcing yourself to try for 15 minutes, you gain a deeper understanding of what you're troubleshooting so that, even if you don't fix it in 15, next time you're in a better position to troubleshoot than you were the last time.
And by forcing yourself to ask for help after 15, you not only limit the amount of banging-your-head time, but you also get to see how the other person solves the problem while all the details are still fresh in your mind, so that you'll more likely have a deeper understanding of why what you were doing to fix it wasn't working, and why the ultimate solution actually worked.
It would be great if I could force every single developer that I know to read this. And after that enforce it.
At least after fifteen minutes you have enough information where you can, hopefully, clearly articulate your question with enough detail. There are times where questions are fielded to me and it was simply "this does not work" where after fifteen minutes of legwork the answer was solved along the way.
Author here. You bring up a very good point. How do you enforce the 15 minute rule?
Part of it is incentive structure. That is, detecting when a team implicitly rewards augering in on a problem when stuck. After that, showing that there's no loss of credibility for asking questions and that answering reasonable questions is part of the job.
After that, subsequently rewarding people who "try and ask", which will net out to more productivity anyway.
Wow. Yeah. There are many paragraphs to write about this. Thanks for the food for thought!
There's something you might have missed. When I approach a problem like this I notice I solve it only after I give up.
It's not spending 15 minutes to go over all assumptions that makes me solve it. It's telling someone I can't solve it. It's the act of saying I can't do it.
I often start writing an email telling someone I can't solve a problem, and while writing I realize something I haven't tried. Then I stop, go try it, and it turns out to solve the problem. But if I don't start writing that email, and instead try to work on the problem for 15 more minutes, I don't solve it.
It's as if I don't take the problem seriously otherwise.
This is very similar to the 15 minute rule, only it's more efficient, since it takes less than 15 minutes to write that email.
So I would argue solving the problem has more to do with admitting you can't solve it than it has with going over assumptions. It triggers something in your brain that frees it to look at options it hasn't looked at before.
I thought it was the possibility you might embarrass yourself to the person you are emailing that helps solve it. But the strange thing is I also solve problems only after I send that email. My mind refuses to look at the problem from a different angle otherwise.
It may not be possible to enforce. My position, some days, tends to lean more towards the DevOps role. Because of past history where often the problems were related to infrastructure issues usually are raised to my team for vetting. It became natural to pass on an issue and wait for team duct tape to take a cursory glance.
My position has made a divide between me and some of the developers because I'm out of the normal management structure. It may be a natural "fear of the unknown," but the ways that I try to counterbalance this:
* Give them interesting or fun problems to solve;
* Debate and challenge their ideas openly;
* Admit that (most of the time) I have absolutely no idea what I am talking about.
I usually end most coffee conversations egging them on and telling them to test their theories. I think by creating a better team environment the fifteen minute rule may organically be followed.
You don't need to enforce it formally. Company culture does that for you if you encourage the kinds of values espoused in these parts. I know it's not a code-y answer, but it's a reasonable and working human one!
> There are times where questions are fielded to me and it was simply "this does not work"
I want this to be defined as misconduct. People need to be fired for repeat offenses. If they can't at least explain what they did and what the actual result was, they're incompetent. If they won't, they're ridiculously lazy. In either case, they need to be out of a job.
I agree, this is great. I run a small team and the author just summed up what I try to convey to everyone on the team. I just emailed it off to everyone.
As someone who gets asked many more questions than he asks himself, I think this is a fantastic rule of thumb. It's annoying when somebody asks me a question which I can tell they spent no time troubleshooting. But, it's possibly even more annoying when I go check in with somebody and find out they have been spinning their wheels for a day and a half on a 5-minute problem without telling anybody. I would rather they err on the side of bothering me than burn hours upon hours of time.
By forcing yourself to try for 15 minutes, you gain a deeper understanding of what you're troubleshooting so that, even if you don't fix it in 15, next time you're in a better position to troubleshoot than you were the last time.
And by forcing yourself to ask for help after 15, you not only limit the amount of banging-your-head time, but you also get to see how the other person solves the problem while all the details are still fresh in your mind, so that you'll more likely have a deeper understanding of why what you were doing to fix it wasn't working, and why the ultimate solution actually worked.