In general, I totally agree. Being able to hire the best person, anywhere, and allow them to work super-effectively is a strong moat. I share this opinion and hire accordingly.
I think the "these companies are wrong" posts, though, are not attempting to see it from the other side.
Try to put yourself in the shoes of these startups. In super-super early startups (e.g. pre-profitability or definitely pre-revenue) one of the goals (aside from staying afloat) is to build a sustainable culture (company etc.). It's very difficult to build a company culture AND product AND hit profitability AND 1,000 other things from scratch before going out of business.
When most are co-located and a few are distributed it just adds one more thing to the pile. I've done it before, so I know how hard it is, even when we were all 'on board' with it.
It's just harder; you need to start from scratch with the assumption that any one can be remote at any time, and so you build your tools/processes accordingly (if you have a physical kanban board then it'll be a real hard thing to support remote devs).
For just one non-top 1% of all software-developer persons? The overhead is probably not worth it if you have a ready talent pool in your city (especially if you now have nexus in another state, which is a very real risk as states are looking to increase their revenue. ugh).
For Joe Average, or Jane Above Average, these companies would prefer to hire a local person than remote. That makes sense to me.
As a big part of getting from 'startup' to 'sustainable business' involves managing risk. So, understand where most of these businesses are coming from. Having one or two remote people in a company full of on-site people is a risk (not from a technical perspective, but from a culture and focus one), and not one they're willing to take.
It's a trade-off, and one that can make sense if viewed in context and done for the right reasons (note: "We can't control them/see their work/trust them/need to see their faces/need them from 9-5/etc." are WRONG REASONS).
Ranting about a system problem isn't very useful; I'd like to see more posts about how to convert a primarily on-site team to support 'work anywhere'. What processes and tools need to change to do this?
1. Continuous Integration (and or delivery)
This is the sine qua non. Everyone should be able to check out and build a complete working eco system and run
all tests on their local laptop or Rackspace cluster you rent just for them
2. Really, get the continuous integration working. Stop now and do nothing else till you have. Tell the dev's remote working is only possible after one month of a CI process that is never broken itself (although build can break). Spurred on, everyone will suddenly get that CI build working.
3. The CEO must build a complete off site copy of the entire company on his remote laptop. Is it getting boring yet.
4. Agree on one place to store all documents, all meeting notes, everything. Do not split comms over IRC and Skype and gmail and ... It will mean no one can reliably contact anyone else because "oh I left you a message on Skype", "but I live on IRC"
5. Get different people to work together on different areas. Pair programming is not ideal IMO, but having Fred write the code for task A and Bob principlaly write the first tests, means they have to talk and decide a solution, and Bob keeps a friendly competitive eye on progess. Move these pairs around a bit.
6. Stop trying to get updates for management - its either working code or not.
7. talk to people a lot. Watch thier checkin velocity - it will speak volumes. Talk if it changes.
8. Assume, perhaps commit visibly, to people as being safe in their jobs for a long time (2 years minimum). This to me seems the biggest - people need to feel safe. Maybve thats just me
"4. Agree on one place to store all documents, all meeting notes, everything."
This can't be understated. When I ask the founder where the company logo is and they say "it's on one of the external harddrives sitting around the office somewhere", it's incredibly frustrating. The most well-oiled startup I worked for had a perfectly organized central-storage of digital resources, which greatly contributed to the smooth workings of the company.
If you're looking for a self-hosted solution to keep you from becoming overly dependent on Github, take a look at Gitlab [1].
Since you're using Git, all those repos are presumably backed up on individual development machines. Or you could easily write a cron job to mirror them every day or so.
The real problem is other content like issue tracking, wikis, and pull requests. If keeping these is important, you may be locked into the platform, at least as far as existing projects are concerned.
I think the "these companies are wrong" posts, though, are not attempting to see it from the other side.
Try to put yourself in the shoes of these startups. In super-super early startups (e.g. pre-profitability or definitely pre-revenue) one of the goals (aside from staying afloat) is to build a sustainable culture (company etc.). It's very difficult to build a company culture AND product AND hit profitability AND 1,000 other things from scratch before going out of business.
When most are co-located and a few are distributed it just adds one more thing to the pile. I've done it before, so I know how hard it is, even when we were all 'on board' with it.
It's just harder; you need to start from scratch with the assumption that any one can be remote at any time, and so you build your tools/processes accordingly (if you have a physical kanban board then it'll be a real hard thing to support remote devs).
For just one non-top 1% of all software-developer persons? The overhead is probably not worth it if you have a ready talent pool in your city (especially if you now have nexus in another state, which is a very real risk as states are looking to increase their revenue. ugh).
For Joe Average, or Jane Above Average, these companies would prefer to hire a local person than remote. That makes sense to me.
As a big part of getting from 'startup' to 'sustainable business' involves managing risk. So, understand where most of these businesses are coming from. Having one or two remote people in a company full of on-site people is a risk (not from a technical perspective, but from a culture and focus one), and not one they're willing to take.
It's a trade-off, and one that can make sense if viewed in context and done for the right reasons (note: "We can't control them/see their work/trust them/need to see their faces/need them from 9-5/etc." are WRONG REASONS).
Ranting about a system problem isn't very useful; I'd like to see more posts about how to convert a primarily on-site team to support 'work anywhere'. What processes and tools need to change to do this?