Remote work

(Thanks to Simon Lepkin for reading a draft of this and providing valuable feedback)

I started working remote in 1994, 29 years ago. Since then, I tried all combinations of remote and in-office work, and I never fully stopped:

• In-office day job and remote side gig

• Remote day job and in-office side gig

• A few days in the office and the rest remote (what they call "hybrid" now)

• Almost completely remote with infrequent office visits for a few days

• 100% remote with the office not even existing

• 100% remote with the office I never stepped in

Add to that that I did it alone, as a single contractor or an FTE and I also did it running teams from 2 to 30+ people. In companies of 5 people total and in companies with 2000+ people. So, you, my dear reader, already figured that I have a lot of things to say about remote work and I'm about to deliver on this expectation.

This is a list of random notes, don't hesitate to ask questions and clarify things.

TL;DR: Statement "remote work doesn't work" (usually followed by "for startups" or "for sales people", etc) is false. Because there's no proof of that and there could be no proof. But there's a lot of proof to the contrary. The only valid form of "remote doesn't work" is the "remote work doesn't work for me". And since you came here to read then you probably want to at least evaluate how to change that.

Why remote doesn't work for some?

Because it's a different modality. You can achieve absolutely the same (or better) results as in-office workers, but you have to do it differently. Not better, not worse, differently. And for many people differently means worse and for them remote doesn't work.

Now, it doesn't automatically mean that these people are wrong. They live in a different modality. In their universe, remote work doesn't work. And in that universe, they are right.

The question is: do they need and do they want to leave their universe, switch modalities and make remote work? Maybe. Ask them. But making an effort to switch modality is the only major drawback of going remote and it easily may outweigh all the benefits of remote. There are also physical/social limitations to remote work and solving these limitations is also an expense and an effort that might not be worth the result.

1. Space: the remote worker needs comfortable isolated space to work. If your house doesn't have A/C and only a few days in the summer you have 100+°F where are you going to work?

2. Cooperating housemates: your family or roommates need to understand that you are "at work". There should be a sign of it, like closed door or something.

3. Same as above but with small kids

How to make remote work work?

Everything that follows is written assuming post-COVID circumstances. We are no longer welded shut in our homes and not fed through a BSL-4 compliant air lock in the door. We have a choice and we want to exploit different modalities of work for the business and personal benefit.

First of all, let's define some constants:

1. "Hybrid" (when you spend N days remote and M days in the office) is not remote. It's literally the worst of both worlds ¹. It's a famous "Tomato-Potato" hybrid from Russian literature 2. Roots from the tomato and shoots of the potato.

2. Commute is work. When doing cost-benefits analysis account for that. Doesn't matter if you don't want to pay for that or if you disagree with this statement altogether, people commute for work. Doing something for work is work.

Now to more fine grained details. There are two areas that you need to excel at:

1. Communication

2. Organization

And they are intertwined together. Your organization structure serves to improve productivity and to improve productivity you need to improve communication, which means that your org structure needs to be build around communication and communication needs to serve the org structure to maximize its efficiency.

Once you read through these thoughts below and read what others have to say on the subject, and start to mentally apply some ideas to your team or a company, you'll realize that almost everything has to change at least a little bit. Even the design of your internal systems will be affected. And this is the change of modality and this is what makes it hard for some companies and people. Just plan carefully, identify weak links and fix/replace them one by one.

Leave a comment

Communication

You and your team should excel at communications whether you work remote, in office or hybrid. Everybody knows that, but we are not perfect. In the office you can short circuit a faulty communication line by knocking on someone's door or tapping on their shoulder. It's not efficient, and it drags the team back, but at least you fixed the problem with some naked wire and electrical tape so everyone can go back to perfect efficiency. Remote work environment has a harsher "electrical code" (continuing the analogy) and such fixes are not possible. That means

• Immediate short circuit fix is not possible

• You fix the underlying problem faster and better

Stringent electrical code means the environment is safer and everyone can move faster.

A few communication rules that worked for me many times:

1. Succinct org structure. The whole company should understand what team is doing what, and who is running each team.

2. Escalation paths should be very clear, especially at times of emergency. My favorite question that sometimes makes people slightly less comfortable: "okay, if this thing fails who's getting fired?"

3. As such, no dual ownership. Something two teams are responsible for is an orphan. "Seven nannies leave the baby without an eye".

4. Hot take/controversial: "ban" (administratively, not technically) direct messages on whatever chat app you use (Slack). DMs are only for really private things. If you are comfortable asking in a meeting or in an open office - it should be in the team channel or some other public place. If you have a technical question - 99.9% it's a crime to ask a coworker in the DM. Even for many non technical ("I know our flexible PTO policy, but it delegates a lot to a manager. So what is OUR team policy?") the optimal place is public. Don't worry if you look stupid. People are stupid, everybody is stupid. AGI is not yet here, relax. Why such a harsh rule? Because of the search. Public search doesn't search in private DMs, we don't have AI (yet) to reliably filter private messages for that. The advice that person A gave to a new hire B will be lost and will be repeated for the new hire C and so on.

5. Good guidance should exist on what type of info goes where. This we put on wiki, this belongs to issue tracker, etc. Maintain the structure of information. It's difficult to justify a dedicated hire to police the content itself, but the structure should be there. Managers should have time allocated to review their team's shared information repositories and plan restructuring/cleanup when necessary. These repositories are not supplementary in remote environment, they are a primary tool.

