UNRESOLVED

Case No. 004·Released June 17 · 2026·Runtime 27:02

The development conversation managers keep skipping for themselves

Yvette Johns spent years at Mailchimp promoting frontline support specialists into engineering roles, making the case they couldn’t make for themselves. The framework worked on everyone she pointed it at, until she turned it on herself.

▶ Now playing·Case file 004·YouTube

At Mailchimp, Yvette Johns redesigned how she screened support engineering candidates. The question wasn’t how much they knew. It was whether they could take a complex system and break it into pieces someone else could use quickly under pressure. She called it technical acumen. She used it to identify frontline support specialists who didn’t see themselves as engineers and made the case they couldn’t make for themselves, with specifics.

The development conversation that only goes one direction

Yvette knew what it took to identify potential in someone who’d already decided they didn’t have it. A manager at Mailchimp made the case to her that way: here are the ten things you’ve already done that are part of this engineering role. You can’t argue against a list. You can only decide to believe in the person who believes in you. She paid that forward, finding the same hesitancy in others and responding the same way.

For years, when her own manager tried to turn that conversation back toward her, her focus would drift to her team. Every instance. It was habit. Her job was her people, and she was good at it. The feedback confirmed it constantly. So she kept pouring in.

When she left her last leadership role, the one where she was managing other managers, she finally sat with the question she’d been facilitating for everyone else: what is it that I actually want? Not what am I good at. What do I want? She’d never had that conversation with herself.

It wasn’t until I left that role that I realized I’d never had that conversation with myself.

What Yvette built, and what she learned building it

At Mailchimp, Yvette’s support engineering team had two jobs: handle escalations and educate frontline support specialists in real time. The second job meant taking technically complex systems and explaining them clearly enough for a specialist in a live chat to absorb in about 30 seconds. That pressure shaped how she thought about what made someone effective in a technical role.

She stopped looking for candidates with deep product knowledge and started looking for people who could reason about unfamiliar systems. Knowledge was less important than what she came to call technical acumen: the capacity to take something complex and break it into its core parts, then explain it to someone else. As platforms for housing knowledge keep multiplying, she said, someone who just knows information is less effective than someone who knows what to do with it and where to find it.

She applied the same logic to promoting frontline specialists into engineering roles. When someone said they couldn’t do the job, she didn’t argue with the feeling. She came back with specifics. The list makes the case you can’t make about yourself. She’d been on the receiving end of it, and she passed it forward.

Brett described a version of the same principle from his time at Frame.io, where the customer base was professional video editors. He realized he could teach customer support, but he couldn’t teach what it feels like to manage a RED camera on set. He started hiring people with production backgrounds and teaching them support instead. Yvette agreed: a manager explaining hardware they don’t understand is a manager under unnecessary stress. Hiring for domain expertise means training time goes toward what you can actually teach.

On AI and people management, Yvette was specific about where the tool breaks down. Complex performance conversations require historical context about a person, what they’ve been through, what they’re currently trying to improve. Compressing that into a prompt is nearly impossible, and a model trained on human-written data will reflect the biases in that data. Her read: use AI to clear the operational load, the data and processes that keep managers from spending time on their people. Don’t use it to think for you when it comes to the humans.

She’d recently seen a company announce a 12 or 16-to-one manager-to-report ratio. Her concern was straightforward. That ratio assumes every report needs the same effort at the same time. They don’t. In any given month some people are at baseline and some are struggling. Add a queue spike, a company goal change, or something personal happening across the team, and most of a team can need more from one manager simultaneously. When people leave because of it, the ratio stops working anyway.

Key takeaway

Yvette built something that worked: a framework for identifying potential in people who’d already decided they didn’t have it, and a promotion path that moved frontline specialists into roles they weren’t sure they belonged in. What she didn’t do was run the same process on herself. The development conversation she became skilled at facilitating stopped at her own door. In CX leadership, where the job is defined by service to others, that’s not unusual. It’s just what the burnout looks like when it finally arrives.

Yvette stepped back into an IC role after leaving her last leadership position. She needed to find out what she wanted before deciding whether to return to management. That answer is still forming.

If you’re a CX manager burning out from pouring in, she’s worth connecting with. She’s on LinkedIn and at coravel.co. The conversation about what you actually want is the one this show keeps circling back to.

§ 02

Links mentioned

§ 03

Follow the show

Open submission · Case files in prep

Have a story to tell?

So many CX leaders are testing with AI and rebuilding with AI as their foundation. Every one of us have to reinvent everything that we’ve known about customer experience systems and processes.

You’re not alone, so let’s do this journey together.
Be a guest