Akamai Diversity

The Akamai Blog

You Must Try, and then You Must Ask

I like working with grownups.

Here's an example:

When I was a wee little New Hire at my current employer, one of the things that came up a lot was the "15 minute rule." That is, if you're stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don't have an answer after 15 minutes, you must ask someone. I shorten this down to "You must try, and then you must ask." It's a simply-worded rule, which works something like this:

  1. If you've hit the point of giving up, you have to push yourself for another 15 minutes. The pressure is now off. You know that in 15 minutes, you'll be able to take what you found and talk to another person about it and get their help. For right now, all you have to do is step back and look at the whole problem from the top. Maybe you'll find the solution that was sitting there all along. Maybe you'll convince yourself it's completely unsolvable. Whatever you end up doing, those next 15 minutes are where you look at the problem one more time.

  2. During those 15 minutes, you must document everything you're doing so that you can tell someone else. So, what does "look at the problem one more time" mean? It means taking notes. Lots of them. I'm a big fan of using a paper notebook with an excruciatingly fine-point pen, because I don't need to move windows out of the way to keep writing in it, and I can fit a lot of words on a single page. Use what you like, but keep writing. Write down all the steps, all the assumptions, everything you tried, and anythingyou can do to reproduce the problem. More likely than not, you've now probably figured out at least one other way to solve the problem, just by getting it out of your head and onto paper.

  3. After that, you must ask someone for help. Okay, you've decided you need help, and you've spent another 15 minutes looking at the problem again (and again (and again)),and you've documented your approach.

    Now, stop.
    Stop trying to solve the problem, if only for a moment.

    Call for help. Even if you think that you almost have it, stop. Even if you think that an incarnation of the wisdom of the masters is perched on your shoulder whispering the answer in your ear, stop. Write that email or walk over to the office/cube/etc. or cast the appropriate summoning spell, but make sure that someone else knows that you need help. Request assistance, state the problem, and show your work. You may not get help right away, but now you've employed at least one other brain in helping you, and now they have a great head-start, courtesy of you.

So, that's the 15 Minute Rule in 3 easy steps.

Here's why it's important:

  1. Your paid hours are costing someone money. You can be in a Professional Services Organization, an internal IT organization, or an independent contractor, but it all works out to the same thing; someone is paying for your skills. While it may feel good to figure out the answer on your own, there's no medal for wasting 3 hours worth of money on a problem that doesn't merit that kind of time. In a sneaky way, this also helps you value your own time, if only by making you ask yourself "Is this problem worth this much of my time?"

  2. Your colleagues will help you because they're playing by the same rules. This means they're used to asking and listening to informed questions, and they'll be expecting the same from their peers. Needless to say, use your common sense... find someone that isn't heads-down in a problem of their own; no one likes to have their flow interrupted. That being said, your colleagues will know that if you come over to ask for help, you'll already have taken time to look it over and documented your findings so they can help you figure out the problem faster or point you in the right direction. It's possible you'll end up Rubber Duck Debugging the problem, and the act of talking through the problem will help you solve it.

  3. Last but certainly not least, You have to interact with your colleagues because they have the answers you need. Building and maintaining an enterprise software platform (to choose something of appropriately fiendish complexity) is not a solo sport. Your colleagues have different ways of understanding problems and different ways of using the knowledge they have. This goes for many definitions of colleague and many definitions of knowledge.

This eventually turns into a virtuous cycle. People value each others' time and their own, so they do their own homework before asking a question. In turn, people are more likely to answer questions because they know the person asking will give them the interesting part of the problem to solve.

Put another way: by explicitly taking enough time, everyone saves time.

Matt Ringel is Enterprise Architect in Akamai's Professional Services team


One advice from my own experiences.

Don't give many 15min before calling someone, but don't just straight call also. Go take a 5~10min break. Some coffee, some quick snack. Most likely you will see some light in the problem or be back refreshed with another point of view. [0]

I would say at least half of time I have done that I was able to solve the problem very quick (like within those 15min you said) and the solution was almost always much simpler.

The other half (or less) I had to call for some help. Even though that's the necessary since you couldn't figure out and that's ok, you won't learn as much as when you do the breakthrough for yourself.

Seems like you are might waste clients time doing that, but you are actually expanding you horizon.

I'm not saying that you should never call you colleague, because exchange of knowledge is awesome. But if you do that all the time you can't solve a problem, than you will never grow.

So, be wise when to be stubborn and when to call for help. But, remind always to pause, because that will do wonders.

[0] that happens mostly because our brains work when we are not working on the problem and is able to see things we can't figure by our own. This is a scientific research featured on "59 seconds" book (and many other places if you google it).

Here's the problem I have with this approach, which I have tried before. Programming, even the simplest task, inevitably boils down to needing to solve 137 different problems. Especially on a system that's new to me, I'll work on one, and discover solutions to the other ones. In other words, problem-solving is naturally asynchronous.

By forcing myself to focus on just one problem for 15 minutes, I may or may not solve that problem (or need to get help), but I effectively cease progress on the other 136.

This kills my throughput. While I might not have answered my question in 15 minutes, I would have answered 23 others in that time.

Worse, my coworkers have things they're working on, too. Interrupting them at a time convenient to me is inconvenient for them (and vice versa). If I'm interrupting them every 30 minutes because I insist on working synchronously, they'll start to ask "Why didn't you just work on this other module for a bit? That would have naturally shown you the solution to this problem".

A better method that I've found is to keep a list of questions as I go. At lunchtime, or when I'm completely stuck, I can take my list of questions to somebody else, and get them all answered at once. That way, I get maximum throughput on all of my problems, and my coworkers get limited interruptions (zero or one!) from me.

This is called "interrupt coalescing", and your CPU has done it for years. :-)

Hi Matt,

Very good post. Thank you!

Great article, can't believe there aren't any comments on this. This is sound advice I would recommend to seasoned and junior developers alike. It's always nice to refresh something in your mind from time to time and this was great!