How to Build and Run a Remote Engineering Team from Europe

You have picked a partner and an engagement model. If not, start with how to evaluate a nearshore partner in Europe and the three engagement models compared. This post covers what comes after the contract: the day-to-day mechanics of building and running a remote engineering team with engineers in Portugal, whether the rest of your company sits in Berlin or in Boston.

Remote teams rarely drift because the engineers are weak. They drift because the defaults were never written down: nobody decided when a message needs an answer, where a decision lives, what "done" means, or which hours belong to meetings. Each section below ends in something you can copy into your repository this week.

Do the Time-Zone Arithmetic First

Mainland Portugal (Lisbon, Porto) runs on UTC+0 in winter (WET) and UTC+1 in summer (WEST). Against the cities you are most likely to work with, Porto is:

• London: the same time, all year.
• Berlin, Paris, Madrid, Amsterdam, Warsaw: one hour behind, all year.
• Helsinki, Athens, Bucharest: two hours behind, all year.
• New York: five hours ahead for most of the year.
• Chicago, Denver, San Francisco: six, seven and eight hours ahead.

The European offsets never move, because the EU and the UK change their clocks at the same instant: 01:00 UTC on the last Sunday of March and the last Sunday of October. The US changes at 02:00 local time on the second Sunday of March and the first Sunday of November. Between those dates the transatlantic gap is one hour shorter. In 2027, Porto is four hours ahead of New York from 14 to 28 March and from 31 October to 7 November, and the other US offsets above shrink by an hour in the same weeks. Most of Arizona never changes its clocks, so Phoenix is seven hours behind Porto in winter and eight in summer.

Those weeks break recurring meetings. A calendar event is pinned to the time zone it was created in, so a meeting set up in New York for 11:00 (16:00 in Porto) shows up at 15:00 in Porto for those weeks. Decide which city's clock owns each recurring meeting, write it down, and remind the other side before each switch.

A Worked Example

Assume everyone works 09:00 to 18:00 local time, lunch included. The shared window runs from the later start to the earlier finish, once both are on one clock:

• Porto and New York: 09:00 in New York is 14:00 in Porto, and Porto stops at 18:00, so you share 14:00–18:00 Porto time (09:00–13:00 in New York). Four hours, five in the mismatch weeks.
• Porto and Chicago: three hours, four in the mismatch weeks.
• Porto and San Francisco: one hour, two in the mismatch weeks.
• Porto and Berlin: eight hours. Porto and Helsinki: seven.

Now subtract lunch. If New York eats at 12:00, that is 17:00 in Porto, and four hours become three usable ones. If the Porto engineers agree to work 11:00 to 20:00, the New York window grows to six hours and San Francisco gets three. That comes out of the engineers' evenings, so it belongs in the written agreement and gets reviewed, never assumed.

To check your own numbers for any date (Python 3.9 or later; on Windows, run pip install tzdata first):

from datetime import date, datetime, time, timedelta
from zoneinfo import ZoneInfo

def overlap_hours(day, a, b):
    """a and b are (timezone, start, end) working days on the same date."""
    def window(tz, start, end):
        zone = ZoneInfo(tz)
        return datetime.combine(day, start, zone), datetime.combine(day, end, zone)
    a_start, a_end = window(*a)
    b_start, b_end = window(*b)
    shared = min(a_end, b_end) - max(a_start, b_start)
    return max(shared / timedelta(hours=1), 0)

porto = ("Europe/Lisbon", time(9), time(18))
new_york = ("America/New_York", time(9), time(18))
for day in [date(2027, 1, 18), date(2027, 3, 22), date(2027, 7, 19)]:
    print(day, overlap_hours(day, porto, new_york))

It prints 4.0 for January, 5.0 for the March mismatch week and 4.0 for July.

Scheduling Into the Overlap

• Spend at most half of the overlap in scheduled meetings. Keep the rest for unblocking: pairing, a quick call on a stuck review.
• Put the overlap in both teams' calendars as a named block, so nobody books over it.
• Default everything else to async: status, code review, design proposals.
• A question asked after the overlap is answered the next morning, so every engineer keeps a second ticket ready.

Write the Working Agreement Down

The working agreement is a short file in the repository, WORKING_AGREEMENT.md, changed through pull requests like code. In a dedicated team with its own tech lead, the tech lead owns it; in a team extension, your engineering manager does. The values below are a starting point; what matters is that both sides agreed to them in writing.

• Core hours: the overlap, stated in both time zones (14:00–18:00 Porto, 09:00–13:00 New York), with the mismatch weeks noted.
• Chat: reply within one hour during core hours. Outside them, no reply is expected.
• Pull request review: first review within one working day of being marked ready.
• Urgent: the paging tool, never chat. If it is not worth a page, it is not urgent.
• Decisions: anything that changes an interface, a dependency or a data model gets a decision record in docs/adr/, reviewed as a pull request. A decision made in a call does not count until it is written there.
• Definition of done: merged, tests green in CI, released to production (behind a flag if needed), monitoring in place, runbook updated, ticket linked to the change.
• On-call: who is on the rotation, which hours each region covers, the escalation path, and how on-call time is compensated and rested, agreed in writing with your partner before the first shift.
• Holidays: one shared calendar with both countries' public holidays. Portugal's do not line up with US or German ones, and municipalities add their own: 13 June in Lisbon, 24 June in Porto.

A decision record does not need to be long:

docs/adr/0007-move-background-jobs-to-postgresql.md

