21 Months In: How to Manage a Remote Team

https://zapier.com/blog/how-manage-remote-team/

by WadeF • 13 years ago

143 48 13 years ago

dylanrw2• 13 years ago

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.

thisisdallas2• 13 years ago

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• 13 years ago

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?

benwoody• 13 years ago

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• 13 years ago

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.

tarr11• 13 years ago

I think it depends on the size and scope of your project. As devs, we all start with simple text files + email for everything, and then add more specialized tools from there.

Complexity is endless, and depending on the scope of your project, it may not make as much sense to add more tools. I have met many people who just skip the entire bug tracking system and dump the whole thing in trello or somewhere else. But I couldn't imagine doing that on a huge project with thousands of issues and customers.

rogerbinns• 13 years ago

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.)

atacrawl• 13 years ago

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• 13 years ago

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• 13 years ago

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.

zck• 13 years ago

Part of the benefit is that setting aside time to talk about what you can do better forces you to think about what you can do better. Sure, some people will think about that without needing prompting, but having a set time to do so is beneficial for everyone else.

Additionally, it gets the employee and his or her supervisor on the same page -- "here's what we agreed I would work on, here's how it's going."

gz5• 13 years ago

I don't have stats but for me it has proven invaluable (managing remote teams for years).

Unstructured, no agenda 1:1 video pings - hey, what's new type pings - have been very important too. The virtual version of the in-person coffee machine conversation, helping to replicate that important part of the co-located enviro.

markdown• 13 years ago

http://en.wikipedia.org/wiki/Kaizen

dmiladinov• 13 years ago

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.

I would too, and here's some anecdata for you: one of my old bosses would conduct weekly one on one meetings with all of the developers on his team (anywhere from 4 to 8 of us at different times) and I'd have to say that personally they were some of the best manager-direct experiences I've ever had since.

One on one meetings are one of the most important tools out there for helping organizations build relationships with their people, helping them produce more results, as well as increase retention.

Anybody interested in starting them at their organizations should check out the manager tools website. They produce several weekly free podcasts as well as offer other products and services.

https://www.manager-tools.com/docs/Manager-Tools_One_on_One_...

http://www.manager-tools.com/2005/07/the-single-most-effecti...

srikrishnan• 13 years ago

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.

arohner• 13 years ago

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.

prayag• 13 years ago

We love meldium. Its very stable for us and works as expected.

sciurus• 13 years ago

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

At previous companies I've used Passpack (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/) and a central git repository.

tempestn3• 13 years ago

Awful in what way? I use LastPass every day and love it. (The Firefox and Chrome extensions, LastPass for Applications on Windows, and the Android app and keyboard replacement, and the Dolphin Browser plugin.) The Equivalent Domains settings are a bit clunky and would be better implemented with the ability to enter regular expressions directly in the URL fields of sites IMO, but it works. The keyboard replacement is no substitute for a real keyboard like SwiftKey, but combined with the app it makes for relatively convenient password entry in apps, and the Dolphin plugin is seamless. Otherwise, everything else about it product has worked perfectly for my use case.

pajju2• 13 years ago

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! :)

retrogradeorbit3• 13 years ago

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.

pajju2• 13 years ago

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. :)

andrewcooke• 13 years ago

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...

jqueryin3• 13 years ago

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

csbrooks• 13 years ago

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

jqueryin3• 13 years ago

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.

aantix2• 13 years ago

Interesting. Versus having to sit in an office?

OGC• 13 years ago

In an office nobody pops in every 8 seconds and takes a picture of you.

All this talk about trust is essentially useless if you're under surveillance all the time.

ownagefool2• 13 years ago

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.

winter_blue• 13 years ago

the best way to manage a team is, in my opinion, is to not manage them.

This is one-view of management. It's called the "hands-off" manager. He trust him team to get the work done, and operates in a sort-of hands-off way.

For the longest time, I felt like this was the right way to manage teams at technology companies, but recently I read a piece that argued that the middle ground -- ie. somewhere between being hands-off and micromanaging (the other extreme), was ideal.

Now I'm not so sure myself if this is right, but it's cast a bit of doubt to my long-held notion that off-hands was the best way to go.

mjolk• 13 years ago

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.

ownagefool2• 13 years ago

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.

bluekite2000• 13 years ago

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• 13 years ago

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

kephra• 13 years ago

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.

agentultra• 13 years ago

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• 13 years ago

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

bane• 13 years ago

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.

retrogradeorbit3• 13 years ago

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.

tempestn3• 13 years ago

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

21 Months In: How to Manage a Remote Team

Related Stories