Asking a teammate for help is part of engineering work. The goal is not to prove that you tried every possible thing before speaking. It is to make the uncertainty small enough that another person can help you move forward.
Decide when to ask
Investigate independently while you are producing useful evidence: locating a code path, reading project instructions, reproducing the failure, or checking a focused test. Ask earlier when the task’s requirements are ambiguous, you may be approaching a risky production action, access or permissions are unclear, or a decision depends on team context you do not have.
Set a time boundary appropriate to the risk and urgency. A routine local setup issue may justify a short investigation; a possible data-loss or security issue should be escalated promptly. “I have spent 45 minutes” is context, not a universal threshold.
Send a compact, answerable message
Use this structure in a team channel, ticket, or direct message according to local norms:
I am working on: [ticket or outcome]
Expected: [what should happen]
Actual: [what happens instead]
Evidence: [exact error, reproduction, test, request ID, or relevant file]
I tried: [specific attempts and what each showed]
I need help with: [the decision, missing context, or next diagnostic step]
Impact / timing: [what is blocked and by when, if relevant]Example:
I am working on the overdue-project reminder. Expected: an active project past its due date shows the banner. Actual: the page hides it for dates that are one day overdue. The failing test uses
2026-10-28; the date helper converts it to local midnight before comparing. I checked the page component and the helper is the only date comparison I found. Could you confirm whether project due dates use the team’s timezone or UTC? I am holding the display change until that rule is clear.
This message includes evidence and a specific question. It does not claim to know the root cause before the team confirms the date rule.
Make the handoff easy
Link the exact ticket, pull request, log line, or code location. Share a minimal reproduction rather than a large archive. Include relevant commands and output, but redact access tokens, cookies, customer data, and internal details that should not leave approved systems.
If your question is blocking others, say so. If you are asking for review, tell the reviewer what kind of feedback you need: correctness, API shape, rollout risk, or a specific decision. Avoid vague messages such as “it is broken” or sending an unexplained screenshot.
Close the loop
After the conversation, repeat your understanding of the decision and next step. If the answer changes the ticket or uncovers a reusable setup issue, update the relevant notes or documentation. If someone pairs with you, send a short thank-you and share the outcome; that turns one interruption into useful team knowledge.
Checklist
- I can say what I expected and what happened instead.
- I have one useful artifact or observation to share.
- I listed what I already tried and what it ruled out.
- My question identifies the decision or next step I need.
- I removed secrets and unnecessary private data.
- I explained urgency when someone else is blocked or risk is increasing.
Practice
Rewrite “Can you look at my code? It does not work” using the template above. If you cannot fill in expected behaviour or evidence, make the next action a small experiment that supplies one of those missing pieces.