Set a latency budget live for a feature I describe.

The interviewer says three words: reads a request, checks calendars, proposes times. You have maybe ninety seconds to turn that into real numbers. Nobody's grading whether you can name the three stages. They're grading which one you protect first, out loud, with no time to go back and think.

How to answer this, stage by stage

Nobody's grading whether you can list "parse, check, propose." They're grading whether you can turn that list into a ranked number, live, and defend it when someone points out the reasoning stage is the one that's actually slow today.

Let's learn

Slotwise is the scheduling assistant Verlask Consulting built for its own staff. Someone types "set up a 45 minute kickoff with the Meridian client team next week," and Slotwise reads the request, checks every attendee's calendar, internal colleagues and outside clients alike, and proposes three ranked times.

Before Slotwise, locking a time for a meeting with at least one outside client took an average of 4 email round trips and about 30 hours of back and forth. Roughly 500 of those requests came in every week across the firm.

Slotwise proposed three ranked times in under 4 seconds instead. People liked it enough that usage grew from 500 requests a week in beta to about 12,000 a week within seven months, once it rolled out firm-wide.

The turn: the conflicts were never about the model getting worse. The same model ran the whole seven months. The turn is that calendar-check and propose-times shared one combined window of 1,850 milliseconds, with no split between a fast internal calendar and a slow external one. Whichever calendars had answered by the time that window closed got used, and propose-times went ahead anyway, with nothing on screen to say an attendee's calendar had never actually come back.

Neither timeout number is real until this gets answered first: what does propose-times say the moment a calendar hasn't come back yet.

Here's the build-up behind the budget the team eventually corrected to. Four seconds, split across five stages, once the external calendar check finally got the slice the decision actually needed.

Parsing and internal calendars barely move. Together they cost 500 milliseconds and both are close to fixed cost, a colleague's calendar on the same company system almost always answers inside a few hundred milliseconds. Propose-times is the heaviest single computation, ranking three candidate times against everyone's stated hours and time zones, but once it streams, the requester sees the first candidate under half a second in, long before the full 1,200 milliseconds finishes.

External calendar-check doesn't work that way. It's a call through a shared link, a forwarded ICS file, or a client's own webmail calendar, none of it inside Verlask's control, and the number that mattered wasn't the average response time. It was how often that call ran out of whatever slice it had been given.

Propose-times can be re-tuned next sprint with nobody the wiser. A wrong invite already accepted can't. That asymmetry, not which stage is slowest today, is what decides who gets the guarded slice.

At its worst, a scheduling assistant that proposes with total confidence keeps quietly sending real invites for slots that were never actually free, until an account manager has apologized to the same client twice in one week for a meeting that was never really open.

What I'd leave alone: request-parsing genuinely didn't need this treatment. It's a small, mostly fixed cost, and it never once produced a wrong meeting on anyone's calendar.

The lesson: a budget that adds up to a clean total can still hide which slice is allowed to fail quietly. That's the one worth protecting, not the sum, and not whichever stage looks hardest to compute.

Now here is the same thing as a story

Read the long version below when you want to feel why a shared timeout that never looked broken on a dashboard still sent a real client a meeting invite for a slot that wasn't actually theirs.

Gethin Thackery could look at a scheduling request and tell inside a minute whether it would be simple or a headache, long before Slotwise ever suggested a time. He'd run client operations at a mid-size accounting firm for six years before Verlask hired him to build Slotwise from nothing.

The early months were genuinely good. Slotwise launched with a single promise, three ranked times, every time, inside four seconds. People who'd spent years chasing email threads loved not chasing them anymore. Requests grew from the 500-a-week beta to 4,500 a week by month three, and every proposal it sent held up, because volume was still low enough that a slow external calendar rarely got squeezed.

It faded in three beats, and none of them looked like a mistake at the time. Beat one: as client-facing usage climbed, a few account managers started noticing a proposed time turning out to conflict with something already on a client's calendar, awkward, but rare enough to shrug off. Beat two: Malick Osokwe, the engineer who owned the calendar-integration calls, started getting pulled into more of those awkward messages himself, tracing why a "checked" calendar hadn't actually been checked in time. Beat three: a few account managers quietly started double-confirming external attendees by email before trusting Slotwise's proposal at all, the exact extra step Slotwise was built to remove.

Same inbox, same engineer. What changed was whether a skipped calendar check announced itself, or just waited to become someone else's apology.

It surfaced on an ordinary Tuesday, not through a dashboard. Yannic Adjei, Gethin's ops lead, pulled ten recent client meetings at random for a routine readiness check ahead of a quarterly review. Three of the ten had already needed a manual reschedule after Slotwise proposed them, because the external attendee had actually been busy at the time Slotwise confidently offered.

Gethin pulled the numbers that afternoon. Slotwise's own dashboard looked fine on the surface, average end-to-end time sitting comfortably under four seconds, right on target. Split by whether the external attendee's calendar had actually answered before propose-times ran, the picture changed: during the two busiest days of each week, external calendars regularly ran past their share of the combined 1,850 millisecond window, and every one of those timeouts let propose-times go ahead anyway, no flag, no warning. Across the quarter, that meant Slotwise proposed 190 meetings with at least one attendee it had never actually confirmed, and 3 of every 10 client-facing proposals sampled in Yannic's audit needed a manual fix.

