How to set goals for remote engineers

Set goals for remote engineers as written, time-boxed commitments tied to shipped artifacts, not activity. The minimum useful baseline for every engineer on a distributed team is "ship one production-visible change per week." Layer commit-based quarterly goals (3 to 5 written commitments per engineer, reviewed every 13 weeks) on top of that. Skip OKRs unless you already have 20+ engineers.

That is the short version. The long version is below, with sample goal sets for a junior on an auth feature, a senior on an observability migration, and a lead shaping a team. We also cover the two biases that make most remote goal-setting useless: under-ambition for engineers you don't see, and over-ambition for senior engineers you trust too much.

The default failure mode

Most remote teams either set no goals or set OKRs they copied from a Google doc in 2018. Both fail for different reasons.

No goals at all means the engineer optimizes for whatever feedback loop is loudest. On a remote team, that loop is usually Slack. So the engineer becomes a fast Slack responder who ships nothing. You feel productive in the meeting; the codebase doesn't move.

OKRs without infrastructure fail differently. The Objective is aspirational ("delight our power users"), the Key Results are made up at the start of the quarter and forgotten by week 4, and the quarterly grading meeting becomes a fiction-writing exercise. We have watched this pattern at three Series-A companies in the last 18 months.

The fix is not a better template. The fix is to pick the simplest goal format that survives a quarter, then stop changing it.

Goal format comparison: OKRs vs SMART vs commit-based

There are three formats founders actually use. Each is right for a specific team size and trust level.

Format	Best for	Cycle	Strength	Weakness
OKRs	20+ eng teams, multiple squads	Quarterly	Forces top-down alignment across functions	Heavy ceremony; needs a dedicated chief of staff to run well
SMART	Individual contributor goals, performance reviews	Annual or biannual	Crisp, measurable, easy to grade	Slow feedback loop; goals go stale by month 3
Commit-based	2 to 20 eng teams, founder-led	Quarterly (13 weeks)	3 to 5 written promises per engineer; reviewable in 20 minutes	Less alignment across squads; needs the founder to triangulate

For most teams reading this, the answer is commit-based goals with a "ship to prod weekly" baseline on top. We will spend the rest of the post on that combination.

The "ship to prod weekly" baseline

Before any quarterly goal, every engineer on the team owes you one production-visible change per week. Not a PR, not a merge to main, not a feature flag flip. A change a user could in principle notice if they were watching.

This baseline does three things at once. It surfaces blockers within 5 working days instead of 5 weeks. It forces real scope decomposition (an engineer who can't ship weekly is being asked to do work that wasn't broken down). And it gives you a leading indicator: an engineer who misses two weeks in a row almost always has a structural problem (broken local env, undocumented system, scope they don't understand, a sick week they didn't flag).

A few mechanics that make the baseline survive contact with reality.

• Definition of "shipped": merged to main and reachable from the production URL. Behind a flag counts if the flag is on for the team. A feature in staging does not count.
• The weekly artifact: a short Friday status note (3 sentences plus the URL or commit link). Loom is fine. A Notion page is fine. An automated GitHub digest is fine.
• Misses are surfaced, not punished: if someone misses, the question is "what got in the way," not "why did you fail." The data point is the pattern across 4 weeks, not the single miss.

The "async standup template" pattern we recommend works well as the carrier signal for the weekly artifact: each engineer's Friday post is the same channel as the Monday-through-Thursday updates, so the review loop costs zero extra meetings.

Commit-based quarterly goals

On top of the weekly baseline, each engineer writes 3 to 5 quarterly commitments. The format is intentionally boring.

By end of Q2 (June 27), I will:
1. Ship a working passkeys flow on web and iOS, behind a feature flag.
2. Cut p95 sign-in latency from 1.4s to under 600ms.
3. Reduce auth-related support tickets by 40% from the Q1 baseline of 82/month.
4. Land one architectural RFC for the planned device-trust system.

Notice what is missing. No "stretch goals." No "aspirational." No 0.6 vs 0.7 grading. Either you shipped passkeys behind a flag or you did not. Either p95 is under 600ms or it is not.

Three rules make the format honest.

Rule 1: written only. If the goal exists only in a 1-on-1 conversation, it does not exist. Every engineer's goals live in a single Notion or Linear document that the engineer owns and edits. The founder or manager can comment but cannot rewrite. We have seen the version where the manager edits the goals: it kills ownership in one quarter.

