
21 Months In: How to Manage a Remote Team - WadeF
https://zapier.com/blog/how-manage-remote-team/
======
atacrawl
_I setup a recurring monthly event with each team member where we both jump on
Skype or Google Hangout to chat about three things: what 's one thing I can do
better to help him with his job, what's one thing he can do better to improve
at his job, and what's one thing the company can do better to make everyone's
lives easier._

I was just talking with a friend of mine about this very topic -- it's
critically important for any company, remote or otherwise, to have this kind
of meaningful, open dialogue periodically, and yet so few companies actually
do this. I'd love to see some statistics on what kind of effect a half hour
per employee per month does for overall happiness and employee retention.

~~~
6d0debc071
I know that company Y does something similar with their artists as part of
their yearly reviews, and their artists don't know of anything they could be
doing better. As one of them said to me "If I knew what I could be doing
better, I'd be doing it."

Feedback can be useful, but I'd be hesitant around structuring requirements
for it.

~~~
sokoloff
It's less to get and act on a concrete answer to the question, but rather that
asking the question unambiguously signals openness and desire to improve. As
long as the recipient of the question believes it's being asked earnestly, it
doesn't ever need to be directly answered.

------
ownagefool
I suspect this is going to rub people the wrong way but the best way to manage
a team is, in my opinion, is to not manage them.

By far the biggest issue for me getting stuff done is managment. I've sat in
several companies, at times with not a lot of work, because managers aren't
willing to sign off. Motivation dwindles and people leave.

Of course you have to hire people you trust. You need to actually trust them
and get out of their way. Let the technical people make the technical
decisions, let them do the work, remove obstacles and make sure you're not one
of those obstacles.

You will pay the price that a couple of non-contributors will fly under the
radar for a bit longer, but between git logs and productivity tools you should
still be more than capable of gauging productivity, which should be a binary.

Regarding the article, written communcation is important even if you're in the
same office. Listen, it's fine if John tells Steve about foo, but unless it's
written down Bob and whoever else wasn't privy to that conversation isn't
going to know and you're going to need to repeat yourself with every hire.

If there is a significant difference between what you do with remote folks and
what you do with guys in your office, you're probably doing it wrong with the
guys in your office and you just haven't figured out how much time you've
wasted having to explain everything verbally to new guy Dave.

~~~
mjolk
>You will pay the price that a couple of non-contributors will fly under the
radar for a bit longer, but between git logs and productivity tools you should
still be more than capable of gauging productivity, which should be a binary.

You're missing part of the picture here - time spend helping other employees
is time that an employee isn't making commits.

Or, conversely, unless you're looking into the contents of a commit, you don't
know the difference between someone making many, regular commits on an easy
issue and the person that commits relatively seldom, but contributes code to
address harder/meatier problems.

>Regarding the article, written communcation is important even if you're in
the same office...you're going to need to repeat yourself with every hire.

Documentation is great, but it's time consuming and much can change in a few
weeks time. Write down the stuff worth keeping around for months, and let go
of the rest -- giving a new hire volumes of text regarding irrelevant
conversations/processes is a sure way to increase spin-up time.

~~~
ownagefool
> You're missing part of the picture here - time spend helping other employees
> is time that an employee isn't making commits.

Actually I do get that, that's why I said its binary. Don't compare Bob, Steve
and John. Look at them individually and see if they're contributing. Set a
minimum standard and stop caring about squeezing every little bit out of them.
You might run into a problem if all you ever do is mentor, but then your
manager should be aware of that and view you in that context.

> Or, conversely, unless you're looking into the contents of a commit, you
> don't know the difference between someone making many, regular commits on an
> easy issue and the person that commits relatively seldom, but contributes
> code to address harder/meatier problems.

Following my advice doesn't preclude you from looking at the context of the
commits, my point was leave the fucking team members alone unless you have a
good reason. Bobs not doing a lot of projects, look at what he actually does
and validate him. Steven has almost low commits? Look at it in the context of
the problem he's working on and judge him based on that. Only step in when
theres a real need, otherwise leave them alone, you'll just make things worse.

