Motivating developers in a project perceived as dull?

Question

As a manager, I can't always end up generating work that'd be cutting edge. Some of the projects do run on maintenance mode, and generate a healthy free cash flow for the company.

As a developer what would it take for you to stick around in this project? I have been thinking of re-branding the work, but I could do with a lot of help here.

EDIT: Thank you all for the suggestions. So far here's what we've got:

1. Rotation of work as per developer interest
2. Flexible working environment
3. Allot time to work on pet projects
4. Socials and fun
5. Branding of the project
6. Use this as a stepping stone for other projects

Answer 1

For projects in maintenance mode, think about what comes next. What will eventually make them unattractive to your customers? To avoid obsolescence, do they need new features, better performance, or to be simplified? If you start over, can some projects be merged? Should they be built with different tools, languages, or processes? Are there improvements or directions that no one's considered? Have your developers answer some of these questions. Build prototypes. Try a new language or framework. Give a project a new mobile interface.

It's easier to experiment with alternatives when there's no looming deadline. Use the dull times to out-maneuver your competitors.

Answer 2

You need offer them something to occupy their time. Projects in maintenance mode often don't require 40 hours a week from each developer. If it does then there is probably something wrong with software, but based on the way you asked the question, I am assuming that you are looking for idea's to occupy your developers while there isn't a whole lot to do. I don't know what your financial budget is, but I think some incentives like sending them to a software conference might be helpful. Another suggestion might include explicitly allowing them to explore their own interests for say 15 hours a week. Someone might be interested in exploring say sorting algorithms or database design. It might not be directly related to your business, but I can't image that you wouldn't benefit from their increased knowledge in the end. Just don't force them to be at work with nothing to do. Allow them to occupy their time with something else if there is not a lot of work to do. I think it fair to ask for a summary of what they are doing to make sure they are not just browsing the web randomly, but let them explore a bit.

Answer 3

Make it fun to work on the project.

In fact interesting projects are pretty rare. And studies shows that employees happiness heavily depend on social and fun. They massively mention colleagues when they are asked why they wouldn't leave their current job.

That's why you should always be happy when you hear laughing in your building instead of yelling.

Answer 4

For me, the best motivator in that situation is very clear goals, especially in the form of a good specification. Or, rather than best, it's one of the few things you have left to offer. The reasoning there is that if the work itself is uninteresting, knowing that I will be reworking a bunch of that dull stuff is a huge further demotivator. That may depend on the programmer clearly recognizing the value of a specification, though.

Answer 5

Another thing is to make it clear that dull as it may be, income generating projects are for the good of everybody - no income, no job etc. The work needs to be done, for otherwise you won't have enough money to keep them onboard. Point this out explicitly, sometimes people don't realize.

Then, divide the load. Try to work out ways of keeping set limits of boring and annoying work (depending on the kind of work, divide up the weekdays, divide the tasks, etc) so nobody has the feeling they are stuck with all the mess while others get to do fun things.

Then, try to even it up with fun things. And talk to the developers, they might have good ideas.

Answer 6

You have to change the perception of the "dull" project. If its generating healthy income, that can't be very hard to do.

Answer 7

Oftentimes, these projects are good for your programmers who are mediocre and are happy being mediocre. You know, the people who aren't passionate about programming and who just view it as a way to pay the bills. Now, understand something: I'm not saying this because they're weaker programmers and you want to make their lives miserable. I'm saying this because these are usually the kinds of people that just don't expect their work to be a source of fulfillment in their lives. By the sounds of it, these sound like low pressure, steady streams of income. More than likely, these workers are more than happy to take some easy, low pressure work.

Of course, that doesn't mean you can just give them dull tasks and forget about them. Perhaps you could give your "A players" 80% fun tasks/20% dull tasks, your "B players" could be 50/50, and your "C players" could be 20/80.

Answer 8

Let your developers earn paid time working on their own pet/open-source/interesting projects by doing some grunt work. Offer them some support with these types of projects, especially if the work is on an in house project or program. That's a strategy that Google uses, I think?

Answer 9

I must admit that I've never worked on a dull and uninteresting project, so I'm not sure that I understand your question. And I develop enterprise systems for a living. :) Seriously, in practice I've found that programmers are bothered by "boring" work much less than I expected. Useless work, like filling out timesheets which nobody ever checks is much bigger problem. That being said:

Know your programmers preferences; some programmers don't like GUI, some steer away from SQL. Try to respect that preferences, since a task that's boring to one programmer might be fun to another. If it's not possible to divide the work in such a way for any reason, make it interesting by increasing competition - let them compete who'll be the first to finish his part, or make a scoreboard on whose part of code had the least amount of bugs in QA. Microsoft is known for their corporate culture which makes programmers compete on different approaches, and choosing the best one in the end or incorporating the best parts of each approach in the final product.

Owning a part of product and having control over it also drastically increases one's engagement. In contrast, there's nothing more boring than having someone micromanage your work. Also, if there's a recurring task everybody hates, explaining the bigger picture - that it's something that has to be done and why and rotating the person that does it each week is usually more than enough.

Answer 10

I have had/seen success with using this sort of project as the path to the more interesting ones.

If your new and mid-level devs all start in the "dull" projects asking questions of the senior devs (who are on the other projects most of the time) and you make it clear that the better you do in the maintenance area the more likely you are to get future involvement in the new work, then assuming you have a decent team and actually follow through with the occasional team change and pulling in the main devs occasionally on the new work the teams will align themselves.

If you have a bad team, or a very good team this approach may not work for you.