You have two problems, a personal motivation problem that will eventually affect every employee in your organization at some point, and a corporate problem regarding HR strategy. <i></i>Standard IANL/HR professional disclaimers, no guarantee these will work in this situation/don't know the people or specifics disclaimers apply<i></i><p>TL;DR:<p>1) Boredom is a sign of little intrinsic motivation to continue working.<p>2) Simply throwing cash at people isn't enough, in fact, it can be counter productive to think tossing cash is the only solution.<p>3) People need to feel a sense of autonomy and ownership to value their work. Find ways to grant it.<p>4) Don't be arbitrary and capricious with your benefits. Simply yanking something is a really good way to breed resentment and cause you to lose even more talent.<p>5) Consider how you're communicating with your teams. Are you issuing edicts or asking for help solving problems?<p>6) Think about how you consider developers: Are they valued contributors whom you've hired because they bring something to the table you or others don't, or are they 21st century factory workers who crank out pieces based on edicts from someone else? How you view them subconsciously determines how you treat them and as a result, how they will respond to you. It will also determine the kind of talent you're able to find, hire, and keep long(ish) term.<p>7) Cultural knowledge and team cohesion matter, you can't simply put a $$$ on it. High profile developers leaving because of semi-public conflict with the company will have a ripple effect and you will probably lose several more lower rung developers who look up to the lead guy because of it. People matter and don't always act simply because $$$ are on the table.<p>============================================================<p>Boredom is a sign of lack of motivation and purpose. The individual in question does not see their interests and corporate interests being aligned and thus has little intrinsic motivation to continue working beyond the bare minimum. As your lead developer, this should worry you significantly because their attitude will trickle down to the rest of the development team. Simply firing them sends the message dissent in the ranks isn't tolerated and people who don't keep with the party line get canned, it's a fast way to lose talent and the fallout won't be insignificant. In one of your comments you argued that all great developers need is a high salary, that's patently false--as the comments here indicate. In psychology speak, this is what's happening.<p>Only providing a high salary--and removing things like 20% time--are creating an environment where the only motivation to do work is extrinsic (the paycheck) and the loss of autonomy (no say in features/implementation/direction) means employees start believing they are losing their locus of control over even small things. Over time, this erodes their intrinsic motivation and interest in doing the work because they perceive the company views them simply as drones who do nothing except what the people "in the know" say. Is this correctable? The answer is yes, providing the company makes some substantial effort to address matters both immediately and long term for all the developers. First, simply throwing cash and trying to extrinsically motivate people to like things isn't enough, if you want truly excited workers you need to work on aligning corporate and personal objectives. You do this by giving them a sense of autonomy and control where they feel they have a say in how things are going and get some skin in the game. You can start simply enough by soliciting your lead developer's feedback and getting them involved in production meetings where feature sets are being decided. Lean on their expertise and seriously consider what they say and solicit their suggestions for features or improvements. Second, consider setting higher level objectives for development and letting developers/designers come up with the plan to meet them. You still get your business objectives accomplished, but the developers and designers feel like they're contributing something more substantial than punching someone else's schedule. Third, come up with a way to reward service and talent that allows people to explore and get a sense of autonomy. Many have mentioned 20% time where the developer works on other projects. that's one aspect. The other might be to ask the developer to undertake a solo R&D project where they flesh out a new system the business has been planning on or version 2.0 of the product. Anything that gives them a sense of autonomy and ownership. It'll go a long ways toward helping cure the problem. Perhaps also create a sabbatical program. After 1 year of "work", employees get a month of R&D time to explore new technologies and projects on the company dime after they reach "lead" rank or something like that. There's a reward for longevity and experience.<p>Corporately, what the heck are you doing? Simply throwing cash at people doesn't get them to stay for the long term. They need to buy into a vision and believe you want them to succeed. It's a reciprocal relationship. The few comments you've posted in some of the comment threads here leads me to think--and I freely admit I could be wrong--you see developers more as Pavlovian conditioned cogs who exist fulfill some greater business destiny and happen to reside in human form rather than people capable of contributing to the organization. For instance, yanking things away because "business objectives aren't being met" (paraphrase). Hiring someone with the promise of benefit X (20% time in this case) and then yanking it will lead to resentment and boredom. If your lead developer is saying he's bored, it's a guarantee others are thinking it but not saying it out loud or voting with their feet--yet. Promising to reinstate the benefit, possibly maybe at some near future point, only makes thing worse because it makes you look arbitrary and capricious as well as reactive. You took it away, might reinstate it, and might yank it again in the future. If you're doing it with 20% time, what else might you do it with?<p>In light of this, my question is how did you communicate with developers about the 20% time and how are you communicating with them now? Did you talk to them and say "guys, we have a problem we need to solve together. We need to up product performance by X and right now we're at Y. Y'all are in the trenches and building this thing, how can we work together to get there?" Or did the conversation go "Guys, product performance is at Y and we need to get to X. Blah blah blah sacrifice for the team blah blah blah, cutting 20% time to free up more time to focus on product blah blah blah together we can achieve this. End Transmission."? The reason is that perceptions matter. One method of communicating tells the development team you view them as a stakeholder who has insights you do not and might have solutions to the problem you hadn't thought of. "Geeze boss, we're blowing a lot of man hours on a couple cosmetic features not related to the current problem. If we suspend that work, we can reorient the teams like so, get so many more people involved and chunk up the workload more efficiently." Then you can have a dialogue about the importance of the features, business objectives and such so that everyone reaches happy conclusion. Conversely, sending the message about pulling benefits--that were probably advertised when you hired--sends the message you see the developers as a machine you reward or punish for effort and nothing more. Over time, this mentality results in people being ground down and believing they aren't valued. As soon as they reach that realization they'll quit and move somewhere else meaning you'll have major turn over in your development department and lose a massive amount of corporate knowledge in the process.<p>Edit: Formatting