I have a small company that produce commercial WordPress themes. Things are working well and I want to hire a freelance Front End Developer to help me. I never managed a remote person(the city I live in is too small, and I don't find local people).

I'm looking for answers to questions like:

  • How can you be sure they are working the hours they say?
  • How often should you talk to them?
  • 1
    This sounds like a question for workplace, not for project management. Could you identify the project management issues so that we can focus the answers? – Mark C. Wallace Jun 19 '15 at 11:10
  • 3
    Results-oriented metrics are your friend. – Todd A. Jacobs Jun 19 '15 at 15:22
  • Check XDSD, which is exactly about managing software developers remotely – yegor256 Sep 12 '15 at 9:07

Managing remote developers: There is sound advice here already, with respect to JIRA and frequent calls to stay in touch. Having managed distant development for the last two years here are a few extra suggestions on top of JIRA and Skype phonecalls:

  1. Be ready for remote development to take longer. Establish good communication lines, encourage the developer to contact you for feedback. Resolve standing issues asap.
  2. Have a draft of clear milestones and due dates (make sure to buffer your actual due dates)
  3. Clarify expectations repeatedly to ensure understanding, define terms you routinely use.
  4. Test deliverables promptly and thoroughly.
  5. Trust your instinct. Remote development is risky because you don't get to sense most of the clues you would notice if you were in the same place as the developer and were experiencing their frustrations first hand. By the time your remote developer articulates frustration, you have probably lost days already. Be on the lookout for signs of weariness, and disengagement. Follow hunches of the subtlest kind. They are your friends.
  6. Do not ever let your developer immerse into solving a problem without setting a time limit which you are happy to lose. Time limit should allow for elaboration, but not for a wild goose chase. Problems get rarely solved.
  7. Do not fall for sunk cost fallacy. Adjust requirements/expectations, or abort development if you see schedule sliding on a critical milestone.
  8. Review code & documentation you receive. If you are not a programmer, have the first deliverables checked for quality by someone qualified you trust.
| improve this answer | |
  1. You can measure results. You can't measure hours in front of screen (and probably shouldn't).
  2. You need to agree on a goal and a deadline.
  3. Given step 2., you need to talk each time the current goal is accomplished, so you can evaluate it, and agree on a new goal and a new deadline.
  4. You need a way (e.g. email) for the remote worker to let you know if the deadline won't be reached because of a particular problem. Then you decide if you need to have an extra talk to set a new deadline or to look for ways of increasing speed/productivity (e.g. proper training).

Depending on the profile of the remote worker:

  • For inexperienced people, start with daily goals (this helps to keep each goal simple and easy to agree on)
  • When someone has demonstrated performance over time, decrease the frequency of the communication (e.g. daily report of advance and weekly chats)

That said, the same could be applicable to on-site workers (set clear goals, frequent report of advances/problems, evaluate performance based on resuls).

| improve this answer | |

Managing remote/near-shore/off-shore development teams can certainly be a daunting prospect, especially if you haven't worked with them before and have yet to build up any trust/rapport.

How can you be sure they are working the hours they say?

This all boils to down to the agreement you have with your development team. Are you paying them on a hourly basis, or are they working for a fixed fee?

Time sheets are a valuable resource for a PM, however, you seem to want to use them as a timecard to ensure they are working 8 hour days, rather than tracking the numbers of hours that have gone into a specific feature/project.

There are numerous time tracking solutions out there, but it's important to find one that works for you. This can be anything from a simple spreadsheet to a more interactive tool such as Harvest or Toggl, depending on your requirements.

How often should you speak to them?

As often as needed. Depending on how you are running your team, you may carry out a 15 minute stand-up in the morning via Skype. If this is too much, you might fall back to a weekly Skype session that Maksim mentioned in his/her answer.

You might also want to look into nonintrusive instant messaging services such as Google Chat or Slack, as these can be excellent for non-urgent questions/problems.

| improve this answer | |

Transparency is key.

I've been working with remote teams for the last few years, and I have had the most success when you have an easily visible measure of progress.

It's essential to have small pieces of work that are clearly done / not done. We use scrum and Jira, but the process and tools are less important that what they display.

By breaking things into tasks that are estimated at smaller than 1/2 a day, you can see progress on a daily basis. It sounds like you are technical, so I would split up and estimate the tasks together with the developer, and make sure you've agreed on the estimates. Some tasks take a lot longer or shorter than anticipated, but that is a talking point for when you next catch up - there should be a reason as to why this was, whether it was technical, personal, or work-related distractions. With the right tools in place you don't necessarily need to talk daily, as you can see progress from looking at the task board and know where you stand. I'd suggest a daily call to start with that is only 5 minutes, but you will quickly work out what feels right for you.

| improve this answer | |

My experience of managing remote developers says that time reporting is necessary. Not for arguing over "why it took so long", but rather for the sake of discipline. So I ask to fill in time spent on items in Jira (or, before Jira it was toggl). I believe 1 hour "grid" is OK. At least 1 weekly Skype call (in the beginning probably daily). Be present at the project, clarify issues before they appear.

Overall, you can't be 100% sure if developers are working the hours they say (and this is probably not that important at all), but you can make the process quite transparent and see if overall the pace of development satisfies you or not.

| improve this answer | |

