Software naturally grows an ever-increasing list of problems. Someone cannot finish a registration. A report produces the wrong total. Staff have learned to avoid a particular button. Meanwhile, a pileup of support tickets arrive, all marked “urgent”.
When your development team is small, you cannot fix everything at once. Start with problems that put people or important information at risk, then weigh the task being blocked, the people affected, the cost of working around it, and any real deadline. Consider effort after you understand the consequences.
That gives you a more useful question than “Which ticket should we tackle next?”
What becomes possible for people when we fix this?
Describe the interrupted task
“The export is broken” tells a developer where to begin looking. It tells the organisation very little about priority.
“Our administrator cannot produce the attendance list needed for tomorrow’s event” adds the missing context. Now there is a person, a task, a consequence, and a deadline.
For each problem, write a short account of what someone was trying to accomplish and what happened instead. Record how often it occurs and whether they can complete the task another way. Distinguish what you know from what you suspect.
One of my favourite personal experiences: I once received an support email with the subject line, "it's not working." No email body. No explanation. Not even an indication of what customer account to check.
Mozilla’s bug-writing guidance recommends clear steps to reproduce a problem, alongside expected and actual results. That technical evidence matters for the actual fix. But the human context is key for deciding why the problem deserves attention.
Separate impact from urgency
Two useful ideas often get bundled into one label.
Severity describes how serious the failure is. Priority describes how soon your team should act. They inform each other, but they are not interchangeable.
A complete failure in a little-used planning tool might have less immediate operational impact than a smaller failure in a registration process closing this afternoon. Timing and circumstances determine how important the issue is.
Atlassian’s guide to bug triage identifies severity, impact, and project deadlines as inputs to prioritization. For a small team, make those inputs concrete:
- Is an essential task blocked, or merely awkward?
- Who is affected, and what happens to them?
- Is there a dependable workaround?
- Is there a real deadline, or just a preference for speed?
Issue reoccurrence isn't a good measure all on its own. A failure that prevents a few people from using an essential service can deserve attention ahead of an inconvenience affecting many.
Count the cost of the workaround
“Staff can do it manually” can sound reassuring because at it can still get done. But it means that a software problem has mutated into a staffing problem.
A manual workaround can put inordinate pressure on staff to remember everything required to correctly set something up by hand.
In a SaaS product I work on, there is an automated process that creates new accounts and provisions all kinds of services. All of these can be set up by hand, but it requires working from a lengthy checklist, and requires at least 20 minutes. Whereas the automated process takes about 10 seconds.
So, "staff can do it manually" is true, but painful. The software still works, but a person is supplying the functionality.
Ask the people doing the work how they get around the problem. Watch the process if you can. Record the time involved and whether the workaround depends on one experienced staff member remembering an unwritten rule.
Keep estimates honest. A week of observation is more useful than a confident annual savings figure built on guesswork. Label what you measured and what you estimated.
Fixing a recurring workaround may free time for the organisation’s actual work. It may also make the process easier for a new colleague to learn. Both belong in the decision.
Make room for diagnosis
A list of reported symptoms is not necessarily a list of separate repairs.
A failed confirmation email, an apparently incomplete registration, and a missing dashboard entry might share one underlying cause. Alternatively, similar complaints might come from unrelated problems. Your team needs evidence before deciding.
For an unclear issue, assign a bounded investigation. Specify the question it should answer: Can we reproduce this? Which records are affected? Did it begin after a recent change? Is the failure limited to one stage of the process?
The outcome should be something usable: a reproduction, an explanation of the affected scope, a proposed next step, or a clear statement of what remains unknown.
This is particularly helpful when outside support joins an internal team. A focused investigation gives both parties a defined responsibility without requiring an outsider to understand the entire application before contributing.
Choose the work before choosing the easy work
Once you understand impact and urgency, consider effort, dependencies, and the risk of making the change.
An easy fix is welcome. It should not automatically outrank a serious problem simply because it fits neatly between meetings.
For the routine queue, use a few plain-language decisions: act now, schedule next, investigate, or defer with a review date. Define what those decisions mean for your organisation. Keep the immediate commitments small enough that your team can finish them.
If a major repair cannot begin yet, record what happens meanwhile. Is there a safe workaround? Who explains it to staff? What event would require escalation? A priority label without an interim plan does little for the person still encountering the problem.
You do not need a mathematically elaborate score. Numbers can help compare recurring work, but multiplying uncertain estimates together can produce an impressively precise guess. Keep the reasoning visible.
Give someone authority to decide
Developers can explain technical risk and likely effort. Support staff can describe repeated complaints. Operations staff understand the workarounds. Someone responsible for the service needs to bring those perspectives together and decide the order.
In a small organisation, one person may hold several of these roles. The important thing is to name the responsibility rather than leave every request to become a negotiation.
Use a shared record, whether that is your existing task board or another tool your team already trusts. Record the decision, its reason, the next owner, and when it will be reviewed. New evidence can change the order. The reason should change with it.
Define what “fixed” will mean
Before work begins, describe the successful outcome in terms the affected person can recognise.
“Change the export code” describes an activity. “The administrator can download the complete attendance list” describes a result.
Ask the developer to verify the original failure and relevant neighbouring behaviour. Then have the person responsible for the task confirm that the result meets the need. Let affected staff know when they can stop using the workaround.
A closed ticket is useful. A restored task is the point.
For your next maintenance review, choose five unresolved problems. Add one sentence to each: “This prevents ___ from doing ___, and the current workaround is ___.”
Bring those descriptions to the people who understand the service and the people who maintain it. Agree on the next action for each. You will have a clearer starting point than five competing versions of “urgent”, and a much happier work life.
