Developers demotivated due to working on same project for more than 2 years

Question

I am currently managing a team of 10 people for a project which was started 3 years ago, which will run for another year. I am not the manager, I am just the most senior developer (6yrs exp.) on the team who needs to do this until the company finds a real project manager.

In our team, there are 3-4 developers who have been working on this project for the last two and half years.
These developers are highly demotivated and it's really affecting their work. I personally think that they can do better than what they are currently doing.

When I asked them about reasons, they simply said that they have been on this project for a very long time hence now they want to work on some other projects or on some XYZ technologies.

I neither have the authority to move them onto another project nor would I like to do so because they know the project inside-out.

Any suggestions on how can I motivate them?

Answer 1

As my study of this situation, there are other problems, actual problems that needs to be investigated. People simply don't get demotivated for working 2+ years on the same project, they get demotivated when they either feel

• They are not valued
• Their work is not valued
• Their opinion is not valued
• They don't see any growth opportunity for their personal as well as professional career

etc.

Given that you're the manager in-charge, either do the following yourself, or report/delegate so someone who is entitled to do:

1. Have a formal 1:1 meeting with the engineers who are demotivated. Listen to their problems / complaints.
2. Ask them for how they think the problems can be resolved without moving them out from the current assignments.
3. Think and reflect back.

Answer 2

Any suggestions on how can I motivate them?

Hack days are a great way to motivate devs. Once a month allow the team to spend their Thursday afternoon working on a hack project. Ask your boss for a budget to buy beer and pizza.

Start by brainstorming R&D ideas, what new tech do they want to try out? what cool thing could you build with your combined skills?

At first hack days can serve simply as a motivation tool. The devs know that once a month they get to work on that cool side project. But in time these projects could develop into viable products your company could use or sell.

Answer 3

As a job-hopper myself, I can testimony about reasons my motivation go down when being in the same project over a long time. This usually has little to do with pay or recognition of my work:

• Working in the same project over a long time lacks of learning opportunities. There is a lot to learn from changing: you learn how projects are different and how they are not, you learn to adapt different teams and technologies, you get a chance to learn from more people, and more situations. Every now and then, I like a new biscuit, it challenges my ability to learn, it adds to my CV, it makes me feel better about my skills. This is usually the core problem to solve.
• Long lasting projects aren't new and shiny. Their technology fall behind. Their code gets big and legacy. Their tasks become repetitive.

This is why given fairly equal conditions, many people enjoy change for the sake of it. Some more than others, and you are powerless on that.

If anything I'd take what they've said seriously, consider that changing them projects might be better than losing them (or might not be). This has a fair chance to happen, because your developers may be unhappy since a long time, and may already be looking elsewhere.

Answer 4

Aside from temporary fixes like sending them to meetups, or other "gamey" approaches:

Those people need a new project, period. They presumably are highly intelligent technical people, who like to play with technology and projects. Nothing you can feasibly do will change that (and you do not want to change it anyways). If you give them the same stuff to do all the time, they get bored - and it does not matter what they do on the side.

If you don't find a solution, they will - which means going to another company. At least in my country (and I don't know about India), this is a strong motivation for upper management to support regularly switching people around between projects. Losing a valued employee just because you (not you personally, but management) failed to provide them with interesting work is just shameful for the company, and can be fixed by an active policy of looking at this regularly.

So, take this "upstairs" and see if you can get them into other projects. If you cannot, and you are not actually the manager, then you at least tried.

Answer 5

If I check back on reasons why I took on new challenges, here's the reasons, and what would have had to change in order for me to stay:

• Using an ancient stack that would never have had been modernized in any way. There was nothing new to learn, which spells death for a developer's career.
  • What should have changed: Migrate to a more modern stack to keep it interesting and fix technical issues and limitations the old system has.
• Regressing from using a really interesting and modern stack that I learned thoroughly while doing the work, to a pile of legacy using an obsolete technology after the project using the interesting stack was cancelled due to non-technical reasons.
  • What should have changed: Migrate to a more modern stack to keep it interesting and fix technical issues and limitations the old system has.
• Blatant lies during the interviews about what the work is about and which stack is used most of the time. You wouldn't hire a Main Battle Tank driver to drive a small-town bus and expect him to be happy.
  • What should have changed: Use the stack you hired me to work on. A developer != sysadmin, the work is completely different.

I think you will see a pattern here :) The life of a developer is fickle, as you need to always be learning new technologies if you want to stay employable. The moment you stop learning new things, you will sink. And if you stay in a project using obsolete technology, you're as good as dead if you stay more than 1-2 years before switching to a new job involving modern tech.

Answer 6

I am prone to this problem myself. Easily find myself demotivated due to boredom. The reason I stayed the longest in my ex-company was because they keep me challenged and I was free to explore new things. Here's a few suggestions:

• Hack days
• Ask the engineers to explore new things that indirectly contributes to the development. If they have not setup CI/CD pipeline before, ask them to work on that
• Role rotation. Put them into customer support for 1 week or 1 sprint. They get to learn new things, company benefit from their new-found experience of working directly with customers.
• Challenge them to be the company's ambassador. Ask them to do public speaking, do knowledge sharing across different departments, start by doing this internally.

