This week, two developers on my team shared feedback that highlighted a gap I’ve been working to bridge — the one between what our dashboards show and what’s actually happening on the ground.
Metrics Tell Half the Story
Every engineering manager knows this dashboard: velocity is steady, deployment frequency looks good, sprint goals are being met. The numbers suggest everything’s fine.
But numbers miss a lot. They don’t capture frustration with rework. They don’t show when developers feel disconnected from decisions. They don’t measure whether people are proud of what they’re building.
Building the Feedback Habit
I introduced weekly health checks about six months ago. The adoption curve was predictable — initial resistance, sporadic participation, then gradual engagement.
Engineers are busy. Another form feels like overhead. For the first few months, responses were minimal. But I kept sending them every Friday, and slowly, patterns emerged.
The Structure Matters
Our health check tracks standard metrics: code review cycles, meeting hours, context switches, sprint completion rates, energy levels. These questions serve two purposes — they provide useful data, but more importantly, they show the team I’m paying attention to their daily experience.
The last question is open-ended: “Anything you’d like to share or discuss?”
That’s where the real insights come from. The structured questions create context and permission. The open field creates opportunity.
What Emerged
This week’s feedback was particularly valuable. Two senior developers independently shared concerns about technical direction, process inefficiencies, and knowledge distribution. Issues that wouldn’t surface in a standup or sprint review.
These aren’t complaints — they’re early warning signals. A developer mentioning confusion about requirements today prevents a failed feature delivery next quarter. Feedback about code quality now avoids technical debt conversations later.
The Compound Value
Regular health checks create several benefits:
Trend Detection: Individual responses might not reveal much, but patterns over time highlight systemic issues.
Psychological Safety: Consistent check-ins normalize sharing concerns before they become crises.
Retention Signals: Engineers rarely quit suddenly. Weekly feedback reveals the gradual erosion of satisfaction that precedes departures.
Decision Input: Understanding team sentiment helps calibrate technical and process decisions.
Making It Work
The key elements that made this successful:
Consistency over complexity: Same questions, same day, every week
Acting on feedback: Following up on concerns, even when the answer is “not yet”
Sharing patterns: Discussing trends with the team (anonymized) shows their input drives decisions
Keeping it brief: The entire check-in takes under 5 minutes
Beyond the Numbers
The most valuable outcome isn’t the data — it’s the culture shift. When engineers know there’s a regular, low-friction way to surface concerns, they share earlier and more openly.
Weekly health checks won’t solve all your team’s challenges. But they’ll help you see them coming. And in engineering management, that visibility makes all the difference.
What feedback mechanisms have worked for your teams? How do you bridge the gap between metrics and reality?
(Relying in order of comment)
I would be interested in learning more on how you find that right person up front. What are the things you are looking for in the resume stage? Would you rather see an applicant with smaller work experience but specialized to your work or an applicant that has done much more in the same amount of time but only has some of the skills listed on the job posting?
Also, does this impact more on young hires as they have a lot more training you need to invest into them or more experience applicants due to higher wage?
I do find the engineers not growing with the companies an interesting topic. I have worked with senior engineers that don't want to touch anything outside their very specific domain of expertise even when the subject at hand is very close to their specific domain not requiring too much additional learning. I always wonder if that is due to not want to grow or heightened fear of possibly making a mistake.
I am curious on the engineering retention, what are the major reasons for loosing or keeping an engineer and how that is different than other disciplines (if any).