The Quiet-Quitting Conversation

Marta had been one of my best backend engineers for three years. Then, over about four months, she stopped volunteering for anything. She still shipped. Her...

Originally published onanselmfowel.com
The Quiet-Quitting Conversation

Marta had been one of my best backend engineers for three years. Then, over about four months, she stopped volunteering for anything. She still shipped. Her PRs were clean, her standups were fine, her tickets closed on time. But she had gone quiet in the way that senior people go quiet when they have already decided to leave and just haven't told you yet.

The Quiet-Quitting Conversation
The Quiet-Quitting Conversation

Her manager wanted to put her on a performance plan. I told him no. I told him to buy her a coffee and ask one question: what changed? That conversation is the subject of this post, because I think most engineering leaders get it exactly backwards, and I've gotten it backwards myself more than once.

What the phrase actually describes

The term got popular as a kind of moral panic about lazy workers. That framing is useless to me as a leader. When someone on my team starts doing exactly their job description and not a gram more, that is not a character flaw I need to correct. It is a signal, and usually a rational one. Someone did a cost-benefit calculation and concluded that the extra effort no longer pays off. My job is to figure out why the math changed, not to shame them for being able to do arithmetic.

In regulated fintech this matters more than in most places, because the discretionary effort is where the safety lives. Nobody writes a ticket that says "notice the reconciliation job is silently dropping 0.2% of records." That gets caught by an engineer who cares enough to look at a dashboard they weren't assigned to look at. When people withdraw to the letter of their role, the first thing you lose is that ambient vigilance. The bugs don't announce themselves. They just start slipping through.

The conversation nobody wants to have

Marta's answer, once she trusted that it wasn't a trap, was blunt. She had spent six weeks the previous quarter fighting to get a payment-timeout fix prioritized. She had written the design doc, gotten sign-off, and then watched it get bumped three sprints in a row for a feature the sales team wanted for one large prospect. The prospect didn't even sign. Meanwhile a smaller version of the timeout bug hit production and she got paged at 2am to fix the thing she had asked to fix in daylight.

She wasn't angry. That was the worrying part. She had simply concluded that her judgment didn't move outcomes, so she stopped spending judgment. Why burn political capital arguing for the right thing when the decision gets made on other grounds anyway? So she went heads-down, did what she was told, and quietly updated her CV. I don't blame her. If I'd been in her seat I'd have done the same, and probably faster.

The engineers who stop pushing back are not the ones who stopped caring. They are the ones who learned that pushing back costs them and changes nothing. Silence is what a smart person does when they've concluded their voice is decorative.

The tells I watch for

I am not a fan of surveillance metrics, and I think most "engagement dashboards" measure noise. But there are behavioral shifts that a present manager notices without any tooling at all. They are qualitative, and they are usually about a change in someone rather than an absolute level.

  • Someone who used to comment on other people's designs goes silent in reviews, approving without engaging.
  • A person stops proposing things in retros and starts only agreeing with whatever the loudest person said.
  • The little unasked-for improvements dry up. No more "while I was in there I also cleaned up X."
  • They start asking very precise questions about scope. "Is that in this ticket?" is often the sound of a boundary going up.
  • Time-off requests cluster on Fridays and Mondays, and interviews are usually on Tuesdays through Thursdays. I am only half joking.

None of these mean someone is a bad employee. They mean someone has recalibrated. The mistake is to read the recalibration as the problem instead of the symptom. If you address the behavior with more oversight, you confirm exactly the belief that caused it, which is that effort here is met with control rather than trust.

Why the performance-plan reflex backfires

The instinct to formalize is strong, especially from HR, because a paper trail feels like control. But a performance plan aimed at a disengaged senior engineer almost always accelerates the departure it was meant to prevent. You're telling someone who already feels their contributions are invisible that now their contributions are also suspect. I have watched a solid engineer go from "maybe leaving" to "gone in three weeks" the day a PIP landed.

