Triage issues and give every one an owner

Issue triage is a task that is easy to do badly and tedious to do well. Most teams do it in a standup, which means it happens once a day at best and the person doing it is guessing at half the context.

Connect Linear and write your rules down

Connect Linear from Integrations. It is served through the managed catalog, so search for it. GitHub Issues and Jira work the same way if that is where you live.

Then write your routing rules into a document. Not in the prompt, in a document, because they will change and you want to change them in one place.

Your rules document should say which labels exist and what each one means, who owns which area, what makes something urgent as opposed to merely important, and what a good bug report has to contain to be actionable.

Triage without assigning, first

Run it read-only for a few days before it touches anything.

Look at issues created in Linear in the last 24 hours.

For each one, using our triage rules document, tell me:
  the label you would apply and why
  the owner you would assign and why
  whether it is actionable as written, or is missing information

Do not apply anything yet. Just tell me what you would do.

This is cheap and it surfaces the disagreements while they are free. Every case where you would have chosen differently is either a rule you never wrote down or a rule that is wrong.

Do not fix these by correcting the employee. Fix the rules document. A correction in chat lasts one conversation. A line in the document changes every future run, and it also makes your triage rules legible to the humans on the team, who were guessing too.

Let it apply labels, then owners

Split the two. Labels are almost free to get wrong. Assignment puts work in a named person's queue, which is a social act as much as a technical one.

Every hour, triage new Linear issues using our triage rules document.

Apply labels. Assign an owner only when the rules give a clear answer.
When they do not, apply the needs-triage label and leave it unassigned
rather than guessing.

If an issue is not actionable as written, comment asking for the
specific missing information. Be concrete about what is missing. Do
not post a generic template.

Never close an issue, never change a priority that a human has set,
and never reassign something already assigned.

The three nevers are worth keeping permanently. They are the actions that destroy human intent, and there is no efficiency argument that outweighs an engineer finding their priority silently changed.

Ask it what it keeps seeing

The pattern report is the part that pays for the rest.

Every Friday, review the issues from this week. Tell me:
  anything reported three or more times that looks like one root cause
  any area accumulating issues faster than it is closing them
  anything sitting in needs-triage for more than three days

For the first, open one issue linking the duplicates, rather than
opening a new one each time.

What good looks like

Issues arrive labelled and mostly assigned within the hour, standup stops being a triage meeting, and once a week somebody notices that the same bug has been reported five times.

The needs-triage pile is a feature. If it is empty, the employee is guessing.