Ask HN: Your lead developer got bored. What to do?
Imagine you have a company with 50 people and several development teams. One of the best developers get bored and want to leave a company if there will be no interesting tasks. What you will do in this case? try to retain him somehow? let him go?
33 comments
Looking at your comments here it seems that you're not really that interesting in keeping him.
Someone suggested 20% time, your response was to say that it was on hold for a year. Someone else suggested letting him work on something he finds interesting for a while, you say that there are a few things he'd like to do, but they're not 100% aligned with what the company wants to do.
Ultimately, you need to decide just how much this person means to you. Do you want their attention 4 days a week, with 1 day being spent on something they find interesting, or do you want them 0 days a week. Either is valid, but you're going to have to choose.
Someone suggested 20% time, your response was to say that it was on hold for a year. Someone else suggested letting him work on something he finds interesting for a while, you say that there are a few things he'd like to do, but they're not 100% aligned with what the company wants to do.
Ultimately, you need to decide just how much this person means to you. Do you want their attention 4 days a week, with 1 day being spent on something they find interesting, or do you want them 0 days a week. Either is valid, but you're going to have to choose.
We just don't want to have special policies for special people. All developers are equal and it will look strange to give 20% free time back for a single developer and hold this for all other developers.
Are you going to go through this dilemma for all your developers when they consider jumping ship at various points of their careers? Probably not, so you're already doing something special for this person.
Since you seem to be intent on being a robot with regard to personnel decisions, there is only one question to answer: Is your company going to go down the tubes if he/she leaves? If so, do what you can to keep them. If not, cut ties and move on.
As an aside, I find it humorous that you're consulting an anonymous online message board for this type of advice. Surely you've handled more difficult problems than this in growing to a 50 person company?
Since you seem to be intent on being a robot with regard to personnel decisions, there is only one question to answer: Is your company going to go down the tubes if he/she leaves? If so, do what you can to keep them. If not, cut ties and move on.
As an aside, I find it humorous that you're consulting an anonymous online message board for this type of advice. Surely you've handled more difficult problems than this in growing to a 50 person company?
One of the things you realize after you get some experience as a manager is that not everyone is equal, so not everyone needs to be treated equally. It's a tech company, not the drive thru line at McDonalds.
People leave for a lot of reasons, and not having opportunities to grow is one of them.
You want to be equal? Everyone with the title Senior Staff Engineer gets to work on super awesome forward looking new space car. Or maybe just 20% time and a ton more stock options.
People leave for a lot of reasons, and not having opportunities to grow is one of them.
You want to be equal? Everyone with the title Senior Staff Engineer gets to work on super awesome forward looking new space car. Or maybe just 20% time and a ton more stock options.
>All developers are equal
In which case let them leave and replace them with another equal developer. Though I am confused as to why you call them one of your best and yet say all developers are equal.
In which case let them leave and replace them with another equal developer. Though I am confused as to why you call them one of your best and yet say all developers are equal.
Best when it comes to skills. Equal when it comes to pay, benefits and professional relationship. That's how most companies see it anyway.
There are lots of ways to make people feel good while keeping pay, benefits, and professional relationships professional. Not knowing where OP is from or where their company operates, I'd give them wide deference in terms of ensuring they follow the law, but talking to an HR professional (who should be involved at this point anyway if there are dozens of folks) can give a lot of good ideas on how to make people feel special without breaching contracts.
As a practical example, Dynamighty listed every full time Dynamighty worker in alphabetical order on CounterSpy, but then called out individuals by their major contributions within the longer credits. It's not a perfect system, but it provided a good balance between giving due credit to folks who worked long hours for equity and those who were making normal salaries the whole time.
As a practical example, Dynamighty listed every full time Dynamighty worker in alphabetical order on CounterSpy, but then called out individuals by their major contributions within the longer credits. It's not a perfect system, but it provided a good balance between giving due credit to folks who worked long hours for equity and those who were making normal salaries the whole time.
It's not unusual for upper management to have discretion and a budget. Forget side projects -- work with him to find an important and interesting thing you won't micromanage at all.
Perhaps importantly: maybe "lead" roles no longer have any meaning, but if you are determining the engineering schedule months in advance, in enough detail for him to know it won't be interesting to work on, he could be frustrated by the micromanagement (whether it is real or only perceived is something I cannot know).
Perhaps importantly: maybe "lead" roles no longer have any meaning, but if you are determining the engineering schedule months in advance, in enough detail for him to know it won't be interesting to work on, he could be frustrated by the micromanagement (whether it is real or only perceived is something I cannot know).
That sounds nice in theory, but they're not all equal. Some are much more productive, knowledgeable, etc.
Look at it this way: You can give him 20% time or he'll give you 0%.
Look at it this way: You can give him 20% time or he'll give you 0%.
This is a great way to lose special people
So Prime Minister can kill people for no punishment? Great developers have high salary, all other benefits are equal.
Yeah, unfortunately the high salary is still not proportional to abilities. You get maybe 30 or 40% more for being 2 to 3x as useful (we'll forget about the mythical 10x-ers for now.)
Does this seem fair?
Does this seem fair?
This has always perplexed me. You could hire a junior on say 10,000 credits who could produce 10 units of work per week. You could then hire someone more experienced, on 25,000 credits, but they could produce 50 units of work per week. You could then hire seniors and pay them 40,000 credits, but they're producing 200 units of work per week.
Why is it fair to increase the wage so slowly? Either less experienced developers are not worth the money to begin with or someone, somewhere has an idea of what the max cap of a developer is, and sticks to it.
Why is it fair to increase the wage so slowly? Either less experienced developers are not worth the money to begin with or someone, somewhere has an idea of what the max cap of a developer is, and sticks to it.
It is really hard to measure developers productivity and nobody knows how to do that with a good precision. But in general I agree that top developers should be paid good money, like 2 times less then CEO.
No, but he may get off the hook wrt/ a speeding ticket.
Equating 20% time to murder seems like a bit of an overreaction. Do you do that often?
Anyway, you're asking a room full of developers what they would want and they're telling you. 20% time is a solution that works. Toiling away on the same problem day after day sucks and it gets boring. 20% time breaks up the drudgery.
I suspect that you don't want to solve the developer's problems though, just your own.
Anyway, you're asking a room full of developers what they would want and they're telling you. 20% time is a solution that works. Toiling away on the same problem day after day sucks and it gets boring. 20% time breaks up the drudgery.
I suspect that you don't want to solve the developer's problems though, just your own.
I agree, I overreacted. We had 20% rules for few years with mixed results, but put this practice on hold till Summer. Maybe we will not see such problems when it will be back.
I hope for the best for you with this. In my experience, the mixed results are part of the process. Think of it more as R&D costs rather than "loss" per se, and it may be easier for you (and your investors) to think about.
Management is hard. We're all learners when it comes to working with people, especially when some of the people are smarter than we are. Keep learning!
Management is hard. We're all learners when it comes to working with people, especially when some of the people are smarter than we are. Keep learning!
WWWade(1)
There's a good comment down-thread about 20% time. You don't have to say "go and do whatever you want." It can be about "non-billable" R&D. Perhaps this developer sees an issue, or a potential optimization, or even a new product or service, but never has time to develop it. This arrangement allows both of you to get what you want.
As far as "special treatment" goes, why not extend this to all the leads? It seems reasonable to have these folks pushing the technical boundaries for the company.
As far as "special treatment" goes, why not extend this to all the leads? It seems reasonable to have these folks pushing the technical boundaries for the company.
Why is he "lead" then, if he's not special?
Important that 20% time can be beneficial to your entire team. And this doesn't have to be absolutely free, it can be tangentially related to something that at least sort of aligns to your company - whether internal (support, communication, internal fun) or external (product, trying new platforms / technologies).
And it doesn't have to start at 20%; if your core product can't afford everybody to take 20% time toward interesting things, then 10%.
And it doesn't have to start at 20%; if your core product can't afford everybody to take 20% time toward interesting things, then 10%.
maybe you should just give everyone 20% time then?
you could compromise, one day every other week?
you could compromise, one day every other week?
Special policies are for special people.
And all developers are not equal, but you know this. Treating them as such is destructive.
And all developers are not equal, but you know this. Treating them as such is destructive.
I was in his shoes and decided to leave. And there were only two things I wanted in order to stay:
1. Skin in the game. Equity, profit sharing, guaranteed monthly bonus based on performance. Doesn't really matter as long as we share. Because if I'm good and work hard, I want to enjoy the results too. A fixed salary is not going to cut it anymore.
2. Freedom over actual implementation and veto power. You may be good at running a company. But I'm great at building things. So when you give me a task, don't tell me how to do it. Yes, we can talk about it and make decisions together. But I must always have the last word. Because, more often than not, I understand things better than everybody else. Including you.
If your lead developer does leave, expect a major slowdown, morale decrease and even further resignations. On paper he might look like a replaceable asset. But your development team doesn't see it that way. We're all humans. And relationships matter.
1. Skin in the game. Equity, profit sharing, guaranteed monthly bonus based on performance. Doesn't really matter as long as we share. Because if I'm good and work hard, I want to enjoy the results too. A fixed salary is not going to cut it anymore.
2. Freedom over actual implementation and veto power. You may be good at running a company. But I'm great at building things. So when you give me a task, don't tell me how to do it. Yes, we can talk about it and make decisions together. But I must always have the last word. Because, more often than not, I understand things better than everybody else. Including you.
If your lead developer does leave, expect a major slowdown, morale decrease and even further resignations. On paper he might look like a replaceable asset. But your development team doesn't see it that way. We're all humans. And relationships matter.
I wish I read this years ago when I left a company. Being young and stupid however, I doubt either of these things would've been afforded to me.
A corollary to this is to make sure you leave gracefully if you feel you must leave. You may be the lead developer on this project, but you probably have lots of projects ahead of you. I made the mistake early in my career of burning some bridges I shouldn't have over titles. Took a decade or more to realize what I had done.
There's a number of ways to compensate your best developer in ways not necessarily money orientated:
- Give them flexi-hours. They can come and go as they please so long as either a minimum amount of time is worked or better still they are measured on output and not on time
- Give them the opportunity to work on research and development (aka 20% time)
- Give them the opportunity to work on problems that your company has. If you have 50 people and several development teams I'm sure there are lots of internal problems this developer could help address
- Give your developer people to mentor. S/he might relish the opportunity to help others raise their game to his/her levels of awesomeness
If none of that hits the spot, find out what motivates your developer and work out how to align his/her motivations to the output of the work they go on to do.
Above average developers are not easy to find. You need to make sure that you've done everything in your power to keep your best developers onboard as replacing them is not easy.
- Give them flexi-hours. They can come and go as they please so long as either a minimum amount of time is worked or better still they are measured on output and not on time
- Give them the opportunity to work on research and development (aka 20% time)
- Give them the opportunity to work on problems that your company has. If you have 50 people and several development teams I'm sure there are lots of internal problems this developer could help address
- Give your developer people to mentor. S/he might relish the opportunity to help others raise their game to his/her levels of awesomeness
If none of that hits the spot, find out what motivates your developer and work out how to align his/her motivations to the output of the work they go on to do.
Above average developers are not easy to find. You need to make sure that you've done everything in your power to keep your best developers onboard as replacing them is not easy.
For me personally I like the R&D option, however in smaller teams with timelines it always leads to being scrapped because project X needs to be delivered by Y.
A note to employers around this, let the developer choose the project - even if it has to be relate-able to the company in some way. If it's a big company I'd love to go to other areas of the company, meet people in other areas of work and ask them about their work flow, problems they encounter day-to-day and if it's interesting and tech-solvable - build a solution!
Or if your devs aren't as "go-get-em" as I appear to be, offer a few examples that you've researched and offer them the opportunity to do the above.
A note to employers around this, let the developer choose the project - even if it has to be relate-able to the company in some way. If it's a big company I'd love to go to other areas of the company, meet people in other areas of work and ask them about their work flow, problems they encounter day-to-day and if it's interesting and tech-solvable - build a solution!
Or if your devs aren't as "go-get-em" as I appear to be, offer a few examples that you've researched and offer them the opportunity to do the above.
As a developer, the only times I am bored with the work are when there is nothing that I feel I can contribute or there is no sense of ownership in the work. If you are just assigning your developer tasks all the time, as a developer it starts to feel like you're a computer mouse, being dragged from place to place. It's kind of debilitating because there's a lot of potential and developers have some insight on angles for creative direction that may not be taken into consideration. If there's nothing of value we can contribute, there's no heart in the work.
Give him some opportunities to pitch some ideas, contribute, or find ways to let the developer be invested in the work. If that is not possible, maybe give him some leeway to do some personal projects or side projects for the company.
Give him some opportunities to pitch some ideas, contribute, or find ways to let the developer be invested in the work. If that is not possible, maybe give him some leeway to do some personal projects or side projects for the company.
That's a questionable matter. In every project, there is a little interesting stuff, and the rest is just chores.
Even if you're doing your own project, there will be a bunch of boring unpleasant work.
Even if you're doing your own project, there will be a bunch of boring unpleasant work.
Speaking only for myself, the boring parts of personal/20% work often pay huge dividends when I go back to non-personal work.
This. I've just left a company I've worked with for a long time in a lead developer role, because they started saying how to do everything as if my opinion didn't matter at all. There were even cases where I've said that a particular feature is not going to work if I implement it in the way they want and I went ahead to propose an alternative, but the manager just told me to do it that way. 2 weeks later I had to start again when they finally saw that it's not going to work that way and the manager just repeated my proposal and he even had the nerve to say it was his idea...
Find out was his or her long-term goals are and what your developer truly wants. Maybe you can find a way to redefine your developer's role and responsibilities in a a sufficiently interesting fashion.
I have personally been in a situation where I quit from a company of similar size because I got bored. First of all, the work wasn't all that challenging on a technical level even though we got to work with the latest bleeding edge technologies. The second reason was a lack of room for career advancement due to a very flat hierarchy. The third reason was a lack of strategic vision for the company itself. Essentially, I was stuck in a dead end position with basically no input on the company's strategy. I did propose some ideas that were later successfully implemented by other companies but ignored or delayed by mine which was highly frustrating. So, in the end, their attempts to retain me (and even re-hire me a year later) failed. I actually liked the team, but the negatives outweighed the positives.
When thinking about this episode some years later, an idea came to me. What I really wanted was to have more input, more responsibilities and a way to fix the problems I saw on several levels of the company. What I should have asked for was a transfer to product management or possibly a dual role in PM and development. At the time our product managers were exclusively people with business backgrounds who often had problems understanding the technical details as well as possibilities and limitations. With my technical background I would have been able to help bridge that gap. I would have also had the management access and strategic input that I wanted and would have most likely been a more valuable asset in that position than as a pure developer. But I didn't think of this and neither did they.
The bottom line is that sometimes it can make sense to not only think vertically about possible career moves but also horizontally. You may not have a choice when it comes to losing your developer, but said developer may be even more valuable and happier in a new role.
I have personally been in a situation where I quit from a company of similar size because I got bored. First of all, the work wasn't all that challenging on a technical level even though we got to work with the latest bleeding edge technologies. The second reason was a lack of room for career advancement due to a very flat hierarchy. The third reason was a lack of strategic vision for the company itself. Essentially, I was stuck in a dead end position with basically no input on the company's strategy. I did propose some ideas that were later successfully implemented by other companies but ignored or delayed by mine which was highly frustrating. So, in the end, their attempts to retain me (and even re-hire me a year later) failed. I actually liked the team, but the negatives outweighed the positives.
When thinking about this episode some years later, an idea came to me. What I really wanted was to have more input, more responsibilities and a way to fix the problems I saw on several levels of the company. What I should have asked for was a transfer to product management or possibly a dual role in PM and development. At the time our product managers were exclusively people with business backgrounds who often had problems understanding the technical details as well as possibilities and limitations. With my technical background I would have been able to help bridge that gap. I would have also had the management access and strategic input that I wanted and would have most likely been a more valuable asset in that position than as a pure developer. But I didn't think of this and neither did they.
The bottom line is that sometimes it can make sense to not only think vertically about possible career moves but also horizontally. You may not have a choice when it comes to losing your developer, but said developer may be even more valuable and happier in a new role.
In my personal experience this kind of boredom means that he wants to play and not to work.
I have seen more than 10 or 15 cases of developers who were hired to develop and evolve a product and get "bored" after they learn the new tech that brought them to the company/project and use this as an excuse to not finish the project or keep running the product/company.
I'm not saying that keeping working with new tech or new projects is a bad thing, but it is usually a bad thing for companies to keep such people when what they need is someone to help the company grows and move forward.
I would suggest you to offer him a position where he could use his intelligence and tech skills to help solve real problems for the company and not only program. A few examples:
* Put him in touch with your operational people - If you an e-commerce that ships physical products, let him known and learn how logistics works and what pain points they have
* Make him participate in marketing/product growing meetings and let him help bring more money in
* Enable him to help other developers or fix major problems in the product - not technical problems by themselves, but real problems that slow down the development
If he doesn't want to help maybe he is not a keeper and should be better off doing consultancy/freelancing projects where usually there is not much responsibility once the project is finished.
I see great value on being technically safe and capable, but most of the time what is most valuable is people eager to work and make things go forward for the company.
I have seen more than 10 or 15 cases of developers who were hired to develop and evolve a product and get "bored" after they learn the new tech that brought them to the company/project and use this as an excuse to not finish the project or keep running the product/company.
I'm not saying that keeping working with new tech or new projects is a bad thing, but it is usually a bad thing for companies to keep such people when what they need is someone to help the company grows and move forward.
I would suggest you to offer him a position where he could use his intelligence and tech skills to help solve real problems for the company and not only program. A few examples:
* Put him in touch with your operational people - If you an e-commerce that ships physical products, let him known and learn how logistics works and what pain points they have
* Make him participate in marketing/product growing meetings and let him help bring more money in
* Enable him to help other developers or fix major problems in the product - not technical problems by themselves, but real problems that slow down the development
If he doesn't want to help maybe he is not a keeper and should be better off doing consultancy/freelancing projects where usually there is not much responsibility once the project is finished.
I see great value on being technically safe and capable, but most of the time what is most valuable is people eager to work and make things go forward for the company.
It's a problem with our industry. Devs want to spend time on activities that enhance their career. Because there is almost no internal career progression this means focusing on transferable skills.
Without loyalty, or at the very least aligned incentives, you will never get the most business value out of developers.
Early on in my career I was the sole dev looking after a large legacy system. For 4 years I worked really hard and added a lot of business value. I was not rewarded at all; No promotions, minimal pay increases, no respect etc. All the while my tech skills were getting out of alignment with what the industry was paying well for.
Without loyalty, or at the very least aligned incentives, you will never get the most business value out of developers.
Early on in my career I was the sole dev looking after a large legacy system. For 4 years I worked really hard and added a lot of business value. I was not rewarded at all; No promotions, minimal pay increases, no respect etc. All the while my tech skills were getting out of alignment with what the industry was paying well for.
It's your problem that you couldn't convince them of your worth and get fair compensation. And I don't mean that you hold the keys to the kingdom and ask the king for ransom. Simply quantify the benefits that your system provides and prove that it's in their best interests to have you working there.
"It's your problem that you couldn't convince them of your worth and get fair compensation."
If a company doesn't respect, value, and trust their developers it is very difficult to change their minds (as a developer). I tried for over a year.
I've found it is far simpler and more profitable to focus on the skills the market values rather than focusing on what is best for a specific business.
If a company doesn't respect, value, and trust their developers it is very difficult to change their minds (as a developer). I tried for over a year.
I've found it is far simpler and more profitable to focus on the skills the market values rather than focusing on what is best for a specific business.
That sounds like a situation that a lot of developers find themselves in. Do you have any recommendations for people in similar situations?
How did you end up getting your next job?
I was in that situation once and the main reason that I was able to make the next move was because I was working on a side project which gave me the experience.
How did you end up getting your next job?
I was in that situation once and the main reason that I was able to make the next move was because I was working on a side project which gave me the experience.
> I have seen more than 10 or 15 cases of developers who were hired to develop and evolve a product and get "bored" after they learn the new tech that brought them to the company/project
My guess is that those developers saw the clusterfuck in your company. And instantly decided "Fuck this bullshit. I don't get paid enough to care.".
My guess is that those developers saw the clusterfuck in your company. And instantly decided "Fuck this bullshit. I don't get paid enough to care.".
Sorry for not mentioning it, but it was in more than one company.
As a developer, I see my boredom as a sign of gross mismanagement.
I'm not altogether lazy. I can always find something to do on my own that is at least tangentially related to the goals of the company. If nothing else comes to mind, I try to find and retire some technical debt, because there's always some technical debt lurking around somewhere.
So when I get bored, it is because I have been forbidden to do things beyond what I have been allowed or ordered to do. It is because I feel that any initiative will be ignored at best, or punished at worst.
Boredom is a subset of frustration. If there are any bored developers at your company, you need to take a long, hard look at how you allocate their time. And if the lead is bored--the person who should nominally have the most flexibility and autonomy on the dev team--I guarantee that some people lower on the totem pole already have their resumes out there.
I'm not altogether lazy. I can always find something to do on my own that is at least tangentially related to the goals of the company. If nothing else comes to mind, I try to find and retire some technical debt, because there's always some technical debt lurking around somewhere.
So when I get bored, it is because I have been forbidden to do things beyond what I have been allowed or ordered to do. It is because I feel that any initiative will be ignored at best, or punished at worst.
Boredom is a subset of frustration. If there are any bored developers at your company, you need to take a long, hard look at how you allocate their time. And if the lead is bored--the person who should nominally have the most flexibility and autonomy on the dev team--I guarantee that some people lower on the totem pole already have their resumes out there.
I think your best bet is to part ways with the developer on good terms. The problem you don't seem to see is your company's culture. There have been several good suggestions in this thread (20% time, flexible hours, mentoring, etc), but you haven't been receptive to any of them.
You want your developer to stay there, but only on your terms. Your developer is saying that they need an interesting challenge, but you don't have any to give, and you've taken away a significant perk for the good of "the company." That's a big problem, and unless I miss my guess you're going to start losing other developers as well. A company is made up of people, and if your people aren't happy then they are going to go elsewhere.
You want your developer to stay there, but only on your terms. Your developer is saying that they need an interesting challenge, but you don't have any to give, and you've taken away a significant perk for the good of "the company." That's a big problem, and unless I miss my guess you're going to start losing other developers as well. A company is made up of people, and if your people aren't happy then they are going to go elsewhere.
I've been in a very similar situation myself. Being the lead developer from a very early stage, working with shaping the product and the business itself as well as actually making it happen by coding as well as heading the development team.
However, in my case, a larger company group was the sole owner of the company and a significant part of the vision and goal went out the window after launch due to internal politics in the company group. This was demotivating because frankly, a large part of my purpose of getting on board disappeared. So this is one part to ask yourself, in terms of organisation/vision/company goals - has anything changed?
In terms of tasks, I'm motivated by actually creating value - shipping things that made sense business wise. During the first 1-2 years this was the case, but when strategy was changed to cut costs (yet again due to internal company group politics of the owner) I felt I didn't really contribute on the level I wanted (e.g. architecting/developing large scale, heavy traffic modern web application versus copy/paste the nth banner network JavaScript code for yet another ad).
Also, does the person have a niche in their role they particularly excel in and enjoy? Has it changed? In my case I very much was the bridge between business development and technical development. Getting tech people to understand business value of what to do, and work with business developers to leverage technology. When the company cut down on more or less all development and went into maintenance mode this opportunity kind of disappeared. Another take on this is that people may enjoy and thrive during different phases of a company.
In the end I asked myself - in the end of the year, would I feel I've made the most out of it in terms of personal development, experience and pure happiness if I continued with this - or would it be better to leave.
However, in my case, a larger company group was the sole owner of the company and a significant part of the vision and goal went out the window after launch due to internal politics in the company group. This was demotivating because frankly, a large part of my purpose of getting on board disappeared. So this is one part to ask yourself, in terms of organisation/vision/company goals - has anything changed?
In terms of tasks, I'm motivated by actually creating value - shipping things that made sense business wise. During the first 1-2 years this was the case, but when strategy was changed to cut costs (yet again due to internal company group politics of the owner) I felt I didn't really contribute on the level I wanted (e.g. architecting/developing large scale, heavy traffic modern web application versus copy/paste the nth banner network JavaScript code for yet another ad).
Also, does the person have a niche in their role they particularly excel in and enjoy? Has it changed? In my case I very much was the bridge between business development and technical development. Getting tech people to understand business value of what to do, and work with business developers to leverage technology. When the company cut down on more or less all development and went into maintenance mode this opportunity kind of disappeared. Another take on this is that people may enjoy and thrive during different phases of a company.
In the end I asked myself - in the end of the year, would I feel I've made the most out of it in terms of personal development, experience and pure happiness if I continued with this - or would it be better to leave.
Keep him for sure. Give him some freedom to work on his side projects during working hours.
Not only will he appreciate this, but it will send a positive message to the other 50 who are wondering if they will have an interesting career or if they should be passive looking for other opportunities.
Not only will he appreciate this, but it will send a positive message to the other 50 who are wondering if they will have an interesting career or if they should be passive looking for other opportunities.
Side projects are fine, we had 20% rule for own projects, but put it on hold for 1 year to reach our product goals (product is not growing as fast as it should). So this practice will return soon. It seems he is not ready to wait for several more months though...
You seem to be saying that the project is not moving forward quickly enough because the developer doesn't work enough.
Are you sure the management / communication / teamwork is not the problem ? You may be setting expectations at the level that cannot be reached with your current team and management. Maybe you should set easier targets so that everybody stays motivated after reaching said targets.
Are you sure the management / communication / teamwork is not the problem ? You may be setting expectations at the level that cannot be reached with your current team and management. Maybe you should set easier targets so that everybody stays motivated after reaching said targets.
Problems are everywhere as in every other company. We have flat hierarchy, no middle management and almost nobody above developers. They do all technical decisions and decide how to implement features. Features are selected by Product board and developers have little influence here.
That might be a core problem right there. There's no developer influence in product meetings? While on the business end there might be a need for a feature, business people are not going to understanding what complexities are involved in a particular feature. What you might think takes a day could take 3 weeks. On the other hand, you may be passing over useful features you think are complex but only take a day. If you trust your developers with as much as you say you do, they should have a voice in your meetings. That may be a way to retain this lead developers interest
I'm sure others will comment on the fact that 1 year sounds really long to the average developer. Not really because 365 days is unreasonable (though in some cases it might be), but because it symbolically sounds like BS. It sounds like the company is in economic trouble or that you will "have a change of plans' and postpone the 20% rule in the months to come. Either way, that doesn't make a very motivated team.
I read your comment of only requiring 40 hour work weeks. That shows you're aware, I wish more employers had that outlook.
This may not be popular, but I think you do need to make an exception to the rule, while maintaining it for the other 49.
People will understand if the the Lead Developer has "research projects" that stay undefined. It might even accidentally inspire some to want to be the Lead Developer.
I read your comment of only requiring 40 hour work weeks. That shows you're aware, I wish more employers had that outlook.
This may not be popular, but I think you do need to make an exception to the rule, while maintaining it for the other 49.
People will understand if the the Lead Developer has "research projects" that stay undefined. It might even accidentally inspire some to want to be the Lead Developer.
There is an obvious hidden assumption that 20% rule results in a productivity decrease, which is true for coal mining or agricultural harvest work, but not so much for software development.
A bit less water cooler time talking about sports to avoid something boring, a bit less HN time, combined with fresh new perspectives and new techniques and new ideas can easily result in a net productivity gain. If as per other posts you do strict 40/wk then we all know that at 4:45pm most folks are stalling till 5 so if you officially let him whip out a book on cool new technology you've lost exactly nothing while gaining quite a bit for free. Only a madman or a fool would "start something big" 15 minutes before going home and you claim he's skilled so we can assume nothing of huge importance would be lost by whipping out a book at 4:45pm. Or on the other side of the clock we all know time is spent spinning up, some folks delete emails, some gossip or talk, if he spins up by reading "cool new tech book" or fooling around in another language for 15 minutes to get into the flow, again, you've lost nothing while gaining quite a bit.
Get there faster by going slower, kind of thing. If you're lost in the woods, running as fast as you can just makes you die tired, so slow down.
If it is just grunt manual labor like data entry, then it is probably too boring to be fixed under any circumstances, but you claim in other posts to never hire juniors etc so by your own definition you can't be that bad... probably.
A bit less water cooler time talking about sports to avoid something boring, a bit less HN time, combined with fresh new perspectives and new techniques and new ideas can easily result in a net productivity gain. If as per other posts you do strict 40/wk then we all know that at 4:45pm most folks are stalling till 5 so if you officially let him whip out a book on cool new technology you've lost exactly nothing while gaining quite a bit for free. Only a madman or a fool would "start something big" 15 minutes before going home and you claim he's skilled so we can assume nothing of huge importance would be lost by whipping out a book at 4:45pm. Or on the other side of the clock we all know time is spent spinning up, some folks delete emails, some gossip or talk, if he spins up by reading "cool new tech book" or fooling around in another language for 15 minutes to get into the flow, again, you've lost nothing while gaining quite a bit.
Get there faster by going slower, kind of thing. If you're lost in the woods, running as fast as you can just makes you die tired, so slow down.
If it is just grunt manual labor like data entry, then it is probably too boring to be fixed under any circumstances, but you claim in other posts to never hire juniors etc so by your own definition you can't be that bad... probably.
That sounds like you've then signaled that you expect the team to be in crunch mode for a year, I'd certainly start looking for a new job in this scenario.
Our crunch mode is 40 hrs work week, no overtimes.
" So this practice will return soon. It seems he is not ready to wait for several more months though..."
I think that your idea of "soon" is very different from the rest of the world.
To bring the 20% rule back takes 1 minute: one email sent to everybody that says just that.
I think that your idea of "soon" is very different from the rest of the world.
To bring the 20% rule back takes 1 minute: one email sent to everybody that says just that.
If you really want to keep him, I would give him free reign on a project he wants to do. It can either be related to the company or not, but let him do a side project for work. It can be either a week or a month or more if you are comfortable. He is probably just burned out. Really I would just try to get to the root of the problem and see what he wants to change and work with him to get there.
I'm going to go a step beyond and say that the real problem is that your company is in trouble. You say below that you have suspended 20% time for ONE YEAR until your product is where you want it to be.
Going by that alone, it sounds like there are serious problems. A year is a LONG time in development world. If I knew I was going to be working on one product for a year--and clearly that product was having problems, I'd look for another job too.
Going by that alone, it sounds like there are serious problems. A year is a LONG time in development world. If I knew I was going to be working on one product for a year--and clearly that product was having problems, I'd look for another job too.
Let him go on good terms. If he stays with the understanding he can do various side projects on company time you are both compromising. You get half a developer and he still has to do tasks he doesn't want to do. This is a recipe for resentment.
In my experience, every time someone leaves another person blossoms and steps up. I've seen "irreplaceable" developers come and go, they were all replaced.
In my experience, every time someone leaves another person blossoms and steps up. I've seen "irreplaceable" developers come and go, they were all replaced.
There may not be anything you can do. In order to grow, sometimes it's just time to move on. Learn a new system and language, work with new people etc. Basically I think it's healthy to change jobs once in a while. Personally I have stayed between 5 and 7 years in one place before I felt that it was time to move on (even though those places were all great).
HN: Didn't Java come from bored developers at Sun Microsystems?
Also, didn't Google Maps and also Google Mail, come from a bored developers 20% time?
In line with other suggestions, if you can afford it, give him free reign to do what he wants with a budget too. It may well be the best thing you ever do if he really is as good as you say he is.
Also, didn't Google Maps and also Google Mail, come from a bored developers 20% time?
In line with other suggestions, if you can afford it, give him free reign to do what he wants with a budget too. It may well be the best thing you ever do if he really is as good as you say he is.
Give/boost his share of a company.
Then he'll feel that his role is more important than just do-it-all coder.
Alternatively boost his salary. Don't become the next statistical corp where the only way to get raise is to leave.
Then he'll feel that his role is more important than just do-it-all coder.
Alternatively boost his salary. Don't become the next statistical corp where the only way to get raise is to leave.
I couldn't disagree more. Obviously it shouldn't be as drastic as having to leave to get a raise. But paying your employees more does not guarantee they will stay or be extra motivated.
https://hbr.org/2013/04/does-money-really-affect-motiv
"Other than its functional exchange value, pay is a psychological symbol, and the meaning of money is largely subjective. For example, there are marked individual differences in people’s tendency to think or worry about money, and different people value money for different reasons (e.g., as a means to power, freedom, security, or love). If companies want to motivate their workforce, they need to understand what their employees really value — and the answer is bound differ for each individual. Research shows that different values are differentially linked to engagement. For example, income goals based on the pursuit of power, narcissism, or overcoming self-doubt are less rewarding and effective than income goals based on the pursuit of security, family support, and leisure time. Perhaps it is time to compensate people not only according to what they know or do, but also for what they want."
https://hbr.org/2013/04/does-money-really-affect-motiv
"Other than its functional exchange value, pay is a psychological symbol, and the meaning of money is largely subjective. For example, there are marked individual differences in people’s tendency to think or worry about money, and different people value money for different reasons (e.g., as a means to power, freedom, security, or love). If companies want to motivate their workforce, they need to understand what their employees really value — and the answer is bound differ for each individual. Research shows that different values are differentially linked to engagement. For example, income goals based on the pursuit of power, narcissism, or overcoming self-doubt are less rewarding and effective than income goals based on the pursuit of security, family support, and leisure time. Perhaps it is time to compensate people not only according to what they know or do, but also for what they want."
Let him go. Tell him you would like he come back in one year or two with new ideas.
Less usual suggestion: it sounds like there's plenty going on. Have him mentor junior developers. Ask him to go and survey the office to find out what people's coding pain points are, then see if he can smooth them over.
(This works better if he's older, if he's in his 20s and bored then you should already start looking for his replacement)
(This works better if he's older, if he's in his 20s and bored then you should already start looking for his replacement)
We don't have junior developers :) He doesn't like mentoring as well, just hardcore development :)
If you don't have work that needs his skills (and it sounds like that's what keeps him interested) then do you really need him?
Lots of developers just like developing. At a place I used to work at, one of the best and most senior developers (15-20 years experience) got promoted to project manager for a major project. It took 3 month before he showed up in his bosses office and basically said "demote me back to a developer, or I quit". All he wanted was an office, a hard problem to tackle and to be left alone.
I can empathize with this situation. I don't know if 'boredom' is the right word for it, but maybe.
I would look at providing more freedom for creativity. If you know the developer well enough, you know it what angle that creativity could take. It could be a new language, it could be new technology challenge, or it could be outside of tech and doing more business/marketing/sales stuff.
Dan Pink had a great talk/video where he talks about what people need: Autonomy, Mastery, Purpose. http://www.brainpickings.org/2013/05/09/daniel-pink-drive-rs...
Try providing more of these things and boredom should go away.
I would look at providing more freedom for creativity. If you know the developer well enough, you know it what angle that creativity could take. It could be a new language, it could be new technology challenge, or it could be outside of tech and doing more business/marketing/sales stuff.
Dan Pink had a great talk/video where he talks about what people need: Autonomy, Mastery, Purpose. http://www.brainpickings.org/2013/05/09/daniel-pink-drive-rs...
Try providing more of these things and boredom should go away.
The problem isn't him, it's you. Do the right thing for everyone and quit.
Ask him what would be an interesting task s/he would like to work on. Maybe it might be interesting to the company too.
Yes, there are some tasks, but they somewhat conflicts with current company goals and he is not sure what will come next (let's say it is clear that for 3-4 months there are some tasks, but then nothing interesting)
An excruciatingly boring task can be interesting if you mock up or demo or test in a new lang or framework or back end or DB or ...
My first scala - play framework project, first toy that tried to do something real, was an excruciatingly mind numbingly boring engineering raw data form entry page (like only the C and R letters of CRUD). Playing with a new framework for a demo/mock up was huge fun.
Beware of the danger of the well known business anti-pattern where the "mock up" "demo" magically gets promoted to "production" when things spiral out of control and then things really hit the fan when it breaks or the requirements expand beyond all imagination. "This temporary mock up will be deleted on June 1st" or whatever probably needs to be on every page and in every header.
My first scala - play framework project, first toy that tried to do something real, was an excruciatingly mind numbingly boring engineering raw data form entry page (like only the C and R letters of CRUD). Playing with a new framework for a demo/mock up was huge fun.
Beware of the danger of the well known business anti-pattern where the "mock up" "demo" magically gets promoted to "production" when things spiral out of control and then things really hit the fan when it breaks or the requirements expand beyond all imagination. "This temporary mock up will be deleted on June 1st" or whatever probably needs to be on every page and in every header.
"Somewhat conflict with current company goals"
Sounds to me like this is a deeper issue around control and management and boring is just the excuse to not work on something s/he doesn't appreciate being "arbitrarily" forced to work on. (Do they understand and agree with the company focus? Understand being the more important word).
This also makes me wonder if there is a communication barrier that prevents genuine dialogue.
My gut tells me that you probably won't agree with me or change...so it's probably best for both of you to let him/her go.
Sounds to me like this is a deeper issue around control and management and boring is just the excuse to not work on something s/he doesn't appreciate being "arbitrarily" forced to work on. (Do they understand and agree with the company focus? Understand being the more important word).
This also makes me wonder if there is a communication barrier that prevents genuine dialogue.
My gut tells me that you probably won't agree with me or change...so it's probably best for both of you to let him/her go.
It's unlikely there are no interesting tasks. It's always possible to go meta – to solve the problem of solving problems. If the developer is bored, then there's probably something structural keeping that person from doing that. Figure it out, clear the way, and it might get better.
Have you considered letting him have input into what interesting-to-work-on technologies get added to upcoming products? I'm not saying that's the best way to decide what product to make, but you could consider it at least as a source of ideas.
How is it possible to be bored in software development - an area that is a fractal of unsolved problems? The only normal state of a software developer is "too many things to do", otherwise it is a burn out, or a pathological lack of creativity.
Well, there are business constraints that doesn't allow you to investigate those fractal of unsolved problems.
Imagine that your work 9 to 5 is creating some CRUD forms, and your company gets payed because you create those forms so, start investigating by your own is not a chance anyhow -> YOU GET BORED and you can not change the situation just by yourself.
Imagine that your work 9 to 5 is creating some CRUD forms, and your company gets payed because you create those forms so, start investigating by your own is not a chance anyhow -> YOU GET BORED and you can not change the situation just by yourself.
As others have said, you can go 'meta' and create a script that creates those forms. Boom! you're being paid to watch a computer do everything for you.
A lot of more traditional places will fire you for trying to automate a task unless you do it on the sly or can do it quickly within a day or two.
True that, but even if I didn't get to implement my ideas, at least my boss had always been aware of them. There wasn't ever a situation when he'd thought that I was simply 'bored'.
[deleted]
If you're not completely willing to care about his happiness at the company, please, don't try and retain him half-heartedly. If he's really great then he will find something else.
How about asking them what they want to do? Ask them what motivates them? What they want to work on? Making assumptions based on what you think or what other people want is a mistake.
If you are in such a spot that you had to cancel 20% time already, and this person doesn't get it that it is time to buckle down and get to work, best to let him go before he can do any real damage to your goals.
There's more to being a lead developer than just having coding skills and technical knowledge. If he is immature enough that getting bored gets in the way of his work ethic, he has no business being a lead developer at all.
On top of that, if in your entire 50 person company there is not even 1 task that interests him, might not be such a good fit in general.
There's more to being a lead developer than just having coding skills and technical knowledge. If he is immature enough that getting bored gets in the way of his work ethic, he has no business being a lead developer at all.
On top of that, if in your entire 50 person company there is not even 1 task that interests him, might not be such a good fit in general.
It sounds like the lead developer has no influence on the overall direction of the product and no influence over any management related decisions. Even worse it sounds like the feature set is being handed down on high by a panel.
So the dev is in a dead end role, "forced" to spend his days working on pointless/less important features. It's no surprise that he is bored/frustrated.
So the dev is in a dead end role, "forced" to spend his days working on pointless/less important features. It's no surprise that he is bored/frustrated.
[deleted]
Throw money at him/her. If this doesn't work, they need to go, imo.
How is this affecting team morale?
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. Standard IANL/HR professional disclaimers, no guarantee these will work in this situation/don't know the people or specifics disclaimers apply
TL;DR:
1) Boredom is a sign of little intrinsic motivation to continue working.
2) Simply throwing cash at people isn't enough, in fact, it can be counter productive to think tossing cash is the only solution.
3) People need to feel a sense of autonomy and ownership to value their work. Find ways to grant it.
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.
5) Consider how you're communicating with your teams. Are you issuing edicts or asking for help solving problems?
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.
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.
============================================================
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.
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.
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?
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.
Edit: Formatting
TL;DR:
1) Boredom is a sign of little intrinsic motivation to continue working.
2) Simply throwing cash at people isn't enough, in fact, it can be counter productive to think tossing cash is the only solution.
3) People need to feel a sense of autonomy and ownership to value their work. Find ways to grant it.
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.
5) Consider how you're communicating with your teams. Are you issuing edicts or asking for help solving problems?
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.
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.
============================================================
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.
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.
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?
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.
Edit: Formatting
Stripclubs!