Name what you will shed before the spike.

Spike night is a choice about what stops

Auction night, a campaign send, a product launch, a go-live Monday. You know the clock. You do not know, unless you wrote it down, which work is allowed to wait, which work must still finish, and which people are actually on. In the absence of that page, the spike chooses for you. A queue backs up. Someone improvises. A promise you meant to keep is the one that slips, because it was never marked as the one you would protect.

Shedding is not failure. Shedding is the decision to stop or defer named work so the work you refused to drop can get through. Holding is the queue you will not drain in order, with a rule for what enters it. Staffing is the roles you add, and the roles you do not pretend to add. Restore order is how you climb back out without creating a second incident the next morning.

This note is the TWIMCO Capacity-Spike Shed Plan. It is not an incident-role matrix and not a library of recovery patterns after something has already broken. It is written before the spike, for a spike you can see coming. It does not contain a capacity number, because this note does not have a measured capacity to offer. Your plan uses your own limits. It does not borrow a fake one.

TWIMCO built Paddle8’s fine-art auction house and marketplace, including the operations that continue after the bid. Auction night is the obvious picture of a spike: a room that is quiet, then not, then quiet again, with fulfillment still owed when the screen calms down. The same shape appears in campaigns and go-lives. The plan belongs next to fulfillment and operations when the thing at risk is a promise you still have to keep after the peak. There is no interactive generator for this plan on the site. The page is the asset.

Write it when the spike is still a date on a calendar. A plan written in the hour the volume arrives will only describe what you already cannot do.

Shed, hold, and staff are different verbs

The TWIMCO Capacity-Spike Shed Plan uses three columns, and a line may sit in only one of them. If everything is “staff harder,” you have not made a shed decision.

Shed. Work you will deliberately not do, or will do in a reduced form, for a named window. Examples of the kind of line, not a prescription: pause a noncritical backfill, turn off a recommendation pass, stop proactive outbound that is not the event itself, defer reporting that nobody will read during the peak, close intake of a request type that can wait a day. Each shed line names the window, the customer or operator effect, and how you will say so if anyone is waiting. A silent shed is how a promise breaks without a sentence attached.

Hold. Work you accept and do not finish during the spike. A hold is a queue with an entry rule, not a junk drawer. Say what may enter, what may not, and who drains it afterward. A hold without a drain owner is a shed you were too polite to name. Bids, checkouts, and paid promises usually do not belong in hold. Internal tidy-ups often do. Write your own boundary. Do not copy a marketplace’s boundary onto a different business and call it done.

Staff. Roles you will actually have in the window, with a start and an end. “The team will be around” is not staffing. Name the role that watches the protected path, the role that handles exceptions, and the role that is allowed to decide a new shed if the plan is not enough. A decision role that is asleep is not a decision role. Write the backup.

Protected path is the fourth idea, even though it is not a fourth column. It is the work you are shedding and holding in order to save. Name it in one sentence at the top of the plan: accept and record the bid, take payment once, ship the paid order, keep the go-live’s write path honest. If you cannot say the protected path, the three columns are a list of preferences.

Each line gets an owner. The owner is the role who may start the shed or the hold, and who confirms it stopped. Shared ownership is how a shed never starts because each person thought the other one did it, or starts twice because both did.

Keep the plan to a page. A spike document that needs a table of contents will not be read when the room gets loud. If you need more, you have two spikes or a different document.

Restore order is part of the plan

The morning after is where shed plans go to become permanent. Someone turned a job off. Nobody wrote who turns it back on. The backfill stays off for a week. A report stays blank. A hold queue becomes the new normal because it was easier than draining it.

The TWIMCO Capacity-Spike Shed Plan ends with a restore order. Not a hope. An order.

List the shed and hold lines in the sequence they return. Some returns depend on others: do not reopen intake before the hold queue is drained, or you fill the queue you just emptied. Do not turn a heavy job back on while the protected path is still catching up. Say the dependency in a clause next to the line.

Each restore line has the same owner shape as the shed: who confirms it is back, and what “back” means. “Back” might mean the job is enabled, or it might mean the held items are below a condition you can see without inventing a metric for this note. If you have a real threshold your operation already uses, write that threshold. If you do not, write a visible condition: the queue is empty, the job has completed one cycle, the role has said the exception pile is ordinary again. Do not invent a percentage to look managed.

Put a latest restore time on the plan, even if it is “next business morning, this role.” A restore without a time is optional, and optional restores do not happen on the day everyone is tired.

If a shed cannot be restored because the spike revealed that you should not have been doing the work, that is a separate decision, made after the spike, by the role who owns the service. It is not a quiet default. The plan’s restore line still exists so the exception is conscious.

Write what you will tell people who were delayed. One sentence is enough. Silence is how a hold becomes a complaint you cannot explain, because nobody remembers that the delay was chosen.

Decide the new shed before the room invents one

Plans meet a spike that is worse than the plan, or a spike that is fine and still produces a surprise. The document should say who may add a shed during the window, what they must write down, and what they may not shed even then.

The protected path is the thing they may not shed without a higher role you name in advance. If payment, safety, or the integrity of the record is on that path, say that those lines are not available for improvisation. People under pressure will reach for whatever is nearest. The plan’s job is to make the nearest lever a lever you already accept.

During the spike, the useful record is small: time, what changed, who decided, what you expect to restore. A narrative incident report can come later. The scrap of decisions is what restore depends on. If it lives only in a chat that scrolls away, assign someone to copy the lines onto the plan before the window ends.

These are delivery-shaped composites, not measurements from Paddle8 or any other client. The team staffed the event and forgot the warehouse morning. The recommendation job kept running and the protected path waited behind it. A hold queue was opened for “anything weird” and became a second product by Friday. A shed was reversed by someone helpful who did not know it was a shed, so the load returned in the middle of the peak. None of those stories comes with a number. Each one is a line the plan is for.

Do not use the plan as a substitute for knowing whether you are already over a limit you have actually observed. If you have monitoring you trust, read it. If you do not, do not decorate the plan with fake headroom. The plan is still worth writing, because the choice of what to protect does not require a graph. It requires a sentence you are willing to keep.

Review the plan after the spike while the restore is fresh. Add one line you had to invent. Remove one line you did not need. That edit is how the next spike gets a better page, not a thicker one.

Put this into practice

1. Name the spike: the date, the window, and the protected path in one sentence.
2. Fill the TWIMCO Capacity-Spike Shed Plan with shed, hold, and staff lines. One column each. An owner on every line.
3. Write the restore order, the dependencies, and the latest time each line comes back.
4. Name who may add a shed during the window, and what they still may not touch.
5. If the protected path is a promise you fulfill after the peak, bring the plan into fulfillment and operations scoping. Paddle8 is the reminder that a marketplace’s busy hour is not finished when the bids stop. The work you chose to protect still has to be operable the next day.

Volume will spend whatever attention you did not assign. The plan is the assignment.