Nobody told me about the red eyebrows.
I was a few weeks into being a first-time mom when I noticed it. The skin just above my daughter's brows would go pink. Then her eyes would glaze. Then she'd start rubbing her face with one tiny fist. The first time I saw it I genuinely thought something was wrong with her. I did what every new parent does and fell down a rabbit hole trying to figure out what I was looking at.
Turns out it's a thing. A completely normal, widely known thing that every experienced parent apparently just... knows. The red eyebrows mean she's tired. Catch it in that window and I can get her down for a nap in five minutes. She drifts off, everybody wins.
Miss the window? Within ten minutes she's screaming, arching her back, completely inconsolable. What should have been a smooth transition turns into an hour of damage control and we're both wrecked by the end of it. The signal was there the whole time. I just didn't know to look for it yet.
I've been on maternity leave with a newborn while thinking about my next role in Quality Engineering, and I keep having these moments where the two worlds collapse into each other. This was one of them.
Most QE teams are really good at responding to the screaming. The production incident. The customer escalation. The regression that slipped through the night before a major release. They know how to triage. They can handle chaos.
What's harder, and what genuinely separates good QE organizations from great ones, is learning to read the red eyebrows before any of that happens.
In a software org those signals are quieter than a screaming baby, but they're just as real. Here are four I've learned to watch closely.
When QE goes quiet, something is wrong.
Not a slow week quiet. A different kind of quiet. Your QE engineers stop raising concerns proactively. Bug triage starts to feel tense. You start hearing engineers say things like "QE will catch it" as a way of closing a conversation rather than opening one.
That's the red eyebrow moment. The underlying issue is usually that quality has become QE's problem to own alone, and your team knows it. They've been blamed for things that escaped. They've learned that speaking up costs more than staying quiet.
By the time this surfaces as a lagging indicator, you're looking at burnout, attrition, and a quality culture so broken that fixing it requires rebuilding trust across the entire engineering org. Not just a process change. A culture change.
QE is filing almost all the bugs.
This one looks like productivity. Your team is thorough, they're finding things, the numbers look fine. But if you look at who is actually filing defects and QE owns the vast majority of them, quality ownership has not shifted left. It just looks like it has.
The leading signal is in your planning ceremonies. Are engineers asking "how will we test this" before work begins? Are they thinking about edge cases during design? Or is testing still an implicit hand-off that happens at the end of a sprint?
When that question stops getting asked, QE quietly becomes a bottleneck. Releases start slipping. An us-versus-them dynamic develops between engineering and QE that nobody ever explicitly created but everyone can feel.
New engineers are struggling to ramp, and nobody's talking about it.
When someone new joins and takes an unusually long time to become productive, the instinct is to attribute it to the individual. Sometimes that's fair. Often it isn't.
Slow ramp time is frequently a signal about the state of your test environments, your documentation, and your codebase. Certain modules become tribal knowledge. PR reviews start taking longer because engineers are hesitant to touch unfamiliar code. Nobody says anything because the people who know where the bodies are buried have been there long enough that they stopped noticing.
By the time this shows up as a lagging indicator, your test suite runtime has ballooned, flakiness has spiked, and your most critical paths have the sparsest coverage. Usually because nobody wanted to go near them.
Test phases are getting shorter, sprint over sprint.
This one is subtle enough that it can go undetected for a long time. It doesn't show up in a single sprint. It accumulates. A little compression here, a "we'll add coverage later" there, QE pulled into manual regression because there isn't time to build sustainable coverage.
Individually each of these feels like a reasonable tradeoff. Collectively they are delivery pressure quietly winning a war that nobody declared.
The lagging indicator is a cluster of production incidents around the same features, post-mortems that keep identifying the same root causes, and tech debt conversations that have quietly disappeared from your roadmap discussions because everyone is too tired to have them.
My daughter can't tell me she's tired. She doesn't have the words yet. So I learned to watch her instead of waiting for her to tell me.
Your organization can't always tell you it's in trouble either. The people closest to the work can often see it coming, but they need a leader who has built enough safety and enough signal for that information to actually travel.
The screaming tells you the window has closed. The red eyebrows are how you catch it while it's still open.
What signals are you watching in your org right now? And are you catching them early enough?