| I have been working remotely for the past ~4 years and it has proven to be one of the most productive approaches for me. I find that meeting many of the "challenges" of managing distributed teams end up being worth much more than just the ability to hire quicker and from a broader pool. Distributed teams and asynchronous communication ( email, wiki, tickets ( and comments to them )) coupled with knowledge repositories ( such as internal stackoverflow clones etc ) allow formal, persistant capture and presentation of best-practices within the team, without a large upfront cost and 'documentation rot'. Having to verbally explain something to each new member in turn strikes me as much less efficient than being able to point to written documentation and a centralized place to request information or clarification. It also helps ensure that goals and approaches are actually captured clearly, rather than assumed based on nodding heads. Tools like assembla.com ( full disclosure, I have done work for them ) and other team / project management offerings with integrated source control also serves to capture raw metrics to allow better estimations going forwards and better pinpointing of areas that need strengthening. It is often said that adding new members to an existing project can extend the duration of the project, as experienced developers need to spend time on getting others up to speed than actually working on the deliverables themselves, by building this documentation into the process as a whole that cost can be amortized, shared across the team and contribute to knowledge transfer even among high-value members. By embracing ticket based development, it means that people can continue working on something else if they come across blockers or are waiting on feedback for whatever they were working with before. It also means that developers can choose tasks that they find compelling or have otherwise non-obvious synergies with their background / recent tasks. While working in that kind of environment I manage 55+ productive hours / week pretty easily, and with pleasure - as have many of the people that I have worked with, by virtue of minimal administrative overhead and being able to 'stay in the flow' working on tasks in a self-directed manner within the context of goals for a particular iteration. Capturing the value-add of developers via tickets ( though obviously imperfect ), tends to minimize social manipulation of managers in terms of who did what. The persistent record of ticket comments, code review input, code commits, and other exchanges works to increase transparency - accountability and value can have a firmer ground to be evaluated. The biggest problem that I find with preferring to work as a telecommuter is how few companies seem to be open to hiring under those conditions. I have had offers where the only sticking point was that I needed to relocate to New York, or California, or Amsterdam, or Brisbane, or Singapore .. etc. They are all great places, or well, fine places at least, but I am pretty content being surrounded by rice fields and having chanting monks strolling by now and then. If you could use a telecommuting fullstack / JS Engineer - let me know :) |