Nobody decided on purpose to give the external check too little room. It just never got a slice of its own.

The decision that opened the door went back to a short design conversation near the end of Slotwise's build. Someone asked how the calendar-check step and the propose-times step should share their time, and the fast, sensible-sounding answer was to fold them into one combined window and let propose-times start the moment enough calendars looked ready. Nobody in that conversation asked what "enough" meant, or what propose-times should do about the ones that weren't.

Run that conversation again with one change: external calendar-check gets its own guarded slice, 2,000 milliseconds, and if a specific attendee's calendar still hasn't answered by then, the proposal shows a plain flag next to their name instead of quietly assuming they're free. Same 12,000 weekly requests. Conflict rate drops from 13 percent in its worst week to about 0.7 percent, and Malick's afternoons of untangling the same double-booking mostly disappear.

One design assumed every calendar in the request would answer at roughly the same speed. The other design asks which calendar, if it's wrong, someone can act on before anyone gets a chance to catch it.

What I'd tell myself, back in that short design conversation: ask what each stage is allowed to assume when the clock runs out, before you ever agree to let two stages share one clock.

A meeting's real risk was never about which company it involved. It was how much of the calendar-check leaned on an external, unreliable answer, and how costly a wrong guess would be if it did.

ORDER, the five letters you say out loud while the feature's still being described

Not a story wearing a framework's clothes. This is a live ranking problem across three stages of one feature, and ORDER is what stops "whichever stage looks hardest to build" from quietly standing in for "whichever stage's mistake nobody can take back."

Three things worth stating directly, since the real judgment sits here. The alternative Verlask's team tried first, and dropped, was removing the timeout entirely and waiting for every calendar no matter how long it took, to guarantee no conflict ever slipped through. It lost in a two-week test: total proposal time on requests with a slow client calendar stretched past 15 seconds, sometimes 40, and close to one in five people closed Slotwise mid-wait and went back to email, the exact habit Slotwise was supposed to be replacing. The AI-specific failure worth naming by name is a confident proposal made without confirming every input: when the shared window ran out, Slotwise didn't say "I couldn't confirm everyone yet," it proposed the time anyway, in the same certain voice it used for everything else, because the model is built to produce a clean answer, not to admit it ran short on time. The guardrail is a validation step that forces a "not confirmed for [name]" flag into any proposal where an attendee's calendar didn't return inside its own slice, logged every time so it shows up as a weekly count instead of only surfacing through a client's confusion. That guardrail isn't free. Verlask accepted a bigger, more compute-heavy slice for external calendar-check, calling two integration paths, a direct API and a fallback file parse, in parallel, in trade for a conflict rate that fell by more than 12 points in one quarter.

And if you want to be sure it really works, try it somewhere else

Same five letters, an ER radiologist's queue instead of a meeting request, and this time the lever wasn't which calendar to trust more. It was what a stalled check was allowed to assume by default.

TriageScan is Corvasan Health's tool. An ER doctor orders an X-ray, and TriageScan reads the image, pulls the patient's prior imaging record to check for change, and drafts a preliminary flag, acute finding, no acute finding, or uncertain, for a radiologist to confirm before the ER doctor ever sees it. Zorion Machtelt owns cost and quality on it.

The build-up: TriageScan's budget gave the prior-imaging pull about 900 milliseconds inside that shared window. When an older record lived in a slower legacy archive, roughly 1 read in 20, the pull didn't finish in time, and the flag defaulted to "no acute change" instead of waiting or asking for help. Over one quarter, that meant 19 cases where a real change from a prior image went unflagged, caught only when a radiologist happened to pull the comparison manually during a routine second read.

Four parts share one clock. The one most likely to run long is also the one whose silence used to read as good news.

Same rank, different lever: the stage touching a live, changeable fact, whether a prior image exists and what it shows, still needs the guarded slice here too, but the lever isn't which archive to call in parallel, it's what the default assumes when time runs out. Zorion's team flipped the flag's default from "no acute change" to "uncertain, needs comparison," so a slow legacy archive now costs a radiologist a flagged manual check instead of a false reassurance nobody double-checked.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: give the guarded slice to whichever stage touches a live, changeable fact a person can act on, not whichever stage does the hardest reasoning, and make its timeout fail with a flag, never a silent guess.
Cost: there's no budget this quarter for both a faster external-calendar fetch and a bigger buffer everywhere else. Fund the external fetch. A guarded slice that rarely times out beats a bigger buffer sitting behind a check that was never split out in the first place.
The model got better, for real: say Slotwise's ranking model gets meaningfully faster at scoring candidate times. That's real, and it should shrink propose-times' own slice further. It does nothing to how long a client's forwarded calendar invite takes to resolve, which is what actually decides how often the guarded slice has to do its job.

Where people run it wrong.
They allocate by which stage looks hardest to build, instead of by which stage's mistake a person can act on before anyone gets a chance to fix it.
They set a timeout number before deciding what the feature says the moment it fires, so the fallback quietly becomes silence instead of an honest flag.
They remove the timeout altogether to chase zero mistakes, and lose the person to a wait that feels worse than the rare conflict ever did.

How to use it live. Say the real question out loud before naming a single millisecond: "if this stage runs out of time, does the answer just get slower, or does it quietly become wrong." That buys a beat to actually rank instead of reciting whichever pipeline diagram you remember from the last product.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0