12 ms·

Of course this is happening. I’m coming up on year 10 of working remotely, and year 2 of completely async. The only forced-commute job I ever had was for 6 mon

Of course this is happening. I’m coming up on year 10 of working remotely, and year 2 of completely async. The only forced-commute job I ever had was for 6 months right out of college. I’ve been preaching remote work for almost the entire time I’ve been doing it. I thought it would catch on much sooner, but it’s here now. I think async is the next thing that will happen. If you’re building software there’s really no reason you have to share working hours with anyone. It’s convenient at times, but it’s by no means required.

lifeisstillgood 4y ago
Can you explain your day to day? And how do you keep up with company politics, changing requirements etc?
- jcpst 4y ago
  As someone who has been fully remote the past two years, and in a team that is gradually exploring/adopting more async work practices over the past year, I would be curious to hear more too. Our team stopped having a standup meeting- we just have a daily automated post in our chat, and we comment in the thread whenever it makes sense. If we’re working on the same thing for days with no blockers, it’s not a big deal to not provide an update. We’ve reduced our synchronous communication by quite a bit. Some weeks I don’t have a single call I join. If you document everything well enough, you don’t really need to. I find myself on calls when I need to extract information from an architect that is just too busy to write everything down, or I’m mentoring a teammate. Or I’m in my monthly 1-on-1 with my manager. Working outside of regular business hours is not off the table, but it is new. It helps that some of us are in the US and some in Poland. Normally, just blocking off time on the calendar and marking your status (out of office) is sufficient.
- ryanSrich 4y ago
  I’m a startup co-founder, so day to day can be a lot of different things. But it’s something like this: 1. log on to Slack in the morning and see if there’s anything that needs attention. We use slack as a central hub. All of our tools funnel activity into slack. My team is small (3 full time, 2 part time contractors). Most of my team works over night and into the morning (very different time zones). Typically when I wake up, there’s a few PRs for me to review, or questions to answer on a ticket in linear. We also have a check in bot that runs once per week. No real need to do daily checkins. 2. After I catch up and respond to any questions (which most likely will be read by people that night or the next day) I see if I have any sales meetings. Since we’re a startup it’s still founders in sales mode. I might have a demo or 2 each day. This is probably my only non-async activity. 3. Outside of sales work, I also write code, review design work, and field customer support questions. So the rest of my day is a buffet of random stuff. As far as politics go. There really isn’t any. The team is pretty small. We might have a disagreement on how a feature should be implemented or something like that, but I’m the deciding factor and everyone is a professional so it’s not a problem.
axg11 4y ago
I like the concept of async work but I’m also scared of how transactional that would make work. Most companies that preach async now have a very strong, “friendly” culture. If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics. I enjoy the human component of work. I don’t like _all_ of my coworkers, but it’s still a net positive to interact with them. When I think about the ideal software job, a lot of the aspects of day-to-day work informally become async. Especially as you work with people for longer periods of time and gain mutual trust, a good workplace allows both managers and individual contributors to structure their own time.
- ameister14 4y ago
  >If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics. Here's the thing; that (a completely transactional relationship between all elements of a team) doesn't actually work well to make good products. Sure, a bunch of companies would probably do it as it's easier to measure worker production that way, but async also requires a different type of management and admin work that has to change as well. A lot of current managers won't be able to hack it, frankly, without the measured 'butts in seats' element. Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem. It's a different concept for business and teams, that's all. Applying the older paradigm is going to be a problem and while a lot of companies will do just that they will also be less successful overall.
  - arinlen 4y ago
    > Here's the thing; that doesn't actually work well to make good products. Sure, a bunch of companies (...) Respectfully,you know nothing about what you're talking about. Async work is already the norm for some companies, even prior to moves to full remote work. I personally know teams in renowned companies which before COVID already split teams working on products between the US, Europe, and India. They stuck with full async because it worked, and worked better than alternatives. With COVID, the whole world went full remote due to necessity, and I personally know teams whose output improved significantly with the move to full remote to the point where they stuck in remote by default. > Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem. I disagree. What I'm seeing is a lazy, conservative mindset of people who feel scared and threatened by a reform shaking up the very core of a system they feel benefits them personally.