6. Keep 1:1s on schedule. When your team grows big, you can't have 1:1s every week with every team member. Keep them on schedule, but let them slip if nobody has anything. If you're a manager you ping your report if they want to meet, not the other way around. If your 1:1s are optional every Nth should be mandatory. Make it a rule that you meet with every direct report every M weeks and every report one level down every K weeks. And don't skip, move around if CEO calls you, but keep it. The purpose is the wellness check, not perf or project planning. Remote work being used efficiently increases efficiency (see what kind of genius I am ?!?) and direct consequence of that is an efficient burning of employees. People burn into ashes, people go nuts (in the medical sense, I've seen that, it's not pretty especially if you are the manager). Wellness checks are mandatory and need to be regular but not very frequent (you're not running the mental ward. yet?). Project checks, etc, could be skipped if you have a good picture (and you should have) and your report doesn't have anything to tell you.

7. Meet with the team, physically. It's expensive, I know, but absolutely crucial. If you wait until it feels crucial, it's already too late. Now, how often?

   1. Once a year: it's not about work it's a holiday gathering when people talk about work sometimes. No major project decision would be made. Folks will be hanging out and having fun.

   2. Twice a year: half work, half holiday. Have work brainstorming sessions, cross team sessions and then go fishing, diving, drinking, racing, whatever. This is my personal favorite, because people will feel satisfied on both fronts.

   3. Once a quarter: mostly work. We've seen each other recently, it becomes a norm, nothing special, how have you been, so, what we're going to do with these containers accidentally shooting to 100% CPU?

8. If you're a manager, travel to your team members regularly between meetups. If they are scattered wide, gather a few geographically adjacent ones in one location, rent a coworking space for a week and work from there.

   • If most but not all people are in one area (e.g. the Valley) the folks outside that region will start feeling that all the decisions are made there and that implementation is just outsourced to them. This is wrong, awkward, counter productive, etc. Instead, artificially create "centers of expertise" by collecting remote people together, make some decisions, work on a particular project, etc.

Organization

1. Succinct org structure. Remember that? The whole company should understand who is doing what and who is running the team doing this what.

2. Escalation paths.

3. Simple is better. Always. Simple solution is the solution. Complex solution is a temporary solution until simple is found.

4. If you think your org structure is simple enough - ask a complete outsider. If they have questions - answer them by eliminating the very reason why the question was asked.

5. Before going remote - make sure you have payroll ready for that. It's very expensive to start hiring somewhere (overseas, US territories, or just EU or...) and then realize you made an offer which was accepted and you have no idea how to pay that gal. Here comes your first one star review on Glassdoor, congrats. Hiring in Puerto Rico? Oh, you know what they did? They put US labor laws and Spanish labor laws of the 19th century into a blender and forgot about them for a while. IRS esta no bueno, senor. La Hacienda!

6. Same for time zones. Continental US is a pretty "narrow" country, but even 3 hours difference there can deliver a lot of headaches. The actual US "width" many people forget and some even do not know is 7 hours (HST to AST in winter), not considering Guam and Mariana Islands. Are you ready to hire someone from Guam? Now you even have a date difference, how cool is that. And so on and so forth. You need to set the expectations and be consistent. And drive these expectations. No meetings at 10am Eastern if you want people from the West. I worked as a boss of a 25+ team scattered across the globe and my day often started at 7am and ended at midnight. I survived for 2 years and ended in ER a few millimeters from the grave. My former boss from there, and personal friend, kept grinding and he's now dead (he was a few months younger than me). Remember, folks: "Company is not a country: it's not worth dying for".

7. It's a generic advice but becomes much more crucial in remote environment: every person can have a maximum of 1 high priority task, something they work on during long uninterrupted stretches of time. If your hectic work environment (and if you build new things, it should be hectic at times) requires changing priorities often, you should have a communication procedure to document that and inform everyone involved. In a remote environment it's very easy to achieve a state where everybody thinks that everybody else works on things they are not working on. My theory is this is the main reason "remote deniers" exist.

Bonus chapter: Onboarding

New engineer onboarding is where Communication and Organization come together and show how you did. A few points:

1. Simplify and accelerate onboarding. The best (in my experience) way is to give a new hire a project as soon as they've set up their laptop and gotten all the creds from IT. It shouldn't be a critical project, obviously, but also shouldn't be a toy. The team should be invested in the project and interested in it being driven to completion.

2. Assign each new hire a mentor. Someone with much longer tenure, but not necessarily more seniority. Someone who has a regular (even daily) sync-ups with the new hire and who can be asked "stupid" questions (but remember, no DMs!). The most direct goal of the mentor is to help the new hire drive a 0-day project.

3. Use devops onboarding for all engineers. Show the "development infrastructure" first and foremost: CI/CD, logging, observability tools, trackers, etc. Remember the "naked wire" fixes I mentioned earlier? The job to fix the underlying problem and do it good and in a "socially acceptable" way (liked by the rest of the engineering) is more often than not will be devops job. Make sure their boss understands that. Devops becomes Engineering Customer Support organization (I just made this name up). Again, change in modality, but now I really feel I'm repeating myself.

Hope this helps.

:wqa