My Third Coworker 'Quietly Disappeared' This Quarter — How Do You Keep Shipping When Nobody Feels Safe?

I need to talk about this because I’m running out of people to talk about it with — literally.

In September, my tech lead’s role was “consolidated” with another team. In November, a backend engineer on my squad was part of a “strategic realignment” — five people across the org, no press release, no Slack announcement. Two weeks ago, the senior QA engineer who’d been here longer than anyone else just… wasn’t in standup on Monday. Her manager said she’d “moved on to new opportunities.” Her Slack went gray the same afternoon.

Three people in five months. None of it made the news. None of it was called a layoff. And every single time, the people left behind are expected to absorb the work, maintain the velocity, and act like this is normal.

The Slow-Bleed Experience

I’ve read the data — the Glassdoor numbers, the “forever layoff” statistics, the fact that 25,000 tech jobs vanished in January alone across 88 events nobody noticed. But data doesn’t capture what this feels like day-to-day.

It feels like sitting in a standup where someone’s name just stops being called. It feels like getting added to a Slack channel you didn’t ask for because the person who owned it is gone. It feels like opening a PR and seeing review requests assigned to someone whose account has been deactivated.

The worst part is the ambiguity. Nobody says “we laid off Sarah.” They say she “transitioned out” or “pursued other interests.” The language is deliberately vague, and that vagueness does something corrosive to trust. Because if you can’t get a straight answer about why your coworker is gone, how can you trust anything else you’re being told?

Survivor Guilt Is Real and Nobody Talks About It

I feel guilty for still having a job. That sounds absurd when I type it out, but it’s true. Every time someone disappears, my first thought isn’t “am I next?” — it’s “why them and not me?” followed immediately by “what am I doing that’s keeping me safe?” And then I start optimizing for visibility instead of quality. I write more Slack messages. I volunteer for demo meetings. I make sure my name is attached to things that executives see.

That’s not engineering. That’s survival behavior. And I know I’m not the only one doing it.

The Workload Creep Nobody Acknowledges

Here’s a specific example. When our QA engineer left, her test automation suite became “the team’s responsibility.” In practice, that means mine, because I’m the one who worked most closely with her. I’m now maintaining 340 integration tests on top of my feature work, with no reduction in sprint commitments and no conversation about adjusting expectations.

My manager — who I genuinely like and believe is doing their best — said “we’re working on getting that backfilled.” That was six weeks ago. The job posting went up, got twelve applicants, and then the req was frozen because of a “budget review.” Meanwhile, I’m doing 1.5 jobs for one salary and being told the OKR targets haven’t changed.

What Actually Helps

I’m not writing this just to vent (okay, partly to vent). I’m genuinely asking: what helps?

From my experience, the things that have made a marginal difference:

  • Managers who say “I don’t know” instead of “everything’s fine”@eng_director_luis’s approach of sharing what you know and don’t know is the only thing that’s kept me from updating my resume every weekend
  • Scope reduction that’s real, not performative — don’t tell me you’re “reprioritizing” if the same work is still expected by the same date
  • Acknowledging the loss — when someone leaves, say their name. Say what they contributed. Don’t erase people from the org chart like they never existed

For the other ICs out there in the forever-layoff grind: how are you staying sane? How do you keep caring about code quality when you’re not sure your team will exist in six months? I’d genuinely like to know, because I’m running low on my own answers.

Hey @alex_dev. I don’t have answers but I have solidarity, and maybe that counts for something right now.

The Erasing Part Hits Different

You said “don’t erase people from the org chart like they never existed” and honestly I got a lump in my throat reading that. At my last company, a designer I’d worked with for three years was let go on a Friday. By Monday, her Figma files had been transferred, her Slack account was deactivated, and her name had been removed from the design system contributors page — a page she’d literally built.

Nobody said anything. Not in the design channel, not in the team retro, not in any meeting. It was like she’d been deleted from version history. And the thing is, I don’t think anyone did that maliciously. I think the system is designed to process departures as efficiently as possible, and “efficiently” means “without acknowledging the human part.”

On Survival Behavior

Your point about optimizing for visibility instead of quality — I see this everywhere and it breaks my heart a little. I watched a brilliant backend engineer pivot from writing elegant, well-tested code to writing Confluence docs about his code so that leadership could see his name attached to things. That’s not a productivity gain. That’s a survival adaptation, and it produces worse software.

The forever layoff doesn’t just remove people from teams. It restructures the incentives of everyone who remains. When you’re not sure you’ll be here in six months, you stop investing in things that pay off in twelve months. Architecture improvements? Why bother. Mentoring the junior? They might get cut. Proposing a bold technical bet? That’s a great way to have your name on a failure when the next round comes.

What’s Helped Me