capableweb 4y ago
I'm of the view that it works best for some, while for others some other solution works best. There is no right or wrong, just personal preference. But even so, it seems to be a bit much to preach for something when you've never experienced another alternative, except from 6 months after college. It's hard to remain unbiased when you don't know anything else by experience. Personally, I've spent lots of my career in an office, and also lots of career working remotely, about the same amount of companies in each category. I'm more of a fan of the in-person dynamic you can create while being in the same location, compared to the almost-human dynamic you can create if everyone and everything is remotely. But I tend to work in much smaller teams (although one office-job and one remote-job were in pretty large enterprises), so maybe that's why I prefer one vs the other. Even though I prefer at-location work, I totally understand how others can prefer a different scenario. Depends on so many variables, so I guess my conclusion is just "it depends". Don't prescribe anything to others without knowing what they want, and don't let yourself be controlled by others opinions, just do what you feel is best for you.
xyzzy4747 4y ago
Incompetent engineers need to share work hours, otherwise they will get stuck and not get much done if nobody has overlapping times to help them. Not all engineers are high caliber.
- zdragnar 4y ago
  If needing help at some point in time means being incompetent, I think that describes everyone I've ever worked with, including some really high caliber folk. Even a simple rubber duck conversation can beat useful thing now and then.
  - seanp2k2 4y ago
    No Google or Stack Oveflow, just everything from my memory into the IDE until the test case written into the JIRAs assigned to me all pass. No internet connection for employees, only test env access. At least, that’s how too many places still do technical interviews.
- lupire 4y ago
  This is also true for competent engineers. No one knows everything.
  - xyzzy4747 4y ago
    What about founders - they don’t just get stuck and give up on random technical things. There are many incompetent people who will sit around and twiddle their thumbs if nobody is actively communicating with them.
  - ipaddr 4y ago
    Wouldn't you go to experts outside of your companies? I may go to the company who makes the product for support or to a popular forum and ask a question.. none of this needs to be sync vs async
    - xyzzy4747 4y ago
hellisothers 4y ago
Maybe this works as an IC that has no collaborative aspect to their day-to-day but as an IC leader async adds material pauses and latency into projects. If everybody is ok with everything taking longer at the start and end of projects then cool (the middle implementation phase is less impacted) but taking a day to answer a question that could have taken minutes is not a bonus.
- ryanSrich 4y ago
  I’m a CTO and startup founder. We ship faster and more often than any team I’ve worked on or observed (multiple times per week). I think your assumption are bad.
  - notyourwork 4y ago
    Without being dismissive of your opinion, being the CTO of a startup doesn’t really say much. I can be the CTO of a startup after I finish an undergrad in computer science or I can be the CTO of a multiple rounds of funding unicorn. So qualifying your opinion with the generic “I’m a CTO and founder” perhaps isn’t a sufficient credence to suggest your experience holds clout.
    - ryanSrich 4y ago
      The reason I mentioned my title is that I don’t think many would consider a CTO an IC. Saying remote and async only works as an IC is wrong.
- db48x 4y ago
  Asking a quick question that only takes a few minutes is a nice bonus for you, but for the person you asked it was an interruption that cost them 20 minutes or more of focus. That might be ok if the person you asked has a job that is designed to be interrupt–driven (aka a manager), but if this was another engineer then this wasn’t a net benefit. But the other side of the coin is that if you do need to ask a question and get an answer, then what is wrong with a text chat mechanism like IRC or Slack or whatever? These tools also work for real collaboration between engineers too.
orangecat 4y ago
If you’re building software there’s really no reason you have to share working hours with anyone. When I'm doing UI work, it's far more efficient to have a real-time session with a designer rather than multiple rounds of email/Figma comments.
- deleted 4y ago
  [deleted]
