Why your team is probably working on the wrong bugs, and why they don't know it.
One of the first things I do when I walk into a new engineering organization is look at the bug queue. Not because I'm a bug-metrics person (I'm not) but because bug queues tell you things about organizational health that sprint data doesn't. The queue is where pressure from the outside world meets a team's internal capacity to respond, and how that collision gets managed says a lot.
There's a reason I care about this beyond Engineering hygiene. As the top-level Engineering leader in most organizations, I own quality. Where there's a Quality team, it typically answers to me. That creates a real tension: I'm trying to care for the people building the product while simultaneously reasoning about what the product's current health is costing the business. How much friction is the defect backlog creating? What level of investment do we need to make to get ahead of it? Those questions require data, and data requires visibility. Without visibility into what's actually broken, I'm flying blind on both sides of that equation.
In a recent role, I pulled up the Jira board and immediately noticed something odd. Every single bug in the system had been created by an engineer. Not a single ticket sourced from Customer Support. Not a product manager, not a customer, not a support request. Just engineers, all the way down.
That's unusual enough to raise a question: is this all the bugs? Or are these the bugs that engineers happened to decide were worth writing down?
The answer, as I started poking around, was the second one.
The bugs weren't in Jira. They were in Slack.
There was a channel where Engineering and Customer Support were collaborating on customer-reported issues. In real time, constantly. When a customer hit something, a Customer Support rep would drop it in Slack. An engineer who happened to be paying attention might pick it up. If they chose to work it, they might create a Jira ticket. If they didn't, the issue would just sort of evaporate. Sit there unanswered or get resolved via a one-off Slack message, no record anywhere.
The result was a defect system that was, at best, a partial view of reality. The real defect queue lived in a Slack channel that nobody had formal ownership of, nobody was triaging, and nobody was tracking. The Jira board was a collection of bugs that engineers had self-selected for visibility. Everything else was in the shadows.
This is the part that usually gets skipped when people talk about bug triage failures. Everyone talks about priority inversion, P2s getting worked while P0s sit. The more fundamental problem is work that isn't captured at all. You can't invert priorities you don't know exist. And you can't be accountable for doing the right things when everything is hidden.
Recency bias is not a triage system
Once I understood that the real queue was in Slack, the pattern started making sense. What passed for prioritization in this org was almost entirely driven by recency. The most recent thing got worked on. Anything that was a day or two old was out of sight, and without active visibility, out of mind. Engineers were constantly firefighting whatever fire had started most recently, not the biggest or most important one.
Customer Support had noticed this from their side. Their experience was blunt: if something didn't get picked up immediately, it never got picked up. An issue that didn't get a response in 24 hours was effectively dead. They'd learned to re-surface things just to get attention, which added noise to the channel and trained engineers to respond to volume rather than urgency.
For their part, engineers weren't being malicious or even particularly negligent. They were underwater. Full-time fire mode. When you're just trying to keep up with the incoming rate of issues, you work what's in front of you. The recency bias wasn't a choice, it was the default behavior of a system with no prioritization structure and a constant stream of new inputs.
The inversion was real, but it was a symptom. The root cause was invisible work and the absence of any mechanism to assign priority before picking things up.
The fix nobody asked for: don't blow up their workflow
My first instinct in situations like this is usually wrong. Or rather: the instinct is right, but the implementation is off. The right answer involves a unified system, priority labels that mean something, and a real triage process, but all of that is correct in the abstract and completely useless if nobody uses it because it's too much overhead on top of a job that's already overwhelming. If your solution requires people to fundamentally change how they work every day, you're going to get justified resistance.
I don't have a playbook for these situations. I have a toolbox. And the first thing I reach for is: where do people actually work, and how do I fit the solution around that instead of expecting them to fit themselves around the solution?
Customer Support wasn't going to use Jira. They had their own tools, their own workflow, and asking them to learn another system to report bugs was adding friction to people who were already stressed. Engineering wasn't going to abandon their board. The Jira setup was messy, but it was theirs.
The solution that actually worked started with capturing the work without changing how it got reported. I built a Jira form linked directly in Slack. Customer Support fills out a form in the channel they're already in, a ticket gets created automatically, and a Zapier integration posts the ticket back into the thread. The Slack conversation continues, but now it's anchored to a Jira ticket, and every comment in that thread gets synced back to the ticket. No new tool, no context switch, no asking underwater people to adopt overhead they don't have time for.
The second piece was giving everyone a single view into Customer Support-sourced work without disturbing Engineering's board. I built a separate dashboard that surfaced everything Customer Support had reported, regardless of where it sat in Jira, sorted top to bottom by priority. Customer Support had a single place to check status. I had a single place to triage and set expectations. Engineering could see what was actually out there and pick work that mattered rather than work that was recent.
None of it worked until we dealt with the vocabulary problem. The severity labels in Jira existed, but nobody was using a consistent definition. "P0" meant different things to different people. Before any of the tooling mattered, I needed Customer Support and Engineering aligned on what each level meant and what the associated expectation was. How fast should a P0 be acknowledged? How fast should it be resolved? That shared vocabulary is the foundation everything else sits on, and it's almost always the thing that gets skipped.
Data as a forcing function for accountability
Once the workflow was running and there was a few weeks of actual data, something important became possible that hadn't been before: accountability.
This is what I was actually after. Getting everything into the system and wrapping data around it wasn't an end in itself. It was the prerequisite for being able to look at the team, and have the team look at itself, and ask whether we were doing the right things. You cannot hold anyone accountable, including yourself, for something that's invisible.
I didn't have to tell anyone they were doing it wrong. I just showed them the numbers. We're creating this many P0s per week. We're resolving this many. The backlog is growing. Here's a P0 that's been open for eleven days.
That last one gets attention. An eleven-day-old P0 creates two useful conversations. The first is with Customer Support: was this actually a P0, or did we mislabel it? Maybe it was really a P2 and the label is inflating the severity. The second is with Engineering: if this really is a P0, why hasn't it been touched? That conversation is the triage mechanism working the way it's supposed to, as an organizational sanity check, not as a performance review.
The goal in these conversations was never to assign blame. It was to get to a shared understanding of what we owed our customers and whether we were delivering on it.
Managing up and across
There's a third thing visibility buys you that doesn't get talked about enough: the ability to protect your team from the rest of the organization.
At this company, there was a weekly operations meeting. It was a small company, so the room included the CEO, the CFO, a couple of people from Customer Support, and a couple from Engineering and Product. We talked about running the business. And without fail, quality came up. Every week. People would drum on specific things that weren't getting fixed, express frustration about the pace of resolution, and I had essentially nothing to say back. The team was working, but I had no information. I couldn't tell anyone what was getting fixed, how much labor we were spending on defects, or what it would actually cost to prioritize the things they were complaining about. I was walking into that meeting empty-handed every week.
Once the system was in place, that changed. I now had data showing how much of the team's capacity was going toward defect repair. I had a ranked list of what was being worked and what wasn't. And when someone in that meeting pointed at a specific bug and asked why it wasn't fixed yet, I could answer the question: it didn't rise to the level of the things we were already working on. Here's what's above it. What would you like us to deprioritize to address it?
That reframe matters. It shifts the conversation from "Engineering isn't fixing things" to "Here are the tradeoffs, and you're now part of making them." It builds trust with the executive team because they can see the work and the reasoning. And it protects the Engineering team from being blamed for prioritization decisions that were never really theirs to begin with. Without a structured system, those decisions were just defaulting to recency, and nobody had agreed to that.
The retention argument
There's a version of this story where I make the customer relationship case: unresolved high-severity bugs damage trust, damaged trust puts revenue at risk, and so on. That's all true. But the argument I find myself making more often is about your people.
Engineers who spend their careers in full-time fire mode turn over. Not always immediately, and sometimes not loudly, but they do. The engineers who have options will eventually go somewhere where the work feels less futile. A mark of a healthy Engineering organization is limited turnover, and high turnover is frequently a signal that the environment is too chaotic to feel sustainable.
The path out of fire mode runs through prioritization. And prioritization requires visibility. The accountability structures I put in place weren't only about product health or customer satisfaction, they were about creating an environment where the team could do their best work instead of constantly reacting to whatever came in last.
Priority inversion is the thing people name. But the thing underneath it is almost always an information problem. The team isn't making bad choices. They're making default choices in the absence of structure, and default choices in an interrupt-driven environment trend toward whatever was most recently on fire. Make the work visible, agree on what it means, and the data will make the difficult conversations easier.
I write about engineering leadership and team health in the Engineering Health newsletter on LinkedIn. Search "Engineering Health" to find it.
