How should I set expectations for when someone should raise a problem?

Frame the agreement as a guide for when to involve someone, not a requirement to report every inconvenience. Separate issues people can reasonably try to resolve themselves from issues where waiting could affect the work, another person, or an agreed commitment.

For example, someone might handle a minor formatting snag independently, but raise a task that has no clear next step or depends on an unavailable decision. Invite them to use judgment: if they are unsure whether something qualifies, they can ask. Also state that raising a problem is useful information, not proof that they have failed.

Keep the triggers tied to the work rather than relying on vague instructions like “speak up sooner.”

Choose triggers that fit the work and spell out what “early” means in your setting. A practical starting point is to raise an issue when:

1. Work is blocked and the person cannot identify a reasonable next step.
2. A deadline or agreed handoff may be missed.
3. A decision, access, or input from someone else is needed and is not arriving in time.
4. The request or priority is unclear enough that continuing could lead to substantial rework.
5. The issue seems outside the person’s authority or could affect other work.

Set a useful threshold rather than assuming one timing rule fits every situation. For instance, your team could agree: “Flag a likely deadline slip as soon as you see the risk, not on the due date.” Treat that as a placeholder to adapt. Specify the channel too: perhaps a project thread for ordinary blockers and an agreed direct contact route when a same-day decision is needed.

Ask for enough context to understand the obstacle and choose a next step, without expecting a polished report or a finished solution. A short message can include:

• What they were trying to do.
• What is preventing progress, stated as an observation.
• What they have already tried, if anything.
• What may be affected and by when.
• The decision, help, or input they need.

A copyable format is:

“Task: [work item]. Problem: [what is stuck or unclear]. Tried: [steps taken, or ‘not yet’]. Impact: [what may be delayed or affected]. Need: [decision, help, or next step]. By when: [time the response is useful].”

People should be able to leave out details they do not know. The purpose is to make the situation understandable, not to make them prove they deserve help.

Use a short agreement, review it together, and replace the bracketed parts with expectations that suit your work. For example:

“Problem-raising agreement

• Raise a problem when [a task is blocked], [a commitment may be missed], [a decision or input is needed], or [continuing could cause significant rework].
• For [time-sensitive issues], tell [role or person] through [channel] as soon as the risk is visible. For other issues, use [channel] by [agreed point in the work].
• Include the task, what is stuck, what you tried if relevant, the likely impact, and what help or decision you need. It is okay to say you are not sure what to try next.
• You do not need to wait until you have a complete solution. If unsure whether to raise something, ask using [simple route].
• The person receiving the issue will [acknowledge it or agree a next step] by [agreed time or milestone]. If they cannot resolve it, they will say who will help or when to revisit it.
• We will revisit this agreement after [project milestone or review date] and adjust anything that causes confusion.”

The response expectation matters too: an invitation to raise problems is less useful if people do not know what happens next. Keep the commitment realistic, and name a backup route for times when the usual contact is unavailable.