How Paul Graham Is Wrong
ma.tt
ma.tt
I've been a 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other.
I'm not advocating an open floor plan with noise and distractions. Even a set of private offices that share a common corridor to facilitate spontaneous conversation with a side conference room for group brainstorming, is superior to keeping Skype windows open.
Yes, there are the common examples of virtual remote workers at basecamp, Automattic, github etc. Those are not billion dollar companies. A lot of startups have ambitious goals and very hard technical challenges and you can't compete with a team made up of 99% remote workers. I see no evidence that this has ever been successfully done. Small scale modest businesses, yes, but not big ones.
Maybe you can hire a 5-person 100% remote team to launch a new web magazine. Journalists and editors by their nature seem to fit the remote work paradigm quite nicely. At first glance, it seems programming also fits, but only for modest projects.
Yes, the remote workers themselves will insist "I'm 100% just as effective offsite as onsite -- in fact, I'm more productive because I'm not interrupted by office nonsense." No doubt they feel that way but the whole team isn't more effective.
Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent.
Also, most offices (and businesses) are not really built to support proper collaboration and working conditions. As an example, due to a recent job move, I'm stuck in an office 80% of the time right now, and it's pretty miserable. It's an open office plan so there's constant noise and visual distractions, my boss can (and does) come over and interrupt me constantly on issues completely unrelated to my work, and in a former life the office was a welding garage, so I'm pretty cold most days this winter.
I hear of the unicorn offices, where they were built to support collaboration and focused development work, but I've always found reality has more in common with Dilbert than Valve.
Programmers tend to want to squirrel themselves away and work on stuff to maximize their own personal productivity, whereas organizations want to get a bunch of people working at a group optimum. That means that every individual takes a productivity hit for communication purposes, but that the organizational output is much higher than any individual could achieve. Hence, we get the fruitless debates about working conditions: what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.
There's definitely a fine line between communication and distraction and it's hard to hit the balance (I've worked in some horrible "open-plan" environments too), but in my experience, programmers nearly always err on the side of too little communication, especially early in their career.
The reason I didn't hit deadline X? 5 "spontaneous collaborations" happened at my desk in 3 days. Wait... I don't get my bonus because we missed the deadline? But... my collaborations helped the marketing dept hit their goal ahead of time, and they did it by coming to my desk and asking me questions. Oh... that'a a different budget?
If you want to foster that sort of behavior, make sure all of the aspects of the business line up in support of it, not just the facilities budget because "open plan" is cheaper than private offices with doors.
> you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.
If you value developer productivity at all, that little bit of friction is a _good_ thing. It means that you have to think for a second about the most appropriate forum for that discussion. And if you decide that you do need to talk to someone, the friction isn't really that high. Click on a user, click on the green button with the camera on it, and you're talking.
In-person spontaneous collaboration is, in my experience as both a developer and a development manager, highly overrated, and the value is very rarely worth the costs. Those costs include lost productivity, developer stress, bikeshedding, and an implicit culture of hostility to anything that doesn't _look_ like productivity (like thinking).
Taking a moment to put on my development manager hat, one of the things I never want to do to my developer employees is interrupt their flow. I go to meetings, so I can give them a brief summary which contains only the information they need to do their job. I work with the customers and listen to 50 minutes of rambling so I can glean the 5 minutes of information my employees need to do their work.
I've hired them, and I'm paying them ludicrous amounts of money, to create programs; to create value for the customer. Anything that gets in that way is up to me to address and remove. And based on my experience as both a developer and a manager, those "spontaneous collaboration" interruptions are usually something that needs to be addressed and removed.
The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem. Whether that outweighs the increased individual productivity from eliminating distractions is very much case-specific, which is perhaps why there's so much heat and so little light on this issue. You'll never capture all the complexities on a web forum.
I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP).
> The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem.
How does colocation solve this where remote does not? Do you expect that your co-workers would somehow notice this from looking over someone's shoulder, as opposed to when you pull in a branch of code from your VCS?
Once you've pulled in the code and notice the problem, you can bring it up in the next scheduled standup or hit the little green button next to their name in Hangouts/Skype/...
I can not see how being colocated would do anything to help speed the discovery of this particular class of problem in a way which is not practical using modern telecommunication software. As a point of reference, I have personally pair coded (with anywhere from 2 to 5 people) with folks in England with great success.
These are not hypotheticals - there have been numerous points in my career, ranging from being a sole technical cofounder to working in a 50K+ employee company, where a chance meeting has saved me weeks-to-months of implementation effort. And in each of those cases, the solution they suggested was not something I would've thought to look for on my own, because my starting assumption was that it needed code to solve. And similarly, it probably would not have been spotted until the feature was done and the time spent, because usually your coworkers' assumption when you embark on writing a solution is that the solution is necessary.
I've seen many examples that exactly the same problem as you've written happens even in co-located team, so it's a problem of lack of communication, not of being co-located (or not).
These behaviors are simply not constrained by the environment, not anymore.
It's an exceptional and rare organisation where this is even remotely realistic as a goal.
The appearance of productivity is usually far more important than the reality - especially in mid/late corporations, where the most significant outputs are primate status plays and politics.
>what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.
I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity.
No sane manager is going to want to do that without a really good reason.
>programmers nearly always err on the side of too little communication
That's because programmers like to be left in peace to work on small, relatively well-defined problems. Communication can be limited to progress and code reviews and goal-setting by team leaders. Everything else is noise.
The real problem with remote working is that too few corps understand it, and too many managers believe employees aren't functional adults who can work without constant supervision.
It's a management issue, not a programmer issue.
I think at some point we're going to see some faddy Harvard Review type write a faddy Harvard Review type book about remote, and it's suddenly going to become the new outsourcing. Because cheap.
But meanwhile - Paul Graham's problem is that he has a nostalgic hankering for a vision of SV and start-up culture that's already well on its way to being disrupted by the global talent he wants to move to the US.
If you're a world-class five percenter, why on earth would you want to move somewhere with insane living expenses and in-bred VC culture of the Valley when you can bootstrap and innovate around it elsewhere?
Does he really believe all that funding and schmoozing and presentation is essential to getting a business up and running on a planet with an Internet?
Graham maybe needs to consider the possibility that those five percenters aren't his future employees - they're his future direct competitors.
"The appearance of productivity is usually far more important than the reality"
No, that's just cynicism talking. Larger organizations care about your personal productivity, but they care less than small organizations. Part of the brilliance of modern corporations is that you don't always have to be at peak productivity as an individual in order for the company to profit. Which means, in turn, that you can do things like get sick or have a family without having to give up your job. The flip side of feeling less efficient is that you have some cushion when you actually are less efficient.
"I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity."
You obviously don't want to interrupt someone gratuitously, but the point is that your perspective on what's important can differ wildly from your employer's perspective. Keeping someone in "The Zone" is not the only goal. An employee in "The Zone" who is churning out "The Wrong Thing" is worse than no employee at all. So you need communication. And as soon as you need communication overhead, people are going to be interrupted. It's a cost of doing business.
It sounds a bit like people shooting the shit about great footballers or something where you up the ante to large it up ;)
That implies a time zone with a lot of overlap. Rome/Berlin time is 9 hours ahead of San Francisco, meaning there really isn't a lot of overlap.
Real time communication also means that you need to consciously set up the call and pay attention to it. Sometimes I overhear something at work, or we talk about something interesting at lunch, or there's an "oh shit" moment (not often:-) when it's really convenient to have everyone jump in.
I've been doing open source and IRC and 'the internet' for more or less 20 years, so I'm pretty comfortable with the whole thing, and happy with it, but when there is a sense of urgency, it can sometimes be less efficient.
If you chose not to talk casually when remote that is really up to you.
I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.
0900 my time is 2400 west coast time. No overlap there. 1700 here is 0800 west coast time. Granted, I don't leave that early from work, but not all programmers are "in the office by 9" people either. There's not a lot of overlap.
> I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.
I don't doubt it's possible, and even the best solution for some people in some situations. But not for everyone.
The key word being "conscious." Finding good developers is hard, and finding good ones that communicate well remotely is even harder.
Shameless self-promotion: we (nearly 100% remote) explain some of soft skills we look for in an engineer here: http://www.staunchrobots.com/blog/staunch/
There's probably a training business opportunity in this sector.
I've been remote for eight years now and I work on a codebase so huge that no one person understands it all beneath the 10,000 foot level. Nearly all of us are remote (only the managers are "local" to San Jose). Once a quarter we get together and meet up, coming from Vancouver, Toronto, Bangalore, Colorado and northern California.
Although it's insanely technically challenging, many computer science projects are more difficult than the Linux kernel to do remotely. For example, watching users interact with the software, anything that involves expensive test equipment, anything that runs on embedded/custom hardware.
MySQL was a 1B company and built with a remote team:
http://developers.slashdot.org/story/13/03/07/1826212/former...
The original Paul Graham essay[1] had a lot of focus on "startups". The companies in the early days scratching and clawing trying to make things work. I thought that was the context.
MySQL was started by 3 guys in Sweden working in the same office. Even if they wanted to have everyone working remotely in 1995, there was no technology (high speed internet) at the time to do it. Sure, as a company becomes bigger, and also as technologies improve, there are possibilities for organizing remote work.
Anyways, back to the context and constraints of startups: If you're a startup, it would be great to recruit the "exceptional" talent in South Africa, Ukraine, China, New Zealand, etc (because 95% of the best programmers are not in the USA).
The MA.TT says remote work is the answer. I don't see how because I've not seen any evidence of any billion-dollar American startup that was built by a 100% virtual team from multiple timezones of Europe/Africa/Asia.
If you're creating a 24/7 tech support department that "follows the sun", having staff in far off timezones is awesome and necessary. If you're trying to build a product with hard challenges for the team to solve, MA.TT's "answer" of international remote workers is not an answer.
A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distributed, and we thrived with email, persistent chat, weekly meetings via phone, and occasional in-person meetings.
It does in Paul Graham's essay and OP's response to it. Again, we're losing sight of the thread's discussion. (Please read PG's essay that started this.)
PG's essay was about H1-B visas (recruiting foreign talent into the USA) and the OP (MA.TT) said the answer was remote workers. This means international remote workers that are 6+ to 12+ hours ahead in timezones.
We're not talking about hiring remote workers in Maine and Rhode Island to work as a distributed team for California companies. We're talking about remote workers in far off timezones like France, Japan, Australia, etc. I know of zero examples where the type of company that Y-Combinator likes to fund (e.g. billion-dollar ideas) was built with remote workers to the extent that the H1-B conversation can be rendered a moot point.
We failed mostly because our product was overly ambitious, solving a broad problem.
Yes, is just an anecdote, but my point is that distributed team can run circles around most of colocated teams and we wouldn't have been able to assemble that team if we insisted that everybody had to be on the same place.
Of course, it only matters if you let it matter. Some people don't care or need that stuff. They worry about their own work and leave work at work, which I'm working on doing :)
I agree that remote removes critical bandwidth for cross team communications.
On the other hand, lots of programming projects are parallizable to n crafty individuals who need colocate only once in a while to " totally sync their mindstate" and can communicate effectively enough in the mean time using other ways without loss of critical bandwidth if the need for that bandwidth is not needed.
Not all teams need the same kind of cross individual bandwidth. Of course loss of colocation leads to loss of serendiptuous talks to create novel insights but if the insividuals working together were located far apart in the first place then they might not be working together at all if not remote.
Personal anecdote to give a practical example:
I recently moved to another team within the same organization working on the same product but on a different level. The team from where I moved developed the stuff that got CI:d to customer builds and it would have been really difficult for me to imagine working remotely there as the work required often going around the floor asking about stuff (lots of undocumented legacy).
My new team focuses on tech and middleware and creates libraries for downstream to consume. Programmers work on their own libraries and I can go on for days without requiring input from anyone. On this team I could easily work remotely.
Based on my experience I would claim it depends on the designed team duties wether remote works or not. And I think this means that team organization must be tightly coupled with the software architecture design. I have no idea which should drive which but I'm pretty sure any changes in one should also be consciously reflected in another.
And those companies aren't billion dollar companies either.
"All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace"
But they're more effective than those people not working together at all.
"Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent."
You have to define 'best'. If the definition of 'best' has to include "people who are willing to uproot their entire life to spend a portion of it in someone else's office", then yes, you're correct.
"I see no evidence that this has ever been successfully done. Small scale modest businesses, yes, but not big ones."
I see little evidence that co-located teams are all that much more successful at becoming billion dollar behemoths than virtual teams.
You get access to a wider breadth of experience of worker when you embrace remote. Just because management hasn't had enough experience with the model yet to be able to grow a billion dollar company doesn't mean a) it's bad or that b) it may not happen in the future.
I think you're underestimating the degree to which day to day office crap weighs on people and makes them far less effective than they might otherwise be, even if they get to have someone come over and "pair" with them.
Remote working is an approach that really needs to be embraced by the entire company, and refined over time to match the needs and skills of the team as they change. Some people need more one on one time, some need more group time, maybe you do some face to face meetings quarterly instead of annually. It's not a one-size fits all, but nothing (including f2f office work) is.
One of my old start-ups had white boards everywhere (when we ran out, there were windows...) and ad-hoc bi-lateral marker-of-death struggles would spring up anywhere all day long. That was super handy.
I've mostly been an independent lone-ranger type for a long time now, and have rarely met most of my clients face-to-face -- but I do miss at-the-drop-of-a-hat white board sessions.
I like f2f problem solving too - whiteboarding, high energy, etc - it has its place.
If everyone on the team has a 2 hour commute, that is a guarantee that there will be less time available to the individual and thus the team. Commutes are a big problem aside from the communication.
I have also found that companies that do remote or allow it, just communicate better, to all parties, even clients or stakeholders. They are more external focused companies without internal blinders, they take an external view of the company instead of internal. Lots of employees time is commuting and dealing with office politics which become a bigger part of your job than working at some places.
Personally I think companies that are remote or allow remote are much better at communication overall and have a saner external view of themselves coupled with the internal view, rather than just an internal view of what matters. I have seen this across many companies I have worked for or with. Some internal places I have worked that didn't allow remote made it very hard to get information because they expect people to barge into offices to ask.
Overall I feel remote companies have the benefit here and make for more robust teams if they do it right, not to mention the benefit of attracting great developers all over the country or world.
Today, virtual communication is how we communicate to most of our clients, customers and stakeholders. Companies that allow remote just do this better because they also communicate that way. Remote companies value external views of the company and communication much higher than non remote capable companies.
Two more benefits of remote capable: When you setup another office upon growth the new office will not have the virtual communication problem (office to office within the same company is typically virtual communication and non remote companies do this badly), also remote companies root out non-contributors more quickly as you can't just hide behind being there physically as work you must contribute and build.
VCs are so against remote that it seems like they almost have some tax hookups and own lots of real estate in SF as some of the logic makes no sense, ultimately labor costs would be cheaper and the companies would be more robust to changes.
I am willing to sacrifice 2-4 hours of personal time per day commuting => I am willing to sacrifice myself to the company's wishes => I am a 'good employee'
A portion of the advantage of office work comes down to employer control of employee. The differing communication systems with clients, customers and stakeholders illustrate the different balances of power accurately.
As such, I agree that remote companies make for more robust teams if they do it right - but it's much harder to do it right.
Remote companies lose some advantage of easy communication (in order to survive as a remote, you have to be better at communication), and you lose some advantage of having a clearly indicated power structure.
Basecamp, has not gotten outside valuation for a long time, but they are just as if not popular that Asana who was valued at $280mm back in 2012.
As a software engineer that previously worked in an open floor plan I can testify that they absolutely crush individual productivity. Headphones are no solution. I think I'd need a potato sack on my head too.
But as a software engineer that currently works with geographically distributed teams, there's no way to deny that certain elements of communication can't be reproduced with chats and hangouts. It's not just technical discussions either - it's much harder to build cultural cohesion in distributed teams as well. Which is a bummer because it's a lot easier to engage in blame and scapegoating when the guy that wrote something is just some email address and not a friend.
I wonder if anybody has had success with some sort of 80/20 (remote/on-site) model...
I haven't read the entire thread of comments, but as I read about the mishmash of remote tools, I'll throw in an endorsement for Microsoft Lync. The full blown integration of email, video, audio, screenshare works really well.
Totally agree. But also feel collaborative periods make up a small amount of our time - remote workers allow having more/better/cheaper developers (whichever of the three you want) which can easily offset the less effective collaborative times.
If software development were a field where we spent most of our time collaborating with others remote work wouldn't make sense. But most developers are spending most of their time alone at their desk coding or communicating with others in a manner that doesn't differ based on location (i.e. you still email people in the same office).
Sorry, this just isn't true, the IT team in my old place was 100% remote (there were sales and marketing in local office), and we had very big growth and success solving quite a few technical problems scaling the business for millions of users. It's more of recruiting people with right skills and right mindset. After scrums/whatever we spend 90% of our time solving the problems - being on site doesn't really help unless you do do some specific R&D that requires constant team consultation - which 99.99% of startups here DON'T do.
As someone who worked remote for 6 years (with a few face to face meetings over those years) and now works in an office I think each have their trade offs and it balances out largely. In an office you can get quick questions answered much faster. If you forget to ask something in a meeting you can find the person and quickly get the answer later that day. Discussions are more natural too. However I've found that when working via email or Skype discussions are much more focussed. We ask our questions, get out answers and get back to work. In a face to face discussions people tend to add words to their sentences to make what they're saying seem longer/more important. Discussions deviate from their intended purpose. Sometimes that can be useful but often it's a waste of time. I've been in meetings which I could have wrapped up in under 5 mins - and the people I'm with are there for 30-60 mins. They talk about irrelevant things, repeat themselves with slight variations etc. etc. Sometimes this can be necessary if you're building a relationship with someone but most of the time it's a waste of time.
Agree. Which, in fact, was one of the reasons that both Bell Labs and the Manhattan Project achieved what they did. (For sure a different time which lacked many of the advantages we have today.) And you could also argue about the negatives, the distractions etc. [1] But there is no question that in many cases it's an advantage to be located near others working in the same area and not in near isolation.
[1] If you don't like listening to music (I don't) use a set of 3M "tarmac" grade earmuffs which will block out nearly everything.
Err, no. The Manhattan Project succeeded because it has most of the available physicists of the world, a blank-check budget, top priority and rather severe real-world pressure. No startup idea will ever have that kind of staff...
Managers + VCs, if they have a choice, prefer all in the office so they can keep power but this actually makes them less competitive and more susceptible to physical disruptions: moving an office, an employee moving, time, office politics, commute, distractions, over meeting and more.
The PG essay on this was glaringly overlooking that you can be a US based programmer and be good or great even if you aren't in SF. Tech companies have a responsibility to not be so monoculture and they currently have a single point of failure in Silicon Valley, which from an engineering perspective is poor distributed design and very little redundancy.
There are benefits of being in one place, the ability to meet physically and be on the same page but we all know the real work gets done back at our desks in our solitary focused modes when it comes to programming and making products. Then we open up for feedback and iteration, then again back to work.
The work part should be setup so programmers perform their best. Just like some of the best scientists, writers, etc, they need their lab/office where they can get somewhere with the problem at hand, not an open office in SF.
Glad Ma.tt mentioned this as he is a leader in the right kind of tech leadership we need: spread it around, live better, work hard, deliver solid products, from anywhere...
The more the VC community gets un-hinged from the reality the quicker the inflation of the bubble and the crazier the assertions.
Time to get out of the bubble.
Let's think about the consequences.
If this is implemented, it will hurt the sender countries (brain-drain) and may even lower the salaries for people who are already here. I'll go back to the brain-drain again. The REST OF THE WORLD NEEDS DEVELOPERS TOO. Maybe even more than the US.
Once here, these people will toil long and hard and face very steep challenges in making serious money. Maybe 1-2% of them will see millions. Most will make sub-par wages as immigrants. Yes, H1-B wages are lower.
Meanwhile, VCs, since their bets are widely hedged will get to play many rounds of the same game increasing the odds of the payout.
So, that means all things being equal, when really good developers leave their countries they are depriving the local market of their talent.
If you think of the equation this way -- when engineers immigrate to the US they are bringing with them the investments that their own countries had made. Outside the US many countries subsidize higher education, especially engineering.
It used to be that the money that these engineers sent back would more than offset the local productivity gains. Given the growth in China and India and the salaries there it is hard to argue that the remittance is a good compensation for this "brain drain".
Morally we'd both be better off, I would like a better quality of life (subjective I know) and you'd be able to contribute to Indian development.
If everyone is co-located, you have inconvenience and higher productivity. If everyone is remote, you have an inherent overhead, but enormous flexibility. If some people are co-located and others are remote, you naturally tend towards a divide where people who are co-located without thinking about it wind up networking with each other and excluding the remotes.
If you are a small startup, the productivity difference really can be the margin between success and failure. Hence the pressure to co-locate. But conversely the availability of better talent in theory can allow for a better workforce which might outweigh the productivity overhead of remote work. But when there are just founders, by definition you can't assume that there are better people available. And the need for close working at the initial stages gives strong pressure to co-locate.
Therefore there is a natural tendency for startups to co-locate. And once the seed of the company is co-located, switching to a remote model is going to involve crossing a difficult cultural barrier that not everyone will succeed in. Thus the continuing pressure to co-locate.
This is purely up to the team. Sometimes being co-located leads to over meeting and lots of time spent on disruptions and chats, while remote working lead you to be more professional and talk to your co-workers only when necessary for the job.
> amazing technology that allows us to collaborate as effectively online as previous generations of company did offline
That's a huge claim, and it's disputable. For example, I've worked both ways a lot and find remote work to be dramatically less effective.
If you accept the claim, then sure, the startups PG was writing about are missing the obvious, and for the most ironic of reasons—technical backwardness. That's possible. But there's also a lot of wishful thinking and saying-makes-it-so on this subject, which comes up on HN all the time. A lot of people just really, really want this to be true. That alone doesn't make it true, and I think it's at least as possible that desire is distorting the analysis. (Which, as someone whose whole career has been plagued by an unsolvable constraint problem of family, work, and geography, I can easily understand.)
Fortunately, we're going to find out. If all those startups are doing it wrong, then there's a gigantic market inefficiency and we'll soon see a new wave of smarter, less backward companies doing much better.
I have been on both sides of remote work, so I totally get that it's not a slam dunk. It works a lot better for companies that have a strong culture established in a home base, and it works a lot better for experienced folks than green college hires. I have shut down the interview process myself when I felt like working remotely wouldn't work out at particular companies.
Even given all of that, I was pretty amazed how quickly some of the conversations got shut down. No remotes, we don't care who you are or what your experience is. I didn't talk to any companies outside of SF that were that quick to say no.
FWIW I landed at Stripe, which in fairness is probably one of the companies pg had in mind when writing his original article. I agree with the spirit of this, and I also don't really agree with a lot of things in pg's essay. But the particulars here might be totally wrong. At least one company in his network is really remote friendly.
In short, I believe it's the commute that engineers don't want causing a big part of all this gentrification and talent shortage talk. Personally, my Linkedin says I won't take any job that I can't walk to from a BART station. Google is an exception though; the whole GoogleBus at MacArthur BART situation.
You can solve the "transportation" issue by avoiding having to transport anyone in the first place, which is exactly what the author is speaking to when they suggest remote working arrangements.
For an industry that often derides 'monoculture', the SF tech scene sure resembles one.
Not factored into the equation: An actual, provable, verifiable history of illegal salary-fixing. The experiential reality that most immigrant programmers get a lot of mistreatment, both from racism and from their own incompetence - and the related experiential fact that a lot of immigrant programmers are utterly incompetent.
The rhetoric of these arguments talks about 10x programmers, but companies really seem to prefer importing 0.1x programmers or even -10x programmers.
Meanwhile, tons of companies have immense success with remote work, and the wage changes associated with the last ten years are not at all commensurate with the increased value of programming work. (See aforementioned illegal salary-fixing.)
Is remote work easy? No. But is PG's business about doing easy things? No.
I literally just ran grep -c "table" against a text dump of this comments page. The count was 122. 122 uses of the table tag. Since that includes </table>, 61 tables.
This whole argument is as up-to-date as the HTML on this page.
> As a side note, avoid remote employees in the early days. As a culture is still gelling, it’s important to have everyone in the same building. [1]
A San Francisco tech company can employ developers in Krakow to work remotely without dealing with visas. But those developers either need to be 1099 contractors, or loaned out from an outsourcing firm.
Both options are poor. Outsourcing firms for obvious reasons (introducing a middleman that serves no purpose whatsoever except to serve as a legal fig leaf). 1099 because (a) it creates a second class of employee and (b) because it's technically unlawful to classify full-time employees as contractors.
Also remote work doesn't mean overseas, there is amazing talent all over the USA too that doesn't happen to live in the SF area.
I really liked this sentence: "The US has less than 5% of the world's population. Which means if the qualities that make someone a great programmer are evenly distributed, 95% of great programmers are born outside the US."
There are about 7 million people in the Bay area, 322M in the US total, so let's say 98% of the great people in the US are born outside of Bay area. There are no visa issues moving between cities or states in the US, but many many other barriers that have nothing to do with visas.
I'm not a lawyer, but I am an employer, and it is not clear to me that the "1099 remote worker" strategy is as clean a solution to the immigration problem as it's being made out to be.
But you cannot issue Social Security Number (SSN) for foreigner without going through immigration process.
I think the same immigration process that would block employers from issuing SSN would also block any foreign contractor from winning "I was de-facto employee" case in court.
IANAL
I have a relative who snowbirds in the US on the max visitor visa from Canada and she has all sorts of problems dealing with even basic things like cable companies who want a SSN to do tech support for some reason.
It's about hiring US/Canada based people and not forcing them to relocate. Using Slack, Skype, screen-sharing, co-working spaces, etc. to collaborate and stay on top of everything. The kind of companies you see hiring at: https://weworkremotely.com/
I'm doing it at a great startup now and it's awesome. I've got kids and my wife is in college–I'm not relocating to SF.
Maybe there are intricacies to being in a heavily-funded, high-growth SF startup that prevent this ... I just don't know what they are and PG & sama aren't elaborating on them.
Thanks. (We're doing a startup from Chicago, with one very, very remote team member.)
A cursory glance at the HN/YC jobs page shows 1 remote-friendly position out of 20+. Why?
I'll admit, people are probably wrongly ascribing bad intentions to PG's essay and sama's related tweets. But that's what happens when you fail to address the other options.
For me remote is the solution to the so called talent shortage in the Valley. If companies were really interested in hiring the best developers they'd drop their archaic view of remote work and remove location-dicated working.
Its even more pronounced in the UK and Europe.
(I used to work at Automattic)
(I work at Automattic)
AFAIK you do not have to file 1099 form in order to deduct foreign contractor expense from US business revenue.
I'm not a lawyer or CPA, but I run my own business and pay to foreign contractors.
It may or may not be the case, but when foreign contractor works as a business entity then "Foreign Person’s U.S. Source Income" seems to be irrelevant.
If I were running a company with hundreds of employees&contractors that would be a point of concern.
However from a bootstrapped startup perspective that probably does not even worth investigating further.
Everyone is free to sue for anything. That's the cost of doing business.
Hiring foreigners directly as employees has many other risks in addition to having inevitable overhead.
But these are some of the worst problems, because they submarine. You pour the money, sweat, and (most importantly) time into an enterprise, risking its total failure. You stick with it, your company gets its footing, you're poised to see a return. Then bam, disaster: some stupid thing you weren't careful about when you were 4 people explodes, counterfeiting your success.
You'd have been better off it exploded when you were just 4 people big. You'd have known you were screwed, and could have saved yourself the time and energy, and used the opportunity to move on to something that had a chance of succeeding. Instead: you lose 90-100% of your outcome to a lawsuit.
There is no reason to sue struggling startup, because if you sue for too much then the startup would simply fold.
That's the main way startup protects itself.
Struggling startup usually does not have funds to lawyer up.
BigCo on the other hand is a very attractive target, but has funds to lawyer up.
If struggling startup successfully transitioned to BigCo then potential exposure from past shortcuts is small (relative to BigCo revenue).
How could "contractor vs employee" shortcuts applied in 4 people startup be a significant problem for BigCo (which already transitioned into lawyered up way of doing business)?
Care to elaborate why this is so bad? As far as I can tell, most employee (FTE) related laws in the US are suited for, well, people living in the US.
This is one of my concerns - to be a second class employee. Company has to have remote modus operandi.
After working at my current startup, I realize I was wrong. We are an entirely remote operation, and have been since day 1. A few of us are in Austin, and rarely meet for a face-to-face, but it's more of a 'oh yeah, you actually exist' meeting rather than a hash-it-out sort of meeting.
I think the reason we have been successful is because being remote has forced us to write things down, in our wiki (in the form of product specs) and in JIRA (in the form of specific features and bug fixes). With just those two forms of written communication, we've solved 95% of our communication needs. We almost never skype or use video conferencing... it's just not needed.
The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough, but does deserve more explanation. (unfortunately I can't muster the amount of typing atm).
IN the end, we can focus on getting work done... without the distraction of office chatter, commuting, long lunches.
I've worked remotely for a few years now and think this is the key. I would not advocate hiring junior developers remotely. There's too much risk in it. I was once faced with the task of trying to mentor a junior dev remotely and it just didn't work.
I recently mentored such person and she is already one of our most productive developers.
Matt says to let people 'live someplace remarkable', but for most of the world that want to work in technology SF is someplace remarkable.
The benefits of using group collaboration tools are still available, but you have other people working on overlapping problems on your doorstep, support and service companies, and access to intelligent finance.
Trying to solve the problems that get in the way of making remote work as seamless as co-location seem to be technical, which are easier than the fundamental problems of economics.
Also recommend this YCombinator startup school talk by Balaji Srinivasan on this topic: Silicon Valleys Ultimate Exit https://www.youtube.com/watch?v=cOubCHLXT6A
One advantage for companies in big cities is they can usually hire these remote employees at a discount. It can get a bit hairy when two remote employees doing the same job are paid differently, but that is already the case in many situations.
The other obvious advantage is that companies that hire remote employees have an almost unlimited candidate pool. Even if a company chose to limit hires to their own country, the only group they cannot hire would be candidates unwilling to work remotely. Based on my discussions with thousands of programmers over the years, I'd suspect this is a very small group.
> Exceptional programmers have an aptitude for and interest in programming that is not merely the product of training.
This is the old "you're either an exceptional programmer or you're not" myth. This is one reason why diversity in tech has regressed since the 80s.
I agree that geopolitical boundaries should matter less in the software business. However, I strongly disagree that this is the solution to programmer scarcity. Expanding your source of resumes to the entire world only delays the inevitable. Why focus on removing the dependency on the passport variable, when we still have such a strong dependency on gender and race?
An 8-12 hour timezone gap is not something easily bridged by chatrooms and videoconferences. To even have a conversation with the remote worker/team, one or both of you need to schedule time at very early or late hours and even then you only get a little bit of overlap. For the most part you are left to collaborate by email or blogs -- which is a significantly degraded way of collaborating, much moreso than just not being face-to-face. Without an easy way to have a realtime conversation, closing the loop on an issue can take 24 hours.. or several days if there is a lot of back and forth.
This style of working can be very difficult in a highly dynamic, less structured, fast moving startup environment. It is not magically solved by "modern communication tools" or high-latency asynchronous working styles. The fundamental issue is.. daylight and human sleep schedules.
I wish all conversations about remote work would qualify which context they're talking about -- near or far timezones -- instead of just lumping it all together as "remote work from anywhere".
* Amount you learn from the office community is orders of magnitude lower than onsite. If you're good at pushing yourself to learn new things, that can help, but your knowledge will almost certainly end up less diversified living remotely. You're just not exposed to the company's tech challenges as deeply, yet that's usually one of the main reasons for working at the company.
* You don't necessarily get top projects, but rather perhaps good projects that fit remote work. Taking a remote role almost certainly hurts your career if you want to compete with traditionally onsite roles.
* You likely don't get to participate in hiring or shaping the culture in a substantial way.
* You'll have a much harder time building the network needed to get access to key resources (e.g. data, people, etc).
* Your company better have a nice VPN or you're going to be doing a lot of systems-oriented stuff for yourself. It can be fun but can slow you down.
* You're probably more likely to be laid off.
The company I worked for started offering remote much more frequently due to recruiting and retention problems. I don't think the net result had a very positive impact on the Eng org. In particular, a lot of junior people were allowed to go remote for retention reasons but they didn't end up doing much in that role-- they would have been much better off just joining a different company (either local to them or one with a much much stronger remote culture).
Agree with the poster that PG's essay has some holes; seems orders of magnitude less polished than his older essays.
http://www.amazon.com/Year-Without-Pants-WordPress-com-Futur...
You can read a free chapter about culture from the book here:
http://scottberkun.com/2014/why-culture-always-wins-an-excer...
What I believe Paul is asking for is that companies have the option to choose. Right now the option is available to anyone to hire remotely in one way or another. This is not the case with physically hiring into the country. Almost every startup I've worked at has had issues trying to hire exceptional people from another country. In almost every case, we lost those hires to the system and were forced to start the search again.
If a small, remote, international startup grows fast enough and they decide that working together under one roof in the U.S. fits their new needs, they should have the freedom and choice to do so.
A better immigration system would be better for the U.S., in that it would allow the best programmers to come here if they want to. That is clearly better for the U.S. as a whole, since it would make it easier to raise the national technical talent level relative to other nations. These new Americans would hopefully become citizens, raise families, vote, sit on school boards, run for elected office, start companies, etc.--improving the nation from within over time with their perspectives, talents, desires, and hard work (as past generations of immigrants have).
Contracting with foreign workers through the Internet does not achieve any of those long-term national goals.
Once new workers are legally within the U.S., I agree that they should have the freedom to choose remote work if they want to, or colocating work if they want to.
...then again, that's probably why remote workers say they're more productive.
The common theme of all that is: timezones matter a lot. It's hard to collaborate with someone really far away because they'll tend to be asleep when you're awake. Programmers like async communication for a lot of reasons, but real-time is important too.
I know we Yanks get no sympathy from the rest of the world, but labor here has taken a beaten long enough.
And, I say this as a dev-turned-founder who would presumably now want to see low rates and a bigger pool. I guess I just appreciate more a little "economic justice" from time-to-time!
Such a company would probably pay less than market rates, due to the "perk" of allowing remote work? But where's that money going? If you are an engineer considering remote working, make sure YOU get a slice of the pie.
I spend a lot of my time online and I have taken a lot of online college classes. When I had a job at BigCo, I got in the habit of emailing my questions to my immediate boss, whose role included answering technical questions. For various reasons, I was unable to master the art of catching her at her desk or whatever. Emailing worked better for me.
I and some of my teammates got transferred to a new team that initially did not have someone in the technical role she filled. Until the new team got their own technical lead, we were all still assigned to our old lead. Other teammates of mine who were used to having face-time with our lead were incredibly frustrated. My transition was quite smooth. I rarely needed face-time with her to get good results. I just continued emailing my questions as usual. I also was not particularly "likable." I was quite ill at the time and not at my smoothest socially. I also just come from a more formal cultural background than the people I was surrounded by. I was not interested in being too schmoozy. In the short run, this seemed to hurt me a bit. But once I got transferred to a new team, it was to my benefit: Getting my questions answered had been a purely professional function, not something rooted in being friendly or whatever.
So I think there are good points on both sides of this argument. I see several really good comments here falling on either side. And I think the disconnect probably has to do with some social thing that can be fostered remotely but many people aren't good at it. As we develop more online/virtual/long distance cultural practices, I think this will become less of a divide for some people.
I still don't feel there's any reason you need to physically exist in the Bay area though. Open an office somewhere that's both attractive and affordable for people to live and you enable the best of both worlds.
Are you saying that remote work is as good if not better than being physically-located?
https://medium.com/@sarperdag/how-to-thrive-as-a-digital-tal...
EDIT: being more explicit I was specifically thinking of remote workers from other countries when writing this statement. Obviously, remote work within the U.S. wouldn't make you a contractor. But how would this work for non us-citizens?
I definately see how looking at from within the US this could be completely different, and there you make many valid points.
Would take me less than a week to do that in the UK for a PLC.
Perhaps there needs to be a distinction between remote workers elsewhere in the US and international ones as well. I imagine there are many talented developers elsewhere in the US that don't want to live in SV.
Which is worth more a company with 5 employed engineers or 5 oversea contractors?
Managing developers across time zones can be a big problem. If the developer in the Ukraine has a question for a manger asleep in California, he has to wait.
There is no casual connection between people - no going to a bar to talk things over, no stepping away from the computer to talk. All communication is filtered down through the pipes.
Trying to solve the problems you outline seem to be technical, which are easier than the fundamental problems of politics or economics.
This is a false dichotomy. You could have 5 on-site contractors or 5 overseas employed engineers.
(However, the rest of your post contains very valid points.)
[1] How much better is a great programmer than an ordinary one? So much better that you can't even measure the difference directly....
You do not get to hire those people. And if you do it's on their terms. Perhaps you get to invest in their ideas if you're lucky.
This is the best rebuttal to the more-immigration-so-we-can-haz-programmers I've read in a long time. And its so true. The way the current work visa (h1-b) is setup makes it far more likely that good programmers get tied to stodgy plodding firms and not smaller innovative ones that tech needs them to work for. Remote work and rewriting the current h1-b laws to make it so that h1-bs can more easily transfer their work permits and work for whoever they like, whenever they like ... remotely as well ... just like their American contemporaries would open up lots of supply.
but what the big firms really want is more pliant programmers who will work within the rigid confines they set up. Thats why we're not talking more about the mechanics of the work visa and the green card process which is currently set up pretty restrictively.
I know this isn't what a lot of HN readers want to hear but I bet Paul and many other VC's would bear me out.
Of course, I closed the tab pretty much immediately after noticing it so I didn't read the article. Can't wait for unnecessary js to go out of style.
Sure enough.
enjoy the downvote