Why I built CrewPulse
A note from Ronda Bergman, founder.
I've spent years in engineering leadership watching the same pattern repeat: a CTO finds out a team is struggling not from a dashboard, but from a one-on-one conversation — usually three weeks after it started.
The tools we had for delivery metrics were good at telling us that something was wrong. Cycle time up, PR review lag increasing, milestones slipping. But they couldn't tell us why — whether the team was blocked on a technical problem, drowning in unclear requirements, or quietly burning out under unrealistic sprint commitments.
And the "people side" tools — Officevibe, 15Five, Lattice — were owned by HR or People teams, not Engineering. They had no connection to what was actually happening in the codebase or the roadmap. You were looking at two completely disconnected pictures and trying to draw your own conclusions.
CrewPulse is the thing I kept wanting but couldn't find: a single weekly view that joins delivery signals with team health, and surfaces the specific things that need a CTO's attention — before they blow up.
The gap in the market
Every existing tool solves half the problem.
LinearB, Jellyfish, Swarmia, Pluralsight Flow
Excellent at delivery metrics — cycle time, DORA, PR review lag. But they measure output, not the people behind it. They tell you that the team is slower this week. They don't tell you whether to have a process conversation or a one-on-one about workload.
Officevibe, 15Five, Lattice, Culture Amp
Solid people tools — but they're HR-owned, not engineering-owned. They have no concept of what's happening in the codebase. And they're built for quarterly review cycles, not the weekly cadence an engineering leader actually needs.
CrewPulse
Joins both halves. Built for the CTO's weekly cadence. Self-serve, no enterprise sales. Plain language callouts, not charts that require interpretation.
What CrewPulse won't become
There are product directions that would be easy to add but would undermine the trust that makes CrewPulse useful. I'm naming them explicitly because I want you to hold me to it.
Per-engineer productivity scores
We will never surface individual scores or rankings visible to managers. CrewPulse is team-level signal, period. Adding individual surveillance would kill the trust that makes engineers answer honestly.
Activity monitoring
We track delivery signals at the team level — not keystrokes, IDE activity, or commit frequency per engineer. There's a category of "productivity" tools built on engineer surveillance. We're not it.
Verbatim open-text responses to managers
Open text is always AI-summarized into themes before the CTO sees it. The raw text is never surfaced. This is load-bearing for trust — engineers need to know they can be honest without being identifiable.
Enterprise sales and procurement complexity
Self-serve only. If you need a 6-month procurement process and a dedicated account manager, we're not the right fit — and we're fine with that.
What we believe
1. Ask why — and earn the right to know
Honest signal only travels when people feel safe. We built anonymous check-ins because the real answer to "why is this team struggling" requires engineers to trust the question. We chase root causes relentlessly — and we know that starts with psychological safety, not surveillance.
2. Every voice in the room
The quietest engineer on the team often has the clearest read on what's going wrong. We built anonymous check-ins so that signal doesn't get lost — and we run our own team the same way. Inclusivity isn't a policy; it's how better decisions get made.
3. Respect for the people who build
Most tools treat developers as throughput to be measured. We think that's backwards. CrewPulse is built for engineers — to protect their time, acknowledge their experience, and give them a channel to be heard. Respect is a design requirement, not an afterthought.
4. Clarity over cleverness
The best insight is the one that actually gets acted on. We obsess over plain language, one clear view, and ruthless prioritization — in the product and in how we communicate.
5. Small and deliberate
We're building for 10–50-engineer teams because that's where focused execution matters most. We run the same way: no unnecessary complexity, no scope creep, no enterprise theater. Fewer things, done exceptionally well.
Get in touch
If you have a question, feedback, or you want to tell me about a problem CrewPulse didn't solve for you — I read every email.
hello@crewpulse.io