Lock Etiquette: Durations, Handoffs and Takeover Requests

A locking tool fixes the mechanics of sharing. It doesn't fix the habits. Teams that adopt a lock bot for their staging environment usually get a few weeks of calm, then hit a new set of small frictions: locks that run all day for a ten-minute check, takeover requests fired at people in meetings, and a quiet sense that some people always seem to hold the good environment.

These are social problems, and they're fixed with a few written norms. This post is a set of norms that work for most engineering teams, with the reasoning behind each, so you can adapt them rather than copy them.

Why norms matter more than the tool

Every shared resource system has the same three pressure points:

1. How long people claim things for. Too long and others wait for nothing. Too short and people re-lock constantly or get interrupted.
2. What happens at the end. Release early, let it expire, or hand it to someone specific.
3. What happens when someone else needs it now. Wait, ask, or escalate.

A tool can make each of these easy. It can't decide what's reasonable for your team. Write that down once and pin it.

Durations: lock for what you'll actually use

The norm: pick a duration that matches the work, plus a small buffer. Then release as soon as you're done.

Most over-locking comes from one of two places. People pick a big number "to be safe," or they don't pick a number at all and get whatever the default is.

Practical guidance by task type:

Task	Reasonable lock
Quick check of a deployed fix	15–30 minutes
Feature testing session	1–2 hours
Regression or E2E suite	Suite runtime plus 15 minutes
Debugging on a device or board	Half a day, release when done
Demo environment for a customer call	Call length plus setup time
Overnight soak test	Until the morning, stated explicitly

Set short defaults for busy resources. The default is what people get when they don't think about it, so make thoughtless locks short. In Lockit, a lock's end time is the duration chosen when locking, else the resource's default, else the workspace default, else 48 hours. Forty-eight hours is a safe fallback for rarely contested things. For a staging environment that five people want daily, it's far too long. Set a per-resource default of an hour or two.

On a paid plan, defaults can be set through the API:

# Busy shared environment: 2 hour default
curl -X POST \
  -H "X-API-KEY: $LOCKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"defaultLockHours": 2}' \
  https://api.lockitbot.com/api/locky/resources/staging-api/default-duration

# Everything else in the workspace: 1 day
curl -X POST \
  -H "X-API-KEY: $LOCKIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"defaultLockDays": 1}' \
  https://api.lockitbot.com/api/locky/config/default-duration

On Discord, people can give natural durations when they lock, including times of day:

/lockit lock resource:staging-api duration:till 6pm

Don't lock "just in case." Locking staging at 9am because you might need it after lunch is the single most common source of resentment. Lock when you start.

Releasing: early is polite, expiry is a safety net

The norm: release when you're finished, not when the lock runs out.

Expiry exists so a forgotten lock doesn't block people forever. It's not the plan. If you finish at 2:10 and your lock runs until 3:00, the person who clicked "Alert when released" has been waiting fifty minutes for nothing.

Three habits help:

• Release in the same breath as "done." When you post "fix verified" in the PR, release the environment.
• Release before meetings. If you're stepping away for an hour, either release or accept that someone may ask for a takeover.
• End-of-day sweep. Before logging off, check what you hold. In Slack, Lockit's App Home tab lists your current locks with a release button for each.

Handoffs: be explicit

Sometimes you're done and you know who's next: a teammate continuing your test, or a QA engineer waiting on your deploy.

The norm: release, then tell the next person directly. Don't "pass" a resource by DM without releasing it, because the record still shows you as the holder.

If your team uses update channels, the release is posted there automatically, and anyone who asked to be alerted is pinged. The direct message is a courtesy on top.

Waiting: use alerts, not channel pings

The norm: if someone holds what you need and you're not blocked, click Alert when released and get on with something else.

Asking "how long will you be on staging?" in a channel interrupts the holder and everyone else. The lock already says how long. An alert tells you the moment it's free. That's usually all you need.

Takeovers: for when you're genuinely blocked

Ask for takeover is the escalation path. In Lockit, it sends the holder a request naming you, with two buttons: Release and Approve and Reject Request.

When a takeover is fair:

• A production incident needs the environment to reproduce or verify a fix.
• A release is blocked on the resource and the holder's lock runs well past the release window.
• The holder's lock looks forgotten: they're offline, and it's been held far longer than their task would take.
• A customer demo or external deadline that can't move.

When it isn't:

• You'd simply prefer not to wait forty minutes.
• You want the "good" environment and another identical one is free.
• The holder is mid-run on something that will be wasted if interrupted, and you can wait.

How to ask well: add context. Before or alongside the request, send one line: "Hotfix for the checkout bug, need staging for 20 minutes, can give it back after." A request with a reason gets approved quickly. A bare request feels like a demand.

How to respond well:

• Answer quickly. Approve or reject, don't leave it hanging. Silence is the worst outcome for both people.
• If you reject, say when you'll be done. "Rejecting, suite finishes in 15 minutes, will release then."
• If you approve and you had work in flight, note what state you left it in.

Platform detail worth knowing: on Discord and Microsoft Teams, approving a takeover locks the resource straight to the requester. On Slack, approving releases the resource, and the requester should lock it immediately so nobody else takes it in between.

Fairness: watch for patterns, not incidents

One long lock is fine. A pattern of one person always holding the same environment is a conversation.

Signs worth raising in a retro:

• The same resource is always locked by the same team. That may mean it should be theirs, and you need another one for everyone else.
• Takeover requests are frequent. That's a capacity problem, not an etiquette one.
• Locks routinely run to expiry. Defaults are too long, or people aren't releasing.

If the queue for an environment is regularly long, no amount of etiquette fixes it. Add capacity, or move some work to ephemeral environments.

Pipelines need etiquette too

CI jobs that lock resources should follow the same rules: a duration slightly longer than the job, and a release step that runs even when the job fails. A pipeline that leaves a lock behind on failure is the most annoying holder of all, because nobody can ask it to hand over. See locking staging from CI/CD for the pattern.

A pinnable version

How we share environments and devices

1. Lock when you start, not before. Pick a duration that fits the task.
2. Release as soon as you're done, even if time is left.
3. If something's taken and you're not blocked, click "Alert when released."
4. "Ask for takeover" is for incidents, blocked releases and abandoned locks. Say why.
5. Answer takeover requests quickly. If you say no, say when.
6. Check your locks before you log off.

Where Lockit fits

The norms above work with any system, but they're easier when the tool supports them. Lockit gives every lock an owner and an end time, lets waiters subscribe to a release, and turns takeovers into a structured request with clear buttons. It works in Slack, Discord and Microsoft Teams. The free plan covers two resources with unlimited locks and members; Starter is $17/month for up to 100 resources with API and MCP access. See pricing and the docs.

For the bigger picture on running shared environments, see how to manage shared staging environments.

FAQ

What's a good default lock length?

For heavily contested environments, one to two hours. For devices and less busy resources, a working day. Lockit falls back to 48 hours only when neither the resource nor the workspace has a default set.

Is it rude to ask for a takeover?

Not if you're blocked and you explain why. It's rude when it replaces waiting for a few minutes, or when it's sent with no context.

What if the holder doesn't respond to a takeover request?

The lock still ends at its end time. If the matter is urgent and the holder is unreachable, escalate to whoever owns the resource. Short defaults make this rare.

Should I release a lock before a meeting?

If the meeting is longer than a few minutes and someone might need the resource, yes. Re-lock when you're back.