3 ms·
> Meetings and collaboration to figure out what to build, discuss issues etc Remote-first, multi-time-zone companies simply don't do meetings. All communicatio
by throwaway984393 5y ago
> Meetings and collaboration to figure out what to build, discuss issues etc
Remote-first, multi-time-zone companies simply don't do meetings. All communication is async and written down. Work gets done without a lot of hemming and hawing and meetings-with-no-agenda-to-talk-about-setting-an-agenda-for-a-future-meeting. It's much more efficient to come to a decision over 7 asynchronous back-and-forths, and people have the opportunity to do some research during the conversation so their decision is better informed. The whole Open Source world [when development is not done within a corporation] works this way.
I think the problem is corporations are obsessed with a definition of productivity as "the person is constantly productive". If you're not in a meeting, or have a ticket in progress, or are doing training, clearly you are just wasting time. You can't be allowed to just ruminate, or research, or play around with an idea, or talk to other teams. They'd rather you be writing code now that will be obsolete in 6 months and take a year to replace, rather than take 2 months to come up with a plan for your code that will take 3 months to write and last for 3 years. We rush into things because we have to have something to show for our work every day, and as a result the quality is poor, and that costs more in the long run.
- jlokier 5y ago> Remote-first, multi-time-zone companies simply don't do meetings. Having worked for such companies, this is not true, at least in my expreience. Plenty of meetings. Very long ones sometimes, 2 hours is not unusual; 3, 4 hours sometimes on Zoom or Hangouts. > [non-remote-first companies would] rather you be writing code now that will be obsolete in 6 months and take a year to replace, rather than take 2 months to come up with a plan for your code that will take 3 months to write and last for 3 years. Hmm. I can assure you some remote-first, multi-time-zone companies would also rather you be writing code now that will be obsolete soon than take substantial time to come up with a plan for code that will last years and serve the product well. Visibility counts for a lot in some remote-first environments. Depending on the management, they may regard the best form of visibility to be regular code updates, PRs, issues filed etc, rather than taking your time over deeper design and research. If they pay more attention to quantity than effectiveness, that can mean shipping code and iterating every few days is something they are looking to see, and a high priority if you want to keep your job. Async written communication on design is sometimes seen as too much talking, not enough doing.