11–20 of 43 posts
Some minimal time-zone overlap is never overrated. I think it is hard to beat real-time communication over chat or voice - asynchronous delays break up any flow in collaboration and turn it more into throw the requirement over the wall and listen for an echo the next morning.
Earlier quoted context omitted.
So then, how does FOSS fit into your notion of human biology?
Good model for maintaining an existing codebase, but not for designing good ones from the ground up. It works best with a singular leader (or geographically centered leaders) who can make the overall architectural and engineering decisions.
---
I believe the key to making remote work work is that everybody has to work remotely, or as if they were remote. If you have meetings and other communications happening face to face, then the remote people, to a greater or lesser extent become Cowboys, through no real fault of their own.
Very interesting food for thought here, but the difficulties of remote engineering are not fundamentally any more challenging than any other collaboration obstacles. Obviously having all the stakeholders sitting in the same room is the platonic ideal of a team, but to me this is a secondary concern after getting the absolute best people we can. I think the author is a bit out of touch with how startups operate. Perso…
I find it interesting that I myself am all for remote workers, but have had nothing but horrible experiences with workplaces where everyone has their own office. Pondering this a bit I think it's because every workplace I've been in with individual offices (Microsoft and others) also seemed to be very old school in terms of communication software.
I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person.
Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
Earlier quoted context omitted.
Good model for maintaining an existing codebase, but not for designing good ones from the ground up. It works best with a singular leader (or geographically centered leaders) who can make the overall architectural and engineering decisions.
How about the Linux kernel? Essentially, it began as something very basic in 1991 when communication methods were much different than we have today (e.g. video conferencing, etc.)[0]. There are many other examples of high quality open source projects that were born or greatly improved on the Interwebs, e.g. Git, Apache, ... --- [0]: http://oldlinux.org/Linus/911010.pdf
I'd love to see negating or supporting data either way, it's just my opinion that if you want a team of engineers (as opposed to a singular dictator) to build you something amazing (C Language, SR-71, Saturn V) they need to be in the same physical location and see each other face to face.
Earlier quoted context omitted.
So then, how does FOSS fit into your notion of human biology?
Good model for maintaining an existing codebase, but not for designing good ones from the ground up. It works best with a singular leader (or geographically centered leaders) who can make the overall architectural and engineering decisions.
I'd be interested in seeing/reading about cases of good "greenfield" projects where major architectural decisions weren't made almost exclusively by a relatively small number of people, particularly if the number consisted of more than one digit.
[1] subjectivity aside
I worked at two companies where everyone worked remotely. I think one of the big differences I noticed is that I never felt like I was that close to the rest of the team. We talked a few times/week through Webex or Skype, but it's just not the same as being there in person. Communication was also a big issue. It's not impossible to have good communication remotely, but I've rarely seen it in practice.
It's easy to say that communication is key, because it is, but all else being equal, if your team can't execute projects in a distributed, remote environment as well as it can in a centralized place, then it's not as good at communicating as you think it is. Dragging a failing remote team into an office isn't going to magically make them successful, and scattering a successful team across the world isn't going to sud…
1. Have the key folks (leads/project managers) travel and stay with team for at least 4 weeks in a common place. 2. Do not force video (leave the mode of comms to peoples preference (video / email / call)) 3. Allow decision to be made over text chat and have it added to project decisions in weekly meetings 4. Identify couple strong people per 15 members team and have relationship where they will tell you before deciding like 6 months in advance and allow people to leave. They will come back later. And wholeheartedly develop them even if you know they will leave, with one condition that they will develop one more person like them for the team. 5. Have good leader in India who can speak open with out fear of a westerner (I find this a most difficult one). This is a real deal maker between peace of mind and micro managing and going crazy. 6. Be open t listen to same idea that your team thought and decided to ditch from your offshore partner. (we can go for full blog post on that)
I think this would take the team long way. Please remember either USA side or India will have to lose 3 evenings a week, irrespective of SRS, Comm tools and so on if you need a successful delivery.