[Off-Topic] Remote Work — Small Office, Home Office (SoHo)
Update: This is a more complicated subject, and some points may need more explanation. Later I’ll see if I write an addendum or a follow-up post, but until then, if anyone disagreed it may be along the lines that @porcelli also disagreed and I tried to explain via Twitter, though it’s more about us agreeing to agree than actually disagreeing :-) I think the main point is: I’m not against remote work, quite the opposite. The TL;DR is that I don’t believe it’s the “only” solution, and the intention is to explore a few scenarios — just that. I know excellent professionals who work remotely. I myself, as I say in the article, have geographically separated teams, so that isn’t the point being discussed.
For a change, SoHo is one of the many subjects most of us only think about superficially and decide “it’s good” or “it’s bad.” It’s bad that Marissa Mayer banned Home Office. It’s good that 37signals is evangelizing Home Office. It’s bad that Microsoft agrees with Home Office but with a possible dystopian view. Remember that SoHo is a topic the industry has been discussing practically since the advent of the personal computer in the mid-80s — this is by no means a recent thing.
Disclaimer: I’m the owner of a software shop, a company that offers software development services, and therefore the core of the company is programmers hired not only in São Paulo (where I live and have clients), but also in Porto Alegre, Fortaleza, and Natal. I don’t intend to go into my process in this article.
I thought about dissecting the book Remote, which is the current reference. But there isn’t much to dissect. If you read the index, you basically already know everything the book says — the rest is filler. Look:
The Time is Now for Remote Work — it will tell you everything we already know as negative points of large offices: the long meetings, the interruptions, the distance to commute, quality of life. I think without reading the chapter we already know exactly what bothers us. The problem is that this is a hard point to counter-argue — the premise is that any place will have things that please and things that displease. Listing what displeases isn’t necessarily the most relevant. For example, if you have a girlfriend or are married, did you make a list of your partner’s items compared to Miss Universe or Mr. Universe? Is it the set of things that displease that matters or the things that please?
Dealing with Excuses — again, it would be the “arguments,” “demagoguery,” “rhetoric” which, in this case, is assumed to be what managers and company owners use as excuses not to allow remote work. And the problem is that half of them aren’t what companies say but what motivational self-help sellers say. “Working close together increases information exchange and therefore creativity.” Others are policies like “data security,” customer service, loss of control. And indeed, these are secondary items. As a company owner, most or all of the points are easy to deal with and agree with. Believe me, the industry isn’t that bad, and none of these points went unnoticed in recent decades. There are still leftovers, without a doubt, but compare today with 20 years ago and you’ll see the difference.
How to Collaborate Remotely — summarizing what we already know: technology has decreased distances. Skype/Hangout/etc., Basecamp/Tracker/Asana/etc., Github/Bitbucket/etc., IRC/Campfire/etc. Not to mention that many other outsourced services are already remote — an accountant is a good example, and I’ll return to this point, so remember it.
Beware of Dragons — this is the only part that “balances” the book and says that remote work isn’t always rosy. Not feeling lonely, not working more hours than you should, having healthy habits, etc. These are tips that apply not only to remote work but to normal habits for anyone. Summary: have common sense — but you already knew that.
Hiring and Keeping the Best — summarizing, and I agree, there are excellent professionals in every location in the world — my reason for exploring outside São Paulo. Again, it’s very simple to evangelize an argument and not take every possible point into consideration. As I said, I agree with the point, and I’ll come back to it later.
Managing Remote Workers — once again, management common sense. Good managers already know this. Believe me, we’ve had multinationals operating on every continent for a few decades. We’re good at this. The premise many believe, that companies don’t want remote work because we don’t know how to manage remote workers, isn’t entirely true. Look at the massive movement of outsourcing services to countries like India. Like newspapers, we only focus on bad news, but believe me, we know how to do this. And it has only gotten simpler. It seems outsourcing to individuals is more complicated than outsourcing to branches in other countries, but overall the process is basically the same.
Life as a Remote Worker — more common sense for any person: have discipline, build a balanced routine, reserve time for your family. In this chapter the only relevant part is the last: “Make sure you aren’t being ignored.” This is my main point for the rest of the article, so remember it.
In conclusion, of the books I’ve read from 37signals, this is without a doubt the weakest of them. When reading the index is enough to understand the whole book, it isn’t hard to reach that conclusion. That alone doesn’t mean it’s wrong or bad, but a blog article would be enough to convey the same message: yes, there are many advantages to remote work. And, of course, coincidentally they develop tools for what’s being described in the book, so it’s an excellent work of self-marketing — it would be stupid not to do it.
The Truth About Remote Work
Now let’s get to the other side of the coin. In my recent article Math, Trolls, Haters and Internet Discussions I tried to convey a simple but very important concept: incomplete formulas are useless. Recapping, a procedure, a methodology, a process can only be “formulas” if they define the “domain” of the problem. I’ll assume 37signals is arguing that service-area professionals could work remotely. I restricted to computing because several other areas simply don’t work remotely. Airline pilots, firefighters, doctors, etc. So the domain is limited to services — never production — and whose results don’t need physical media, so, Internet. Musicians, programmers, writers, accountants, lawyers, architects (partially), etc. I think this is simple to define. For my purposes I’ll restrict myself to the area of software development services.
The biggest problem with books or people who evangelize about human behavior is not having bases in Sociology, Psychology, and fields of study that have already studied this problem. The book Remote is convenient for 37signals’ domain and works there, but the way it’s described will work only there. This is the first thing you look for to distinguish serious research from self-help: “It worked for me, so it can work for you.” That’s how diets are sold.
For several reasons — including the ones Zed Shaw explains in this talk, including the capital contribution from Jeff Bezos — 37signals did very well as a product company. Good for them, but it means the problem domain is “product company that earns and profits very well.” This eliminates a considerable portion of the market from the equation. And if you don’t know the data, we’re talking about a universe much larger — in Brazil it represents close to R$ 37 billion. Much larger than the restrictive universe of tech startups.
Let’s understand another thing that both Getting Real and Remote try to argue — and they could have simplified. Highly centralized structures, with high top-down control, little or no valuation of the workforce, tend to be bad places to work. The wrong conclusion is that complete decentralization is the best form, and the even more wrong conclusion is to imagine 37signals as a decentralized company because everyone is remote, because it doesn’t have a hard and immovable hierarchical structure. In reality it’s centralized, with intermediate levels of decentralization.

