The next 10 Years of Remote Work

This post was developed in conjunction with my talk of the same name for Spring into SledgeConf 2021

My belief is that most tech startups going forward will be 100% remote. Setting up an office for a company that might not last isn’t a great idea. And after 2020 spending your runway on an office is basically wasting money. 

The complication is that remote work requires more discipline from the team than office based approaches. If you have unmotivated employees, managers, management skills, or outdated processes you will not be as productive as a remote company. Going forward there will be a dichotomy between startups that try to succeed with the colocation approach and startups that commit to remote work. My belief is that overtime collocated startups will consistently fail against remote startups. The reasons remote startups pull ahead are lower fixed office costs,  easier access to talent at lower prices and that remote work requires more disciplined processes. 

Fixed office costs

Offices being expensive is an obvious fact for most people. Offices are lowest common denominator environments with constant pressure to cut costs. Workers consistently complain about noise and distractions in ‘open plan’ offices but they have stuck around because they are cheap. 

Remote work allows everyone to setup their own ‘dream’ office space. You can get whichever chair you want. Any combination of monitors and other peripherals. You can play loud music or install noise canceling tiles to ensure silence. Workers also save hours each day compared to commuting, not to mention the environmental benefits. 

Easier access to talent

Access to talent is a major problem for startups. Before achieving profitability startups have limited time to find software engineers and limited money to pay them. Hiring remotely allows startups to access a large number of employees who live in low cost of living areas. This can either be lower cost of living cities, cheap small towns or even other countries. 

For example entry level software engineers typically make over 100k in ‘major’ software areas like Seattle, San Fransisco, San Jose and New York City. But those same engineers will typically make 60-70k in second tier cities despite having comparable amounts of skill and experience. 

Higher Process Bar

A remote first company requires better processes and more motivated employees than the typical office micromanagement scenario. Failing to set up good processes in a remote environment will result in unmotivated employees that don’t do any work. You can’t just assume communication will happen in a remote environment. In the office employees gossiping can make up for a lot of bad communication processes. Whereas in a remote environment employees need to go out of their way to setup a zoom call. 

 Companies with good remote work processes will experience higher average productivity than was ever achieved in classical ‘open office’ environments. 

In a remote work environment you are forced to invest more in onboarding, training and cross team coordination. In the office you can simply walk over to the frontend team’s section and introduce yourself to the new team member. But working remotely without a process to include the new guy, he could just sit in the figurative corner for weeks without interacting with anyone. 

There isn’t any way for new hires to ‘overhear’ conversations about services or context that they don’t know about when working remotely. So those thing have to be documented and included in the formal onboarding process. Which means you actually have to document your software for real.

Meetings need to be orchestrated better when done remotely. You need to have an agenda and focus on solving the problem. 

One meeting that works very well remotely is the architectural document review. A 60 minute meeting would go as follows. 

  1. 20 minutes to read and comment on the document in google docs
  2. Short discussion of each text comment made in google docs starting from the top of the doc
  3. Discussion of action items and any other final comments

What happens next?  

The pandemic caused a massive shift in software engineering working conditions. We went from maybe 5% remote to 95% remote work during the crisis. Now that things are normalizing I expect a gradual shift back towards 90-10 or 80-20 split of hours worked in office vs remote. The fact of that matter is that a lot of people like working in an office. And many bosses think micromanaging is necessary. 

Going forward there will be a lot of demand for remote software engineering jobs and many companies will jump on the chance to acquire programming talent at competitive prices. 

The in-office premium.

Going forward I expect to be paid more to work in an office than to work remotely. Working in an office costs me more in time and transportation costs. It also limits my freedom during the day. To make up for the inconvenience of needing living within commuting distance of jobs I expect to be paid an additional 20-30% premium over what I would charge for remote work. 

Legal hurdles 

The legal burden for international remote work is way too high. Each country has different requirements and the company is essentially required to establish a corporate entity in every country they have employees in. Even if they do not actually do business in that country. 

Even in the United States having a remote worker in New York city could require a company to start paying additional taxes to New York state due to establishing a ‘nexus’ in that state. 

Over time I expect these legal hurdles to be simplified or simply ignored. Functionally, it doesn’t matter where code is written. Remote workers will push for legal accommodations. Nations will be forced to compete by providing supportive legal conditions for remote workers and employers. 

https://news.ycombinator.com/item?id=17022563

Other Perks 

Less workplace drama

One thing that I didn’t expect to come out of remote work is that annoying coworkers are a lot less annoying when they aren’t in your face. You can basically avoid all non-work related communication with people you don’t like. For example we have one guy on my team who goes on rants and never gives people a chance to cut in and steer the conversation back on topic. In the office I would end up listening to this guy talk for minutes at a time without getting a chance to talk. Now since I’m not sitting across from the guy I can avoid his negatives and appreciate his dedication and work more. 

Corporate Culture

For example processes like 6 month RSU vesting are not tenable in a remote first world. You cannot afford for disgruntled employees to wait 6 months for a vest date before they quit. 

Spring into SledgeConf!

https://sledgeconf.dev

Our next SledgeConf is coming on Friday May 21st at 4:30pm PST!

Join us for discussion of the next 10 years of remote work. 

My presentation for this SledgeConf is titled. 

“The next decade in remote work.” 

I’m joined by Mason Traylor presenting!

“How to waste Everybody’s Time with Remote Meetings”

Agenda:

4:30 Introductions 

4:45 Presentation “How to waste Everybody’s Time with Remote Meetings”

5:00 Questions + Discussion

5:15 Presentation “The next decade in remote work.” 

5:45 Questions 

6:00 Promotional Round table 

6:15 Unstructured Discussion time

