Most engineering leaders treat culture like an HR checkbox, something to address after the roadmap is set and the features are prioritized. That’s backwards. Culture directly affects how fast your team ships code, how often bugs make it to production, and whether your best developers are still around when the next major project kicks off.
Recent MustardHub survey data shows that 25% of workers don’t feel trusted to do the job they were hired for. Other research shows that, among developers specifically, 65% reported burnout in the past year. When people don’t trust their environment or feel burned out, they leave. And in software development, turnover can break your team’s ability to deliver.
The generational engagement crisis
The problem runs deeper than general dissatisfaction. There’s a generational mismatch that most engineering managers don’t see coming.
The same MustardHub survey found that 43% of boomer leaders report feeling engaged at work, compared to only 14% of Gen Z and 15% of millennials. In short, those in leadership positions often feel fine. The people they’re leading don’t.
This gap exists because each generation has different needs to stay productive. Among all workers surveyed, 36% identified regular appreciation and feedback as their top engagement driver. But when you break that down by age, only 14% of boomers say they need frequent feedback. Nearly half of Gen Z (47%) and 43% of millennials say they need it to stay engaged.
Many engineering leaders are Boomers or Gen X. They built their careers in environments where you kept your head down, shipped your code, and assumed no news was good news. That approach worked for them. It doesn’t work for the developers they’re managing now.
This creates a perception problem that compounds the engagement gap. Most C-suite leaders say they put employee well-being first. Most employees don’t see it that way. Only 60% agree their employer actually prioritizes their well-being. The gap matters because employees who think their company cares more about output than people feel overwhelmed nearly three-quarters of the time. When employees feel supported, that number drops to just over half. That difference is where attrition starts.
What retention actually requires
Most engineering teams try to fix retention with the same approach that worked decades ago, when people stayed at companies for years and stability mattered more than engagement. That’s not how careers work anymore.
The typical response is to roll out generic culture programs designed for large enterprises. These initiatives add meetings, require documentation, and create overhead that doesn’t match how engineering teams actually operate.
Worse, some companies respond to engagement issues by adding surveillance. Time tracking software, productivity monitoring tools, and micromanagement disguised as “visibility” can make people feel like they’re not trusted. That erodes the autonomy people need to solve complex problems and pushes your best engineers toward the door.
The fix isn’t complicated:
- Start with clear expectations and then get out of the way. People perform better when they understand what success looks like and have the freedom to figure out how to get there.
- Build feedback into how the team already works. Code reviews, standups, and retrospectives can double as recognition opportunities. Younger team members need regular feedback to stay engaged. Make it part of the workflow instead of a separate HR initiative.
- Address burnout before it becomes a crisis. If someone is struggling, waiting until their next one-on-one means you’ve already lost time. Create space for people to flag issues early without it turning into a performance conversation.
- Treat culture work the same way you treat infrastructure maintenance. You wouldn’t skip security patches because you’re busy shipping features. Losing any part of your team mid-project can be a major setback that can kill projects entirely.
When a senior engineer leaves mid-project, they take unwritten context with them — why certain architectural decisions were made, where the technical debt actually lives, how the legacy systems connect. Rebuilding that knowledge costs six to nine months of reduced productivity and code quality issues that won’t appear in your sprint metrics.
The engagement gap between leadership and their teams isn’t closing on its own. The mismatch between what younger engineers need and what older leaders think they need keeps widening. Every month you wait to address it, your best people get closer to accepting offers elsewhere. The cost of prevention is always lower than the cost of rebuilding lost context after they’re gone.
