> In contrast, if you are 5 people co-located you just stand up and say: “everyone over there - we talk now”.
I much prefer working on software teams with other people in the same office, and yet this is one of the things I hate about it. Just because I'm physically near you doesn't mean there's zero cost to interruptions.
Working remotely is like memory protection and pre-emptive multitasking. Maybe in a perfect world, it wouldn't be needed, as there's a slight performance hit from requiring these abstractions, and in some cases it can be awkward to have to deal with the communication paths this requires, but the benefit from requiring everyone to be honest far outweighs the performance cost. In practice, not every component of the system is always perfect. Email is my syscall interface, and distance is my MMU. Open floor plan offices make as much sense to me as running all your programs in the same memory space.
Remote work works for software because it enforces desirable management styles -- that I can be sure my process won't be pre-empted in 5 minutes because someone brought donuts.
When the team is actually small (not a small part of some mondo corp), you get a lot of great team dynamics, and it's very easy to know that 'ken doesn't like being interrupted.
Working with a small team in the context of an open office w/100 people where 10-20% of the team is actually remote is what I've found to be the most unique intersection of terribleness.
The last software team I was on was about 3 or 4 (depending on how you count), in a company of about 10. Nobody in management or sales ever really learned the "doesn't like being interrupted" lesson.
In my experience, as soon as a company is big enough to hire non-programmers with physical access to programmers (usually around 4-6), this problem rears its head.
I manage a fully remote team with staff in time zones from Sydney to LA. In fact I've just messaged people in both zones.
Culture is key:
- People have to be of the mindset that meetings are short and purposeful. Nobody is in the meeting because they are the boss, or forced to join in order to soak up the atmosphere. (Both of those are real things, somehow).
- People exercise judgement in deciding how many people to write to: either DM, or 3-way, or dump it in a public channel.
- Most work is async by far. People post what they're up to, and other people will go and bother them if they're doing something relevant.
There's good and bad things about this:
- We can hire people who are highly experienced, and offer them totally flexible work. Some people like working at 3am. Others like to pick up the kids from school.
- We tend to only hire highly experienced people. There's nobody with under 8 years of work on the team. Juniors will have to somehow convince us they can do it; it's somehow more believable that an older person will be able to work independently than a younger one.
- Work blends in with not-work. Some people like having a division, other people like being flexible and moving their work time around.
It depends on how many people are in the channel and the expected purpose of the channel.
There is certainly some amount of information dissemination by having discussions in a public forum, but you have to weigh that against the information processing burden it adds to the people in the group.
Also, it may become searchable, but it's only findable if you and your communication partners use consistent, appropriate, and relatively unique keywords. There are likely better ways to document things; although, documentation is one of my worry areas, and I understand the desire to have something rather than nothing.
> - We tend to only hire highly experienced people. There's nobody with under 8 years of work on the team. Juniors will have to somehow convince us they can do it; it's somehow more believable that an older person will be able to work independently than a younger one.
Hm, does that imply that you don't have any process or provisions to train up juniors / begineers?
> does that imply that you don't have any process or provisions to train up juniors
If they don't: that's fine. It's better to not hire juniors if you aren't able to provide the mentorship they require than hire them anyway into an organisation that will fail them.
We worried about this but it has proven unnecessary. Juniors can thrive in remote settings if they have the right personality. E.g. Someone who was very disciplined with their University study and assignments I think shows a good base for working remotely.
But take time with onboarding and training. The biggest mistake we made was letting people rush through training.
When remote and particularly asynchronous you'll have times you can't ask anyone for immediate help. So basic process and understanding need to be deeply embedded during training.
Nice article op. I work in a remote-first org and completey agree that org structure is crucial.
A couple additional thoughts: people assume remote work expands your talent pool to everyone. I don't believe it does. You're limited by time zones and by autonomy. Not everyone performs at a high level in a remote context. You need people who are very organized, disciplined and self-starters. Additionally, it can be very hard to unplug in a remote first context so you need a culture that prioeitizes time offline (I.e out of the office)
Not convinced you are totally limited by timezones if you can embrace asynchronous working. Definitely makes it harder though.
100% on self starters. Micromanagers or workers that require great oversight aren't going to work.
Really appreciate the emphasis on requiring 5x the process when working as a remote team. Prior the team I now lead I've only worked on co-located teams and it has certainly required some resetting of expectations on my end. Even though I've got a very talented small team I'm learning that we do need a level of process and protocol that feels much more "big-company" in order to work efficiently. Would love any more insights on practical elements you've added in terms of process that have worked well.
Any good books you can recommend? Most of what I've seen is about "offshoring" rather than "remote-first" situations, I'm about to build a team using the later and want all the reading material I can get my hands on.
One great point in this post that I don't see much of in articles on remote work is the importance of setting people up to work autonomously as much as possible. One thing I love about working remote is being able to spend much of my time deep diving on problems without distraction.
Good communication practices are equally important, but I feel like those are less often overlooked these days.
You make a long passionate speech about what the team needs to do to win the market, just to be followed up with a “Sorry Sarah, your internet connection dropped for a second, what did you say?”
That's why you use text based communication, if the internet drops for someone all they have to do is scroll up a bit when they rejoin...
> That's why you use text based communication, if the internet drops for someone all they have to do is scroll up a bit when they rejoin...
And that's partly why working remote is so inefficient that less than 3% of people do it. Talking with someone in the same room communicates so much more effectively than a chat log.
I'd argue that at this point you can still hire the self motivated people that you only need to lead not manage.
'Managing' programmers in general is hard enough, managing remote team in nigh iimpossible so don't do it, just remove the obvious roadblock, be aware of what everyone is up to (roughly) and don't interrupt, if not needed.
I dare say the daily standups are not needed - just read the commits to see what's already happened and send an email or a wiki page to edit plan for next week, no need for a meeting involving everyone's full hour.
Embrace async and don't manage things that you don't need to.
Agreed – with remote teams you have to embrace async. Don't force meetings that everyone has to be apart of unless it's a critical planning session or something in that realm.
One other thing I would add to this is don't treat remote employees as "set and forget". The tendency is to sry someone up remotely and assume they will be happy with that arrangement indefinitely. But many people will experience changes over time in their enjoyment of remote work and productivity. Not always work related and not always positive.
E.g.we had someone who injured themself and started to struggle being at home all the time. Another person who loved being remote until their relationship ended and then got lonely at home by themselves day and night.
There is a simple fix : every quarter check in with your remote workers to make sure it's still working for them.
Innovation is not a group activity, it is always the work of a single individual's creativity. You might think otherwise, that brainstorming and bouncing ideas off each other is important, but you'd be wrong.
There are really good new get remote team management tools (like Bitrix24.com or its clones) that make the remote work model actually workable and productive.
I don't think the author is saying tech debt is ONLY fixed on Fridays.
Companies have a hard time prioritizing things that only engineers can see. Especially small things. So some form of reserved engineer bandwidth for tech debt can be useful.
I've seen extreme programming work well in some situations, but I've seen it not work in some others...
In my current project we're three people: the owner, front-end dev and back-end dev. We don't really have a methodology other than having a daily call at the same time every day and discuss what needs to be done and any issues we're having. We also have Slack and if there's something urgent we jump on a call. I would say it's worked well so far.
But IMO with smaller teams it's way easier than with larger teams.
I much prefer working on software teams with other people in the same office, and yet this is one of the things I hate about it. Just because I'm physically near you doesn't mean there's zero cost to interruptions.
Working remotely is like memory protection and pre-emptive multitasking. Maybe in a perfect world, it wouldn't be needed, as there's a slight performance hit from requiring these abstractions, and in some cases it can be awkward to have to deal with the communication paths this requires, but the benefit from requiring everyone to be honest far outweighs the performance cost. In practice, not every component of the system is always perfect. Email is my syscall interface, and distance is my MMU. Open floor plan offices make as much sense to me as running all your programs in the same memory space.
Remote work works for software because it enforces desirable management styles -- that I can be sure my process won't be pre-empted in 5 minutes because someone brought donuts.