21 Months In: How to Manage a Remote Team

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.

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

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

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!