Every space programme has a moment when someone walks away from a desk: a shift ends, a contract finishes, an engineer moves to the next vehicle. Whether that moment is clean or messy often decides how the following week goes. A good project handover keeps a spacecraft team calm, while a careless one sends the incoming person digging through old chat threads to learn what the previous owner already knew.
This piece treats the problem like an engineer would. We describe the symptoms, find the likely causes, and then walk through a fix you can apply to any small space project, whether it is a student cubesat, an amateur tracking station, or a research payload that changes hands between two labs. Nothing here replaces the official procedures of an agency, operator or regulator. Treat it as a framework for your own notes, not a rulebook.
The symptoms of a bad handover
The pattern is easy to recognise once you have seen it. The new person opens the project folder and finds files named after dates rather than meaning. Half the commands in the history are unexplained. A telemetry channel looks odd and nobody can say whether it was always like that. The previous owner is now busy elsewhere, and every question costs them a context switch.
Here are the usual warning signs:
- The incoming engineer repeats a test that was already completed, because nothing recorded the result.
- A workaround that lived only in someone’s head quietly disappears and the original fault returns.
- Nobody knows which items were finished, which were abandoned, and which were simply paused.
- Access to a ground station, a mailing list or a data archive turns out to belong to a personal account.
Individually these are small irritations; stacked up, they become what engineers call re-discovery cost: the time spent learning again what somebody already learned once.
Diagnosing the cause
Why does this keep happening, even on careful teams? Usually for three plain reasons.
First, the leaving person is the worst judge of what the next person needs. After months inside a project, certain facts feel too obvious to write down. The orbit of a satellite, the quirk of a ground antenna, the reason a parameter was changed: all feel like common knowledge to someone who lived with them daily.
Second, handovers happen at the busiest time. Contracts end, funding rolls over, a launch window approaches, and the departing person is already half-assigned elsewhere. The handover gets squeezed into the last afternoon.
Third, there is no agreed shape. People write long narrative emails or nothing at all, because no one ever defined what a good handover note contains. Without a template, the quality depends on mood.
The fix: a handover that answers four questions
The cure is not a heavier process. It is a short document that answers four questions in plain words. Write it before the last day, not on it, and ask the receiver to read it back to you.
1. What is finished?
List the work that is genuinely complete and signed off, along with where the evidence lives. For a space project that might be a checked link budget, a completed software review, or a ground-station test with its logs. Keep this list short and honest. If something is only mostly done, it does not belong here.
2. What is half-done?
This is the most valuable section and the one most often skipped. Describe each open thread: what you tried, what you expected, what actually happened, and what you would do next. Naming a dead end saves the next person from walking into it. Even a sentence like “the second approach to the antenna pointing issue failed because of timing, not hardware” can save days.
3. Where are things kept?
Give a plain map of locations: repositories, shared drives, mission logs, spare hardware, calibration files, licences, and the accounts or mailing lists that carry notices. Note who holds the keys. If a login belongs to the departing person, say so now and arrange a transfer while they are still reachable.
4. What should the next person watch for?
Record the quirks. Which telemetry value drifts a little each pass and is harmless? Which sensor reads high after a particular manoeuvre? Which deadline falls in the next month? Add the name of someone who can answer questions, and be clear about when they are available. A named contact with a time window beats a vague promise to “ping me anytime.”
Reading about orbits is not the same as passing on a project
It helps to see how well-explained material is structured. If you want a model of clear technical writing, look at how a beginner article sets out its subject step by step. A page such as this plain walkthrough of a geostationary orbit made simple states the definition first, then the consequences, then the cautions. A handover note benefits from the same order: the situation, what follows from it, and what to be careful about.
Likewise, when a spacecraft moves between mission phases, the team has to carry knowledge across each boundary. A description of the phases a spacecraft flies through makes the point nicely: each phase has its own checks, its own risks and its own people, and the information that mattered in one phase has to be deliberately passed to the next.
A worked example, kept deliberately small
Imagine a university group that operates a small receiving station for a low-orbit satellite. The student who ran the station is graduating. A weak handover is a zip file and a goodbye. A clean one looks different.
The outgoing student writes a one-page note. Under “finished,” they list the antenna alignment and the receiver calibration, each with a pointer to its log. Under “half-done,” they describe an intermittent dropout on one frequency: three explanations considered, two ruled out, one untested. Under “where things are kept,” they give the folder for recordings, the location of the spare cable, and the person in the department who holds the building access list. Under “watch for,” they mention that the tracking software needs fresh orbital data before every pass, that an old computer clock drifts, and that a regional licence needs renewal in a few months.
Then they sit with the successor for an hour, and the successor performs one real pass while the leaver watches without touching the keyboard. This single session surfaces the things nobody thought to write down. The note gets two corrections, and the station carries on without a hole in its record.
Handover habits that make the note believable
- Date everything. A note without a date is a note whose accuracy nobody can judge.
- Separate fact from opinion. Say “I measured this” or “I suspect this,” so the reader knows how much weight to give each line.
- Link instead of paste. Point to the single source of truth rather than copying text that will go stale.
- Do a live walk-through. Thirty minutes of watching the successor do a real task beats a long document.
- Keep a short leave-behind window. Agree that the leaver will answer questions for a defined period, then stop.
When the engineer is a contractor
The stakes rise when the person leaving is not an employee. Small space projects, student teams and start-ups often bring in outside engineers for a bounded task: software for a ground segment, a data pipeline for payload output, or help with how a team deploys and monitors its tooling. When the engagement ends, the knowledge walks out the door unless someone plans for it.
That is one reason the idea of a clean handover matters outside pure space work. One place people look for such short-term technical help is a DevOps freelancer portal organised by country, a setting where an engineer arrives, delivers and leaves in a short span, so the quality of the exit is half the value of the job. Whatever route you use to find outside help, ask early what the handover will look like and agree it in the same conversation as the scope.
A closing checklist for the last day
- Write the four-question note and date it.
- Move any personal accounts or credentials to team-owned equivalents.
- Record where logs, spare parts and licences are kept.
- Name the open threads, including the dead ends.
- Run one real task together, with the receiver at the controls.
- Agree on a short window for follow-up questions.
Space work is unforgiving of lost context, but the remedy is modest: a page of honest writing and an hour of shared practice. For more on how to explain orbital basics to newcomers who might inherit your project, the introduction to working in low Earth orbit for beginners is a useful companion read. Hand over the project the way you would want to receive it, and the next team starts from your best day instead of your worst.