Most important (and often overlooked), in my own experience, is getting to know the person you're working with.

I've worked on many long and complex projects with developers in other countries/time-zones, many of whom speak other languages natively.

Every one of these people needed to be treated a little differently for optimal productivity. I guess that ultimately, that's the 'art' to project management. Knowing how much to push on certain things, with certain people, at certain times.

The key, as always, is good, clear communication.

Expect there to be noise in the transmission, and simplify until the message cannot be misunderstood. What is obvious to you WILL NOT be obvious to them (especially if they are not native English speakers). This is where the problems arise 100% of the time...

Most importantly: Always question your assumptions and the clarity in the instructions you give. Make sure your messages and instructions CANNOT possibly be misunderstood. Then, simplify it more (or make what you want and need even more explicit).

Best advice, as a bullet list:

  • Don't be overbearing, give your devs time work through issues
  • Set VERY clear and easily understandable milestones
    • And give yourself some buffer, especially at first
    • I.e. -- with someone new, I will tell them that something is due a day or two before it really is.
    • But do this within reason. Ultimately, you are responsible for WHEN and HOW things are delivered. And rushing anything will more often create more problems than it fixes. So, as is often the case in management of any sort, it's all about balance. Understanding this balance and using it effectively is what makes a manager great.
  • Break tasks up as much as possible, and give the most precise and concise instructions on each
    • The more time you spend outlining EXACTLY what you are expecting (and WHEN it's due, and HOW it will be made), the less you will be surprised with what is delivered
    • The difficult part of this is leaving enough room for your dev to solve the problem in the best way possible, creatively - they're deep into a problem that for you is sometimes just an abstract note in a long list of such idealized features. By the very nature of this circumstance, your dev will often have a better solution than was originally envisioned. (And they always will if they're really good.) Encourage them to share it when they have an 'a-ha' moment. And have the courage to sell the new idea up the chain. Especially if it'll save you all time, and money.
  • Make sure you know what progress is made each day, and on WHAT specifically
    • But remember that, when it comes to 'checking in', less is more.
    • I always think: Whenever the dev is talking to me, they're not working on the project.
  • I've had lots of success with letting developers manage the task lists themselves. There are lots of tools and methodologies and software systems for this. And ultimately you need to find co-workers you can trust to keep working effectively WITHOUT constant supervision.
    • It doesn't matter how you do it, but make sure that you are always able to get a snapshot of what is being worked on WHEN, and what the status of EACH individual item is.
    • If you can get status of every item (or the important ones) without interrupting your developer's workflow, it's in everyone's best interest.
    • In this regard, As SpoonerNZ said, transparency is key.
    • I like to setup the system and tasks, and deadlines, then let the devs figure out the best order in which to complete, however is most natural/conducive to getting the work done most efficiently.
      • I don't want to check on them constantly any more than they want me IMing or Skyping them all the time.
      • Eventually they learn that I'll bother them less when they actively engage and keep the tracking and notes on each item up to date. When they don't, I have to message them via whatever tool we're using and add notes so I can keep myself and everyone else up to date. And if I have to keep messaging someone nonstop to make sure they're working -- usually that means it won't work long term. There needs to be mutual trust.

Getting long now, so I'll end here.

But good luck, and remember: Every time you manage a new person there's going to be some trial and error. Like any relationship, it's all about understanding each other and figuring out the best way to work TOGETHER.

| improve this answer | |

Its more with Trust Factor. For first couple of weeks you just need to monitor them and try to judge there skills and efforts by asking right questions and see how they are approaching.

Then you can delegate delivery responsibility to one of the good member from that remote team who will keep eye on deliverables and then you only have to monitor that particular member by giving proper direction.

Don't do micromanaging no developer likes this.

Hope this will help you

| improve this answer | |

This is a typical situation and there's a lot of cities like yours, where it's really hard to find a particular IT specialist. Answering your questions:

  1. For time tracking, you can use software like Redmine. This way, your remote employee would have to track the time and progress of each task. Of course, there's no real guarantee the tracked time was really worked. This is why it's really important to hire the right person. For example, you can consider using services of an offshore software development company like Mobilunity. They would find and hire the right person and they would also provide the management and make sure everything goes as planned. As the services provider actually hires an employee for your purposes, they would have to worry about the efficiency and make sure this employee was really working all those hours.
  2. This one is a bit tricky. Honestly, it depends. I guess it's okay to communicate every day just to make sure nothing is missing out. On the other hand, you could get in touch only when you really have something to say or some part of a project is to be discussed. There's no right answer here. There's no such thing as 'too much communication', but if you are constantly calling or sending messages, it may actually bring a lot of destruction and even miscommunication.

This is why it's a good practice to use the services of a dedicated development teams provider. Here you can see the benefits of using such a model at https://mobilunity.com/blog/hire-dedicated-developers-10-reasons. This will not only provide you with the needed employee but will help you to gain peace of mind.

| improve this answer | |
  • Hi Anastasia, welcome to PMSE! As your answer stands, it's being considered self-promotion by the community and because of it, tagged for deletion. Could you please rephrase it to be less self-promotional and more question > answer oriented? Further guidelines on meta.stackexchange.com/questions/57497/… – Tiago Cardoso Apr 7 '18 at 20:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.