The Leadership Conversation Nobody Practices
The email you need to send when your engineer seems off and you don’t know how to ask.
Your senior engineer has been quieter than usual. Shorter Slack messages. Camera off in standups for the third week in a row. She shipped clean code last sprint — merged two PRs ahead of schedule, actually — so nothing’s technically wrong. But something is off. You noticed it on a Tuesday, and by Thursday, you’ve constructed three possible explanations: personal life, burnout, or dissatisfaction with the project. You’ve ranked them by likelihood. You’ve drafted an opening line in your head, discarded it, and drafted another one.
You haven’t sent anything.
Not because you don’t care. You care more than she probably realizes. But you don’t know how to open a conversation like this without sounding like HR conducting a welfare check. You don’t know whether to name the pattern you’re seeing — “I’ve noticed you’ve been quieter” — or wait for her to bring it up in your next 1:1. You’ve read about psychological safety and radical candor and active listening. You still don’t know what to actually write when the compose window is open, and the cursor is blinking.
So you wait. And two months later, when she puts in her notice, you sit with the knowledge that the conversation you avoided was the one that mattered most.
Every engineering manager has a version of this story. The details change — the quiet engineer, the underperformer whose work is fine but whose energy has vanished, the high performer whose Slack tone has gone cold — but the structure is the same. You notice something. You don’t act on it. Time passes. The situation deteriorates into something harder to address than it would have been at the beginning.
The conventional wisdom says this is a courage problem. You were afraid of the awkwardness, the vulnerability, the possibility that asking “are you okay?” would surface something you’re not equipped to handle. And courage is part of it. But framing it purely as courage obscures the more mechanical issue: you don’t have the practiced skill of initiating this kind of conversation.
Consider how different this is from technical leadership. If a production system shows anomalous behavior — latency spikes, an error rate creeping up, or one service running slower than usual — you have a playbook. You check the dashboards, look at recent deploys, and correlate the timeline. You don’t wait two weeks to see if the anomaly resolves itself. You don’t avoid looking at the metrics because the conversation with the on-call engineer might be uncomfortable.
The diagnostic instinct is the same. You read signals, synthesize context, and form a hypothesis. The engineering manager who notices their senior engineer going quiet is following the same pattern-matching they’d use for degraded service. The skill gap isn’t in the observation. It’s in the intervention — the moment where you have to convert your hypothesis into words directed at another person.
Watch what happens at that conversion point. The diagnosis is clear: something has changed in how this person is showing up. But the moment you try to articulate it, the softening begins.
You open with the project instead of the person. “How’s the migration going?” when what you mean is “I’ve noticed you seem disengaged, and I’m concerned.” The project question is safe because it has a technical answer. It lets both of you stay in a register where the conversation is about code and timelines rather than about how someone is feeling. Occasionally, the person volunteers something — “Actually, I’ve been a bit overwhelmed” — and you feel relief that the real conversation emerged without you having to force it. More often, they say, “Fine, on track for next week,” and the window closes.
You generalize instead of specifying. “How are things going generally?” is a question that invites a general answer. “I noticed you turned your camera off for the last three standups and your Slack replies have gotten shorter — is something going on?” is a question that demonstrates you’ve been paying attention and that you care enough to name what you’ve seen. The first question is easy to deflect. The second is harder, and that’s exactly why it’s more useful.
You wait for the scheduled venue. Your next 1:1 is on Friday. You’ll bring it up then. But Friday’s 1:1 has an agenda — there’s a sprint review to discuss, a promotion case to revisit, and a cross-team dependency that needs attention. The opening for a vulnerable conversation never materializes because the structured meeting pushes it out. And next Friday will have its own agenda. The “right moment” for this conversation doesn’t arrive. It has to be created.
You defer to someone else’s judgment. You mention it to a peer manager: “Have you noticed anything with Elena lately?” They say she seems fine. You take this as evidence that you’re overreading the situation, when what it actually means is that your peer doesn’t have the same observational vantage point you do. You are the person who sees her work most closely. Your signal is the relevant one.
The common thread across all four moves is that each one substitutes a lower-risk action for the one that would actually address the situation. And each one feels, in the moment, like a reasonable choice. You’re not avoiding the conversation — you’re approaching it thoughtfully. You’re being measured. You’re respecting boundaries.
But the practical effect is indistinguishable from avoidance. Two weeks of “approaching it thoughtfully” looks exactly like two weeks of doing nothing, and from your engineer’s perspective, that’s what happened.
This is where the medium matters. Verbal conversations are structurally forgiving of these delays. You can always tell yourself you’ll bring it up in the next 1:1, and the 1:1 is its own kind of deferral mechanism — a future container that absorbs the urgency of the present concern.
Writing doesn’t offer that escape. When you sit down to compose the email — “Elena, I want to check in about something I’ve noticed” — you have to decide, in that moment, what you’ve noticed and why it matters enough to write about. The act of composing forces the clarity that the conversation requires. You can’t mumble through a sentence in an email. You can’t trail off. You can’t let the other person’s body language redirect you away from the thing you came to say.
You also can’t pretend you said it when you didn’t. The email is either in the sent folder or it isn’t. The words are either on the screen or they’re in your head, which is where they’ve been for the last two weeks.
The engineering manager who has written that email — who has sat with the discomfort of typing “I’ve noticed a shift in your energy and I want to understand what’s going on” and revised it three times until it was both direct and humane — is going to be better at saying it in person next time. Not because the email is a script. Because the act of composing is where the skill actually develops. The writing forces you to resolve the tension between care and clarity before you send it, instead of hoping the tension resolves itself in the moment.
This is the tension at the center of The Burnout Blindspot — the first scenario in Prism Signal. A senior engineer on your team seems... off. Performance is fine on the surface. But the signals are there, in the length of her emails, the meetings she’s skipping, the questions she’s stopped asking. The scenario doesn’t test whether you can recognize the pattern. Most managers can. It tests whether you can write the message that opens the real conversation — without deferring to the next 1:1, without hiding behind a project question, without waiting for someone else to confirm what you already see.
No suggested responses. No templates. Just a compose window and the specific weight of choosing words that are honest enough to matter and careful enough to land.
Your first scenario is free — no credit card, no commitment. Just the conversation you’ve been putting off, waiting for you to write it.