How to Manage Remote Developers: Time, Velocity and Days Off

Four simple things to get right so you know what your remote team is doing, how fast it moves, who is available and when you can talk.

# Quick answer

To manage remote developers well, you need to get four things right:

1. What they worked on. Either track hours with a short log of tasks, or skip hour tracking and ask for a short report at the end of each day.
2. How fast they deliver. Measure velocity - either stick to storypoints in Jira so you can see burndown charts by the end of the sprint or measure typical amount of tasks that dev sort out during the sprint.
3. Who is available. Record vacations and sick leave in your CRM, so sprint planning reflects who will actually be working.
4. When you can talk. Agree on a 3–4 hour overlap each day for news, new tasks and questions. Everything else happens asynchronously.

None of this takes much of a manager's time, and it removes most of the guesswork of working with a remote team.

# 1. Measuring time: track hours or not?

Time tracking always comes down to micromanagement. The question is how much control you need and how much your developers will put up with.

# If you track time: tasks and hours

Hours on their own tell you nothing. "8 hours" could mean a finished feature or a day stuck on a bug. Ask developers to note the task next to every block of time.

Jira, Toggl, Harvest or Clockify all work. Choose the tool that links time to a ticket, so you can later compare estimates with actual hours.

# If you don't track time: a daily report

Ask for a short report by the end of each working day. Keep it to a list of task → status. It should take under five minutes to write.

Daily report – Oct 14

PROJ-212  Stripe webhook handling      ✅ Done, in review
PROJ-218  Slow orders report           ✅ Done, deployed to staging
PROJ-221  Invoice PDF redesign         🔄 In progress (~60%)
PROJ-224  CSV export for admins        ⛔ Blocked: waiting for field list from client

Tomorrow: finish PROJ-221, start PROJ-224 if unblocked

A Slack channel, a Jira comment or an email is enough. What matters is that it arrives every day and that someone reads it. Blockers are the most useful line in the report, so act on them.

💡 Rule of thumb: track hours when you pay by the hour or bill a client by the hour. Otherwise, a daily report gives you about 90% of the visibility with much less friction.

# 2. Development velocity

Hours and reports tell you what developers are doing. Velocity tells you how much gets done.

# Measure velocity in story points

In Jira, estimate tasks in story points and look at how many points the team completes each sprint. Jira's Velocity Chart (in Scrum boards, under Reports) shows this automatically.

After 3–4 sprints, velocity usually settles. That number is your baseline for planning: if the team averages ~33 points, don't plan 50.

# AI has changed velocity, but not on every task

Since AI coding tools went mainstream, some tasks have become much faster and others have barely changed. Old estimates and "industry averages" no longer hold, so you need to measure your own team.

# How to set your baseline

1. Start with a trial period. Work with the developer for a few sprints before you draw conclusions.
2. Pick typical tasks. Choose the kind of work your project does most often: a new API endpoint, a new admin screen, a bug fix.
3. Record story points for each one. Later you can pick your "golden stories" per amount of SP.
4. Compare by task type, not just in total. A developer who uses AI well may finish CRUD work twice as fast and complex logic at the usual pace. Both numbers are useful.
5. Review every few sprints. As tools and the team improve, the baseline changes.

# Watch out for

• Point inflation. If velocity keeps rising but the product doesn't move faster, the estimates are growing. Compare against finished features, not just points.
• Speed at the expense of quality. AI-generated code still needs lots review. Track bugs and reopened tickets alongside velocity.
• Comparing developers by points. Story points are relative to each team. Use them to plan, not to rank people.

# 3. Track vacations and sick leave in your CRM

With a remote team, you won't notice that someone is away just by walking past their desk. Every day off should be in one place, and your CRM is the natural place for it.

# What to record

# Why it matters

• Sprint planning reflects real capacity. If one of four developers is on vacation for a week, plan about 25% fewer points for that sprint.
• No surprises before a release. You can see who is away well before a deadline.
• Clients and stakeholders get honest timelines.
• Patterns become visible. Frequent sick days can be a sign of burnout, not just bad luck.

# Simple rules that work

• Vacation requests at least 2 weeks in advance, longer for anything over a week.
• Sick leave reported in the morning, before the daily stand-up.
• Local public holidays added at the start of the year, for every country your team works from.
• A handover note before any vacation longer than two days.
• Everyone can see the calendar. Most CRMs and HR tools (HubSpot, Bitrix24, Zoho, BambooHR, Personio) support a shared calendar or a Jira/Google Calendar integration.

# 4. Time zones: a 3–4 hour overlap is enough

You don't need a full working day in common with your team. 3–4 hours of overlap a day is enough to talk through news, hand out tasks and answer questions. The rest of the day is for focused work, and developers get more done when they aren't in calls.

# What the overlap is for

# Example schedules

# Rules that make it work

• Fix the overlap window and put it in everyone's calendar. Stand-ups and calls happen only inside it.
• Write tasks so they can be done without you. Clear acceptance criteria, links, screenshots. If a developer has to wait 6 hours for an answer, the task wasn't ready.
• End-of-day report before the overlap ends (see section 1), so blockers come up while you can still answer.
• Agree on response times. For example: within 1 hour during the overlap, by the next overlap otherwise.
• Prefer written and recorded updates outside the overlap: Slack threads, Jira comments, short Loom videos.
• Watch the clock changes. The US and Europe switch to and from daylight saving time on different dates, so for 2–3 weeks in March and in October/November the overlap moves by an hour. Check your meeting times then.

# Checklist for managing remote developers

• Decide: hourly tracking with task notes, or a daily end-of-day report
• Estimate tasks in story points in Jira
• Run a trial period and set a velocity baseline on typical tasks
• Review velocity by task type, taking AI-assisted work into account
• Track bugs and reopened tickets alongside velocity
• Record vacations, sick leave and holidays in your CRM
• Plan each sprint's capacity after checking days off
• Agree on a 3–4 hour daily overlap and keep meetings inside it
• Write tasks clearly enough to be done asynchronously