> Documentation is great, but it's time consuming and much can change in a few
> weeks time. Write down the stuff worth keeping around for months, and let go
> of the rest -- giving a new hire volumes of text regarding irrelevant
> conversations/processes is a sure way to increase spin-up time.

No, you should give a new hire a piece of A4 that tells him how to get up and
running. You need a network login? It should tell him where to go. Need to do
something to project? Get it from git, vagrant up. Expected to be on IRC?
Heres the creds. Need more info? Heres the Wiki.

In the wiki, you only need to give specific minimal information such as
specific repo the project is in, steps to push your changes, etc. Anything
non-standard as your hires should know how to do their job or to google it and
figure out. I never said anything about giving them irrelevant conversations
or processes, I said the info needed to be a remote worker is exactly the same
as one in the office and it's pretty much always the same a) Where do I find
this shit? b) what does it use? c) Any gotchas? d) Ok fixed, how do I make my
changes live?

The only exception is if you're training juniors, they might need you to
actually talk to them about work now and again, everyone else should get on
with it from the above.

------
pajju
We too are a remote team at ninjaas.com.

I admire startups which open-source their - workflows, tools, processes and
philosophies. They must be having really-really-big heart! :)

In our case, we are currently just Ramen Profitable. All our team members are
remote, in the same time-zone.

Many small startups don't care much to invest in bringing Greater workflows,
Processes and tools.

I keep telling to my co-founder - the hardest part in company building is
setting up Processes, tools and workflows -- the Nurturing phase. It takes
lots of gut, time and patience to explore and fix workflows, tools.

From my experience so far -

\+ Any remote work sits on top of love for the work. I must love the job. Job
satisfaction.

\+ There must be a sense of ownership, reward and instant gratification. All
other things like responsibility, Trust, faith comes on top of that.

\+ Remote teams need highest levels of Communication clarity, Protocols and
aligning with the Product vision. Communication tools are important. We use
Google+ Private communities.

So, what if you are an idea-Stage/early-stage? If its an Idea and still not a
concrete product? Then remote teams can't collaborate easily and brainstorm.
We've found it very hard.

Also for Remote teams - Everyone should be doing support, sales, marketing,
pitching, writing cool articles and almost full-stack work. Overall a
Generalist attitude. This brings more clarity, responsibility and leadership
overtime.

Finally as you said - The biggest wins aren't usually found in any blog posts
or comments like mine, but in what you discover on your own, over time.

So keep exploring and don't stop! :)

~~~
retrogradeorbit
> Also for Remote teams - Everyone should be doing support, sales, marketing,
> pitching, writing cool articles and almost full-stack work. Overall a
> Generalist attitude. This brings more clarity, responsibility and leadership
> overtime.

See my other post on here to see that I disagree with this. This is deeply
unprofessional. Perhaps your programmers aren't professionals, so then it
might make some sense. But then it's more a shop of amateurs than a really
professional organisation.

Would you expect a physician to drive the ambulance, triage the emergency
room, treat the patients and keep the hospital accounts balanced to bring
'clarity, responsibility and leadership'?

How about expecting a lawyer to write contracts, appear in court, manage the
computer systems, man the front desk, keep the filing cabinet ordered and
handle the invoicing and billing, answer the phones and including chasing
clients who are late paying?

As a software professional I would certainly not work for you. Why would you
make me do sales, support, marketing, pitching and writing articles? I'm not a
sales person or a tech support person. I didn't study marketing nor creative
writing. I develop software. And I'm damn good at it. Asking me to do these
other things would be a waste of my time and of your money. If you hired me
and asked me to do these things I'd say no. If you forced me to, I'd
respectfully quit. And then go get a job developing software with a team of
professionals, not a bunch of amateurs.

~~~
pajju
Startup != company.

Have you worked in a startup environment?

In any early stage startup, you need to be ready to roll out your sleeves and
ready to do anything awesome in the interest of your team.

