Set Explicit Help Timeouts episode artwork

EPISODE · Apr 5, 2021 · 4 MIN

Set Explicit Help Timeouts

from The Swyx Mixtape · host Swyx

This is the narrated version of my latest blogpost.Set Explicit Help TimeoutsThis 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.Personal Help Timeout PolicyThe 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.Shared Help Timeout PolicyAs 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.Disclosures: This is a new policy I have made for myself, but have not applied at a team level yet.

This is the narrated version of my latest blogpost.Set Explicit Help TimeoutsThis 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.Personal Help Timeout PolicyThe 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.Shared Help Timeout PolicyAs 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.Disclosures: This is a new policy I have made for myself, but have not applied at a team level yet.

NOW PLAYING

Set Explicit Help Timeouts

0:00 4:13

No transcript for this episode yet

We transcribe on demand. Request one and we'll notify you when it's ready — usually under 10 minutes.

Big Old Life: Heather Blackbird interviews people on planet earth. Heather Blackbird loves asking questions. This podcast is a learning experience. Join me, Heather Blackbird, as I talk to people about their lives. Frequency of new episodes is a little all over the place and I'm learning as I go. Big Old Life is a small way of talking about the vastness of life, one person at a time. If you are reading this or found this podcast it's probably because someone you know gave you a link to it. :) Explicit Tales Of A Superstar DJ The Insomniac Spun seemingly out of nowhere from her complacent life in the corporate world, turned seemingly overnight from 16-Hour shift work and into the life of a literally starving artist and working musician, The Protagonist navigates her supposed rise to fame and superstardom on a journey through spiritual awakening, coming-of-age, and intimate self-realization--guided by an omnipresent force and equipped with the power of love, magic, and music. {Enter The Multiverse.} [The Festival Project] The Festival Project, Inc.™ is a multidimensional multimedia platform which encompasses exploratory and artistic social personifications and expressions on cosmic theory, spirituality, growth, health & wellness, philosophy and theoretic dynamics in entertainment such as music, design, film, television, radio, dance and festival culture, art, fashion, literature, and science. The Festival Project™ and its subsidiary Non-Profit, The Collective Complex © aims to challenge modern artistic and philosop Explicit Bitcoin Is Dead Trey Carson Welcome to Bitcoin is Dead, the ultimate Bitcoin variety show where host Trey takes you on a journey through the ever-evolving world of Bitcoin. Each episode brings new personalities, fascinating locations, and insightful conversations with politicians, educators, and innovators shaping the future of Bitcoin. Whether you're a seasoned Bitcoiner or just starting your journey, tune in for thought-provoking discussions, unique perspectives, and a deep dive into the ideas and people driving the Bitcoin revolution. Explicit The Sacred +Profane Podcast nephtaragrace The Sacred + Profane Podcast is a provocative conversation dedicated to cementing a better future for all. We specialize in unpacking the nuances of what is considered sacred and profane, particularly focusing on sex, death, and all that pertains to the circle of life. Our aim in focusing on such ”taboo” subject matter is to demystify what is unconscious, bring to light what has been known for centuries as ”the occult,” and empower the rapid transformation that is occurring on the Planet. Explicit

Frequently Asked Questions

How long is this episode of The Swyx Mixtape?

This episode is 4 minutes long.

When was this The Swyx Mixtape episode published?

This episode was published on April 5, 2021.

What is this episode about?

This is the narrated version of my latest blogpost.Set Explicit Help TimeoutsThis 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...

Can I download this The Swyx Mixtape episode?

Yes, you can download this episode by clicking the download button on the episode player, or subscribe to the podcast in your preferred podcast app for automatic downloads.
URL copied to clipboard!