[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. Until then, if anyone disagreed, it may be along the lines that @porcelli also disagreed and I tried to explain over Twitter, though it’s more a case of us agreeing to agree than any real disagreement :-) The main point is simple: 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 point here is to walk through a few scenarios. 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 up for debate.

For a change, SoHo is one of those subjects most of us only think about at the surface before deciding “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 possibly dystopian view. Worth remembering that the industry has been chewing on SoHo practically since the personal computer showed up in the mid-80s. There’s nothing new about it.

A disclaimer: I own a software shop, a company that offers development services. 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 get into my process in this article.

I thought about dissecting the book Remote, which is the reference of the moment. But there isn’t much to dissect. If you read the table of contents, you basically know everything the book says already, and the rest is filler. Look:

• The Time Is Right for Remote Work: it lists everything we already know as the downside of big offices, the long meetings, the interruptions, the commute, the quality of life. Without reading the chapter, we already know what bugs us. The problem is that this is hard to argue against, because any place has things you like and things you don’t. Listing only what you dislike isn’t the most relevant thing. If you have a girlfriend or you’re married, did you make a list of your partner’s traits stacked up against Miss Universe or Mr. Universe? Is it the set of things that annoy you that matters, or the set of things you love?

• Dealing with Excuses: again, the “arguments,” the “demagoguery,” the “rhetoric” assumed to be the excuses managers and company owners use to block remote work. Half of them don’t even come out of the companies’ mouths; they come from the motivational self-help crowd, along the lines of “working close together boosts information exchange and therefore creativity.” The other half are policies like data security, customer service, loss of control. Those items are secondary. As a company owner, almost all of them are easy to handle and agree with. The industry isn’t that bad, and none of these points slipped by unnoticed over the past few decades. There are still leftovers, no doubt, but compare today with 20 years ago and you’ll see the difference.

• How to Collaborate Remotely: it sums up what we already know, that technology shrank distances. Skype/Hangout, Basecamp/Tracker/Asana, Github/Bitbucket, IRC/Campfire. On top of that, plenty of outsourced services are already remote. An accountant is a good example, and I’ll circle back to it later, so hold that thought.

• Beware the Dragons: the one part that “balances” the book and admits remote work isn’t always a bed of roses. Not feeling lonely, not working more hours than you should, keeping healthy habits. These are tips that apply to remote work and to anybody’s routine. Bottom line: use common sense, but you already knew that.

• Hiring and Keeping the Best: in short, and here I agree, there are excellent professionals in every corner of the world. That’s my reason for looking beyond São Paulo. Again, it’s easy to evangelize an argument without weighing every angle. I agree with the idea and I’ll come back to it later.

• Managing Remote Workers: once more, management common sense. Good managers already know this. We’ve had multinationals running on every continent for decades, and we’re good at it. A lot of people believe companies reject remote work because they don’t know how to manage people at a distance. That doesn’t hold up: look at the massive movement of outsourcing services to countries like India. Like the newspapers, we only look at the bad news, but we know how to do this, and it keeps getting simpler. Outsourcing to individuals looks more complicated than outsourcing to branches in other countries, but overall the process is the same.

• Life as a Remote Worker: more common sense for anybody. Have discipline, build a balanced routine, set aside time for your family. The only genuinely relevant bit is the last one, “make sure you aren’t being ignored.” That’s my central point for the rest of the article, so hold on to it.

To wrap up: of the 37signals books I’ve read, this is easily the weakest. When reading the table of contents is enough to grasp the whole book, the conclusion comes easy. That doesn’t make it wrong or bad, but a blog post could carry the same message: yes, there are plenty of advantages to remote work. And, of course, by pure coincidence they sell tools for exactly what the book describes. It’s a terrific piece of self-marketing, and it’d be dumb not to do it.

The Truth About Remote Work

Now for the other side of the coin. In my recent article Math, Trolls, Haters and Internet Discussions I tried to get across a simple but important idea: an incomplete formula is useless. To recap, a procedure, a methodology, or a process only becomes a “formula” once it defines the “domain” of the problem.

I’ll assume 37signals is arguing that service professionals could work remotely. I’m restricting it to computing because plenty of other fields simply don’t work that way, like airline pilots, firefighters, doctors. The domain is limited to services, never production, and whose output doesn’t need physical media, meaning it travels over the Internet. Musicians, programmers, writers, accountants, lawyers, architects (partly). Simple enough to define. For my purposes, I’ll stick to software development services.

The biggest problem with books and people who evangelize about human behavior is ignoring Sociology, Psychology, and the fields that already studied this thing to death. The book Remote is convenient for 37signals’ domain and works there. The way it’s described, it works only there. That’s the first tell for separating serious research from self-help: “It worked for me, so it can work for you.” That’s how they sell diets.

For several reasons, 37signals did very well as a product company. Among them, the ones Zed Shaw explains in this talk and the capital injection from Jeff Bezos. Good for them, but it means the problem domain is “product company that brings in revenue and profits very nicely.” And that already knocks a huge slice of the market out of the equation. If you don’t know the numbers, we’re talking about a much bigger universe, one that in Brazil came close to R$ 37 billion. Way bigger than the narrow universe of tech startups.

Worth understanding another thing that both Getting Real and Remote try to argue, and could have simplified. Highly centralized structures, with heavy top-down control and little or no regard for the workforce, tend to be bad places to work. The hasty conclusion is that full decentralization is the best form. Worse still is picturing 37signals as a decentralized company just because everyone is remote and there’s no rigid hierarchy. In practice it’s centralized, with intermediate levels of decentralization.

It gives the impression of 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 nothing wrong with that, and it’s exactly how it should be.

