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.
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.
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.
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."
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.
> 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.
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.
>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.
> 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.
> 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.
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.
> 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.
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. :)
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!
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.
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".
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.
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.
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.
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.)
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.
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.
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.
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
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.
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.
However you spin it, I don't think many people would enjoy having a webcam on them as they code. It doesn't sit well. Chatting is one thing, because there's no sense of someone watching you. There's a certain creepy factor about not knowing if someone else is just watching you on their screen.
I've used Campfire, IRC, Skype, GTalk, and most recently Hipchat with various agencies and startups. It's just my personal preference to use that over face to face when we have random questions.
It's definitely not a one size fits all situation, there's room for personal preference. Just upthread there's someone lamenting a downside of GTalk and the like. I'm only saying that while the concept definitely sounds a bit invasive, the actual downside is really no different than that of widely accepted alternatives that don't have that stigma.
Absolutely agreed with this. Opened the comments just to mention that while I agree with most of the article, Sqwiggle would be a huge no-go for me. And that's essentially why. Even aside from the big brother aspect, I wouldn't want it for the same reason I hate those setups where you put two desks back to back and get to stare at your buddy across the table from you while you're trying to concentrate. It just doesn't make for a productive work environment. I don't want to have to think about what I look like while I'm coding. I don't want to have to worry about how it looks if I walk around while I'm thinking instead of sitting at my desk, or if I go to the bathroom too often or whatever.
Google is actually doing away with online status as they move from Talk to Hangouts, and while it originally bothered me, I realized that I leave my status set to away all the time anyway! Having it advertised when I sit down at my computer - the exact time when I'd prefer people not bug me unless necessary so I can focus on what I'm doing - is counterproductive and useless anyway since I'll get their messages just as easily on my phone, and if they're important enough I'll answer them whether I'm busy or not.
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.
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.
* 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.
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.
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...
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.
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.
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.