How to manage remote developers?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

The answers here are good in that they emphasize transparency, setting expectations, testing deliverables, anticipating disengagement, problem anticipation, and tooling. However, I think integrating such strategies is also important.

For instance, a transparent time tracking system can double as a means of communication while making sure they are working the hours they say, but not invading their privacy. You should never have to ask "how's it going", but instead you can say more meaningful things in reaction to their work reports. Create a system where the communication mechanism IS the time tracking mechanism. Talking to them at least over chat, at least a couple times a week, is a good idea.

• Time tracking softwares like Hubstaff are invasive in that they take screenshots, but fixed price agreements are exploitive, so you might want to try something that integrates the communication with time logging. Slack work sessions are one idea (based on the pomodoro technique for productivity). Essentially, developers log what they work on which is subject to engineering manager approval:

• Reward productivity by approving their work frequently, especially if they include a quality git commit in the work sessions they log.
• Set standards for good work sessions like that they have to have a git commit or a visual application or testable feature update.
• You can keep projects on budget and “effectively fixed price” by asking developers to get granular about their estimates when interviewing them. They should break down projects into “minimum possible subtasks” which is the smallest unit possible (without actually doing it). Then, they should engage in “task visualization” where they visualize what they would need to do to complete the minimal subtasks to give a rough estimate.
• Make sure you are using all the best practices which themselves create a layer of quality assurance: DevOps, Continuous Integration, linters, unit tests, end2end tests, package management, logging, a dev testing environment, a protected prod server, and organized peer code reviews on github.
• Engage them in the design process so they feel motivated, and ask them to be able to explain why they are doing what they are doing.
• Use feedback sandwiches which as cheesy as they may sound, do a good job of recognizing genuinely what they do well before offering constructive criticism.
• Show that you care about their code and give quality peer reviews. This also shows that you care about their growth.
• Include your brand in your communication to them - send them swag, make them feel part of the team.
• Care for their mental health - give them tips and such to keep themselves healthy and productive.

I run a team of 5 remote developers and these are the tactics I use daily. Each manager may have different opinions about these techniques but I hope these techniques can be useful to you as you navigate the remote developer management process.

Answer 5

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 down to the agreement you have with your development team. Are you paying them on an hourly basis, or are they working for a fixed fee?

Timesheets 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, Toggl, Timely 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.

Answer 6

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.

Answer 7

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.

Answer 8

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

Answer 9

The pandemic has increased the popularity of remote working over one year. Flexible working schedules and saving conveyance to the office have made remote work a comfortable space with added perks. Companies building remote developer teams are experiencing greater benefits rather than sticking to in-house developers.

So how can companies manage their offshore remote developers’ teams?

When the remote team grows and with more members, the management needs to follow new strategies and adapt to these changes. Here are some essential tips you can invest for managing remote developers:

Becoming structured and organized The company needs to prepare a proper work structure and proving your employees with their specified tasks and responsibilities. Even more so, everyone should be clarified with who they need to communicate with if facing a problem. Reduce micromanaging and focus on divided leadership.

Utilizing new tools Every tool that is available in your company is reliable for your remote team to manage if they are a small team. It is important to keep a check on what your remote team lacks and provide simplified solutions for the deficit. Opting for better tools that are available for all remote developers can solve the problem. You can properly do your research, take advice from experts, and then implement the right tools.

Prevention of burnout Be aware of your team’s workload. Finding the specifications that are challenging at managing the work, it is easier and cleared to understand the shortages in time or the availability of equipment. Have a discussion with your team members about the challenges they’re facing and get to the actual reason behind the workload. If required, hire more people and never hesitate to hire new people in the process. If the current team is not well-equipped then you can rehire and organize proper team training programs.

As we know, remote working will stay for the next few years and companies are opening up their minds in adopting this method of a smooth and seamless workflow. With a remote team of developers, it is easier to clear projects faster with a better development rate.

Answer 10

Very, very simple ... "hire them!"

(Think COVID-19 ...) "Work from home" is commonplace now, of course to the utter consternation of the vendors of "Class-A Office Space" and "Cubicles." (Which, as you might not have known, were actually rented.)

Source-code management (in a software project) is handled through private repositories in public sites like "GitHub," while conferencing is handled through Zoom or Microsoft® Teams.

"Out of Sight '≠' Out of Mind!"

Even though these employees are not physically "in your workspace," they are still your employees. Problem solved.