- db48x 4y ago
  Then one of you needs to work on your written communication skills.
  - incrudible 4y ago
    Writing is always going to be slower, especially if done well. When it comes to UI, tight feedback loops are crucial at virtually every step of the way.
    - db48x 4y ago
      A feedback loop can be tight, or high–bandwidth, without having low latency. You just have to increase the sending window. Either that, or delegate more. If your designer tells you to implement X, and after that is done tells you to do Y, have them increase the sending window by telling you to do X, Y, Z and W up front. Then, when you implement W and it doesn’t feel quite right to you, you can implement W’ instead; that’s delegation.
      - incrudible 4y ago
        That is not a solution. You do not get to just decide on whether latency or bandwidth is the bottleneck of your task.
        db48x 4y ago
        There’s no law of physics saying that a company cannot delegate decision–making authority to individual employees. If your employer doesn’t let you make that kind of decision, then that is a social problem rather than a physical one. Note that I have not said that an individual employee can decide how their employer does business, only that your development processes can be arranged so that they do not require low–latency in–person meetings between employees. You can do your business with or without any overlap in working hours between employees that interact with each other; the overlap is not required.
pharmakom 4y ago
Sync is, occasionally, essential to me as an IC. I think it would be reasonable for a company to require a few hours per week, with the precise time negotiated between the people involved.
nickjj 4y ago
> I think async is the next thing that will happen. Async or a few hours of common hour overlaps are really going to be a big contributor to work / life balance even though it sounds counter-intuitive. It's counter-intuitive because it could mean working outside of "normal business hours", but this is often exactly what you need to do if you want to do things on a whim (aka. having some type of work / life balance). Right now a lot of remote companies expect working hours between 9am to 6pm, that doesn't really leave any room for much of a work / life balance. By the time you get a chance to relax, prepare dinner, etc. it's already 7pm or even 8pm if you need to run errands. Even if you wake up at 6:30am it very quickly becomes 9am after doing a bit of exercise, breakfast, shower, etc.. If you're up at 6:30am you're probably pretty drained by 10pm. After dinner that leaves you like 2 hours to live your life and maybe fall asleep to a movie or book. Basecamp seems to have a very good policy on this. I forgot where I read it but I'm sure I once saw DHH mention that you can work any hours you want as long as you overlap 3-4 hours with CST and put in ~40 hours a week (~32 from May to September since every Friday is off). This is IMO a great first step towards async. It means you can on a whim decide to leave at 2pm EST because you worked from 10am to 2pm EST (9am to 1pm CST) so that you can go swimming on a nice day but you make up the hours later in the evening, or maybe you shift your working hours so you always finish by 2-3pm EST because your best working hours are really early in the morning and occasionally deviate from that for special circumstances from the business as needed. The hard 9-6 rule means pre-scheduling PTO with a lot of notice for things that often require little to no notice. I know some companies will let you occasionally take a couple of hours off without officially filing for PTO through HR but these often need a decent amount of prior notice unless it's an emergency. Basically it puts you into a position where you always need to ask permission instead of just doing it and be trusted to make up the hours.
Fire-Dragon-DoL 4y ago
How do you handle brainstorming sessions or design sessions where things are hard to solve, so there is no direct answer? I love the idea of async, but there are just some sessions that are incredibly valuable and develop on others thoughts, evolving in a final solution. At the company I work at, we compromise with a specific 4 hours overlap so that meetings can be scheduled only during those times
- db48x 4y ago
  It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually, and only then had a meeting to present their best ideas. And by “does worse” I mean that they come up with fewer good ideas, even when they are quite confident that they have completely explored a problem. Personally I doubt that having face–to–face meetings is ever truly necessary. Once everyone in the group has thought of several ideas, they can write a page or two description of it and why they think it is a good idea. Then the decision makers (which obviously might be the same group) can read those papers and decide between them. Mozilla used to work something like this specifically to allow contributions by volunteers outside the company (no idea if they still do though). The Rust programming language is developed in a similar way: anyone can write an RFC to propose making a change to the language (or the associated tooling, the standard library, etc).
  - Fire-Dragon-DoL 4y ago
    I'm not convinced by this. It works but for a subset of problems, not all of them. And it overlooks the fact that people might build on top of each other, I don't think that was taken in consideration. What about exploratory meetings, where people are trying to understand a problem in the first place, those happen to be synchronous because answers evolve in other questions. Keep in mind that I never mentioned face-to-face, I just asked for synchronous time. That being said, I'm open to explore the idea, I think I already do this for a certain subset of problems using Slack threads
    - db48x 4y ago
