The phrase "quiet quitting" entered the mainstream lexicon in 2022, and most of the conversation has been useless. Op-eds about "lazy workers" from one side. Counterpoints about "setting boundaries" from the other. Almost none of it has been specific enough to help an engineering manager recognize what is happening on their team.
That is because quiet quitting looks different in engineering than it does in other functions. Engineers do not have the same visibility signals as salespeople (declining pipeline) or marketers (fewer campaign ideas). Engineering disengagement hides inside systems that already reward quiet execution: version control, ticket trackers, and asynchronous communication tools.
Gallup's 2025 State of the Global Workplace report puts the numbers in sharp relief: global employee engagement fell to 21% in 2024, and in the U.S., it dropped to 31%, a ten-year low (Gallup, 2025). That means 50% of U.S. employees are now classified as "not engaged," the group Gallup defines as quiet quitters. And the economic damage is staggering: $8.9 trillion in lost productivity globally (Fortune, 2024).
Here is what those numbers actually look like when they play out on a software team.
The Six Engineering-Specific Signals
1. Rubber-Stamp Code Reviews
This is the earliest and most reliable signal. An engaged engineer reviews code with intent. They ask why a particular approach was chosen. They flag edge cases. They suggest alternatives. A disengaging engineer approves PRs with "LGTM" and nothing else. The review technically happened. The review added zero value.
Research on quiet quitting in software development confirms that disengaged developers show "minimal concern for ensuring that a feature meets its basic functional requirements, neglecting thorough testing for potential bugs or edge cases" (TechAsHuman). Code review quality is where this manifests first, because reviews are discretionary effort. Nobody gets penalized for a short approval. The absence of thoughtful review is invisible until a bug ships.
2. PR Velocity Changes
Watch for two patterns. The first is shrinking PR size. Engineers who used to ship medium-to-large features in cohesive PRs start breaking work into the smallest possible increments. Each PR is technically correct. None of them reflect architectural thinking. The second pattern is slower turnaround on reviewing others' PRs. Response time creeps from hours to days. Neither pattern triggers any alert in your project management tool. Both reflect a shift from ownership to compliance.
3. Standup One-Liners
The standup update that used to be "I am working on the payments refactor, hit an issue with the webhook retry logic, going to pair with Sam this afternoon to work through it" becomes "Still on payments. No blockers." The information density collapses. Slack research identifies this as a key disengagement signal: "passionate employees turning monosyllabic in meetings, responding with brief yes or no answers" (Slack).
This matters beyond the individual. When one person stops sharing context, the team loses visibility into their work. Coordination costs rise. Assumptions replace communication. The damage is multiplicative.
4. Declining Optional Meetings
Architecture discussions. Retros. Brown bags. Tech talks. Pairing sessions. These are the connective tissue of an engineering culture. They are also the first things a disengaging engineer drops. FranklinCovey research shows that disengaging employees "begin limiting contact with peers, avoiding team tasks, and skipping events they once enjoyed" (FranklinCovey).
On remote teams, this is especially damaging. Optional meetings are one of the few channels for informal knowledge transfer. When engineers stop attending, silos form faster than any process can prevent.
5. Slack Response Time Shifts
An engaged engineer responds to team questions within a reasonable window, contributes to technical threads, and shares links or context proactively. A disengaging engineer responds only when directly mentioned, answers with the minimum viable response, and stops contributing to asynchronous discussions. The shift is subtle. Slack activity volume is not a reliable signal. Response quality and initiative are.
6. Silence in Architecture Discussions
This is the most telling signal of all. Architecture discussions are where engineers invest in the long-term health of the system. They require thinking beyond the current sprint, considering trade-offs, and advocating for positions. When someone who used to have strong opinions about system design stops speaking up, they have stopped caring about the system's future. They are planning to leave before those decisions matter.
Teams with high rates of quiet quitting show 37% fewer documented sharing instances and a 44% reduction in voluntary inter-team projects (International Journal of Research and Innovation in Social Science). That knowledge drain compounds. Every piece of undocumented context, every avoided debate, every unasked question makes the codebase worse.
The Five Stages of Engineering Disengagement
Quiet quitting is not a switch. It is a gradient. Understanding the stages helps you intervene before the damage becomes permanent.
Stage 1: Enthusiasm
The engineer is invested. They propose new approaches. They review code carefully. They attend optional meetings because they want to shape outcomes. They ask "why" before "how." This stage correlates with what Gallup calls "actively engaged," a category that only 23% of global workers fell into before the 2024 decline (Gallup, 2025).
Stage 2: Routine
Output stays high, but initiative drops. The engineer executes well on assigned work but stops proposing improvements or flagging risks. They still attend meetings but contribute less. This stage is hard to detect because every metric you track (velocity, ticket completion, deployment frequency) looks normal. The leading indicator is behavioral: fewer questions, fewer suggestions, fewer voluntary contributions.
Stage 3: Withdrawal
Optional activities start dropping off. Code reviews get shorter. Standup updates get thinner. Slack responses slow down. The engineer is doing their job. They are no longer doing the discretionary work that makes a team function. Research shows that individuals connected to disengaging colleagues are 3.1 times more likely to exhibit similar behaviors within four months (IJRISS). Disengagement is contagious.
Stage 4: Minimum Viable Effort
The engineer delivers exactly what is specified in the ticket. No more, no less. Tests cover the happy path. Documentation is bare minimum. PRs include no explanation of design decisions. They have become a function that converts tickets to code. Most quiet quitting discourse focuses on this stage, treating it as the problem. It is a symptom. The root cause happened in Stages 2 and 3, when nobody noticed the withdrawal.
Stage 5: Job Search
By this stage, the engineer is interviewing. Calendar blocks appear with no context. Commit patterns shift as energy goes toward interview prep. The average software developer tenure is about 2 years at large companies (Centum Search, 2024), and replacing a departing developer costs 1.5 to 2 times their annual salary (SHRM via Devsu). By the time you are at Stage 5, you have already lost. The investment needed to retain is enormous, and the chance of success is low.
The Reframe: This Is a Team Dynamics Failure
Here is the part most articles get wrong. Quiet quitting is framed as an individual choice. An employee "decides" to do less. The framing puts the locus of control on the worker.
The data tells a different story. Gallup's research shows that 70% of team engagement is attributable to the manager (Gallup, 2025). Manager engagement itself fell from 30% to 27% in 2024. When managers disengage, their teams follow.
Workers exposed to unexplained pay differences from their colleagues increased their likelihood of quiet quitting by 52% within six months (TechAsHuman). The root causes are systemic: lack of growth paths, insufficient recognition, eroded psychological safety, chronic overwork, and unclear purpose.
The engineer did not change. The environment did. Or more precisely, the environment failed to provide what kept the engineer engaged in the first place.
This distinction matters because the intervention is different. If quiet quitting is an individual problem, the fix is a one-on-one conversation. If quiet quitting is an environmental problem, the fix is structural. You need to change the conditions that produce disengagement, not convince individual engineers to try harder within broken conditions.
Why Surveys and Jira Velocity Miss It
Most organizations rely on two tools to detect engagement issues: annual (or quarterly) surveys and productivity metrics. Both are inadequate for catching engineering disengagement.
Surveys are retrospective and self-reported. By the time an engineer reports low engagement on a survey, they are already at Stage 3 or 4. Surveys also suffer from response bias. Disengaged employees are the least likely to complete them, or they default to neutral responses to avoid attention.
Velocity metrics measure output, not engagement. A Stage 4 engineer can maintain acceptable velocity. They complete tickets. They ship code. They meet deadlines. What they do not do is contribute to team intelligence, share knowledge, mentor juniors, or invest in system health. None of that shows up in Jira.
Slack activity is noise, not signal. Message volume does not correlate with engagement. An engineer sending 40 Slack messages a day might be deeply engaged or might be performing visibility for a manager who confuses activity with impact. We wrote about this problem separately.
The gap is behavioral data from actual collaboration. Not how many messages someone sends, but how they show up when working with their team. Do they volunteer ideas? Do they support teammates? Do they engage with problems that are not on their ticket? These behaviors reveal engagement in real time, not six months after the fact.
What to Do About It
Fixing quiet quitting on an engineering team requires intervening at the system level. Four structural changes matter most.
1. Increase feedback frequency. Gallup data shows employees who receive feedback at least once per week are 3.6 times more likely to feel motivated than those who receive annual feedback (Peaceful Leaders Academy). For engineering teams, this means regular, specific, behavior-based feedback. Not "great job this sprint." Specific recognition for specific contributions. (Here is a guide on giving feedback to engineers.)
2. Create growth paths beyond promotion. Most engineering career ladders are narrow. Senior, Staff, Principal. When the next promotion is two years away, growth stalls. Technical growth (new domains, architecture ownership, mentorship, open source), not just title progression, is what keeps engineers engaged through the middle stages.
3. Rebuild psychological safety. Psychological safety is perishable. If engineers have learned that pushing back gets ignored or that proposing ideas gets shot down, they will stop doing both. Rebuilding requires visible, repeated signals that contribution is valued, starting with how leadership responds to dissent.
4. Generate behavioral data from real collaboration. QuestWorks, the flight simulator for team dynamics, runs teams through scenario-based challenges on its own cinematic, voice-controlled platform. Each quest generates behavioral data that surveys and Jira cannot capture: who communicated proactively, who stepped into leadership, who withdrew, and where collaboration patterns shifted. QuestDash surfaces these trends in real time so managers can intervene at Stage 2 instead of discovering the problem at Stage 5.
HeroGPT, the private AI coaching layer, provides each team member with individualized feedback after quests. It never shares upstream. This means engineers get the consistent, specific feedback that Gallup's research identifies as critical, without the awkwardness or inconsistency of manager-dependent delivery.
The difference from surveillance tools is fundamental. QuestWorks does not monitor individual productivity or track Slack messages. It creates shared team experiences and measures how people collaborate within them. Disengagement surfaces through behavioral patterns in teamwork, not through keystroke logging or message counting.
The Cost of Doing Nothing
Here is the math. The tech industry faces an average 23% annual turnover rate among software engineers (Stack Overflow Developer Survey, 2024). Each departure costs 1.5 to 2 times annual salary. Organizations lose an average of 42% of project-specific knowledge when turnover exceeds 20% per year (Full Scale).
But the cost of quiet quitting is not just turnover. It is the degradation of team intelligence that precedes turnover. A team where three engineers are at Stage 3 or 4 produces worse architecture decisions, ships more bugs, and operates with less shared context than a team where those same engineers are at Stage 1 or 2. That quality gap does not show up on any dashboard until the consequences are already in production.
Quiet quitting is a signal. The signal says: something about this environment stopped working for the people inside it. Treating the signal as the problem guarantees you will keep losing the engineers you can least afford to lose.
The engineers who quiet quit first are usually the ones who cared the most. They are the ones who used to push back, propose alternatives, and invest in the system beyond their own tickets. When that energy disappears, the team lost something surveys will never measure and velocity metrics will never capture.
Here are 7 more behavioral signs your team is already disengaging.
Try it free