It gives the impression of being a decentralized organization because it uses open source processes for execution, but the chain of command is clearly centralized in Jason Fried and David Hansson. There’s no problem with this, and it’s how it should be.
Given this understanding, I want to show a graph I took from Nicholas Christakis’ class. He mentions a study of Broadway shows. Some are very successful, others are box-office failures, and the researchers wanted to know if there was any correlation between the type of social network of the show’s organization and success rates.
Consider on the X axis the density of relationships among the show’s team professionals. 0 being highly centralized where people at the edge of the network don’t talk to each other, and 100 being a highly decentralized network where anyone talks to anyone. Level 0, highly centralized, we intuitively know must be bad, and in fact the correlation is that it’s associated with failed shows. But what isn’t intuitive is that totally decentralized networks show the same level of failure. The successful shows are in the intermediate networks, where there is some decentralization and some centralization.

37signals isn’t totally centralized (the remote programmers talk in chats, via Github, etc.) and isn’t totally decentralized (there’s some level of specialization, and obviously there’s a central strategic command).
I’m experimenting with different scenarios, and the first step — in my case — starts with this other diagram:

But as I said before, I won’t stray from the main subject in this article. Just a hint.
The Career Problem
I’m repeating that domain definition is important because in the case of 37signals you can indefinitely increase people’s salaries because the product has already reached a scale where revenue is orders of magnitude higher than costs and expenses. Well, you can invest in racing at Le Mans — you can certainly pay 5 or 6 digits to programmers.
If you continue to evolve the product, create new products carefully, keep old customers happy, do good marketing to attract new ones — anyway, what a good company should do — it will be possible to keep growing for a good while.
Except similar product companies aren’t common — actually it’s the most uncommon thing in the industry — and the same rules don’t apply to service companies, which are the majority. And it’s not out of bad will, it’s because of industry fundamentals.
And from that comes the thinking of “That’s why it isn’t good to open service companies and you should go straight to products.” And my answer is simple: “Good luck.” The obvious premise of this statement is that product companies immediately work out. I discussed this in my previous article Tech Startups, B2C overcrowding. Boring..
“Oh, just follow Lean Startup, Agile processes, Business Canvas,” and the whole little package they sell today, which has instructions any child can follow and the batteries are included, and boom automatic success … does anyone really believe in that nonsense?
Now let’s get back to reality. The biggest problem of hiring home office programmers is an HR problem, a career management problem, and not just one of control. We’re reaching a maturity level in software development where programming by following good practices, good technologies, with efficiency, with predictability, with ease of future maintenance, etc., is no longer a Premium — it’s becoming the norm. I’m not going to offer a cheaper programmer to a client because they have low quality — I want my junior to rise to mid-level quickly, and for the client to have a similar level of technical quality, no matter who does it, and for the quality to always be above average — because the industry average is still indisputably below the poverty line.
Except if this is the norm, how can a company give raises to programmers? Up to a certain point, technical capacity makes a lot of difference, but considering they’re rare — not only in the services area, but even in the products area — that we’re dealing with very high technology still experimental and few people have any idea what to do, the rest becomes commoditized fast. The open source world almost guarantees that once a hard problem is solved, it will be quickly replicated. If at some point it was considered “complicated” to make a responsive web front-end with minimally pretty visual elements, a Foundation or Bootstrap eliminated much of that curve, for example.
This is the core of the issue: just programming is very little for 90% of software development projects. I discussed in another article, Estimates are Promises. Promises must be kept. that the hardest thing in a Software Engineer’s career is understanding that much of a software project isn’t solved with software. A “senior” professional isn’t the one who makes the prettiest code, but the one who best knows how to manage client expectations (whether a corporate client or consumer client) and assume responsibilities.
Again, I’m not going to dwell on exceptions like research centers or consolidated products. By being inside a group, properties emerge that only exist inside a group (again, see the talks by Christakis or others like Duncan Watts to start understanding these properties). Activities that normally don’t happen individually like peer-to-peer training, where a junior has the chance to learn from someone more senior, where communication skills, negotiation, responsibility, teamwork in general can be exercised. All of this is possible while remote, but it’s much slower and much less obvious because each individual is in fact isolated. A geographical cluster also influences the market and local community around it, so it isn’t restricted only to your primary group — secondary groups emerge. And each cluster relates as described even in the Remote book, with online tools and occasional in-person trips.
In practice, how much more productive and efficient is a good senior developer than a junior? 10 times, at most? That means that if a junior earns 1000, at most a senior earns 10,000? And after that? Now, a good professional who can train, mentor, and self-scale from 1 to 3 has already risen orders of magnitude. They can easily go to 20,000 or more this way. Do this in clusters and soon we have a more resilient network. And I’m not saying mentoring is something that can only be done in person, but again, those who can do it remotely are the exception today, not the rule. We hire people who still have little experience, or just left college, and although it isn’t impossible, it’s also complicated to mentor them at a distance. In the end, it always depends on the person.
So does that mean an individual working remotely is wrong? Of course not, and that’s another problem with that type of argumentation — it makes it seem there are only two paths. And as in everything in sociology, there are various different scenarios for different configurations. What the evidence indicates as the most inefficient are in fact the two extremes: totally centralized and totally decentralized. In between them there is a series of different opportunities.
Conclusion
So yes, what’s in Remote isn’t wrong. What’s wrong is considering it the only solution. I could hire isolated home-office individuals and would have no problem with it. But I still can’t imagine ways to make them evolve, expose them to more activities besides just coding, and I could hardly delegate more responsibilities beyond just code. The great advantage of working in the services market is having access to more companies and more situations than any employee of just one company or a single product would ever have. Being remote, there are very few opportunities.
And again, there are exceptions — big names in the open source world who work as freelancers, alone, and are doing very well and their reputation only grows. Now I’ll return with: is that the rule or the exception? Exceptions exist, and if possible it’s better to be the exception. But it would be very irresponsible to evangelize the exception path all the time.
Working from home is an experience worth trying — by no means is it necessarily better than working within a group, even considering “wasting time” on commuting — which, by the way, is a terrible excuse — considering whether your region has options. If the options are scarce, however, remote is indeed a good alternative — just consider that there are pros and cons.