This is the narrated version of my latest blogpost.
This is the backstory of how a 1-2 hour task stretched into 2 weeks because I kept it to myself.
A few weeks ago a customer conversation resulted in a simple documentation request. Take something undocumented, and document it. I've done this a gazillion times. I happily took it on.
But when I actually looked into it, this task was different. I knew in theory how it worked, but I had never personally used this functionality before. So to document it, I had to learn it. And there was no source material, no YouTube tutorial, no Stackoverflow answer.
I felt that little "uh oh" pit of despair. Our CTO had given some pointers, so I fired up my sample code, and tried them out. Didn't work. Several variations also didn't work. By then my time was up and I had to go to the next meeting.
The next attempt, I realized that I didn't have an optional dependency (Elasticsearch) configured for this feature to work. Stupid me! Of course nothing I tried worked! That was on us for not having helpful errors to warn about such things, but that's a task for another day. I enabled it, and went on to try out the exact same pointers given.
Still didn't work. Several variations also still didn't work. Then my time was up.
If you had asked me, at the outset, how long this task would take, I would have said 1-2 hours at most. I ended up intermittently banging my head on it for 2 weeks before admitting defeat.
Only when I asked for help after 2 weeks - literally typing "I need help" into Slack - did I find out that the pointers given were incorrect and we needed a deeper inspection of the source code.
There were multiple failures here - my failure to go back to my CTO to pin down what exactly he meant, my lack of familiarity with something I only conceptually understood, my failure to open up source code when surface level attempts didn't work (something I preach!).
But I think my biggest failure of all was letting it drag on for 2 weeks. I should have just asked for help after the first day. Or first week. Anything would've been better than 2 weeks.
The real reason was this: I was new at the company and wanted to appear like I knew what I was doing, so I didn't ask for help. Keep in mind I'm someone tells people to embrace the power of ignorance. And yet, that's what I did. I was in a supportive environment and it still felt embarrassing to type the words "I need help".
From now on I'll make it a point to simply call out where I'm stuck when I'm stuck.
The trick is setting the "help timeout" — how long before you ask for help? Clearly zero timeout is too noisy, and 2 weeks is too quiet. I put it to a poll:
If you have a daily standup, this is the kind of "blocker" that is ideally brought up there, limiting your help timeout to 1 day. However, in practice, there are many long-running async tasks, "important but not urgent", that don't get brought up as blockers in daily standups.
It's obviously context dependent, but I'm personally fine with a 1-4 hour timeout for most things I do. Struggle is useful and you can learn a lot through it, but you should never have to struggle for more than 4 hours alone on a problem, when you have a team.
As much as this policy might be helpful individually, I think it might be even better when set as a team. I am not in any real danger when I ask for help. But others might feel like they are.
Without having a real conversation about help timeouts, it is easy to end up in a situation where implicit help timeouts vary from 1 hour to infinity, and team progress is slowed by having to overcome this barrier every time. Make it explicit, and shared, and you enable lampshading of lack of progress and normalize asking for help. Team leaders should role model this too, instead of merely saying it's ok for everyone else to ask for help.