# If They're Bored, It's Too Late
In his excellent book Managing Humans (opens new window) Michael Lopp observes that bored people quit because once someone is bored an internal timer starts counting down. When it expires they give up and leave. He's right, but I believe the situation is even more dire than this; once they are bored it's probably too late.
While many developers are strongly motivated by material benefits such as salary and perks, a Harvard Business Review summary of research into Money and Motivation (opens new window) suggests that the association between salary and job satisfaction is very weak. The combined dataset of a huge set of studies indicates a correlation (r = .14) of less than 2% overlap between pay and job satisfaction levels. In situations where remuneration did show motivational benefits, these effects tapered off dramatically as salaries increased.
In the software development world the rewards of creative, challenging and appreciated work often outweigh the impact of a bigger pay cheque. This is probably a good thing as there is very little an Engineering Manager can accomplish in this area quickly enough to stop someone from leaving.
The good news is that looking for a new job is hard work, and the best developers apply inspired laziness (opens new window) in choosing the work they don't do. Job applications, coding assessments and interviews are all extra work that your team members will only complete when they've determined the effort is warranted. If you can keep them happy, engaged and motivated they won't get bored in the first place.
# Things You (Probably) Can't Control But Still Need to Address
Engineering Managers are unlikely to be the final decision makers for these aspects, but they can dramatically influence how they impact their teams.
While it never seems to be the #1 reason provided in an exit interview, more money is often the primary cause of attrition and almost always a factor. Your junior developers are specifically prone to leaving for higher salaries; the same ones you've just spent significant effort and time helping grow. While the retention impact of more money is complex and unique to the situation, it's unlikely you have the power to make unilateral salary decisions anyway. In addition, counter offers made when an employee resigns are almost always a bad (opens new window) idea (opens new window) for both sides.
# Career Progression and Growth
Promotions do typically involve higher salaries, and this is an area you can impact directly. Start with sharing your organization's promotion and advancement framework, or in absence of one helping to create a career development framework. This needs to include a definition for the expectations of each role and provide clear explanations of how these expectations are evaluated and measured. You should be providing regular constructive feedback to team members and working with each individual to build an actionable growth plan that describes a path to their next level. You are their advocate for both official promotions and opportunistic experiences and projects.
# Legacy Projects
It is a rare developer who would choose a legacy project over greenfield development, but teams are often tasked with maintaining old products, often for a significant period of time. These cash cows (opens new window) are critically important to companies over the short-to-midterm, but they will accelerate the typical developer's journey along the boredom spectrum. The work must get done, but there are strategies to mitigate the negative impacts or your team.
# Share Painful Work
Be honest with timelines and product roadmaps
Share painful work across the entire team
Promote the importance of the project (i.e. impact on the bottom line)
# Company Goals
Poorly defined and communicated company goals often feel disconnected and out-of-touch with a developer's daily work.
Consistently share the motivation (the why) behind a company goal
Frame goals in concrete deliverables
Help team members develop personal goals that contribute to the overall goals
Seek clarification up the hierarchy for unclear or unrealistic goals
# Provide Room to Explore and Learn
Most developers are inherently curious but it's a challenge to find the time and space in which to learn. If you have a formal program intended to accommodate learning it should be treated as important as any project or feature work. If you don't have a defined program you can still carve out opportunities for exploring and experimentation. A variety of technology spikes, investigations and research tasks mixed in with regularly scheduled work gives developers a chance to gain new skills and enrich the team. You should be looking for opportunities that tie the learning back to company objectives, advance department goals and increase the capacity and resiliency of the team.
An Engineering Manager cannot wait for team members to tell them they've become bored, not only because it is unfair to make the employee responsible for what is clearly a management job, but also because they themselves may not be aware of the creeping boredom until it's too late to address.
You don't control many of the high-level causes of boredom but there are several key aspects where you have influence. Your role is to balance the promotion of a unified organizational direction with advocating for team members' individual needs and desires. Be fair, intentional and consistent.
Within your team you can influence important facets directly. Simple but meaningful recognition and rewards send powerful messages that outweigh their monetary costs. Sharing both the exciting green-field work and less-fun maintenance tasks builds a sense of community across your team.
- If someone doesn't have a project that makes them light up, let them experiment. Your job isn't just building product, but building people.
- Share the crummy work fairly. Be aware of who's doing it, communicate that you're aware, and tell them when they're going to be done.
- Promising productive and creative time that is only taken away by urgent tasks accelerates the boredom clock.