Granola's CX team doesn't just file bugs, they fix them. Here's how empowering support agents with coding tools transforms the engineering relationship.

At most companies, the CX team's relationship with engineering follows a familiar pattern: support finds the bug, writes up the ticket, and waits. The fix comes when it comes. The customer waits longer.

At Granola, the AI notepad app for people in back-to-back meetings, CX Lead Vicky Firth is rewriting this playbook. Her team has Cursor open alongside their support tickets, and they're not just reading the codebase. They're shipping code.

"We'll ask Cursor questions about what causes that error message, what could be going on here, is this actually maybe a bug. But above that if there's a small code fix that we're pretty sure on, we're welcome to try and make that. An engineer can review and work with us."

— Vicky Firth, CX Lead at Granola

From Black Box to Open Book

The shift started with a mindset change. Most support professionals see code as a mysterious black box—something you hand over to engineers to work their magic. Firth's early career in a coding bootcamp gave her just enough exposure to know it wasn't as inaccessible as it seemed.

"I think that can be a myth—that when you're non-technical, it feels like this whole other level of thing that you can't even possibly access. A lot of the terminology is not as scary as you think."

At Granola, the team started small. Read-only database access. Cursor for chatting with the codebase. No code changes at first—just understanding.

"You can chat with the codebase and work out, what does that error message mean? What are the limitations on this thing? That's a great starting place."

Then, gradually, more. Small scripts. Then writing those scripts themselves. Then internal tools. Now, Firth's team builds and modifies their own admin dashboards—the tools they use every day.

Taking Control of Your Own Tools

For anyone who's worked in support, the internal tooling problem is painfully familiar. Engineering time goes to the product, not the admin interface you're stuck clicking through eight times a day. That button placement that drives you crazy? That extra step to look up user information? Not a priority.

"Having that power back in your hands is incredible. I hate that I have to click two buttons to get to that place. We're able to just make a code change to literally have control of the tool that we are working in."

This extends beyond tooling. Even small product improvements—the kind that reduce customer confusion but would never make the sprint—are now in reach.

"Even if it's just a small copy change, having that power to say, you know what, I think just tweaking that word will actually make people less confused. We'll sync with the appropriate product person to check, but it just really empowers the team."

What About the Engineering Bottleneck?

The obvious concern: doesn't this just shift the bottleneck? Previously, engineers needed to understand the problem. Now they need to understand the problem and review code from non-engineers.

Firth's answer comes down to scope and investment.

"We're not going to re-architect an area of the app from our side. It's going to be small scope. Things we see regularly. Things that are quite clear. But we all see it as an investment into the future. By reviewing that and teaching us the skills, you're really investing in us being able to upskill ourselves even further."

The result? Engineering sees CX differently.

"Our engineers are like, 'Oh my God, our customer experience team are incredible,' which I'm very proud of. We have these great relationships because we can work as equals."

Avoiding the "Fun Distraction" Trap

Could the ability to tinker with code become a distraction from the queue? Firth acknowledges the risk but points to hiring and culture.

"We have quite a high bar of hiring. We really want to find people who want to fix people's problems and do the most impactful work. Perhaps they'll go on the odd side quest. But I think the focus always comes back because we know that's going to have the biggest value."

She frames it as a trade-off worth making:

"The level of empowerment - you could go and do that, but you know what your role is, we trust you, go and do what you need to do."

The alternative? The old failure modes: "Teams that aren't empowered, you see other behaviors like cherry-picking simple tickets or not giving high-quality responses."

A New Career Path for Support

Perhaps the most lasting impact is what this does for career development in support. The traditional paths of team lead, customer success, specialist are limited. Coding tools open new directions.

"The more tools we let teams get empowered by, the more routes people have to say, 'This is the area I really am interested in. This is what I want to deep dive in.'"

For CX leaders considering this approach, Firth's advice is to start small:

"Start with read-only access to a database. Make sure it's clear an engineer should review any code changes. Taking small bits at a time, thinking what's just one thing that would be helpful."

It can feel new and scary. But the tools have made the gap between "technical" and "non-technical" smaller than ever.

"I strongly believe that a customer support team can leverage so much in the business and bring so much insight. If you see them as central to your business, rather than this kind of outsourced cost center, they can bring so much value to everyone."

The future of support may not just be faster responses, it may be support teams that ship.

Want to hear the full conversation? Listen to Vicky Firth on The Squawk podcast.