I’ll be honest about what’s kept me functional (not thriving, functional):

  • Setting hard boundaries on work absorption. When my teammate left and I was asked to take on her component library maintenance, I said “yes, but I’m dropping the responsive audit we planned for Q1.” My manager pushed back initially, then agreed. The key was making the trade-off explicit rather than silently absorbing it.
  • Having one person you trust enough to be honest with. Not your manager, not HR. One peer who you can text “I’m scared” to at 11pm without it becoming a performance conversation.
  • Remembering that your worth isn’t defined by whether this company keeps you. Easier said than felt, but I try.

You’re not losing your mind, @alex_dev. The environment is genuinely abnormal. Don’t let anyone normalize it for you.

@alex_dev, I owe you and every IC in this thread an honest response, because what you’re describing is a failure of management — my profession — and we need to own that.

What Managers Can and Should Do

Let me be direct about the things that are within a manager’s control, because I think too many of us hide behind “it’s a leadership decision” when there are concrete actions we can take.

1. Make the trade-offs visible and documented.

When your QA engineer left and her test suite became your responsibility, your manager should have done the following within 48 hours:

  • Written an email to their leadership stating: “We’ve lost a QA engineer. Here are the three things we can deliver this quarter. Pick two. The third is deferred until we have headcount or a scope reduction.”
  • Shared that email with you so you know the conversation happened.
  • Updated the sprint commitments before the next planning session, not after you burn out trying to do everything.

If your manager didn’t do that, they failed you. Not because they’re a bad person, but because the system incentivizes managers to absorb pressure silently upward while passing workload silently downward. That’s the mechanism of the forever layoff, and it only works if middle management cooperates.

2. Name the departures.

You’re absolutely right that we should say people’s names. At my teams’ retros, when someone leaves — for any reason — I spend five minutes acknowledging their contributions. I keep a running doc of “what [person] built that we’re still using.” It sounds small, but it does two things: it honors the person who left, and it reminds the team that people matter more than headcount numbers.

3. Be honest about what you’re fighting for.

I tell my reports: “I submitted a backfill request. It was deprioritized in the budget review. I’m escalating to my VP with a written case. If it’s denied again, I’ll come back and we’ll discuss what we’re dropping from the roadmap together.” That level of transparency costs me nothing and gives my team something priceless: evidence that someone is advocating for them, even if the outcome isn’t guaranteed.

What Managers Can’t Do

I can’t promise you won’t be laid off. I can’t guarantee your backfill will be approved. I can’t change a CFO’s spreadsheet model that values headcount reduction over team health. And I want to be honest about that limitation rather than pretending I have more power than I do.

What I can do is make sure that if the system fails you, it doesn’t also gaslight you about the fact that it’s failing.

@alex_dev, I want to respond to this from a data perspective because I think there’s an opportunity to make the invisible visible — and that might be the most useful thing we can do right now.

Measuring What Nobody’s Tracking

You described the experience of workload creep, eroding trust, and survival behavior. These are all measurable phenomena, and most companies aren’t measuring them. Here’s what I’d recommend any engineering org start tracking:

Workload Indicators:

  • PR size and review turnaround time — when teams are stretched, PRs get bigger (less time for decomposition) and reviews take longer (fewer reviewers available). A 20% increase in average PR size over a quarter is a signal.
  • On-call incident response overlap — when team members are covering more surface area, incidents take longer to resolve and more people get paged for issues outside their expertise.
  • Meeting load per IC — track the number of hours spent in meetings per engineer per week. When people leave, meeting overhead doesn’t decrease proportionally; it often increases as remaining people fill coordination gaps.

Trust and Morale Indicators:

  • Voluntary attrition rate among top performers — not overall attrition, but specifically people in the top quartile of performance reviews. If your best people are leaving faster than your median, you have a trust problem.
  • Internal mobility requests — when people start applying for internal transfers, they’re often testing whether the company will keep them in some role. A spike in internal applications is a leading indicator of external applications.
  • Discretionary effort metrics — contributions to documentation, code reviews for other teams, open-source work, internal tech talks. These are the first things to decline when psychological safety erodes.

The Double-Hit Data

Research on repeated layoffs is unambiguous: the second round of cuts has double the negative impact on remaining employee sentiment compared to the first. This isn’t intuitive to leadership because they expect the second round to be “easier” — people have been through it before, they know the drill. But that’s exactly wrong. The second round confirms the pattern. It tells people: this isn’t an event, it’s a policy.

Glassdoor’s data showing “distrust” up 26% and “misalignment” up 149% year-over-year is the aggregate version of what @alex_dev is describing at the individual level. When that data shows up in public reviews, you’ve already lost — those are the people who feel strongly enough to write about it. The silent majority is just quietly updating their resumes.

What I’d Build

If I had the ear of a CHRO or CTO, I’d propose a “team health index” that combines:

  • Sprint velocity trends (normalized for headcount)
  • PR cycle time
  • Employee NPS (quarterly, anonymous)
  • Attrition rate by performance tier
  • Ratio of planned vs. unplanned work

None of these are revolutionary metrics. But tracking them together, over time, in the context of headcount changes creates a narrative that’s hard to ignore. It turns @alex_dev’s lived experience into a trend line that a CFO has to respond to.