Rule 2: signed at the start, reviewed at the end. Both engineer and manager add a comment like "I commit to these as of April 1" at the start. At the end of the quarter, both add a comment grading each commitment hit / missed / partial. No essay. The grades are the conversation prompt for the quarterly review.

Rule 3: 3 to 5 items, never more. The engineer who writes 12 commitments is telling you they don't know what matters. Send the doc back and ask them to cut.

The Linear team famously runs a version of this with a "project doc" per quarter. Stripe runs an internal variant. Both work because the artifact is short, owned by the engineer, and graded in writing.

The two biases that wreck remote goal-setting

Every remote manager we have advised falls into one of two opposite traps. Sometimes both, on different reports, in the same week.

Bias 1: under-ambitious for unknown reports

The engineer who joined three weeks ago, ships fine but you don't have a read on yet, gets a "safe" goal set: keep doing what you are doing, ship at the current pace, don't break anything. This is the engineer who has the most upside from being stretched. The cost of getting their goals wrong is one quarter. The cost of leaving them on autopilot for a year is a stalled team and a quiet quitter.

The fix is to deliberately set one ambitious goal per engineer you have less than 6 months of context on. Pick the one commitment you would be most impressed if they hit. If they hit it, you learn they have a higher ceiling than you thought. If they miss it but ship a serious attempt, you learn what got in the way.

Bias 2: over-ambitious for high-trust seniors

The senior engineer who has been with you 2 years and ships consistently gets the impossible quarterly load because you know they will figure it out. Then they burn out, miss their goals by 30%, feel like they failed, and start looking at job listings.

The fix is symmetric. For the engineer you trust most, look at their goal set and ask: would I be okay if they hit only the first 3 items? If the answer is no, the load is wrong. Cut a commitment. Most senior engineers will fill the slack with quiet excellence that does not need a goal attached.

Sample goal sets

The right shape of a goal set depends on tier and scope. Three real examples follow.

Junior engineer on an auth feature (13-week quarter)

A junior in the $500 per week tier is being asked to ship a contained feature, with mid or senior review. The goals reflect that.

By end of Q2:
1. Ship email + password sign-up flow to production, behind a feature flag.
2. Land 80% line coverage on the auth module (currently 12%).
3. Write the onboarding doc for the next engineer to extend auth.
4. Pair with a senior engineer on the rate-limit design RFC.

Notice all 4 items are observable. The senior pair is concrete (one RFC, named). The doc has an owner (the junior; the next engineer is the reader). This is the tier where commitments must be small enough that the engineer can write a credible plan in a 1-hour offsite.

Senior engineer on an observability migration (13-week quarter)

A senior in the $1,500 per week tier owns scope. The goals reflect that.

By end of Q2:
1. Migrate logs from Loki to Datadog with zero data loss across the cutover.
2. Cut median MTTR for SEV-2 incidents from 47 minutes to under 25 minutes.
3. Land one RFC on the long-term metrics strategy (Datadog vs Grafana Cloud).
4. Onboard one mid engineer onto the on-call rotation.
5. Ship the alert-fatigue audit and reduce noisy alerts by 50%.

The pattern is: one project (logs), one quality metric (MTTR), one strategic deliverable (RFC), one people goal (onboard a mid), one cleanup (alert audit). Five items, all observable. The MTTR target is concrete; the alert reduction is concrete.

Lead engineer on team shape (13-week quarter)

A lead in the $2,000 per week tier is the architect or fractional CTO. Their goals look almost nothing like an IC's.

By end of Q2:
1. Hire 2 engineers (one mid, one senior) to the backend pod.
2. Land the service-decomposition RFC; get sign-off from the founder.
3. Reduce backend deploy lead time from 38 minutes to under 12.
4. Run weekly architecture reviews; build a backlog of the next 6 RFCs.

The lead's goals look like a CTO's because they are. The hiring goal is concrete. The deploy time is concrete. The RFC backlog is observable. If you are using "Cadence to book a lead engineer" for a 13-week scope, this is the shape of commitment you should write into the booking spec.

The quarterly review cadence

A quarterly review of these commitments takes 45 minutes per engineer if the artifact is honest and 4 hours if it isn't.

Here is the cadence that works.

• Week 1 of the quarter: engineer drafts goals, manager comments within 48 hours, both sign in writing.
• Week 6 (mid-quarter): 30-minute checkpoint. Are any goals already off-track? What changed? Is the load right? No grading yet.
• Week 13 (end of quarter): engineer grades each commitment in the doc (hit / missed / partial) before the review meeting. Meeting is 45 minutes: 15 on the grades, 15 on what was learned, 15 on next-quarter shape.
• Week 14: next quarter's goals get drafted while context is fresh.

