[acdha]

> Walking over to someone and having a 15 minute conversation is less disrupting to the day than tossing a mention into the void and then having responses dribble in over the next hour and a half.

There’s a balance here, as the 15 minute conversation is often a 45 minute disruption for the target and often the people around them. The other challenge is in my experience the trade off wasn’t “this information cannot be obtained any other way” but more along the lines of “it’s easier to walk over than read the documentation/make any attempt to answer the question on my own”.

Asynchronous shifts the downsides to the person asking, so people tend to have strong opinions if they tend to be on one of those sides a lot more than the other.

[nottorp]

Of course, you can also ask about the blockers ahead of time or just do something else. This does require your org to trust you with more than one strictly defined ticket at a time though.

[acdha]

> Of course, you can also ask about the blockers ahead of time or just do something else

Sure, but that’s going to impact the claimed time differential if you have to schedule it and wait.

I think both approaches have their merits but unless you’re in a group focused on the same goals I prefer the approach of trying to solve it yourself and trying an asynchronous message first, possibly turning into synchronous if needed, because the first two steps don’t have dependencies and will make the last more productive.

[nottorp]

> if you have to schedule it and wait

I mean you ask away... asynchronously... then do some other task or part of task that doesn't require the blocker. By the time you're done with that you may have your answer or whoever's attention that you need.