Managing Remote Teams(klinger.io)
klinger.io
Managing Remote Teams
http://klinger.io/post/180989912140/managing-remote-teams-a-crash-course
47 comments
Have you worked on this small of a team before?
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.
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.
Yup. I've worked at a company of 2!
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.
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.
A: "Do you have a minute?"
B: "I do, now..."
A: "Oh good, could you fix this please?"
B: "I do, now..."
A: "Oh good, could you fix this please?"
totally agree. Small team in a separate room is great. Small in open office or cubes simply sucks.
Right, I don't understand why interrupting everyone's work in a local team is acceptable...
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.
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.
» People exercise judgement in deciding how many people to write to: either DM, or 3-way, or dump it in a public channel.
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?
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?
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.
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.
That's my default as well, because I value the durable, searchable record.
(In Slack [and presumably others],) You can set notifications per channel and turn some channels into "pull" type consumption.
(In Slack [and presumably others],) You can set notifications per channel and turn some channels into "pull" type consumption.
> - 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?
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.
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.
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)
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.
author here
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
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
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.
Thanks for a great article!
Thanks for a great article!
Also this free ebook from Valentina Thörner from the support team at Automattic is helpful for managers creating remote teams.
https://valentinathoerner.com/from-a-distance-book-remote-le...
I have not read it but it's by Jason Friend and DHH:
https://www.amazon.com/dp/B00C0ALZ0W/ref=dp-kindle-redirect?...
Lisette Sutherland's book is very practical and very thorough
https://www.amazon.com/Work-Together-Anywhere-Remotely-Succe...
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.
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...
The problem is that video calls are broken.
There are many reasons for that, mostly people using inadequate equipment and bad internet connections.
There are many reasons for that, mostly people using inadequate equipment and bad internet connections.
Video calls are fun for socializing perhaps, but for serious work I prefer having an automatic record.
> 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.
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.
That depends on your talk/work ratio...
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.
That sounds like how all my best managers have worked, whether on site or remote. Their job is to facilitate your work, not control it.
I enjoyed this article but I wish those GIFs were not there, constantly trying to grab my attention.
https://addons.mozilla.org/en-US/firefox/addon/superstop/
With SuperStop, you just hit Shift+Esc and all animations will stop. :)
With SuperStop, you just hit Shift+Esc and all animations will stop. :)
Try putting this in the console: `jQuery('img').remove();`
Dad?
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.
Useful article. I really wish startups put a lot more thought into making their team/culture remote ready from day one.
Reading this post is a great step in that direction...
Reading this post is a great step in that direction...
> Innovation easier in person
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.
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.
> Friday’s employees can work on what they think creates value:
> fixing tech debt
Why wouldn't you fix tech debt on a normal working day?
Why wouldn't you fix tech debt on a normal working day?
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.
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.
Scrum methodology is what works for us - creating different apps.
As a counterpoint, in my last company we used scrum and every developer hated it. In fact, I've never seen scrum work...
What did work in your experience?
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.
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.
(2012)
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.