The mid-quarter check is the highest-leverage 30 minutes you will spend. It is the moment to re-scope a goal that became unrealistic, not the end-of-quarter excuse session.

What to do this week

If you are not currently doing any of this, the order of operations is:

1. Tell the team you are introducing a weekly ship cadence. Start this Friday. Three sentences plus a URL.
2. Block 90 minutes next week for each engineer to draft 3 to 5 quarterly commitments in writing.
3. Comment on their drafts within 48 hours. Don't rewrite them.
4. Put a calendar block for a mid-quarter checkpoint and an end-of-quarter review.

That is it. There is no tool to buy. Notion or Linear is fine. Loom for the Friday update is fine. The whole system runs on writing things down.

If you are hiring remote engineers right now and want them to land into a working goal system from week one, the Cadence flow is built for this: every engineer on Cadence is AI-native by default (Cursor / Claude / Copilot fluency vetted in a voice interview before they unlock bookings), and the daily-rating + weekly-billing model is itself a tight commitment loop. You can find a remote engineer in 2 minutes and they will be in the goal cadence by their second Friday.

Common pitfalls

A few patterns we see repeatedly when teams try this for the first time.

• Goals written by the manager. Kills ownership in one quarter. The engineer must hold the pen.
• Goals tied to inputs ("ship 30 PRs"). Optimizes for the wrong thing. Tie to outputs (latency, support tickets, on-call MTTR).
• No mid-quarter checkpoint. The first time anyone notices a goal is impossible is at the grading meeting. Too late to do anything about it.
• Verbal-only goals. They don't exist. If it isn't in Notion or Linear, the engineer's manager and the engineer remember different versions.
• Same goal shape for every tier. A lead's goals should look like a CTO's. A junior's goals should be 4 contained items. One template doesn't fit.

The teams that get this right ship a real weekly artifact and write down 3 to 5 quarterly commitments per engineer. That is the whole system. Everything beyond that is overhead.

If you want to skip the hire-and-onboard loop entirely and start the goal cadence with an engineer who already knows how to work this way, Cadence books vetted, AI-native engineers in 2 minutes with a 48-hour free trial. Weekly billing means the goal loop and the billing loop run on the same cadence.

FAQ

How often should I review goals with remote engineers?

Weekly for the ship-to-prod baseline (5-minute scan of Friday status notes), mid-quarter for a 30-minute checkpoint per engineer, and end-of-quarter for a 45-minute graded review. Anything more frequent becomes ceremony; anything less frequent lets bad goals fester for too long. The mid-quarter checkpoint is the highest-leverage of the three.

Should I use OKRs for a 5-engineer remote team?

No. OKRs are alignment machinery for teams of 20+ where multiple squads need to point at the same outcome. On a 5-engineer team, the alignment cost is higher than the alignment benefit. Use commit-based quarterly goals (3 to 5 per engineer, written, signed, graded) plus a weekly ship baseline. You can always graduate to OKRs at 20+ engineers.

What if an engineer misses their weekly ship baseline?

One miss is a data point; two in a row is a conversation. The conversation is "what got in the way," not "why did you fail." Usual culprits: broken local env, undocumented dependency, scope they don't understand, a sick week they didn't flag. The baseline is a diagnostic; treating it as punitive kills its diagnostic value within a month.

How do I set goals for a remote engineer I just hired?

Set their first quarter's commitments lighter than you think you should (4 items, not 5), and bias toward one slightly ambitious item so you learn their ceiling. Pair them with a senior engineer on at least one commitment. The first quarter is mostly about calibration; the goal-setting muscle gets stronger from quarter 2 onward.

Where should remote engineer goals live?

In writing, in a single tool the engineer owns. Notion and Linear are both fine. The format is a short doc per engineer per quarter with 3 to 5 commitments, comments from both engineer and manager, and an end-of-quarter grading row. Verbal goals from a 1-on-1 don't count. If it isn't written, it isn't a goal.

How are these different from performance review goals?

Performance review goals are annual, broad, and tied to compensation. Quarterly commitments are operational, narrow, and tied to shipping. Both can coexist: the quarterly commitments roll up as evidence for the annual review. Don't try to make one document do both jobs; they have different audiences and different time horizons.