Motivating a distributed team of senior engineers

What the old advice assumed

A decade ago, “motivate your team” advice tended to assume a shared office, a fairly junior team that needed direction and encouragement, and a manager whose presence and mood set the tone for everyone in the room — “be motivated yourself, so others catch it,” “provide a pleasant place to work,” “have fun to manage stress.” None of that is wrong exactly, but it answers a question most engineering teams don’t actually have anymore. A distributed team of senior engineers, several time zones apart, mostly communicating asynchronously in writing, doesn’t run on office mood. It runs on a different set of things going right.

Autonomy is the baseline, not a perk

A senior engineer’s motivation problem is rarely “I need more enthusiasm from my manager.” It’s much more often “I don’t understand why this decision was made, or I understand it fine but had no say in it.” The fix isn’t a pep talk, it’s structural: give engineers real ownership over the how, once the what and why are clear.

Concretely, that means a senior engineer should be able to answer “why are we building it this way” without needing to ask someone else — because they were in the room (or the doc) where that got decided, not informed of it afterward. A team where architecture decisions arrive as already-finalized announcements, however well-intentioned the announcement, is a team that’s optimized away the exact thing that makes autonomy motivating: having actually shaped the decision.

Ownership means the whole lifecycle, not just the build

Ownership that stops at “merge the PR” and hands the result to someone else for deployment, monitoring, and incident response isn’t ownership, it’s task completion. A team that motivates senior engineers gives them the full lifecycle of what they build: they deploy it, they’re the first call when it breaks, and they’re the ones who decide when it’s paid down enough technical debt to move on. That loop — build it, run it, feel the consequences of how you built it, improve it — is what makes engineering work feel like it belongs to the person doing it, rather than a task assigned and later judged by someone else.

Written communication is the actual skill, not a workaround

For a distributed team, most of what used to happen as a hallway conversation or a whiteboard session has to happen in writing instead — which is a real change in what’s needed from people, not a lesser substitute for the in-person version. A design doc that a reviewer in a twelve-hour-offset time zone can read, understand, and comment on without a live meeting is a different (and harder) writing task than notes taken during a conversation everyone already had.

Teams that do this well treat writing as a first-class engineering skill: a decision that isn’t written down somewhere durable — a design doc, an RFC, a well-structured PR description — didn’t really happen for anyone who wasn’t in the room live, and on a distributed team, most people weren’t. The team’s velocity depends more on the quality of its written record than on the speed of any individual conversation.

On-call fairness is a concrete, auditable thing

Nothing erodes trust on a senior team faster than an on-call rotation that quietly isn’t fair — one person getting paged constantly because their service is the flaky one, or a rotation that never adjusts even after someone raises it. This is worth making explicit and measurable rather than trusting it to work itself out:

Track pages per person per rotation, and treat a persistent imbalance as a signal to fix the underlying reliability problem, not just the schedule.
Compensate on-call time explicitly — time off in lieu, or pay — rather than treating it as an unstated expectation of the role.
Make the escalation path and expectations (what counts as page-worthy, what can wait until morning) a written, agreed document, not tribal knowledge that varies by who you ask.

A team that gets this wrong doesn’t lose motivation because nobody’s having fun — it loses trust because the burden isn’t distributed the way people were told it would be, and trust is much harder to rebuild than enthusiasm is to generate.

What actually motivates a senior distributed engineer

Less office-culture and more structural: real input into decisions before they’re final, ownership that extends through deployment and incident response, writing that a global team can act on asynchronously, and an on-call load that’s genuinely, visibly fair. None of this requires everyone being in a good mood in the same room — which is useful, because on a distributed senior team, they mostly aren’t in the same room at all.

Originally published in 2015 and updated for 2026.