ubermonkey 4y ago
>I think async is the next thing that will happen. If you’re building software there’s really no reason you have to share working hours with anyone. Whoooboy do I ever disagree with you there. We have never had offices, so everyone has always been remote, but we absolutely could NOT get in a groove with our former Indian subsidiary. There were a LOT of issues with us and them, some cultural and some just expertise-based (I don't think we had a great lead over there, and I DO think he was afraid of hiring people smarter than he was), but a HUUUUUGE chunk of the issue was that any issue became much harder to resolve because of the lack of meaningful time zone overlap. We ended the experiment and hired up more US folks, at greater cost, but with drastically better cohesion. I get that anecdotes aren't data, but I do not think I would join any team that was spread over more than 4 or 5 time zones. The lack of overlap makes meaningful collaboration too difficult.
- ryanSrich 4y ago
  > The lack of overlap makes meaningful collaboration too difficult. Please describe in detail what meaningful collaboration even means. The reason why people don’t often explain what it means (especially in threads like this) is because if they actually write it out, they’ll realize how completely unimportant and unnecessary it is.
  - ubermonkey 4y ago
    Peak HN right here. There's this vision that a Good Dev doesn't ever need to talk to anyone, because they'll always get the Perfect Specification, and no business needs will ever intrude and force adjustments, and no meetings will ever need to happen. Candidly, that's crap. If the spec is written well, there will STILL be points where you need to discuss things interactively. Bouncing emails back and forth during a workday is inefficient anyway; it's CRAZY inefficient if the time zones don't overlap, because then you're really only going to get one volley a day. Sometimes, TALKING is the right answer. If your dev team is working a day that is totally outside the rest of the company's working hours, then somebody is going to be working weird times to have that meeting, and that sucks for somebody. The hassle of setting UP that sort of call means people don't want to do it, and so cans of misunderstanding get kicked down the road. I'll never hire offshore again, and I won't work in an org that does it.

lifeisstillgood 4y ago

Can you explain your day to day? And how do you keep up with company politics, changing requirements etc?

jcpst 4y ago
As someone who has been fully remote the past two years, and in a team that is gradually exploring/adopting more async work practices over the past year, I would be curious to hear more too. Our team stopped having a standup meeting- we just have a daily automated post in our chat, and we comment in the thread whenever it makes sense. If we’re working on the same thing for days with no blockers, it’s not a big deal to not provide an update. We’ve reduced our synchronous communication by quite a bit. Some weeks I don’t have a single call I join. If you document everything well enough, you don’t really need to. I find myself on calls when I need to extract information from an architect that is just too busy to write everything down, or I’m mentoring a teammate. Or I’m in my monthly 1-on-1 with my manager. Working outside of regular business hours is not off the table, but it is new. It helps that some of us are in the US and some in Poland. Normally, just blocking off time on the calendar and marking your status (out of office) is sufficient.
ryanSrich 4y ago
I’m a startup co-founder, so day to day can be a lot of different things. But it’s something like this: 1. log on to Slack in the morning and see if there’s anything that needs attention. We use slack as a central hub. All of our tools funnel activity into slack. My team is small (3 full time, 2 part time contractors). Most of my team works over night and into the morning (very different time zones). Typically when I wake up, there’s a few PRs for me to review, or questions to answer on a ticket in linear. We also have a check in bot that runs once per week. No real need to do daily checkins. 2. After I catch up and respond to any questions (which most likely will be read by people that night or the next day) I see if I have any sales meetings. Since we’re a startup it’s still founders in sales mode. I might have a demo or 2 each day. This is probably my only non-async activity. 3. Outside of sales work, I also write code, review design work, and field customer support questions. So the rest of my day is a buffet of random stuff. As far as politics go. There really isn’t any. The team is pretty small. We might have a disagreement on how a feature should be implemented or something like that, but I’m the deciding factor and everyone is a professional so it’s not a problem.

axg11 4y ago

I like the concept of async work but I’m also scared of how transactional that would make work. Most companies that preach async now have a very strong, “friendly” culture. If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics. I enjoy the human component of work. I don’t like _all_ of my coworkers, but it’s still a net positive to interact with them. When I think about the ideal software job, a lot of the aspects of day-to-day work informally become async. Especially as you work with people for longer periods of time and gain mutual trust, a good workplace allows both managers and individual contributors to structure their own time.

ameister14 4y ago
>If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics. Here's the thing; that (a completely transactional relationship between all elements of a team) doesn't actually work well to make good products. Sure, a bunch of companies would probably do it as it's easier to measure worker production that way, but async also requires a different type of management and admin work that has to change as well. A lot of current managers won't be able to hack it, frankly, without the measured 'butts in seats' element. Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem. It's a different concept for business and teams, that's all. Applying the older paradigm is going to be a problem and while a lot of companies will do just that they will also be less successful overall.
- arinlen 4y ago
  > Here's the thing; that doesn't actually work well to make good products. Sure, a bunch of companies (...) Respectfully,you know nothing about what you're talking about. Async work is already the norm for some companies, even prior to moves to full remote work. I personally know teams in renowned companies which before COVID already split teams working on products between the US, Europe, and India. They stuck with full async because it worked, and worked better than alternatives. With COVID, the whole world went full remote due to necessity, and I personally know teams whose output improved significantly with the move to full remote to the point where they stuck in remote by default. > Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem. I disagree. What I'm seeing is a lazy, conservative mindset of people who feel scared and threatened by a reform shaking up the very core of a system they feel benefits them personally.

capableweb 4y ago

I'm of the view that it works best for some, while for others some other solution works best. There is no right or wrong, just personal preference. But even so, it seems to be a bit much to preach for something when you've never experienced another alternative, except from 6 months after college. It's hard to remain unbiased when you don't know anything else by experience. Personally, I've spent lots of my career in an office, and also lots of career working remotely, about the same amount of companies in each category. I'm more of a fan of the in-person dynamic you can create while being in the same location, compared to the almost-human dynamic you can create if everyone and everything is remotely. But I tend to work in much smaller teams (although one office-job and one remote-job were in pretty large enterprises), so maybe that's why I prefer one vs the other. Even though I prefer at-location work, I totally understand how others can prefer a different scenario. Depends on so many variables, so I guess my conclusion is just "it depends". Don't prescribe anything to others without knowing what they want, and don't let yourself be controlled by others opinions, just do what you feel is best for you.

xyzzy4747 4y ago

Incompetent engineers need to share work hours, otherwise they will get stuck and not get much done if nobody has overlapping times to help them. Not all engineers are high caliber.

zdragnar 4y ago
If needing help at some point in time means being incompetent, I think that describes everyone I've ever worked with, including some really high caliber folk. Even a simple rubber duck conversation can beat useful thing now and then.
- seanp2k2 4y ago
  No Google or Stack Oveflow, just everything from my memory into the IDE until the test case written into the JIRAs assigned to me all pass. No internet connection for employees, only test env access. At least, that’s how too many places still do technical interviews.
lupire 4y ago
This is also true for competent engineers. No one knows everything.
- xyzzy4747 4y ago
  What about founders - they don’t just get stuck and give up on random technical things. There are many incompetent people who will sit around and twiddle their thumbs if nobody is actively communicating with them.
- ipaddr 4y ago
  Wouldn't you go to experts outside of your companies? I may go to the company who makes the product for support or to a popular forum and ask a question.. none of this needs to be sync vs async
  - xyzzy4747 4y ago

hellisothers 4y ago

Maybe this works as an IC that has no collaborative aspect to their day-to-day but as an IC leader async adds material pauses and latency into projects. If everybody is ok with everything taking longer at the start and end of projects then cool (the middle implementation phase is less impacted) but taking a day to answer a question that could have taken minutes is not a bonus.

ryanSrich 4y ago
I’m a CTO and startup founder. We ship faster and more often than any team I’ve worked on or observed (multiple times per week). I think your assumption are bad.
- notyourwork 4y ago
  Without being dismissive of your opinion, being the CTO of a startup doesn’t really say much. I can be the CTO of a startup after I finish an undergrad in computer science or I can be the CTO of a multiple rounds of funding unicorn. So qualifying your opinion with the generic “I’m a CTO and founder” perhaps isn’t a sufficient credence to suggest your experience holds clout.
  - ryanSrich 4y ago
    The reason I mentioned my title is that I don’t think many would consider a CTO an IC. Saying remote and async only works as an IC is wrong.
db48x 4y ago
Asking a quick question that only takes a few minutes is a nice bonus for you, but for the person you asked it was an interruption that cost them 20 minutes or more of focus. That might be ok if the person you asked has a job that is designed to be interrupt–driven (aka a manager), but if this was another engineer then this wasn’t a net benefit. But the other side of the coin is that if you do need to ask a question and get an answer, then what is wrong with a text chat mechanism like IRC or Slack or whatever? These tools also work for real collaboration between engineers too.

orangecat 4y ago

If you’re building software there’s really no reason you have to share working hours with anyone. When I'm doing UI work, it's far more efficient to have a real-time session with a designer rather than multiple rounds of email/Figma comments.

deleted 4y ago
[deleted]
db48x 4y ago
Then one of you needs to work on your written communication skills.
- incrudible 4y ago
  Writing is always going to be slower, especially if done well. When it comes to UI, tight feedback loops are crucial at virtually every step of the way.
  - db48x 4y ago
    A feedback loop can be tight, or high–bandwidth, without having low latency. You just have to increase the sending window. Either that, or delegate more. If your designer tells you to implement X, and after that is done tells you to do Y, have them increase the sending window by telling you to do X, Y, Z and W up front. Then, when you implement W and it doesn’t feel quite right to you, you can implement W’ instead; that’s delegation.
    - incrudible 4y ago
      That is not a solution. You do not get to just decide on whether latency or bandwidth is the bottleneck of your task.
      - db48x 4y ago
        There’s no law of physics saying that a company cannot delegate decision–making authority to individual employees. If your employer doesn’t let you make that kind of decision, then that is a social problem rather than a physical one. Note that I have not said that an individual employee can decide how their employer does business, only that your development processes can be arranged so that they do not require low–latency in–person meetings between employees. You can do your business with or without any overlap in working hours between employees that interact with each other; the overlap is not required.

pharmakom 4y ago

Sync is, occasionally, essential to me as an IC. I think it would be reasonable for a company to require a few hours per week, with the precise time negotiated between the people involved.

nickjj 4y ago

> I think async is the next thing that will happen. Async or a few hours of common hour overlaps are really going to be a big contributor to work / life balance even though it sounds counter-intuitive. It's counter-intuitive because it could mean working outside of "normal business hours", but this is often exactly what you need to do if you want to do things on a whim (aka. having some type of work / life balance). Right now a lot of remote companies expect working hours between 9am to 6pm, that doesn't really leave any room for much of a work / life balance. By the time you get a chance to relax, prepare dinner, etc. it's already 7pm or even 8pm if you need to run errands. Even if you wake up at 6:30am it very quickly becomes 9am after doing a bit of exercise, breakfast, shower, etc.. If you're up at 6:30am you're probably pretty drained by 10pm. After dinner that leaves you like 2 hours to live your life and maybe fall asleep to a movie or book. Basecamp seems to have a very good policy on this. I forgot where I read it but I'm sure I once saw DHH mention that you can work any hours you want as long as you overlap 3-4 hours with CST and put in ~40 hours a week (~32 from May to September since every Friday is off). This is IMO a great first step towards async. It means you can on a whim decide to leave at 2pm EST because you worked from 10am to 2pm EST (9am to 1pm CST) so that you can go swimming on a nice day but you make up the hours later in the evening, or maybe you shift your working hours so you always finish by 2-3pm EST because your best working hours are really early in the morning and occasionally deviate from that for special circumstances from the business as needed. The hard 9-6 rule means pre-scheduling PTO with a lot of notice for things that often require little to no notice. I know some companies will let you occasionally take a couple of hours off without officially filing for PTO through HR but these often need a decent amount of prior notice unless it's an emergency. Basically it puts you into a position where you always need to ask permission instead of just doing it and be trusted to make up the hours.

Fire-Dragon-DoL 4y ago

How do you handle brainstorming sessions or design sessions where things are hard to solve, so there is no direct answer? I love the idea of async, but there are just some sessions that are incredibly valuable and develop on others thoughts, evolving in a final solution. At the company I work at, we compromise with a specific 4 hours overlap so that meetings can be scheduled only during those times

db48x 4y ago
It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually, and only then had a meeting to present their best ideas. And by “does worse” I mean that they come up with fewer good ideas, even when they are quite confident that they have completely explored a problem. Personally I doubt that having face–to–face meetings is ever truly necessary. Once everyone in the group has thought of several ideas, they can write a page or two description of it and why they think it is a good idea. Then the decision makers (which obviously might be the same group) can read those papers and decide between them. Mozilla used to work something like this specifically to allow contributions by volunteers outside the company (no idea if they still do though). The Rust programming language is developed in a similar way: anyone can write an RFC to propose making a change to the language (or the associated tooling, the standard library, etc).
- Fire-Dragon-DoL 4y ago
  I'm not convinced by this. It works but for a subset of problems, not all of them. And it overlooks the fact that people might build on top of each other, I don't think that was taken in consideration. What about exploratory meetings, where people are trying to understand a problem in the first place, those happen to be synchronous because answers evolve in other questions. Keep in mind that I never mentioned face-to-face, I just asked for synchronous time. That being said, I'm open to explore the idea, I think I already do this for a certain subset of problems using Slack threads
  - db48x 4y ago

ubermonkey 4y ago

>I think async is the next thing that will happen. If you’re building software there’s really no reason you have to share working hours with anyone. Whoooboy do I ever disagree with you there. We have never had offices, so everyone has always been remote, but we absolutely could NOT get in a groove with our former Indian subsidiary. There were a LOT of issues with us and them, some cultural and some just expertise-based (I don't think we had a great lead over there, and I DO think he was afraid of hiring people smarter than he was), but a HUUUUUGE chunk of the issue was that any issue became much harder to resolve because of the lack of meaningful time zone overlap. We ended the experiment and hired up more US folks, at greater cost, but with drastically better cohesion. I get that anecdotes aren't data, but I do not think I would join any team that was spread over more than 4 or 5 time zones. The lack of overlap makes meaningful collaboration too difficult.

ryanSrich 4y ago
> The lack of overlap makes meaningful collaboration too difficult. Please describe in detail what meaningful collaboration even means. The reason why people don’t often explain what it means (especially in threads like this) is because if they actually write it out, they’ll realize how completely unimportant and unnecessary it is.
- ubermonkey 4y ago
  Peak HN right here. There's this vision that a Good Dev doesn't ever need to talk to anyone, because they'll always get the Perfect Specification, and no business needs will ever intrude and force adjustments, and no meetings will ever need to happen. Candidly, that's crap. If the spec is written well, there will STILL be points where you need to discuss things interactively. Bouncing emails back and forth during a workday is inefficient anyway; it's CRAZY inefficient if the time zones don't overlap, because then you're really only going to get one volley a day. Sometimes, TALKING is the right answer. If your dev team is working a day that is totally outside the rest of the company's working hours, then somebody is going to be working weird times to have that meeting, and that sucks for somebody. The hassle of setting UP that sort of call means people don't want to do it, and so cans of misunderstanding get kicked down the road. I'll never hire offshore again, and I won't work in an org that does it.