Latest / The Operator's Manual with Fexingo: Daily Decisions, Tactical Wins, and Business Execution / How One Utility Cut Interconnection Delays 80 Percent With a Queue Change
Transcript
- Lucas: So there's a number that's been bugging me all year: over two terawatts of solar and storage projects sitting in interconnection queues across the US, waiting for permission to plug into the grid. And the average wait time has stretched past five years now. Luna: Five years. That's longer than some projects' entire development timeline. And it's not like the grid is expanding just for fun — that's capacity that could be generating power or storing it. Lucas: Right, and it's a massive bottleneck for the whole energy transition. But today I want to talk about one utility that decided it wasn't going to accept the status quo. They cut their interconnection queue time from around three years down to under nine months in a little over eighteen months. And the lever they pulled wasn't a giant capital investment or a new federal policy — it was a change to how they prioritize and review the applications they already had. Luna: Okay, that's the kind of story I want to unpack. So what was the actual change? Did they just hire more engineers? Lucas: Not exactly. They did add a few headcount, but the core shift was moving from a 'first-come, first-served' queue to a 'first-ready, first-served' model. In the old system, a project developer could submit a half-baked application, get a place in line, and then take years to finalize their studies. That gummed up the works for everyone behind them. The new system requires a complete application upfront, with all the technical data and deposits in place, before you even get a slot. Luna: So it's like the difference between waiting in line at the DMV with a stack of incomplete forms versus showing up with everything ready and getting called to the window first. Lucas: Exactly. And it sounds obvious, but the resistance was huge. Developers had gotten used to the old way. They'd reserve a spot early even if their project was years away from shovels in the ground. The utility had to effectively tell them, 'We're not going to let you hold a spot hostage anymore.' There was an 18-month transition period where they worked through the legacy queue, then they flipped the switch. Luna: And what happened to the projects that weren't actually ready? Did they just get kicked out? Lucas: Pretty much. They had a 'use it or lose it' clause. If you didn't progress to the next stage within a certain window, you got a warning, and then you were out of the queue. It was harsh, but it cleared out a ton of zombie projects. In the first year, they processed more than double the number of applications they had in the previous two years combined. Luna: That's a huge throughput jump. But I have to wonder — did the quality of the applications improve, or did they just let in more junk that had to be rejected later? Lucas: Good question. The data shows the rejection rate actually dropped. Because the upfront requirements forced developers to do more engineering work before they even applied. They had to have a site control, a signed interconnection agreement with the transmission owner, and a detailed equipment spec. That weeded out the people who were just speculatively reserving capacity. Luna: So it's a bit like the difference between a soft credit check and a hard pull. The friction up front prevents a lot of wasted effort later. Lucas: Precisely. And here's the thing — the utility didn't just change the rules. They also redesigned the internal workflow. They created a triage team that did a first-pass review within two weeks of receiving an application. If anything was missing, it bounced back immediately instead of sitting in a pile for six months. That alone cut the average first-response time from 120 days down to 11. Luna: Eleven days is a big deal. I mean, in most industries, that would be a dream. But you mentioned software earlier — what role did automation play? Lucas: They implemented a system that could automatically check for completeness against a checklist of required documents and even run some preliminary feasibility models. So instead of an engineer spending an hour reviewing a 300-page application, the software would flag the top five issues before a human ever opened it. That let their engineers focus on the actual technical studies instead of administrative triage. Luna: And that's the kind of thing that scales. You don't need to hire a thousand engineers to review a thousand applications if you can automate the first pass. But did the developers actually see a difference in their experience? It's one thing to have a faster queue on paper — but were they happy? Lucas: Actually, yes. A developer survey they ran showed satisfaction scores jumping from something like 2.1 out of 5 to 4.3. The developers said the biggest win wasn't just the speed — it was the predictability. They knew exactly when they'd get a response, and if there was an issue, they found out in days, not months. That let them plan their financing and construction timelines with confidence. Luna: That's the hidden cost of a long queue, right? It's not just the wait — it's the uncertainty. You can't tell investors when your project will actually come online, so you can't secure financing or power purchase agreements. Lucas: Right, and that uncertainty had real dollar figures attached. Some estimates put the cost of queue delays at tens of billions of dollars in stranded projects and lost revenue. By cutting that time, this utility essentially unlocked a pipeline of viable projects that had been stuck in limbo. They now have a waiting list of developers who specifically want to interconnect in their territory because the process is faster. Luna: So they turned a bureaucratic bottleneck into a competitive advantage. That's the kind of thing that doesn't show up in a typical efficiency report, but it's massive for their long-term growth. Lucas: And it's a great example of a principle that applies way beyond the energy sector: when you have a backlog, the first question isn't 'how do we process faster?' It's 'are we processing the right things?' Moving from first-come to first-ready is a mindset shift that any business with a queue can apply — whether it's a customer support ticket system, a loan application pipeline, or a permitting process. Luna: I love that. And it's a reminder that sometimes the highest-leverage change is in the rules of the game, not just the speed of the players. Lucas: Exactly. But there's one more layer to this story that I think is worth digging into. The utility also started publishing real-time metrics on where projects were in the queue — how many were in study, how many were in the final agreement phase, and what the average processing time was for each stage. That transparency did two things: it put pressure on the internal team to keep the numbers moving, and it gave developers a clear picture of what to expect. Luna: Transparency as a performance tool. I've seen that in other contexts too — like how some airlines publish on-time performance stats and suddenly their gate agents start hustling a little harder. Lucas: Ha, exactly. And the utility didn't stop there. They also created a 'fast track' lane for smaller projects under five megawatts. Those get a simplified study process because their grid impact is minimal. That faster lane now handles about 40 percent of all applications, and those projects get through in about four months. Luna: So they segmented the queue by complexity. That's like a hospital having a separate line for minor injuries so the ER isn't clogged with sprained ankles when someone's having a heart attack. Lucas: Exactly. And it's that kind of thinking that gets results. In the first year, they interconnected 2.8 gigawatts of new capacity — that's more than the previous five years combined. And the queue is still growing, but they've proved they can process it without the backlog spiraling out of control. Luna: That's a tangible win. And it's a great case study for our listeners who are dealing with their own bottlenecks. Sometimes the answer isn't more resources, it's a smarter triage system. Lucas: Yeah, and on that note — you know, we spend a lot of time on this show talking about exactly these kinds of operational fixes. And if these conversations have given you a new idea or helped you solve a problem at work, that's genuinely the best outcome we could hope for. And if you want to help us keep doing this, there's a simple way to support the show — you can buy us a coffee at buy me a coffee dot com slash fexingo. It's a small gesture, but it helps us keep the lights on and the episodes ad-free. Luna: Yeah, and it genuinely takes five minutes. There's no subscription, no recurring charge — just a one-time coffee if you feel like it. We really appreciate it. Lucas: Okay, back to the utility. Because there's a broader lesson here that I think is worth unpacking. When they made this change, they didn't just tweak a process — they changed the culture of the organization. The engineering team went from being gatekeepers to being partners. They started proactively communicating with developers about what was needed to get through the process, rather than just rejecting applications that didn't fit the old mold. Luna: That's a huge shift. It's the difference between a bouncer at a club and a concierge. Both are at the door, but one is trying to let people in. Lucas: Right. And that cultural change was actually the hardest part. The technical changes — the software, the checklist, the fast-track lane — were straightforward. The hard part was convincing engineers who had been doing things the same way for twenty years that a faster process wouldn't compromise safety or reliability. They had to show them that the new system still included rigorous studies, just in a more efficient order. Luna: How did they win that buy-in? I imagine that's not easy. Lucas: They brought the engineers into the design process from day one. Instead of rolling out a top-down mandate, they formed a working group with representatives from engineering, legal, and even a couple of developers. They mapped out every step of the old process, identified the delays, and then co-designed the new workflow. That meant the people who had to live with the changes actually owned them. Luna: So it was a participatory redesign, not a directive. That's a textbook example of change management. Lucas: It is, and it's a big part of why the numbers moved so fast. They also started an internal 'war room' — a weekly meeting where the team reviews the current queue status and flags any project that's been stuck for more than thirty days. That forced escalation and accountability. Luna: A war room is a great idea for any bottleneck. It turns a nebulous problem into a concrete list of things to unstick. Lucas: Exactly. And the result is that this utility went from being a laggard to being a model for the industry. In fact, a couple of other utilities have already reached out to them to learn how they did it. There's even talk of adopting a similar first-ready-first-served model at the regional level. Luna: That's great to hear. It's rare that a good idea spreads so quickly, but when it's backed by real numbers, it's hard to argue with. Lucas: For sure. And I think the takeaway for our listeners is this: if you have a queue that's piling up, don't just throw more people at it. Step back and ask whether the queue itself is set up the right way. Are you processing in the order people showed up, or in the order they're ready to be processed? Are you making it easy for the good projects to move through, or are you letting the bad ones clog the system? Luna: And the answer might be a simple rule change that unlocks massive value. I'm sure there are a lot of listeners hearing this and thinking about their own 'interconnection queues' — whether it's a support ticket backlog or a product development pipeline. Lucas: Yeah, and if you want to dig deeper into the mechanics of queue design, there's a great paper by the Lawrence Berkeley National Lab that analyzes interconnection queue data across the country. It's a bit academic, but the findings are fascinating. We'll link to it in the show notes. Luna: Perfect. I think this is one of those episodes where you come away with a concrete idea you can apply immediately. I know I'm going to look at my own to-do list differently. Lucas: Ha, me too. That's the goal. Thanks for listening, and we'll catch you in the next one.