CRYPTO WITHOUT KYCGPU rental · 3, 7 or 30 days
Capordia
Language: English
Menu
Team / Handover

Hand over with a state, an action and an owner.

A successful handover lets the next colleague understand what is running, what is waiting, and what they can decide. A link to files is not enough. Prepare a short brief, have its recipient use it, and confirm the moment of handover together. The goal is continuity of work between people, once access and the environment are prepared.

01

Define the responsibility actually being handed over

Specify the project, the campaign, and the period concerned. The handover may cover monitoring a batch, accepting its results, or preparing an export. It does not automatically transfer the business decision, the purchase of a new period, or the right to change the software. Name a person who receives the work, a backup, and the manager to contact for decisions outside the scope.

Keep access preparation separate from the transfer of responsibility. The dedicated access guide covers identities and permissions; here, check that the recipient knows how to use the intended means and find the right information. Do not pass on a password in the brief. The ordering account reference and operational access serve different purposes.

02

Capture the state of the work at a precise time

The handover brief must show completed tasks, those in progress, those pending, and open discrepancies. Add the time of this snapshot, the active version, the last change, and the next operation. A sentence like "everything is normal" goes stale as soon as a task fails. Identifiers and a timestamped state let the colleague reconcile the brief with what they actually observe.

The Site Reliability Workbook describes reading the previous handover at the start of a shift and preparing a written pass-down for the next one. For your GPU campaign, adapt this principle to a few useful facts: expected progress, blocked work, action already attempted, and person informed. The brief must guide the next decision, without becoming an exhaustive log of every message.

03

Write a procedure that distinguishes observing, acting, and stopping

An operational procedure, or runbook, describes a situation and an authorized action. For each action, state its prerequisite, its expected effect, the check after execution, and the stop condition. Replace "restart if needed" with a rule that identifies the task concerned, verifies that no already-accepted result exists, and prohibits a concurrent restart. If the procedure does not cover the observed case, the recipient knows who to call.

The proposed grid organizes your team's decisions; it does not create any permission in Capordia. Thresholds, people, and tools must be adapted to the project. Also separate the technical ability to run a command from the authorization to do so: functional access is not enough to approve a deletion or a new expense.

Example of action limits to be completed by the team
SituationPlanned actionDecision to obtain
Task still activeObserve its state and its last resultBefore any interruption
Failure covered by the procedureRestart the identified task after checking the outputsIf the cause differs from the documented case
Result discrepancySet the output aside and notify the managerBefore publication or acceptance
End of period approachingPrepare the export and report the remaining needBefore a new order
04

Have the recipient explain the next action

Organize a short one-on-one handover. The colleague taking over opens the brief, finds a task, and explains what they will do next, as well as what they will not decide alone. Have them identify the export destination and the chosen resume state. A demonstration led entirely by the outgoing person can hide information still missing from the document.

For someone new to the project, complement this handover with a bounded hands-on exercise. The Google SRE chapter on learning distinguishes documentation to know, expert contacts, and comprehension questions. Choose a routine operation within a trial scope here; there is no need to trigger a real incident or stop useful processing to assess understanding.

05

Worked example: handing over 128 tasks without re-running them twice

In this fictional example, Camille hands over to Noor at 14:00 UTC. The campaign includes 128 tasks: 96 accepted, 8 in progress, and 24 pending. The sum 96 + 8 + 24 = 128 matches the inventory. Yet two of the eight active tasks have just failed. Without reconciliation at the moment of handover, Noor could treat an already outdated snapshot as the current state.

Camille therefore updates the record: 96 accepted, 6 in progress, 2 failed and 24 pending. The two failures fall under the already authorized recovery case; Noor verifies that there is no accepted output and no process still active, then sets them back to pending. The state becomes 96 + 6 + 26 = 128. The six active tasks continue. Noor confirms acceptance of the handover and records their next check; Camille stops launching actions on this scope.

Fictional states at handover
Point in timeAcceptedIn progressFailedPending
Before reconciliation968024
After updating966224
After authorized reset to pending966026
06

Handling absences, changes and the end of the handover

If the recipient cannot confirm the handover, use the designated backup and clarify who remains responsible in the meantime. Avoid sending a message to several people without explicit acknowledgment. When an incident is already open, also pass on the hypotheses that were ruled out and the actions in progress; a new person must not silently repeat an intervention that has already been attempted.

Whenever the software baseline changes, update the procedure and flag what becomes obsolete. At the end of the need, link the accepted exports, the residual actions and the deadlines to the project register. A period of 3, 7 or 30 days is not extended merely because a colleague takes over the work. The next rental, if needed, remains a separate decision and order.

Questions to decide

Does a handover require a long document?

No. A short record can be enough if it states the scope, the dated state, the next action, the authorization limits and the useful contacts. Detailed procedures remain linked from that record. Above all, test whether the recipient can find and explain the next step.

Can work be handed over through a spoken message alone?

A spoken exchange helps convey nuances, but leave a dated record of the state and the handover agreement. It makes it possible to distinguish what was already done from what remained to be done, especially if a third person steps in after the handover.

What should be done when an instruction is missing from the procedure?

The recipient notes the gap and asks the designated person in charge before any action that could modify the data or interrupt the work. Then add the decision to the procedure, along with its scope. An improvisation that worked once does not automatically become a general rule.

CONTINUE WITH YOUR ORDERReview configurationsView frequently asked questions