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.
Feedback can be useful, but I'd be hesitant around structuring requirements for it.
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."
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 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.
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'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.
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.
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.
So keep exploring and don't stop! :)
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.
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. :)
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!
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.
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.)
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.
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.
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
All this talk about trust is essentially useless if you're under surveillance all the time.
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.
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.
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.
It looks like meldium is headed in the right direction but the last time I tried it, it was still too early.
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.
* 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.
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.
"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 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.