Right, but development this is correct; if you're remote and require sync, you're not actually getting things done. Meetings are not the desired outcome; deployed, working code is. Communication is necessary, but not the output, and so to be effective you have to find ways to make that communication asynchronous wherever possible. It's fine to still have the -output- be synchronous (i.e., pairing), but don't confuse the default synchronous tasks (meetings) without output.
Anyway, all of that is a red herring; don't just tell me you're remote, tell me if you're prioritizing asynchronous work or not. The places trying to recreate the office, just now remote, are not places I want to work at.
> Meetings are not the desired outcome; deployed, working code is
Maybe if all you want to do is code. I get the sentiment. If you're working on a product, getting input from team members and stopping bad ideas from making their way to the hands of the "don't bother me with meetings, I only want to code" person is important.
You seem to have completely ignored my "Communication is necessary, but not the output". Put another way, meetings are the 'how', not the 'what'. The how is not a deliverable, and so can be changed so long as the 'what' stays the same. You can get input, collaborate, etc, in other ways that are not synchronous.
We've all had that "this meeting could have been an email" experience. Make it an email. Start re-evaluating every meeting; any sort of unidirectional informational meeting can be offloaded onto a doc or recorded presentation just as efficiently. Bidirectional decisional meetings can often be done more effectively by writing up a problem statement, the various options, and a 'due' date for input. Allow people to read over it, comment, propose new suggestions, etc, then at that due date, hold a vote (can be done sync or async). Voila, a decision is reached that allowed for greater amounts of discussion, and was arrived at as democratically or 'loudest voice in the room' (if only a select few people's votes count) as you care to have it, rather than whatever organically happens in your meetings. Etc. In my experience what I'm left with are the meetings where it's the 'personal connection' that matters; these are things like the occasional AMA/Town Hall style meetings, and 1-on-1s. 90% of my pre-COVID meetings turned out not to need to be meetings.
I didn't ignore anything. The product is the output. Code is not the output. Your code is as much the output as communication is. Users don't care if you spent your time coding or in a meeting. They care if the product fulfills their needs. A meeting that stops a terrible redesign contributes as much the output as the heads down programmer who would have implemented it. Now I would hate to be in meetings all day, don't get me wrong. But I disagree that code is the output specifically for a product.
Yeah, I have too. Oftentimes for business stakeholders and leadership, that is the case, as it helps justify their existence ("I was so busy!"). Which presents, unfortunately, opportunities for useless devs to glom on; sit in meetings, do no work, collect a paycheck.
Anyway, all of that is a red herring; don't just tell me you're remote, tell me if you're prioritizing asynchronous work or not. The places trying to recreate the office, just now remote, are not places I want to work at.