24 Hours, One Laptop, Zero Clue: We Speedran a Fake Company's Entire Onboarding and Lived to Blog About It

Every sysadmin has had the dream: you show up on day one, someone hands you a laptop, and by Friday you're confidently restarting things in production without your hands shaking.

We wanted to know how far off that dream really is. So we did what any reasonable editorial team does on a slow Tuesday: we invented a fictional company — call it Cornhusker Analytics LLC, headquartered in a WeWork in Omaha — wrote up its infrastructure as badly as humanly possible, and challenged our staff writer Marcus to go from "hello, here's your badge" to "your daemon is live in prod" in 24 working hours.

No cheating. No asking the imaginary former employee who "knew how everything worked" (he left for a series B startup in Austin, obviously). Just Marcus, a runbook, and the clock.

Hour 0–2: The Laptop Is a Lie

The first two hours went exactly how everyone's first two hours go: waiting. Marcus spent 47 minutes on a VPN that required a text message code sent to a phone number belonging to "the previous IT admin, Dave." Dave does not exist. Dave is a load-bearing fiction in this exercise, as he is in most companies.

Time wasted on access, credentials, and VPN: 2 hours, 11 minutes.

When we polled real sysadmins about this afterward, the answers were unanimous and bitter. "Onboarding is 80% permission requests and 20% actual work," said one 20-year veteran of a Fortune 500 shop. "The badge photo is the easiest part of the week."

Hour 3–6: Reading the Sacred Texts

Cornhusker's runbook was a single Confluence page titled "infra stuff (READ ME) (OUTDATED — see Dave)" last edited in 2021. Marcus's notes from this stretch include the phrase "the billing daemon is named gerald and nobody knows why," which, honestly, is the most realistic sentence in this entire article.

He found three undocumented daemons running on the staging box: a log shipper, a mysterious Python script in /opt/thing/, and something called cron_janitor.sh scheduled at 3:17 a.m. — the 3:17 being a telltale sign that someone, somewhere, once got paged at 3 a.m. and made an emotional decision.

Time spent deciphering undocumented processes: 3 hours, 40 minutes.

One commenter from our forums put it perfectly: "Every company has a gerald. If you don't know which process is your gerald, you haven't looked hard enough."

Hour 7–12: The Config Format Gauntlet

Here's where the speedrun nearly died. Cornhusker's config story was a Bermuda Triangle of YAML, one TOML file, and a JSON blob with trailing commas that somehow worked in production because the parser was written by someone who "meant to fix that."

Marcus burned 2 hours and 25 minutes on configuration alone — most of it figuring out which values were load-bearing. His verdict, delivered over cold brew at hour 11: "I would trade my retirement account for one comment in this file explaining what 'retries: 3' actually retries."

Hour 13–19: Deploying, or Trying To

The deploy pipeline was a Jenkins job named "DO NOT TOUCH (working)" with a build history stretching back to 2019 and zero successful runs since March. Marcus routed around it with a shell script, which felt sacrilegious and took 20 minutes, and then felt guilty and took another 90 minutes documenting what he'd done.

This is the part of the speedrun that surprised us. The actual technical work — understanding the service, wiring the daemon, smoke-testing — took under four hours. Everything around the work took three times longer.

Hour 20–24: Production, and the Strange Quiet After

At hour 22 and 14 minutes, gerald's replacement service went live on the fictional Cornhusker prod box. Marcus watched the logs for 45 minutes straight, which every sysadmin recognizes as the real deployment step.

Final tally:

• Access and tooling: 3h 40m
• Reading and archaeology: 5h 55m
• Config archaeology: 2h 25m
• Actual deploying: 4h 10m
• Staring at logs, pacing, existential dread: 7h 50m

What Real Companies Get Wrong

We asked working sysadmins what they'd fix first, and the answers clustered around three sins:

1. The runbook is a museum. Documentation written at launch and never touched again is worse than none, because it lies with confidence.
2. Nobody budgets for access. Your new hire's first day is fully scheduled and 60% of it is waiting for a ticket to clear.
3. Tribal knowledge walks out the door. Every "Dave" who leaves takes a decade of context about why cron_janitor.sh runs at 3:17.

The speedrun worked because we controlled the fiction. Real onboarding has no timer and no respawn. But the lesson stands: the fastest way to get a new sysadmin productive isn't a better checklist. It's leaving fewer geralds behind.

Marcus, for the record, finished in 22 hours and 14 minutes, then spent the last two hours writing a runbook for the next person. We're told that's the most unrealistic part of the whole simulation.