There is a version of this that is legitimate. If someone's output has genuinely collapsed and the coffee conversation reveals nothing fixable, then yes, a plan is fair to everyone including the rest of the team. But that is the rare case. Far more often the drop is recent, correlated with a specific event, and reversible. The plan is the manager outsourcing an uncomfortable conversation to a process. Processes don't rebuild trust. People do, in conversations, over weeks.

The causes I keep running into

Over roughly fifteen years and a few hundred one-on-ones about this exact thing, the reasons cluster tighter than you'd expect. It is almost never money first, though money is the socially acceptable thing to say last. The recurring ones are: work that gets thrown away, promises about scope or promotion that quietly evaporated, a reorg that severed someone from work they cared about, and a new manager who manages tickets instead of people.

Thrown-away work is the poison I see most in fintech specifically. We build a compliance feature for a regulation that gets delayed, or a migration that gets shelved when priorities shift, and the person who poured three months into it watches it rot in a feature flag. Do that twice to the same engineer and they learn to invest less, because the expected return on caring has dropped. That's not disloyalty. That's a portfolio manager rebalancing away from an asset that keeps losing value.

What actually moves the needle

The thing that worked with Marta was embarrassingly simple and took me too long to do. I let her own the reliability roadmap for her domain outright, including the authority to bump a feature for a fix when she judged the risk warranted it. Not a suggestion channel. Actual authority, with me backing her in the room when sales pushed. Within two sprints the timeout work shipped, and within a quarter she was back to being the person who noticed the reconciliation job was misbehaving before anyone got paged.

Restoring engagement is mostly about restoring the link between effort and outcome. If someone believes that working harder or thinking harder changes what happens, they will do it. If they believe it doesn't, no amount of ping-pong tables or recognition Slack channels will move them. The lever is almost always autonomy plus follow-through: give real decision rights, then honor them publicly even when it's inconvenient. The public part matters more than the private part.

When to let them walk

Not every case deserves a rescue, and I've learned to be honest about that. Sometimes a person has genuinely outgrown the problems you have. A staff engineer who wants to work on distributed-systems research is not going to be re-engaged by a payments platform that mostly needs careful CRUD and airtight audit logging. Trying to hold that person is a disservice to both of you. The right move is to be the reference that gets them the next job, and to keep the relationship, because good people come back.

The trap is telling yourself that story about the person you could have kept. It is a comfortable lie, because it means the disengagement was inevitable and not something you missed. The discipline is to have the coffee conversation early enough that you actually know which case you're in, rather than diagnosing it from behavior after the decision is already made in their head.

What this asks of you

The uncomfortable truth is that quiet quitting is usually a lagging indicator of a leadership decision made months earlier. Every time I've dug in, I've found a moment where I, or a manager reporting to me, chose the expedient thing over the credible thing. We bumped the fix. We softened the promotion timeline. We let the reorg happen without walking someone through why. Each of those was defensible in isolation and corrosive in aggregate.

So the practice I try to hold myself to is to keep a mental ledger of the promises the organization has implicitly made to each senior person, and to notice when we're about to break one. Not because I can always keep them, but because I can at least go tell the person myself, before they find out by watching their work get shelved. That five-minute conversation buys more loyalty than a year of perks, and it costs nothing but the discomfort of being straight with someone.

Anselm Fowel, CTO and fintech architect
Anselm Fowel — CTO & fintech architect

The favor they're doing you

Here is the thing I'd tell my younger self, the one who wanted to fix disengagement with process. The quiet engineer is doing you a favor. They're showing you exactly where your organization stopped being trustworthy, and they're doing it politely, by simply declining to give you the discretionary effort you were never entitled to in the first place. Go have the coffee. Ask the one question. And then be prepared to do something with the answer, because the fastest way to turn a quiet quitter into a resignation letter is to ask what's wrong and then change nothing.

Chat with us