

Ask HN: Trust and remote work - qixxiq

We've recently started building a team of remote developers for our startup; but I'm having some trust issues and would like to hear how people have resolved similar situations.<p>We've been hiring to work on a new side project which I feel is going too slowly. The team I have working on the project are very good and I'm quite impressed with whats coming out but its just taking a little long. I could easily replicate the amount of work they are getting done in just a couple hours per day.<p>To be honest if they're just a little slower I'm alright with that -- my main concern is simply that they're not working as hard as they could be. I know it could be a motivation problem but I don't really have any clue how to solve that remotely? Maybe I just need to challenge them on their speed, but I feel that could end badly.
======
reduxredacted
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.

------
eengstrom
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
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
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. :-)

