When to escalate, how to brief, what to bring to the conversation. Engineers are a force multiplier. Used well, they unblock you in minutes instead of days.
The whole retreat teaches you to build without an engineer for the 80% of work that does not need one. This protocol teaches the other 20%: when to call, what to bring, how to be unblocked in minutes.
Two traps. Calling too often, becoming dependent, never getting past the 80%. Never calling, spending two days on a problem that takes the engineer fifteen minutes. The discipline is recognizing which problem you have, fast.
The whole retreat teaches you to build without an engineer for the 80% of work that does not need one. This protocol teaches the other 20%: when to call, what to bring, how to be unblocked in minutes.
These rules are obvious in hindsight. They are also the difference between a 5-minute fix and a 90-minute hand-holding session.
Stop debugging and pick up the phone when any of these are true. The marginal cost of one engineer minute is way lower than another hour of your time.
A good engineer call is 5 minutes long, ends with a one-line fix, and updates the docs so the next person does not hit the same gotcha. A bad one is 90 minutes long, ends with the engineer doing the work for you, and updates nothing.
Pick a real blocker from any project of yours. It does not matter if it is solved already, you are practicing the brief. Use a doc, a Slack message, or just a notebook.
Take a screenshot of the error message, or paste it verbatim. No paraphrasing. The exact text matters; engineers grep for it.
Run git log -1. Paste the commit hash and the diff (git show HEAD). The thing that changed last is almost always the thing that broke.
A 5-line list. Each line a single attempt. "Restarted dev server, no change." "Cleared .next cache, no change." "Reverted last commit, error gone." The list narrows the search.
Even if you are wrong, say it. "I think the env var is missing in prod." The engineer will either confirm or correct in 30 seconds. Either way, you are debugging together, not playing 20 questions.
Drop the four-item brief into Slack, email, or your IL engineer's preferred channel. Watch how short the conversation gets.
A practiced four-item brief you can run cold on any future blocker. The brief itself usually surfaces the answer halfway through, before the engineer even reads it.
You have a real on-site engineer at the retreat for exactly this. You bring them your stickiest blocker, practice the brief, and watch a 30-minute problem become a 5-minute fix.