From 300 open tickets to fewer than 10: how WIP limits fixed my controls team's backlog

When I stepped into the role of leading the controls and electrical engineering teams, coming straight out of my Black Belt assignment, one of the first problems on my desk was a ticketing system.

The business used it to manage questions and problems from the field. Over time, the work assigned to the controls team had grown to more than 300 open items. Our service team was frustrated because their issues sat waiting. My engineers were exasperated because they were being pulled in every direction at once. They had project work and product development to deliver, with project managers on site pushing them every day, and a pile of field tickets that never seemed to shrink.

Everyone knew it was bad. Nobody knew how bad.

The math that became our burning platform

I started by measuring two things: how fast new tickets were coming in, and how fast the team was closing them. Pulling from my experience as a Lean Six Sigma Black Belt, I turned to Little’s Law, one of the most useful and least known tools in process improvement:

Lead time = Work in process ÷ Throughput

In plain terms, how long something waits depends on how much is already in the queue and how fast the queue gets worked. With 300+ tickets and the rate we were closing them, the answer was sobering. If the team kept working the way it was, it would take several years before a brand-new issue got addressed.

That number changed the conversation. It wasn’t a complaint from the service team or a feeling of being overloaded anymore. It was a fact, and it became the burning platform I used to show the team that something had to change.

What counted as work in process

Our WIP was the set of open support tickets, and they covered everything: software bugs, drawing errors, requests for clarification, simple questions, performance shortfalls, and issues that had shut a site down.

What we changed

We didn’t ask anyone to work faster. We changed how work flowed to them.

We cleared out the dead wood. We started with a push to close stale tickets that no longer needed action, so only real issues were left. That only took us to just under 300, but it meant every remaining ticket was real.
We made the work visible. Working with the team, we set up a visual management board and a kanban system with sticky notes, similar to what agile software teams use. Each week, in a short planning session, the next tickets from the system went onto sticky notes on the board.
We protected time for it. Each engineer had a four-hour window every week to work only on tickets. Field issues stopped competing minute by minute with project deadlines.
We capped work in process per person. This was the big one. We ended up putting all of each engineer’s work on the board, not just tickets, and set a cap of three items per person at any time. You finish something before you pull the next thing.
We set a team-level andon. Once the backlog came down, 20 open tickets became our trigger. If we crossed it, I made a decision to put more time or people on tickets until we were back under the cap.

The board also changed how work was assigned. Instead of a manager pushing tickets at people, engineers pulled the next item when they finished one.

The pushback

The first resistance came from my most experienced engineers. They were the fastest at resolving issues, and I think they felt they had to be the ones to solve every problem, even as they complained they never had time. Showing them the Little’s Law calculation was sobering. They were an amazing team of extremely talented engineers, and seeing this harsh reality was enough for them to get on board quickly. This was further aided by the fact that I involved them in coming up with the solution.

The second came from project managers, who worried that time spent on field issues was time taken from their projects. The board answered that too. They could see exactly what each engineer was working on, and the WIP cap made everyone more efficient. In the end, the project managers saw the benefit as well.

The results

In about two months, the open ticket count dropped from more than 300 to fewer than 10, and it stayed there. With WIP stable around 10 and the andon set at 20, the team could respond to almost everything quickly. Urgent issues were handled immediately, and even less critical items got answers within hours or days.

What had been the team’s biggest pain point became one of the organization’s bright spots, and everyone could see it.

The part that surprised me most: we did nothing to make anyone work an individual ticket faster. The gains came entirely from focus. People could concentrate on a few things, with a clear goal of finishing them, instead of switching between a dozen.

What I’d tell an engineering manager to try on Monday

Involve your team in the solution. You have very smart, talented people. Bringing them into the process lets you draw on their abilities and earns their buy-in from the start. After all, they’re the ones who will live with the process.
Make the queue visual and visible. When everyone can see what’s being worked and what’s waiting, communication outside the team gets easier and the team can direct itself, pulling new work as fast as it finishes.
Limit work in process for every engineer. People can’t multitask. Letting engineers focus on a few things and finish them before picking up the next one does more for throughput than any amount of pushing.
Do the math. Measure what comes in and what goes out, and apply Little’s Law. A wait time measured in years will get attention that “we’re overloaded” never does.

The side effect I didn’t expect was morale. Less task switching meant less stress, and the team was happier doing the same work. Visible work and WIP limits sound like process tools, but in practice they’re about giving people the room to do their best work.