Managing a remote software development team is challenging. Managing an outsourced remote software development team with a 10-11 hour time difference is near impossible! Or at least that’s what I thought when I was tasked with making this happen several years ago. This article outlines some of the process-related challenges and solutions that I’ve dealt with over the years.


The obvious challenge here is the small time overlap that falls at the end of your development team’s day and the beginning of yours. Making the most efficient use of this time is critical to ensure the success of your team. In addition, you want to make sure your team has as much information as possible as any questions / issues can end up costing you a day or two in lead time to get the right answer back to the developer. We use a flavor of the Agile Methodology for all product development and apply those same principles in our geographically-disconnected team.

Preparation is Key

My main goal at the end of each day is to ensure that the following are true:

  • The team has a healthy queue of work to be picked up as tasks are completed.
  • The queue of work has been discussed with the senior members of the team to ensure understanding of the original requirement.
  • The queue items have sufficient detail on the solution that needs to be built.

Having these things in place sets the team up for success as they start their day while I’m sleeping.

Healthy Work Queue

Tasks in the queue to be worked should be ordered so that the higher priority items are worked first. Prioritization will prevent developers from cherry-picking the “cooler” items over the less exciting issues that need to be resolved. It also makes each member of the team more self-sufficient as they do not need to be tasked directly.

Daily Hand-Off

Our “Stand Up” meeting each morning is actually more like a hand-off between the remote team and the rest of the team based in the US. We use this time to perform the following tasks:

  • Resolve any questions and/or issues that have come up with items currently being worked
  • Discuss any new requirements that are being added to the queue to ensure understanding by the entire team
  • Agree on the solution to those requirements to ensure Development and QA are on the same page with what will be built
  • Quickly demo any in-process work to ensure the implementation meets the previously discussed solution
    • Provide feedback to the developer on anything that might need to be reworked

Our overlap time is valuable, so normal “Stand Up”-type status messages are included in a separate messaging channel (we use Slack) ahead of time so I can review these updates before the meeting. On most days, these text updates are sufficient and require no further discussion. Every day is different depending on what’s going on at the time so we need to be flexible to keep things running smoothly day-to-day.

Embrace Disagreements

Encourage your team to voice their opinion if they do not agree with your designed approach. This discussion is healthy and will ultimately ensure you end up with a more robust solution. Do not be afraid to admit when you’re wrong. Making mistakes is one of the key ways that we learn and help us to get better over time.

Be wary if you are not getting good feedback from the team. The lack of feedback may indicate that the team members are not properly analyzing the work before getting started. The best way to achieve success is to ensure that everybody feels some sort of ownership in product / process.

Tools are Invaluable

If you’re not using some sort of software to manage your work queues, you will need something in place to make this work. Individuals should be able to naturally pull work from a queue as they complete other items. This leaves you time to work with Product Management to ensure those queues have enough well-defined work to keep the team busy each day.

As with anything, your results may vary. We are frequently reviewing our processes and retooling them as necessary. You should too!

[kad_youtube url=”” ]

What Would You Say You Do Here?

If you’ve seen Office Space, I’m sure you remember the scene above. It sounds silly, right? The guy just receives customer specifications and takes them to the software developers. Where is the value in that part of the process??

Comedy Based in Reality

In the real world, I believe this guy is the most important person in the software development process. Jokes aside, the person(s) responsible for taking a customer requirement and crafting a solution to meet those needs must do a good job or the entire enhancement / feature risks being built “wrong”.

Solution Design Considerations

There are a few things to think about here as we design the solution:

  • Does the customer really know what they want? Have they done a good job in describing the need?
    If not, we need to go back to the customer and get any outstanding questions resolved first.
  • Do other customers that use the product have the same or a similar need? What about future customers?
    Engage your other customers to get their input. You may be able to solution multiple customer problems with a single feature!
  • Can we build a configurable feature that meets everyone’s needs and also allows for further enhancements in the future?
    Ensure you are thinking about the product as you design the solution. Do not let the customer dictate everything you build or else you may end up with a mess.
  • Have you considered that a customer may not want this new feature at all?
    When possible, make sure each feature can be disabled and allow the customer to decide if they want to enable it.
  • Are you open to collecting feedback from your customer base?
    Let each customer enable the feature in a test environment and get feedback so that you can evolve the new functionality organically.

Additional Reading

My good friend, Rese, has a nice post with additional solution design considerations when building SaaS software. Check it out!