Patrick Ward 
One of the most common questions people ask me when they become interested in working with a remote app development team is: “how do I know they’re working?”
The inconvenient truth is: you don’t. And that’s a good thing.
I don’t mean to say that you should pay for work and not worry about getting a result. What I mean is this: when you’re engaging a vendor for outsourced work, billable hours should be secondary to the deliverables and milestones you agreed on.
My best advice: measure by week, not by hour
If you only take one piece of advice from this article, it should be this: weekly pricing gets better results than hourly pricing.
Weekly pricing is best for productivity for a few reasons, the main one being that it plays neatly into agile development sprints, which are a best-practice for iterative app development.
It’s also good because it enforces KPI-based measurement over “butts in seats” measurement, which ultimately drives more business outcomes.
Additionally:
- Hourly pricing incentivizes extra work to increase billing. Weekly pricing prioritizes pre-defined deliverables and makes it obvious if things are going off-track.
- Hourly pricing invites scope-creep by making it easy to add “nice to have” features. Weekly pricing makes it difficult to stray from the plan before you get user feedback.
To be more specific, when I’m working between our nearshore developers and a client, we always rank components on a Fibonacci scale. Then, we can allocate time with our developers based on the estimate and value-add of the tasks.
Remote development has pros and cons, but the big pro of focusing on tasks over time is that it forces you to avoid scope creep and focus on the key deliverables that drive ROI quickly.
Focusing on weekly deliverables over hourly “time spend” forces you to start by thinking: “what is important to finish and ship first?”
This is why billing by week is best, because it focuses on outcomes and shipping, vs “punching the clock” and getting 40 hours per week.
Pros and Cons of a Remote App Development Team
Pros
- Focus on deliverables over "time in the seat."
- Low paperwork: at small scale, the compliance needs for contractors are low.
- Cut-and-dry agreement on project scope and timeline. Employees are distracted by other projects and internal politics, whereas a remote shop has to deliver on time to keep the contract.
Cons
- Developers may be working with multiple clients throughout the week. (It’s important to ask about this when vetting a vendor. Make sure you get an agreement on dedicated resources if possible.)
- Legal exposure: some countries have stricter laws about contractors, and you could run into issues if the country views you as a full-time employer rather than client for the contractor.
- Lack of institutional knowledge. Training put into remote developers won't stay with your company, and they start with low context on the project.
Time Tracking Recommendations When Working With Remote App Developers
I’ll preach about deliverable-based work until the cows come home, but I’m no stranger to hourly time tracking. As discussed, time isn’t the thing to focus on. But still, you need to track time to some degree.
Harvest is an example of a tool that balances the paperwork with the value well. I’ve also used Toggl, HubStaff, and multiple others. The tool you use doesn’t matter much, so long as it is low-effort to use and produces low-effort reporting you can use with your manager or client.
This is generally more helpful in consulting or one-off arrangements where the project is poorly defined and hourly tracking is needed to keep maximum flexibility. Hopefully, you’re not in this position when doing app development work. But it’s certainly useful if you need to be able to charge a client at the end of a short engagement for a collection of hourly tasks.
Again, if you’re working on an engineering project with a remote team, you really should be using a proper sprint framework with a product roadmap, planned iterative testing, and a laser-focus on the minimum features needed to ship version one. If you need hourly tracking for billing, you probably should be working with an in-house team that won’t be rewarded for dragging out an ill-defined process.
Weekly time tracking in the form of “effort points” and other agile measurement systems is best because it helps the client to build a sense of how much is feasible in a time period, and calibrate their followup requests accordingly.
Honestly, the best place for time tracking might be at the individual contributor level, or internally at the dev shop. Hourly time tracking can be powerful when used privately to enhance your productivity, but almost always becomes counterproductive when imposed by a client or boss.
Value Measurement: How to Measure the ROI of Your Remote Team
The best way to measure the ROI of your remote development team is to define clear success metrics. Usually, that means focusing on a product that’s good enough to start testing and iterating on, rather than a product that’s “perfect” or “looks pretty.”
This is particularly important because there’s a bit of a “yes man” culture with some agencies, and it’s easy to get sucked into scope creep since it enables the vendor to charge more. At the end of the day, it doesn’t matter for a remote shop if your product is successful. In some ways, it can be better for them if you change your mind several times or have arguing stakeholders, because it allows them to charge extra for the “nice to have” features that pile up without a clear roadmap.
I strongly recommend that you measure the ROI of a remote team based on how closely their deliverables match those defined in your product roadmap. Then, make sure they understand you’ll only be staying with them long term so long as you’re able to quickly and iteratively test your product on a weekly basis.
In summary: the ROI of your product is separate from the ROI of your remote development team. The only way to align incentives is to stick to an iterative production cycle that holds them accountable for the performance of the product, not just how friendly they are to an account manager.
How to Avoid Communication Issues With a Remote Development Team
At the risk of beating a dead horse, the roadmap is where you get ahead of communication issues with a remote development team. If a project breaks down mid-way, assuming you’ve vetted the shop well, it’s almost always caused by a bad product roadmap. And this problem can’t be fixed cheaply.
While the roadmap isn’t an iron-clad document, it’s still highly important for keeping all parties agreed on what’s important to focus on each day. If and when a feature gets added, this process forces you to do one of the following up front:
- Spend more money to add features to the project.
- Bump an existing roadmap item off the board to make room for the new feature.
No one wants an unexpected $150,000 incremental fee on top of a project, and that’s what happens if you let scope creep enter a project, regardless of whether it’s with a remote or in-house development team.
Thankfully, most well-regarded remote development vendors are well aware of these issues and will work to help you get ahead of them. After all, when a project breaks down, it’s usually the vendor who takes the blame and bad review, not the client.
The Hidden Cost of Micromanagement
I understand that people like real-time time tracking and granular data about how their teams are working. It’s only human to want to know what people you’re paying are doing.
The thing is, even in-office, you rarely know what people are really up to hour-by-hour. Sure, you can see them in their seat — but unless you spend days of your life pouring over screen recordings of their laptop, you’re not going to know how much time they spent in the codebase rather than on Facebook. Even if you block social media in-office, you can’t stop people from zoning out or hanging around the water cooler.
Trust is the key, and many studies have shown that trust between workers and managers builds better results than hierarchical surveillance-based teams.
While decades of research on the topic of employe motivation point to structure and supervision being positive, overly-supervised or “babying” staff is shown to have the opposite effect.
The cost of lost trust isn’t small. One study estimates as much as $400 Billion lost in the US economy each year due to “non work” distractions related to micromanagement.
The only way around this is to focus on building trust instead of building surveillance systems. And the key to trust is specific, attainable, and measurable business deliverables.
Recap: Specific Deliverables, Clear Business Goals, Strong Roadmap
To summarize, there are three things you absolutely need to track when working with a remote development team, and none of them involve the email response time or hourly time spend of individual developers on your team:
- Specific deliverables measured weekly, instead of meticulous time tracking measured hourly.
- Clear business goals instead of unattainable “great products.”
- Strong roadmaps with no room for scope creep.
