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.
B: "I do, now..."
A: "Oh good, could you fix this please?"
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.
I still haven't figured this one out. Unless it is a criticism or "hey you broke this", my thought is the default should be a public channel, no?
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.
(In Slack [and presumably others],) You can set notifications per channel and turn some channels into "pull" type consumption.
Hm, does that imply that you don't have any process or provisions to train up juniors / begineers?
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.
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.
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)
thanks for posting the article on HN -
i am a daily (more or less) lurker and a huge fan :)
let me know if any parts in the article aren't clear or major points are missing - happy to extend or answer here
Just throwing this out there - the animated gifs are cool and fun but make reading the text next to them almost impossible.
Thanks for a great article!
Good communication practices are equally important, but I feel like those are less often overlooked these days.
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...
There are many reasons for that, mostly people using inadequate equipment and bad internet connections.
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.
With SuperStop, you just hit Shift+Esc and all animations will stop. :)
Reading this post is a great step in that direction...
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.
Why wouldn't you fix tech debt on a normal working day?
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.
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.