The TWIMCO notebook
Field notes.
Useful observations from inside the work.
For people building a better way.
Operations · 38 notes
Spec the batch-failure alert before the nightly job.
Just after midnight the batch fails, and someone gets "job failed" with no counts, no sample records and no safe first step. Or it half-fails, reports success, and the gap turns up at 9 a.m. in customer care.
Read the note ↗︎
Make the submission prove itself before a person reads it.
Google just paused an open source bug bounty because machine-written reports buried the people reading them. If your support queue, claims inbox, or seller applications run on human reading time, you're next in line.
Read the note ↗︎
Name shed order before the API throttles you.
When the API starts saying no, someone has already chosen what to drop. Better if that choice was written down before the peak.
Read the note ↗︎
Define the metric before you dashboard it.
A chart without a definition is a decoration. Name the numerator, the clock, the exclusions, and who may change them.
Read the note ↗︎
Budget the exceptions before they budget you.
The SLA slide shows on-time rates for the clean cases. Split shipments, payment retries and seller corrections are "handled by the team," and nobody has written down how many of those the team can absorb before something gives.
Read the note ↗︎
Write rollback criteria before you cut, not after it hurts.
A TWIMCO card for cutover abort and revert: what must stay green, who may call rollback, evidence required, and the restore path per critical system.
Read the note ↗︎
When A succeeds and B fails, decide—don’t improvise.
Payment captures and inventory doesn't. The carrier said yes, but your call timed out. By morning the ledgers disagree, and whoever was awake decided what to retry. Half-done writes are ordinary, so decide in daylight what happens next.
Read the note ↗︎
Map the source of truth before you trust the sync.
Inventory lives in the warehouse system and in a spreadsheet that feeds ads. The customer lives in three tools that merge records differently. Adding another sync job won't settle it. It just copies the argument faster.
Read the note ↗︎
Dual-write cutover needs a checklist—not a brave night.
Turning on dual-write feels safe. Weeks later nobody owns the comparison, rollback is theoretical, and writing everything twice has quietly become the architecture. It only works as a phase with a clear end and someone in charge.
Read the note ↗︎
Write the cutover on one page before the freeze.
The migration plan is a deck, the freeze is "sometime Saturday," and rollback means "we can switch back." Cutovers tend to fail in the blanks nobody filled, and most of those blanks fit on one page if you write them before the freeze.
Read the note ↗︎
Recover with a pattern library, not folklore.
The queue is stuck, a write landed on only one side, and whoever is on call is working from memory. That gets you a different recovery every time, sometimes the one that makes things worse. Short, rehearsed steps beat improvising at 2 a.m.
Read the note ↗︎
Design the exception path on a canvas, not in a hallway.
Payment cleared but inventory didn't. The warehouse can't keep the window the customer was promised. The clean path always gets built first and the awkward cases arrive next sprint as a pile. It goes better the other way around.
Read the note ↗︎
Put automation scope on one page before you buy.
It looked capable in the demo. After the contract, the awkward cases still live in inboxes and nobody can say what success looks like. Usually the tool wasn't the problem. The job was never written down, and one page would have done it.
Read the note ↗︎
Map the waiting, not just the work.
Most of a case's life isn't spent being worked on. It sits in a queue, waits for an answer or a signature, or comes back to be redone. Speed up only the busy minutes and the calendar barely moves.
Read the note ↗︎
Count the cost of coordination, not just the work.
Both tools work and nothing looks broken, yet the same handoff keeps eating time in waiting, clarifying and redoing. Put your own numbers on that loop and see what a year of it really costs.
Read the note ↗︎
Scope the automation before you buy the tool.
Map the handoff, owners and exception path first. Tool choice is easier once the job is clear—and riskier when it is not.
Read the note ↗︎
Name the exception before you automate the happy path.
The work that breaks automation is usually the exception someone already handles by judgment. Design that path before you wire the clean one.
Read the note ↗︎
Start with the handoff.
The most useful place to automate may be the space between two perfectly good tools.
Read the note ↗︎A familiar problem? Let’s look closer.
Tell us where you want to go. We’ll find the first thing worth changing.
Tell us about it ↗︎