Ask HN: Trust and remote work

eengstrom · on March 17, 2011

You need to synchronize your operations and shake out the trust issue.

Set up a mandatory morning and afternoon call at the same time every day. 15 minutes.

Spend the first two minutes of each call recapping your current milestones. If it takes more than 2 minutes you're talking about the wrong stuff. See below.

"Yesterday we expected to get to X." Then reiterate what the team members told you in the last meeting.

Person 1: What are you working on? Need anything? Next step? Person 2: What are you working on? Need anything? Next step? Person 3: What are you working on? Need anything? Next step?

Anything taking more than 2 minutes take offline, or stay on the bridge line after the others are gone. If you do this for a few weeks you'll quickly spot who is flaking, working for another company or project on the side, or who really just needed more direction from you.

When people experience trust issues, there's a good reason: either they are insecure, or someone is untrustworthy. I've managed large corporate customers remotely for years, performed complex projects remote. Once you get the process under way you can move to a single morning call.

Do not skip it. Do not reschedule it. Do not miss it. Get in the habit and your team will fall in line. The rest of the issues will sort themselves out.

stevenp · on March 16, 2011

Setting expectations is important. You should let them know what your observation is about the amount of time that you expect the work to take, and give them the opportunity to explain to you why it's taking longer.

Agile/Scrum are good for this, because they give people the responsibility to commit to which work they'll be completing on a given day, and explain why they're blocked or moving more slowly.

Perhaps you should have a daily 15-minute scrum meeting to get a sense of exactly where they are and how things are going? More communication always makes things more transparent.

If you can't do that, set a deadline. Work will always expand to fit the allotted time, so make sure you're keeping the timeframe short enough to make sure the team knows that the project completion date is not open-ended.

sagacity · on March 16, 2011

Have you tried to voice your concern to them? If not, I think you should give that a go. For all you know, that's all it would take. :-)

reduxredacted · on March 16, 2011

My advice from the perspective of a remote worker:

Rule #1: Communicate directly, precisely, and clearly.

It's not about how hard someone works, when you're managing remote workers, in that it's not about how many hours (to be clear: too few or too many). You have absolutely no way to micromanage their time, so you must set expectations at the project level. "Feature/Component X needs to be done by day Y, and if that deadline is going to slip you need to let me know as soon as you see that happen so that I can plan accordingly." You might have someone who gets Feature X done on day one and slacks off the rest of the time. But you got what you wanted.

If you expect them to be available and contactable at certain times of the day, state it clearly. If you don't care as long as the job gets done, don't hold them to certain hours and state that clearly.

Rule #2: Remote workers, especially ones who are new to working remotely, can tend to feel "left out" or "lonely". This is, in my opinion, the equivalent of the manager of remote workers feeling like their workers are not completing work in a timely enough fashion. In an office environment where you can toss a piece of paper at your boss, you can get constant feedback. In a remote environment, that's impossible to replicate completely and dangerous to try to replicate for people who write software (where interruption kills productivity). Whenever there is a lack of communication, both parties tend to jump to the worst possible conclusion. The manager assumes the employee is being lazy, the employee assumes his manager is incapable of handling remote workers and is looking to fire him at any moment (so some of that slack time is spent getting the resume together and shopping it at alternative places of employment). Back to Rule #1.

I know it could be a motivation problem ... maybe I just need to challenge them on their speed...

Yes, but do it by giving them clear deadlines, not by questioning their lack of motivation. When the work is completed properly and on-time, ask for feedback about the deadline to ascertain if you were being too reasonable or very unreasonable. When it slips, say these words: "What do I need to do differently to ensure you can reach the deadline next time?" This is a nice trick. If your developer says "nothing, I just needed more time", you can carefully launch into questions about (1) whether or not they have the right skill-set, (2) if they're having difficulties with the remote work arrangement and how that can be solved. You sound like a pretty decent guy who would give his employees a good deal of slack if they're just a little slower. Work that angle a little bit, but be careful to not allow that to be something that can be taken advantage of.

Consider a Skype video call on occasion. Video calls just "feel" more connected.

Just to add a little perspective to my advice:

I work remotely. Three days in a remote office, two days from home. My bosses have ranged from being on different continents to being as close as six hours drive away. My "remote office" is 7 people, none of which work in my division. I was new to working remotely six years ago, prior to which I had a "boss two cubicles over" sort of working arrangement. It took a little while to adjust, but I had a very good manager who who managed both his local and remote employees this way (some of his staff start work at 5:00 AM, some start at 10:00 AM, he doesn't care as long as the work gets done). I also write software all day, sometimes as part of a team, sometimes as a lone developer. So use that when deciding to take my advice. My situation may not fit with your circumstances.