The zoom link will be sent to the mailing list the day of SledgeConf. Please go to SledgeConf.dev and sign up for the mailing list. If you are one of my connections on linkedin the zoom link will also be available there.

https://sledgeconf.dev

Remote Startup Wishlist

My belief is that most tech startups going forward will be 100% remote. Setting up an office for a company that might not last isn’t a great idea. And after this last year spending your runway on an office is basically wasting money. 

What would a ‘best practice’ startup look like if it launched today? 

Tech stack 

The tech stack really depends on what you are doing. There are a bunch of right answers just do your do diligence and commit to one. 

For an MVP I would go with Ruby on Rails with Heroku and postgresql. Don’t waste your startup’s time on infrastructure as code, use a complete platform as a service. Infrastructure as code provides next to no value to customers and eats insane amounts of time. Use the simplest cloud architecture you can whether that is Heroku or copying code straight into EC2 hosts. Kubernetes is great but your startup should achieve product market fit long before you consider that beast. 

If you are doing machine learning Pytorch or tensor flow are good options. For low level or high performance computing Rust and modern C++ are great. 

The only things I would be careful about here is in picking the framework. You want a ‘batteries included’ framework. If you are in a rush you don’t want to have to dig through a bunch of github pages to figure out which authentication library is best. 

Communications 

There are a lot of options here. Just make sure you have a good videoconferencing application, email and a messaging app. 

Slack, Email, Zoom 

Github/Gitlab, source hut, etc

Teams is another great option with everything included.

Regular one on one meetings with teammates is a huge benefit for remote workers. I recommend scheduling a variety of optional meetings where you can get face time in with teammates.  

Donut is a slack app that will automatically schedule 1 on 1s with different team members.

https://www.donut.com

Document based decision making 

Document based decision making is one of the best ‘mechanisms’ I’ve encountered at Amazon. Technical proposals are written up into an architecture document and then reviewed in a team meeting. The first half of the meeting is spent reading the document and making comments in google docs. Then the second half is spent discussing the proposal and comments. 

Agile Kanban style workflow 

Kanban is the most realistic way to organize work on a software team. It supports coordination, helps avoid duplicating work and eliminates process. 

Planning processes 

Do a monthly and quarterly planning process. Leadership should identify the business areas that are the priority for the next 1-3 months on a regular basis. 

At Amazon we have a bottom up planning process where teams and groups put together a document of their goals and priorities which is then reviewed and approved by the executive team. A bottom up process shouldn’t be possible in a startup because there is no ‘executive’ team just a few founders. 

Solutions Engineer, Cloud Architect what does it all mean?

There are a ton of titles in the software industry. Two slightly misleading ones are Solutions Engineer and Cloud Architect. These sound like technical roles but they are not on the software engineering career ladder. Solutions Engineer and Cloud Architect are pre-sales roles. 

What is Pre-Sales? 

Pre-Sales is the part of a project that happens before the sale. If you are selling a software product or digital transformation, you need someone technical to evaluate where the prospect’s software stack is. The Solutions Engineer is the technical expert who joins the sales team and helps build out what needs to be included in the deal. That entails researching the prospect’s tech stack, interviewing their engineers and doing technical demos for the potential client. Solutions Engineers sometimes need to travel to client offices as part of the job. You might do some coding to create demos and prototypes but that is about it. Don’t expect your technical skills to grow while working as a Solutions Engineer. But you will get lots of opportunities to interact with clients, make connections and learn about what different companies are doing on the tech side. 

Then what is a Cloud Architect?

A Cloud Architect is a solutions engineer working with potential clients of public cloud services. A Cloud Architect would work with clients on what services they need and how to migrate their websites and services to the cloud. They will demo cloud services and help develop plans for customers to migrate their workloads to the cloud. 

Why become a Solutions Engineer?

Becoming a Solutions Engineer is a great way for software engineers with decent social skills to move into a more sales focused role. You will have opportunities to present and learn about customers that you probably do not as an engineer on a product team. 

Knowing more about the sales process can help you prepare to run your own agency or move up the corporate ladder on the business side. 

Software advances are slower than you expect.

Most people think of technological advances using the eureka metaphor. But software doesn’t work like that. Take a clear technological advance like a self-driving tractor. They are on the market now but there was no eureka moment, no sudden breakthrough. Self-driving technology just advanced to the base level required for tractors on clearly mapped fields, then a team of software engineers built a working system over several years.

There’s no invention or breakthrough moment, just a slow build in none software capabilities than an investment in building out software to leverage those capabilities. 

There were no software engineering advances that enabled the self-driving tractor. Instead machine vision improved until it was good enough to unblock the software solution.

What advances in software are in sight?

Reproducible builds are one of my favorite advances in software recently. Strictly speaking reproducible builds have been available for quite some time, but that doesn’t mean it isn’t a real advance. Having a trustworthy build environment where you can debug the inputs vs the outputs for different machines is a big benefit. Without reproducible builds software engineers end up spending extra time fixing build failures and figuring out dependency resolution overrides. 

Golang is in my opinion an advancement in software engineering. Instead of focusing on productivity for a single or small number of engineers, Golang is focused on maximizing productivity for large software projects with thousands of engineers. It does this by simplifying the language as much as possible to ease readability and eliminate magical effects. Everything in Golang is very procedural and easy to follow. 

Easy to use gradual typing is a more recent advancement in the Python and Ruby worlds. You can now build your MVP in a dynamic quick evaluating language and then after you reach product market fit you can add types to the code base. Typing is no longer and either/or thing but a sliding scale where you can chose the most opportune time to transition. Overall I think gradual typing has huge advantages compared to the old standard of rewriting the codebase in Java.