With that in mind, I want to show a chart I pulled from a Nicholas Christakis lecture. He cites a study on Broadway shows. Some are big hits, others are box-office flops, and the researchers wanted to know whether there was any correlation between the type of social network in the show’s organization and the success rates.

Picture on the X axis the density of relationships among the show’s team professionals. 0 is the highly centralized network, where people at the edges don’t even talk to each other; 100 is the highly decentralized network, where anyone talks to anyone. Level 0, intuition already flags as bad, and the correlation confirms it: it shows up in the shows that flopped. The counterintuitive part is that fully decentralized networks flop just as much. The successful shows sit in the intermediate networks, with some decentralization and some centralization.

37signals isn’t fully centralized, since the remote programmers talk over chat, via Github, and so on. And it isn’t fully decentralized, because there’s some level of specialization and, of course, a central strategic command.

I’m testing different scenarios, and the first step, in my case, starts with this other diagram:

But, as I said, I won’t stray from the main subject here. Just a hint.

The Career Problem

I keep repeating that defining the domain matters because, in 37signals’ case, you can raise people’s salaries almost indefinitely. The product already hit a scale where revenue is orders of magnitude larger than costs and expenses. Well, if you can bankroll racing at Le Mans, you can pay programmers 5 or 6 figures.

Keep evolving the product, build new products carefully, keep old customers happy, do good marketing to draw new ones, in short, what a good company should do, and you can keep growing for a good while.

Except a product company like that isn’t common. It’s actually the rarest case in the industry, and the same rules don’t apply to service companies, which are the majority. And the reason is structural, tied to the fundamentals of the industry.

From that comes the reasoning: “That’s why opening a service company isn’t worth it, better to go straight to products.” My answer is simple: “good luck.” The obvious premise is that product companies pan out right away. I already covered 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, with instructions any kid can follow and batteries included, and boom, automatic success… does anyone really buy that nonsense?

Now back to reality. The biggest problem with hiring home-office programmers is HR and career management, not just control. We’re reaching a maturity level in software development where programming with good practices, good technology, efficiency, predictability, and easy future maintenance stopped being a Premium and became the norm. I won’t offer a client a cheaper programmer because they’re low quality. I want my junior to move up to mid-level fast, the client to get the same technical level no matter who does the work, and the quality to stay above average, because the industry average is still below the poverty line.

Except, if that’s the norm, how does a company give programmers raises? Up to a point, technical ability makes a big difference. But cases of very high, still-experimental technology, where few people know what to do, are rare, in services and in products alike. The rest gets commoditized fast. The open source world all but guarantees that once a hard problem is solved, it gets replicated in no time. If making a responsive, halfway good-looking web front-end was once “complicated,” a Foundation or a Bootstrap already flattened most of that curve.

This is the core of the issue: just programming is too little for 90% of software projects. I discussed in another article, Estimates Are Promises. Promises Must Be Kept., that the hardest thing in a Software Engineer’s career is realizing that much of a software project isn’t solved with software. A “senior” professional is defined less by the prettiest code and more by managing client expectations, whether corporate or consumer, and by taking on responsibility.

Again, I won’t get hung up on exceptions like research centers or established products. Inside a group, properties emerge that only exist inside a group. (See the Christakis talk again, or others like Duncan Watts, to start getting a feel for these properties.) These are activities that usually don’t happen solo: peer-to-peer training, where a junior gets to learn from someone more senior, plus the exercise of communication, negotiation, responsibility, and teamwork.

All of that is possible while remote, just much slower and much less obvious, because each individual really is isolated. A geographical cluster also influences the market and the local community around it, so it isn’t confined to your primary group: secondary groups emerge. And each cluster relates the way Remote itself describes, with online tools and the occasional in-person trip.

In practice, how much more productive and efficient is a good senior developer than a junior? Ten times, tops? Meaning if a junior earns 1000, a senior earns 10,000 at most? And after that? Now, a good professional who trains, mentors, and self-scales from 1 to 3 has already climbed orders of magnitude. They easily reach 20,000 or more that way. Do this across clusters and soon you have a more resilient network.

I’m not saying mentoring only happens in person, but the people who can pull it off remotely are still the exception, not the rule. We hire folks with little experience, or fresh out of college, and mentoring that person at a distance, while not impossible, is tricky. In the end, it always comes down to the person.

So is an individual working remotely wrong? Of course not. That’s another problem with this kind of argument: it makes it look like there are only two paths. As with everything in sociology, there are many scenarios for many configurations. What the evidence flags as the most inefficient are precisely the two extremes, fully centralized and fully decentralized. In the range between them lives a whole series of different opportunities.

Conclusion

So yes, there’s nothing wrong with what’s in Remote. The mistake is treating it as the only solution. I could hire isolated home-office individuals with no problem at all. It’s just that I still can’t picture how to make them grow, expose them to more than coding, and I could hardly delegate responsibility beyond the code. The great advantage of working in the services market is having access to more companies and more situations than any employee of a single company or a single product ever would. Remote and isolated, very few of those opportunities are left.

And again, there are exceptions: big names in the open source world who work as freelancers, alone, doing great, their reputation only climbing. I’ll fire back with a question: is that the rule or the exception? Exceptions exist, and if you can pull it off, being the exception is better. But evangelizing the exception’s path all the time is deeply irresponsible.

Working from home is an experience worth trying. It is by no means automatically better than working inside a group, even counting the “wasted time” on the commute, which, by the way, is a lousy excuse. A lot depends on whether your region has options. If they’re scarce, then remote becomes a good alternative. Just keep in mind there are always pros and cons.