Status:       accepted, 2027-02-03
Context:      what forces a decision now, in five lines or fewer
Options:      what was considered, one line each
Decision:     what we will do
Consequences: what gets easier, what gets harder, what we will watch
Review:       link to the pull request where this was discussed

Whoever missed the call, or joins next year, can read why.

If you want a second opinion before rolling this out, our free nearshore team assessment looks at exactly these pieces: your real overlap hours across the year, your draft working agreement, and where decisions are getting lost between time zones.

Run a Hiring Loop That Tests Remote Work

Your partner screens candidates first. You still run your own loop on the shortlist, and it should test the job as it will be done: in writing, across a time-zone gap, on code.

1. 1A work sample on realistic code. A small repository that looks like yours: a service with a failing test, a vague bug report and one small feature request. Time-box it at three hours, or pay for it if it needs more. Ask for a pull request with a description.
2. 2A pairing session on their own submission. Sixty to ninety minutes, remote, with your team's everyday tools. Extend the feature together or fix something raised in review. Watch how they reason aloud, take a suggestion and say "I don't know".
3. 3A written exchange. Leave one deliberate gap in the work-sample brief and see whether they ask before guessing, and how.

Assess the writing as seriously as the code:

• The conclusion comes first, the reasoning after.
• Assumptions are stated wherever the brief was ambiguous.
• The pull request description lets a reviewer in another time zone approve without a call: what changed, why, how it was tested, what is out of scope.
• Commit messages explain intent, not just the diff.

Skip algorithm puzzles and unpaid multi-day take-homes. Neither shows how someone works on your codebase, and the second filters out the senior engineers who have other options.

Onboard for a Merged Pull Request in Week One

Most onboarding work can be done before the engineer starts.

• Before day one: accounts, repository and CI access, chat, the issue tracker, read-only access to staging, the password manager, and a laptop that meets your device policy. One person owns that checklist and closes it before the start date.
• Day one: the engineer clones the repository, runs one documented command (make dev, a dev container, a compose file) and has the application running locally with seed data. Every step that fails is an onboarding bug, and fixing the docs is their first commit.
• A named buddy: one person, ideally with a full overlap, with time taken off their sprint load for the first two weeks. "Ask anyone" means asking no one.
• Week one: a merged pull request. Pick the issue before the start date: small, real, and touching the deploy path. The point is the loop: branch, test, CI, review, merge, deploy. How long that pull request waits for review is the first measurement of your own process.

Then a 30-60-90 plan with outcomes you can check:

• Day 30: has merged several pull requests in one area, reviewed someone else's, run a deploy, and shadowed an on-call shift if the role includes one.
• Day 60: has shipped a small feature from ticket to production, written or updated a decision record, and joined the review rotation.
• Day 90: is first reviewer for one component, presents their own work at the demo, and owns the onboarding doc for the next hire.

Keep Synchronous Only What Needs It

The overlap is your scarcest resource. Spend it on what goes badly in writing:

• Synchronous: weekly planning, retros, design discussions where people actually disagree, 1:1s, incident response, and pairing to unblock.
• Async: daily status (posted at the start of each person's day: done, next, blocked), code review, design proposals, and announcements.

Demos stay live, inside the overlap, presented by the engineers who built the thing. If only the in-house team ever demos, the remote team becomes invisible to the people who set priorities.

For retros, collect items in writing beforehand so the meeting goes on discussion. Alternate the facilitator between sites and turn every action into a ticket with an owner. An action that comes back three retros in a row is a signal on its own.

If a chat thread has gone back and forth three times without converging, move it to a call in the overlap and post the outcome in the thread.

Measure It and Watch for Drift

Take a baseline in the first month from systems you already have, and review it every few weeks. Compare the remote team with itself over time and with your in-house team on the same codebase, not with someone else's benchmark.

• Lead time: from first commit to running in production.
• Review turnaround: from pull request marked ready to first review, split by whether author and reviewer share a region. Time-zone friction shows here first.
• Onboarding time: days from start date to first merged pull request, and to first independent production change. It measures your onboarding, not the person.
• Retention: who has left, and how many components have only one person who has ever reviewed changes to them.

If you export pull request data from your Git host into PostgreSQL, the review numbers are one query:

SELECT
  date_trunc('week', ready_at) AS week,
  author_region = reviewer_region AS same_region,
  count(*) AS pull_requests,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY first_review_at - ready_at) AS median_to_first_review,
  percentile_cont(0.5) WITHIN GROUP (ORDER BY merged_at - ready_at) AS median_to_merge
FROM pull_requests
WHERE merged_at IS NOT NULL
GROUP BY 1, 2
ORDER BY 1, 2;

Drift shows up before missed deadlines do. Watch for:

• Cross-region review turnaround creeping up while same-region stays flat.
• Pull requests getting bigger, because people batch work when review is slow.
• Questions moving from team channels to private messages, or stopping altogether.
• Written status getting shorter and vaguer: "continuing on the ticket".
• Decisions made in calls with no decision record, discovered by the other side afterward.
• Remote engineers receiving tickets but never problems, and no longer presenting at demos.
• Messages sent at 21:00 Porto time becoming normal.

One of these is worth raising in the next 1:1. Several at once usually mean the working agreement has stopped being followed: revisit it together rather than adding a meeting.

Where to Start

Do the overlap arithmetic, write the agreement, and get the first pull request merged in week one. Everything else here builds on those three. If you are setting up a nearshore engineering team and want an outside view, our free assessment reviews your overlap and meeting schedule, your working agreement, your onboarding path from laptop to first merged pull request and your review-turnaround data, and tells you where the team is most likely to drift.