13 ms·

21 Months In: How to Manage a Remote Team

143 points by WadeF 13y ago

srikrishnan 13y 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.
dylanrw 13y 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.
- thisisdallas 13y 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 13y 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?
    - dylanrw 13y ago
      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.
    - thisisdallas 13y ago
      Honestly, I think it comes down to a trust issue. It's so easy for a company to get burned by a remote worker. Then again, I worked remotely for a very small company for about 6 months and didn't get paid for the last three months until about two months after I quit. I guess it goes both ways.
benwoody 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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.
arohner 13y 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 13y ago
  We love meldium. Its very stable for us and works as expected.
- sciurus 13y ago
  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.
- tempestn 13y 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.
pajju 13y 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! :)
- retrogradeorbit 13y 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.
andrewcooke 13y 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...
jqueryin 13y ago
Using Sqwiggle sounds a little too Big Brother for my liking.
- csbrooks 13y 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.
  - jqueryin 13y 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.
- aantix 13y ago
  Interesting. Versus having to sit in an office?
  - OGC 13y 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.
    - mdbennett 13y ago
      I equate it to Google Talk. Replace "webcam picture" with "online status" and you can say remarkably similar things about the two. Both Google Talk and Sqwiggle are meant to facilitate communication and not to be used as accountability tools, but if you don't trust those you're sharing that info with then it could be used that way. Both give out signals of my online status based on my presence, and both can manually be set to a "busy" mode(to the detriment of communication) if I want to not be bothered or "watched". Sqwiggle is obviously a more intimate version of this, but that works to its benefit in lowering barriers to having quick conversations with people you can "see" are available. Disclosure: I work at Zapier.
ownagefool 13y 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 13y 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 13y 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.
bluekite2000 13y 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 13y ago
  HR and legal compliance is much easier when dealing with domestic vs. international employees.
kephra 13y 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 13y 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 13y ago
  Sqwiggle from the article sounds like it would make it more obvious when everyone is working.
bane 13y 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.
retrogradeorbit 13y 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.
tempestn 13y 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 http://www.paulgraham.com/makersschedule.html

143 points by WadeF 13y 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.

dylanrw 13y 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.

thisisdallas 13y 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 13y 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?
  - dylanrw 13y ago
    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.
  - thisisdallas 13y ago
    Honestly, I think it comes down to a trust issue. It's so easy for a company to get burned by a remote worker. Then again, I worked remotely for a very small company for about 6 months and didn't get paid for the last three months until about two months after I quit. I guess it goes both ways.

benwoody 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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 13y 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.

arohner 13y 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 13y ago
We love meldium. Its very stable for us and works as expected.
sciurus 13y ago
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.
tempestn 13y 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.

pajju 13y 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! :)

retrogradeorbit 13y 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.

andrewcooke 13y 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...

jqueryin 13y ago

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

csbrooks 13y 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.
- jqueryin 13y 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.
aantix 13y ago
Interesting. Versus having to sit in an office?
- OGC 13y 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.
  - mdbennett 13y ago
    I equate it to Google Talk. Replace "webcam picture" with "online status" and you can say remarkably similar things about the two. Both Google Talk and Sqwiggle are meant to facilitate communication and not to be used as accountability tools, but if you don't trust those you're sharing that info with then it could be used that way. Both give out signals of my online status based on my presence, and both can manually be set to a "busy" mode(to the detriment of communication) if I want to not be bothered or "watched". Sqwiggle is obviously a more intimate version of this, but that works to its benefit in lowering barriers to having quick conversations with people you can "see" are available. Disclosure: I work at Zapier.

ownagefool 13y 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 13y 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 13y 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.

bluekite2000 13y 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 13y ago
HR and legal compliance is much easier when dealing with domestic vs. international employees.

kephra 13y 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 13y 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 13y ago
Sqwiggle from the article sounds like it would make it more obvious when everyone is working.

bane 13y 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.

retrogradeorbit 13y 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.

tempestn 13y 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 http://www.paulgraham.com/makersschedule.html