This might be getting new leads, contracts, deals or whatever. This is how all
great companies started.

This should be the attitude.

And please don't say - I'll only do this and not that. I will never hire you
or work alongside such minds.

Its the role of founders and early team to nurture the project and processes.

Startups are very low on budget and can't spend $$ for sales or MBA heroes.
Today developers can write a great blog article and attract customers in your
niche.

Note: We are all full-stack developers and completely bootstrapped. We have
failed and learnt things the hard way so far. Once things are setup we have
plans to invest/hire dedicated staff. We believe in training and making them
align with our vision.

I think you might have never worked in a startup, so you don't get the idea
and feel of it. :)

~~~
retrogradeorbit
I actually started a startup once, when I was younger. The legal structure was
a company. What legal structure is yours, if not a company? A partnership? Or
even worse, it has no legal structure? Just a sweat equity and a promise?

After two years we were not profitable and wound up the company. I made a lot
of mistakes and learnt a lot about writing _maintainable_ software. We hacked
shit together quickly and out the door, and we paid the price in the medium
term.

At least our feelings are mutual. You would never hire me and there's no way
I'd ever work for you. So it's all good!

------
dylanrw
Lack of trust and an abundance of paranoia are big obstacles lurking beneath
the surface with remote work. Experience leads me to believe most 'managers'
or founders aren't able to handle it. However, when you have a good one that
gives you the space and trust you need to get things done. It's marvelous.

~~~
thisisdallas
That makes sense from my experience. When looking for front-end jobs it seems
like there are very few remote positions available. If there is a position
available, they usually fall into two different categories. One, the position
is for a senior level front-end wizard or the position is remote but only to
the extent of the city limits. For example, "remote but must live in San
Francisco".

~~~
emclaughlin
I don't get that. Is there an actual reason why employers care about where you
live when you work remotely? Beyond, I suppose, time zone concerns?

~~~
dylanrw
I'm sure it's a matter of being able to meet in person without the need for
pricey flights, having the ability to come in with some sort of frequency.

------
benwoody
Maybe I use these tools differently than Zapier does, but using Trello AND
Github issues AND iDoneThis seems a bit redundant. There's nothing worse than
keeping up with different tools to do basically the same thing.

~~~
bryanh
Ah, we find the complete opposite.

One serendipitous thing we've discovered while using and working on Zapier is
that the tool itself allows you to use whatever _your_ best in class
application is for the task at hand, regardless of what else you'll need to
shoehorn into it. Zapier can help you connect up the different tools that are
the best at what they do.

Multiple tools also help us silo stuff, for example:

    
    
        * Trello covers product roadmap.
        * Github covers bugs.
        * iDoneThis covers everything else we're working on.
    

Just like you might use a particular database for its strengths (Cassandra for
write heavy loads, Redis for crazy fast in memeory, Mongo for speedy
development), you should use various SaaS tools for their strengths.

~~~
rogerbinns
We abandoned Github for bugs and only use Trello. The issue is that bugs need
to prioritized alongside other work rather than done separately. Bug is a very
broad term covering everything from a bona fide clear cut bug to 99.3% of some
feature has been implemented but there is that missing .7%. Also Github
doesn't support a 'priority' field for issues making them useless with more
than a trivial number of issues.

The other problem is that Github doesn't allow multiple repositories per
project (Google Code does). That means each project has its own bug tracker
and wiki (we also gave up on them) and has exactly one source repo. If your
final product experience is an aggregate of multiple different projects (eg an
android client, a web server, a data backend) then bugs can easily be reported
against a project when the fix is in a different one. Having to
copy/move/reference issues across projects is far too much busy work.

The final issue was that I talked to Zapier folk and bidirectional syncing
wasn't supported (and doesn't appear to be today). For example if it supported
bidirectional sync between a Trello card and a Github issue then it might be
manageable. (By bidirectional syncing I mean that changes made on either side
show up on the other one automatically and there is no infinite loop.)

------
retrogradeorbit
> Everyone does support

