Why We Built CrewPulse: The Two Signals Every Engineering Leader Is Missing
There’s a version of this story that plays out in engineering organizations every day, and most leaders don’t recognize it until it’s already over.
A strong engineer starts missing standup. Their PRs sit open longer than usual. Their Slack responses get shorter. You check in, they say they’re fine. Three months later they hand in their notice, and when you ask why, the answer is some version of “I just needed a change.”
You nod. You write up the offboarding notes. You post the job description.
And somewhere in the back of your mind, you wonder if you missed something.
You did. But here’s the thing: the signals were there the whole time. You just didn’t have a way to connect them.
Two kinds of signals. Most teams only watch one.
I’m Ronda Bergman, founder of CrewPulse. I’ve spent 25 years in engineering, leading teams across healthcare, automotive, and enterprise platforms, scaling organizations, building distributed teams from scratch, and coaching engineers through some genuinely messy situations. CrewPulse exists because of a pattern I kept seeing and couldn’t find a tool to solve.
In most of the organizations I’ve been part of, we watched delivery signals closely. Cycle times. Open PRs. Tickets going stale. Blocked work. That data was visible, trackable, and easy to put on a dashboard. When something slipped, you could usually point to it.
What we didn’t have was the other half of the picture. And over the years, through coaching, consulting, and conversations with engineers at all levels, I started to understand what that half looked like.
When you’re talking to engineers with no performance review on the line, you hear a different version of things. What I hear, consistently, is that people knew something was wrong long before their manager did. They just didn’t feel safe enough, or seen enough, to say so.
Morale was low. Priorities were unclear. The workload felt unsustainable. But nobody asked, and nobody had a system for listening.
That gap, between what the delivery data shows and what the team is actually experiencing, is where problems live before they become expensive.
Delivery data tells you what’s slipping. It doesn’t tell you why.
Here’s what makes this genuinely frustrating: when delivery starts to slow down, most leaders go looking for a process problem. Maybe the sprint planning needs work. Maybe there’s too much work in flight. Maybe the architecture is getting harder to change.
Sometimes that’s right. But sometimes the work is slowing down because an engineer is blocked and doesn’t feel comfortable saying so. Or because priorities are so unclear that nobody knows what to finish first. Or because someone has been quietly burning out for months and is running on empty.
Research from Gallup consistently shows that disengagement precedes departure by months, sometimes longer. People don’t go from “fine” to “I quit” overnight. They go from engaged, to coasting, to checked out, to gone. Each stage has observable characteristics in both how people behave and how the work moves.
The delivery signals and the health signals are telling the same story. Most teams just aren’t reading them together.
What “Team Health” actually means
Team health gets thrown around a lot. It usually means morale, which usually means “does the team seem okay right now.” That’s too thin to be useful.
Morale is a snapshot. Health is a trend.
Google’s Project Aristotle, which studied hundreds of teams over several years to understand what made them effective, found that the single biggest predictor of team performance had nothing to do with individual talent or technical process. It was psychological safety: the degree to which people felt safe to take risks, raise concerns, and be honest without fear that it would be used against them.
Teams with high psychological safety ship better software, handle incidents better, and retain their people longer. Teams without it develop a specific kind of learned silence that feels stable until it catastrophically isn’t. And that silence shows up in the delivery data too, in PRs that nobody reviews, in concerns that don’t get raised until after the bad decision ships, in work that drifts without anyone pushing back.
Belonging is another one I’ve come to take seriously. Building inclusive, people-first environments has been a through line in my career, and what I’ve learned is that belonging isn’t a culture initiative. It’s a leading indicator. When people feel like they don’t fully belong, they start self-protecting. They share less. They raise fewer concerns. They stop bringing their best thinking to the table. That’s a team health problem before it’s anything else, and it’s a delivery problem shortly after.
These things are not soft. They are measurable. And when they deteriorate, there are early signals well before anyone hands in their notice, in how people answer a direct question about how they’re doing, and in how the work is actually moving through the system.
Why I built CrewPulse
Replacing a mid-level software engineer costs, on average, between 50% and 200% of their annual salary. For a senior engineer at $150k, you’re looking at $75,000 to $300,000 per departure. Per person. Most engineering teams lose one to three people a year they didn’t see coming.
But the cost isn’t just the attrition. It’s every month of slowdown before the departure. Every blocked PR that sat open for a week because nobody felt like they could ask for help. Every sprint that underdelivered because the team was underwater and nobody knew how to surface it.
I built CrewPulse because I kept watching both of these problems play out in parallel, and I couldn’t find a tool that treated them as connected. Delivery metrics that show what’s slipping. Team check-ins that show why. And the combination of both, so you can see when a slowdown is a process problem and when it’s a people problem, before it becomes a crisis.
The signals are there. The question is whether you’re set up to see them.
CrewPulse connects delivery data and team health signals so engineering leaders can stop finding out too late. Get early access here.