Answer 7

On the project I lead, I split up the tasks and used a spiral development cycle.

The tasks were small so that each developer would get a sense of accomplishment.

The tasks were ordered into milestones. Each milestone to show something tangible, for example, getting a "Hello World" printing on an embedded device (this was used to get the development environment working). Next milestone would be a command system via a debug port. The third milestone may be minimal functionality (or a Hardware Device test).

The milestones would be checkpoints on the project. We could use the milestones to show the stakeholders the progress that we were making. The spiral development model allowed us to adjust to changing or development requirements (basically, the only guarantee is that requirements would change).

This gave the developers a sense of empowerment and responsibility. If the task was too much for them to handle, they were either coached by a mentor or the task split into more pieces (they could also pick a different, maybe simpler task).

So, for a given milestone, the developers picked the tasks they wanted.

After the product matured, a database of defects developed. Defects were assigned to the developers based on priority of the defect, the area of expertise, or to give the developer knowledge in a different area of the code.

We have many projects, so some developers switched to different tasks after about 2 years, to do something different.

Have a meeting with each developer. Find out what their interests are.

Split up projects into small tasks.

Allow developers to choose the tasks, based on their interests (not necessarily their expertise).

Be prepared to lose developers due to attrition, as this is normal.

Answer 8

I agree with Sourav Ghosh's answer. However, I would like to add a few things.

I'm one of those developers who can get bored when on the same thing for extended periods of time and/or bashing my head against a wall trying to get things done.

bashing my head against a wall trying to get things done

I mean this in the sense of:

• In the past tried to get management systems acquired / installed / used for at least the development part, e.g. version control, ticket management systems, etc. After months, it got done, while the basic need of it is extremely obvious. For me, that's a big demotivator
• Getting processes started to share information, e.g. store documentation / information in systems such as Confluence, get daily stand-ups going

There are additional factors of course, such as colleagues and interaction. Most of all, it's personal for each and every individual.

get bored when on the same thing for extended periods of time

In my opinion, this is one of the more easier things to remedy. Then again, it's personal and that's where Sourav's answer comes in: ask your devs!

Simple things that can be done to help remedy boredom:

• Go to meetups! Possibly the easiest thing. Your devs get to discuss, with people they don't know, technologies each uses, methods and processes, projects they're working on, etc. etc. This is fun and shares knowledge, something devs love doing. Also: it brings additional knowledge into (!) the company
• Organize meetups! Wow, other way around. Yes, it'll cost money (devs love pizza), but if you let the devs handle this, it gives them something to which is work-related, but not their day-to-day grind (yes, after 2.5 years, a project is a grind)
• Have in-house (and possibly organized as like a meet-up) hackatons! (pizzaaahh!!) Think of a theme, order pizza. Go. Might not produce something of great value, but it's fun, new techs get tried, etc. etc.
• Switch over teams a bit. If you got a few islands within your devs, e.g. that guy does devOps, those are back-enders, those 2 there are front-end, switch them up a bit. Share tasks / responsibilities. Push towards everyone at least understanding everything (different from being able to do everything). Might slow down development a bit, but it promotes learning and knowledge sharing.
• If your employer is feeling generous, steal an idea from Google and allocate weekly time for personal development projects, e.g. every Wednesday afternoon, starting 2 hours before clocking out, all devs do not work on work projects, but their own. Up to your company whether or not those projects should be something that the company could later also profit form, pure self-improvement for devs or completely non-related (e.g. wood working or whatever is possible at the office)

Some ideas. Might not help you out fully, but surely some of these things would be possible, enjoyable for your devs and bring variation into the grind that is work.

Answer 9

On a long-running project, there are likely to be processes that can be automated, or other repetitive jobs that can be refactored. Make some time to address issues like these, even though they aren't direct requirements.

They're fun to work on, make everyone's life easier, and will save time over the life of the project.

And they're a lot easier to sell to management than a 'hack day'.

Answer 10

Working on an old project is often not as interesting as creating something out of scratch. Some of the reasons might be,

1. The tech stack has become old and the developers want to work and learn new technologies.
2. The project is too big and has become difficult to maintain.
3. The product is really mature and there is not a lot to do besides simple maintaining it. These works can be repetitive.
4. They simply want to do something new.

Speak with your team to find the reason. Based on the reasons you can try,

1. Migrate the project to newer technologies.
2. If possible split the project into microservices.
3. Is it possible to rotate the roles a bit for a short time? This could spice up things if the work is very repetitive. Make sure the developers are okay with the new roles.
4. You can try doing something new with the internal development process. If CI/CD is not yet implemented, implement it.

Answer 11

In our team, there are 3-4 developer who are in this project from last two and half years.

These developers are highly demotivated and its really affecting their work. I personally think that they can do better than what they currently doing.

Do you have a manager to whom you report? I am sure you are not the one who would be directly reporting to CEO/CTO. Does that manager ask you about performance of the team? If yes then have a meeting with those developers and the manager. Decide what technologies people want to work on.

Sometimes the company has ever lasting product and its not always possible to give everyone new project all the time.