I once worked at a company who did this. It was terrible on the developers. It
destroyed productivity. It destroyed flow. And it was really just a way to
plaster over not having clearly defined software goals and processes. If you
develop software in a _professional_ manner, you can really do amazing things
for the customer without making your 6 figure salaried senior programmers
answer phones and tell people to try rebooting their windows machine.

The developer doesn't need to 'hear the voice of the customer' if the
customers needs are being accurately transformed into proper specifications
and plans by competent technical leads. The developer will meet the needs of
the customer through creating excellent, testable, modular and clean code that
excels at meeting the specifications.

------
agentultra
Another bit that is really important I find as a remote worker: feedback.
While it's nice that you can get long, uninterrupted stretches of work it
becomes a problem when you can't get a snappy answer to a simple question
because everyone has their head down and is ignoring their email, IMs, etc.

You have to be more up-front with your availability and response times. One
thing that irks me working on remote teams is the person who leaves their
online status as "available," all of the time. It can be infuriating when you
send someone a message and not get a reply for hours. I find you have to
manage your statuses a little more carefully. However the payoff is nice
because you can't always mediate conversations like that in a co-location
setup.

~~~
bostonvaulter2
Sqwiggle from the article sounds like it would make it more obvious when
everyone is working.

------
tempestn
Aside from Sqwiggle, which I hadn't heard of but hate on sight, this sounds
remarkably similar to my team's workflow. I'm not certain whether idonethis
would offer enough benefit to be worthwhile compared to simple daily emails to
a team mailing list, filtered into a label (or folder for non-gmail folks)
though.

Actually, we use Hangouts a bit differently too. We don't really have a
concept of 'at work' vs 'not at work'. When I'm working, I am, by definition,
busy. It's often more convenient for me to receive a chat when I'm not working
- watching TV or whatever. Plus, I have Hangouts on my phone, so I'm very
rarely unreachable, unless I'm sleeping. The distinction therefore shifts from
at work/not at work to available/busy. If I'm available I'll answer a chat
immediately; if I'm busy I won't, unless it's particularly important. Also,
each member of our team works whatever hours are most convenient for them,
which often don't overlap much, so it's beneficial that we're available when
necessary to answer quick questions even when we're not in work mode. (Not
that we need to often, since asynchronous methods of communication usually
tend to do the trick.)

