The 20-Minute Rule

July 28, 2014

When I first started at my current company, my technical manager said something that I carried with me through my entire development career.

“If you make no progress on a task after twenty minutes of work, find someone to help you.”

That simple phrase carried me through multiple league-level redesigns & more tentpole events than I could count as a developer. It became my measuring stick as to whether I was running into a real block when I was coding, or if I just needed to step back and take a breather from whatever issue I was having with my code. I realized as I worked on things that my former manager actually gave me the words on something that was part and parcel of my work habits as a front-end developer, and I kept it at the forefront of my mind as I worked.

I didn’t really think that the 20-Minute Rule would ever be just as important on the Product side as it was on the Development side, though. There wasn’t much that I felt I could show to someone else on the Product side when my job wasn’t a webpage but an idea of a webpage. I shuffled the idea of the 20-Minute Rule off to the back of my brain and got to work sorting through my documentation and trying to make sure that I understood what I was going to be doing for a living now. Then came the End-of-Year Recap…

I had to build out a deck for the executives to review telling them how my new-to-me product did in the previous year. My boss thought that it would be a good learning experience for me, but I was terrified that I was going to mess it up. How could I tell anyone what went well and what didn’t on something that I hadn’t lived through? I was sent enough analytics to bury myself in, but making heads or tails of it to tell the right story? I was hitting a wall.

As I was explaining the near-paralysis I was encountering to my aunt one evening, it hit me.

The 20-Minute Rule.

I’d not been able to make any progress on something for days, not minutes. I’d forgotten that I can always ask for help, even if all I had was a ton of spreadsheets and a partially completed slideshow instead of a block of code.

The next day I already had a one-on-one scheduled with my boss, and I went over some of the blocks that I was running into getting things in a better shape for the deck. He ran through it with me, pointed out where I was on the right track, and where I needed to improve on some of the information, just as it would have been had I been a dev asking for help on building something. Here it was, the first thing that really seemed to resonate between the career I’d left to the one I was just starting out on. Hopefully it would be the first of many of these moments that I could correlate and navigate successfully from one to another.

Leave a Reply

Your email address will not be published. Required fields are marked *

More Articles