What you're describing is exactly the kind of problematic culture difference that I'm warning about. This is what I said earlier:
> because the organization's culture stays synchronous and in-person-oriented
Asynchronous does not mean slow, but it is different and requires structuring your work differently. Remote works much better asynchronously, but at an organization that has too few remote employees will never learn to do that.
It's not that you're doing something wrong or that they are, it's that your organization is designed to be incompatible with remote workers. If you're not willing to adapt, then you're absolutely on the right track by phasing out remote, but don't take your anecdotes from working in an organization that refused to change as evidence that remote doesn't work.
> When our senior engineers are physically available I can put myself in their office or at their desk and demand they help me.
Slight tangent, but this is exactly why a lot of people like myself will never go back into an office. I don't want to be paid to be at someone's beck and call whenever they want to interrupt me, I want to be given a large chunk of work that I can work on independently without interruption unless I'm specifically designated to be on call as part of a regular rotation (at which point you can interrupt me just as well on slack as you could in the office).
> Asynchronous does not mean slow, but it is different and requires structuring your work differently. Remote works much better asynchronously, but at an organization that has too few remote employees will never learn to do that.
> It's not that you're doing something wrong or that they are, it's that your organization is designed to be incompatible with remote workers. If you're not willing to adapt, then you're absolutely on the right track by phasing out remote, but don't take your anecdotes from working in an organization that refused to change as evidence that remote doesn't work.
This is wishful thinking. Not all work can be done asynchronously, and often the most important work is important because it's a blocker for other things. In practice this kind of mindset simply increases the critical path of the project, which is the most important part, and in many cases senior engineers are on the critical path. But hey, if you're able to be productive at scale with remote work, guess you'll have a large pool of talent to draw from, so I'm hoping to see many successful companies replace FAANG.
> Slight tangent, but this is exactly why a lot of people like myself will never go back into an office. I don't want to be paid to be at someone's beck and call whenever they want to interrupt me, I want to be given a large chunk of work that I can work on independently without interruption unless I'm specifically designated to be on call as part of a regular rotation (at which point you can interrupt me just as well on slack as you could in the office).
Yes, this is what YOU want. It's not for the benefit of the company, no matter how remote people try to frame it. But hey, if that's my only choice, then we should hire top talent in Bangalore or Warsaw instead of remote mid talent from high cost areas.
Precisely. I don't want to work for you, you don't want me to work for you, so it's a win-win: I'll keep doing good work for a company that appreciates what I can do and is happy to give me the flexibility that I need to do it well. You keep hiring people who don't mind being interrupted by a boss who values their physical presence over all else. Everyone's happy!
> Not all work can be done asynchronously, and often the most important work is important because it's a blocker for other things.
This sounds like a project management failure. One of the cardinal rules of the remote programs I run is: Never let the critical path be blocked by one person having to physically do some synchronous task. If Task X requires Person Y to approve it by Date Z, then you obtain that approval asynchronously, waaaaay before Date Z, where you would otherwise become blocked.
> In practice this kind of mindset simply increases the critical path of the project
I mean, I think that's what you're getting at here, so design your business processes just like you'd design a multi-threaded program: such that there are no locks and mutexes.
> because the organization's culture stays synchronous and in-person-oriented
Asynchronous does not mean slow, but it is different and requires structuring your work differently. Remote works much better asynchronously, but at an organization that has too few remote employees will never learn to do that.
It's not that you're doing something wrong or that they are, it's that your organization is designed to be incompatible with remote workers. If you're not willing to adapt, then you're absolutely on the right track by phasing out remote, but don't take your anecdotes from working in an organization that refused to change as evidence that remote doesn't work.
> When our senior engineers are physically available I can put myself in their office or at their desk and demand they help me.
Slight tangent, but this is exactly why a lot of people like myself will never go back into an office. I don't want to be paid to be at someone's beck and call whenever they want to interrupt me, I want to be given a large chunk of work that I can work on independently without interruption unless I'm specifically designated to be on call as part of a regular rotation (at which point you can interrupt me just as well on slack as you could in the office).