It's similar to one of the many objections I had to Sqwiggle: this idea that
since I'm sitting at my desk, it's therefore a good time to contact me. Often
the exact opposite is true:
[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

------
jqueryin
Using Sqwiggle sounds a little too Big Brother for my liking.

~~~
csbrooks
I feel like it conflicts with the advice to trust your employees, too. Like,
trust them, but have them on camera at all times.

~~~
jqueryin
Exactly. It's one thing to jump on Google Hangouts or Skype on a whim, but
it's entirely different to ask employees to be monitored like animals at their
desks. I'm envisioning management questioning why an employee is away from
their desk if they went to the bathroom or to get something from the kitchen.
It would seem to cast more doubt than assurance in my opinion.

------
arohner
Does anyone have a recommendation for a better tool than LastPass? I use
LastPass every day, and it's awful.

It looks like meldium is headed in the right direction but the last time I
tried it, it was still too early.

~~~
sciurus
I hadn't heard of Lastpass Enterprise or Meldium before.

At previous companies I've used Passpack
([http://www.passpack.com/en/home/](http://www.passpack.com/en/home/)) but
didn't really like it. The sharing model is a real pain and doesn't scale.
Team members create passwords in their individual accounts, then transfer
ownership to a company account. Now the person who administers the company
account gets an email, logs in, accepts the transfer, and shares the password
to the appropriate team members.

Now that I'm in a simpler environment where veryone has access to all the
passwords, I just use pass ([http://zx2c4.com/projects/password-
store/](http://zx2c4.com/projects/password-store/)) and a central git
repository.

------
srikrishnan
Wanted to add a couple of items:

* Would rather always over communicate than under (respecting the 'maker schedule', of course)

* Make sure you are always aware of what your team mates are working on - not because you don't trust them, but so you know they are always spending time on higher priority things. A daily scrum - even over a skype call or text based chat can help set clear priorities. Should be part of process for any remote team so its not at end of day that you now time was wasted.

------
bluekite2000
I noted the OP's blog has a job post for a content manager that states
Anywhere,USA. Why limit yourself to USA? I figure if it is remote it should be
remote anywhere.

~~~
otoburb
HR and legal compliance is much easier when dealing with domestic vs.
international employees.

------
andrewcooke
the first part of that article is everything, really. if you get that right,
they/we will find the right tools.

and i say this as a remote worker who just ended up going for a walk in the
rain to calm down; returned to an email saying "sorry for the poor
management"; and would quite happily give the silly idiot a hug if he were
here...

------
bane
communicate communicate communicate

I've worked in several jobs with remote teams (as the team and managing the
team) and the difference between the ones that worked like clockwork and the
ones that didn't almost inevitably came down to communication.

The amount of time and energy sorting out problems because of a lack of
communication will absolutely dwarf the amount of time you should have been
communicating.

\- Have at least 1 weekly roundup, guaranteed, no exceptions. Even if it's
just for everybody to get together and say they have nothing to report, that
is even in and of itself a communication. Some places did daily end of the
days, some did Mon & Friday mornings, it doesn't matter. Do it.

\- Use more efficient communication proxies when possible: trello, jira,
salesforce, whatever. Enforce it with an iron fist. Don't let people get away
with not using the tools, they're easy to use and if you get in the habit,
saves hours upon hours of time. I love love love Trello for this.

\- Have constant ad hoc communications. IM, phone, email. Schedule times so
you don't interrupt somebody's work day. Missing a scheduled time should be a
shocking breach of protocol.

\- Please try not to use speakerphone or conference room speaker phone, it
makes the meeting unpleasant on the other end and much harder to undertand.

\- Google docs, really great for drafting up things and early collaboration.
Switch to Office for the final work.

\- if you can afford it, have as many face-to-face meetings as possible, be it
once a week, or once a quarter, or once a year. Try and make the effort. I've
found that learning people in-person helps smooth over digital communications.

\- document document document - everything. Have a centralized and constantly
organized document repository. People leave, sometimes without doing a good
handoff. Not having good documentation will kill a company for months or
years.

I agree with most everything else here: especially "5\. Hire people who are ok
without a social workplace."

Amazingly, most people don't actually realize what it means to work alone
every day, all day. I've had a couple people go a bit loony and flake out
after a few months on their own. The environment was discussed, and they felt
confident about it, but simply couldn't handle the reality of it. If this is a
requirement, prepare for issues no matter what. Try and hire people with a
track record for this kind of work.

One guy ended up hitting bottle pretty hard (bars can be chatty places), his
wife filed for divorce, and he simply stopped showing up to work. Working
remotely it took a couple of weeks of no shows on the weekly all together to
figure it out. He ended up quitting and moving to the desert to sort his life
out. Working alone simply shattered him.

And finally, "4\. Hire people who can write"

You wouldn't believe how many emails I've received from certain remote workers
that are utterly indecipherable. You think most native speakers of a language
with some college in them can write an intelligible email. It turns out many
can't. And you waste lots of time clarifying, making phone calls, etc. And the
worst case is you go off on the wrong direction.

------
kephra
I prefer to work remote for ages, but I dislike the choices of tools.
Publishing valuable business critical documentation into the cloud looks to me
to like typical US stupidity, I prefer to host them myself.

I host my own teamspeak, my own upload file server, my own repository, my own
wiki, my own ...

I do not need PRISM scans. We had two burglars in 2010 who did not steal
anything, but tried to reboot systems to install malware. Just raise the bar
for industry spionage, do not make it to easy for them.

In the list of tools Sqwiggle would be a no go for me. I would walk out of the
virtual hiring chat, if someone tells me that he wants to watch me with a
webcam, while i'm sitting here in underpants. Hey - go to chatroulet if you
want that.

