One tip: Make sure that tickets (both bugs and support requests) make sense.
Meaning: Make sure that you're either running, or involved with, ticket triage. No ticket should go to an engineer without a basic review. (Edit: 2-3 minutes a ticket)
What are things that you should look for, before assigning a ticket to an engineer?
- Is the title and description coherent? Written in decent English (or whatever language your office uses.)
- Did whoever submit the ticket do an appropriate amount of troubleshooting for their role? (Or are they just trying to pass work off on your engineers?) Specifically, if this is a support escalation, did the submitter follow any troubleshooting steps that you've already documented?
- If this is a bug, do the steps to reproduce make sense?
- Do your processes require things like logs, screenshots, videos, ect? Are they present? (Edit: QE and support need to be trained on what kind of information to collect before passing a ticket to your team. Being a "team player" means holding other groups accountable for providing your engineers what they need to do their jobs.)
- Is this a duplicate of a well-known issue?
- Is the bug steered to your team appropriately, or should a different team take the first attempt?
- [Edit] Are there multiple bugs / support requests in a single ticket? (I have a firm one-bug-per-ticket, or one-escalation-per-ticket rule. It just gets too confusing otherwise.)
The above shouldn't take long. Specifically, during triage, you aren't trying to understand the bug or escalation. You're just making sure that whoever wrote the ticket put in enough knowledge that you're comfortable handing it off to your team.
When a ticket doesn't make sense, just send it back to whoever wrote it. You might need to meet with other managers to make sure that everyone understands what you need, and expect, prior to assigning work to your team.
The point is that you should be the filter blocking other teams from sending crap to your engineers. You can also involve your team members in triage, as long as your team members understand the difference between triage and actively working on a bug.
What happens when you don't triage well? Bugs pile up on your team and don't get solved. Some engineers will be good at asking for clarification for bad bugs, other engineers will just let them sit.
In this case, when tickets aren't being resolved, the solution is to re-triage and send back poorly-defined tickets.
Meaning: Make sure that you're either running, or involved with, ticket triage. No ticket should go to an engineer without a basic review. (Edit: 2-3 minutes a ticket)
What are things that you should look for, before assigning a ticket to an engineer?
- Is the title and description coherent? Written in decent English (or whatever language your office uses.)
- Did whoever submit the ticket do an appropriate amount of troubleshooting for their role? (Or are they just trying to pass work off on your engineers?) Specifically, if this is a support escalation, did the submitter follow any troubleshooting steps that you've already documented?
- If this is a bug, do the steps to reproduce make sense?
- Do your processes require things like logs, screenshots, videos, ect? Are they present? (Edit: QE and support need to be trained on what kind of information to collect before passing a ticket to your team. Being a "team player" means holding other groups accountable for providing your engineers what they need to do their jobs.)
- Is this a duplicate of a well-known issue?
- Is the bug steered to your team appropriately, or should a different team take the first attempt?
- [Edit] Are there multiple bugs / support requests in a single ticket? (I have a firm one-bug-per-ticket, or one-escalation-per-ticket rule. It just gets too confusing otherwise.)
The above shouldn't take long. Specifically, during triage, you aren't trying to understand the bug or escalation. You're just making sure that whoever wrote the ticket put in enough knowledge that you're comfortable handing it off to your team.
When a ticket doesn't make sense, just send it back to whoever wrote it. You might need to meet with other managers to make sure that everyone understands what you need, and expect, prior to assigning work to your team.
The point is that you should be the filter blocking other teams from sending crap to your engineers. You can also involve your team members in triage, as long as your team members understand the difference between triage and actively working on a bug.
What happens when you don't triage well? Bugs pile up on your team and don't get solved. Some engineers will be good at asking for clarification for bad bugs, other engineers will just let them sit.
In this case, when tickets aren't being resolved, the solution is to re-triage and send back poorly-defined tickets.