111

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?

ReinstateMonica3167040
  • 103
  • 3
Bhushan
  • 761
  • 2
  • 5
  • 8
  • 84
    Re: "Project will run for another one year." What are the chances that a quagmire software project scheduled for another year will actually conclude on time? Practically zero, I'd wager. – Daniel R. Collins May 13 '19 at 05:37
  • 10
    What was the original estimate for the project? Was it 4 years, or significantly less? – Ed Grimm May 14 '19 at 03:36
  • 1
    Can i get OP to come work as a project manager for me while I pay them as a mid level dev? They are never going to hire a project manager if you do the work. – NDEthos Aug 13 '21 at 16:29

11 Answers11

162

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.
Sourav Ghosh
  • 72,905
  • 46
  • 246
  • 303
  • Comments are not for extended discussion; this conversation has been moved to chat. – Neo May 13 '19 at 13:27
  • 4
    Would be nice if you could add some comments on what to do when their answers are "re-write from scratch" or "double my pay" etc. Because quite often those really are the only ways to fix the situation. Maybe you could suggest some other options to put to them. – user May 13 '19 at 13:45
  • So many possible problems. I was once on a project, we had 5 devs, dedicated UX designers and testers. After about 16 months we had our first release. Subsequently most people were moved to other projects, only 2 people left to fix bugs, implement small improvements and mainly write e2e tests. The project became very frustrating. – Sulthan May 13 '19 at 20:01
  • On another occasion, people just hated the project. There was no real leader of the team and the project architecture got overly complicated. The programmers themselves just started to hate the codebase. That's not so unusual what proper programming processes are not followed (e.g. architecture discussions, code reviews). – Sulthan May 13 '19 at 20:03
  • 37
    OP should have a formal 1:1 with all of the engineers on the team. Whether he or she likes it or not, OP is the manager. – Denis de Bernardy May 14 '19 at 01:28
  • 7
    I feel "they perceive the task to be impossible/improbable" is important enough to make that list. I've been a late addition to a few "fly a pig" projects, In two of the three, I was able to find ways to fly the pig (RFC1925.2.(3)), and the rest of the team's spirits picked up each of those times. – Ed Grimm May 14 '19 at 03:45
  • 1
    No growth opportunity or tangible deliverables, yes, they can be the cause (along with possibly not feeling valued). – Helen May 14 '19 at 12:18
  • If I would be asked for a "formal 1:1 meeting because you might be demotivated", I'd almost be directly posting here: "Should I look for a new job opportunity as manager seems to want to push me away due to attitude." - Be careful and straightforward in how you word it. – paul23 May 14 '19 at 18:58
  • 2
    Of course, some developers simply see tedious and repetitive tasks as mundane and don’t spark creativity (or joy -ha). Some developers don’t feel empowered to take ownership or control over their jobs and thus withdrawal. There could be any number of reasons. One potential solution is to gamify the work left to do. Competitions (even without monetary incentive) sometimes invoke primal behavior that incurs focus and drive. Recognizing and celebrating the work being done and possibly showing a weekly leaderboard if it doesn’t discourage, might prove fruitful. – vol7ron May 15 '19 at 02:23
64

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.

Pixelomo
  • 2,790
  • 1
  • 17
  • 24
  • 7
    This is a fantastic idea to both keep engineers energized and management perked up, but since no man is made equal how mandatory should they be in case someone doesn't like it? – lucasgcb May 13 '19 at 08:51
  • 3
    Maybe Pepsi and Pizza... but yes, fantastic suggestion. It's also sometimes known as a "google day". – vikingsteve May 13 '19 at 10:22
  • 1
    Good companies are already doing that once a week anyway. It really sounds like the company itself is a bad place to work and this is just a symptom of that. – user May 13 '19 at 13:47
  • 32
    I like the idea... and I don't like hack days. I've done a couple and they're not for me, so OP should 1) make sure everyone enjoys them or 2) make them non-mandatory – MlleMei May 13 '19 at 14:27
  • 6
    +1 for making them optional. I hate them, but I know a lot of people do like them. I think a lot depends on how prescribed the subject area is, and the technology choices, etc. – Martin May 13 '19 at 15:07
  • 3
    Anything that comes out of a "hack day" that looks like it might go further should START with "how do we make this production-grade". I've seen too many hacks that management thought were ready for daily use. – Rob Crawford May 13 '19 at 16:59
  • This reminds me of Overwatch Workshop, which was born from some free time of two devs. – Jannis May 13 '19 at 20:57
  • yep hack days should definitely be optional, but if the subject isn't prescribed and the devs all enjoy working on it then it shouldn't be a problem – Pixelomo May 14 '19 at 00:55
  • 2
    OP could be someone from my last job. They tried "hack days" as a way to solve OP's problem. It didn't work, and backfired miserably. I go to work to work, I already write code in my own time. If I'm not already free to make arbitrary improvements to the codebase I'm working on, then something is broken with the team that "hack days" won't fix. – Qix - MONICA WAS MISTREATED May 14 '19 at 07:18
  • 1
    Well the thing with optional work hour is that depending of your location it ca be more complexe. Optional paid or not paid? Does the dev aleady reach his weekly quota? Extra hours, means that dev now has to work 5 days in 4.5 days –  May 14 '19 at 07:49
  • hack days have to be paid, but I've found often devs will stay after hours to keep working on a project if they're having fun. – Pixelomo May 14 '19 at 08:55
  • @Qix Would you mind expanding how did offering incentive to learn and make new things backfire when the engineers in question are just bored of maintenance rather than lacking in competence? – lucasgcb May 14 '19 at 11:28
  • 3
    @lucasgcb The strawman of "offering incentive to learn and make new things" falls down when you realize that, even if the "hack day" is a full day, it's still just a distraction from other shoddy management practices. If you're under pressure to get something done, and you have product, sales, CEOs, etc. on your back about getting X feature out the door, the last thing you want to do is feel pressured to do a 100% context switch to something entirely unrelated to the task you've been pressured into completing the last Y days. It's a miserable experience, and generally eats at your weekend too. – Qix - MONICA WAS MISTREATED May 14 '19 at 21:15
  • 2
    @Qix It's not a strawman when the OP says the engineers are just that; bored. In the case you do have piled on work and features and superiors on your neck then yeah of course that an afternoon doing something else is counter productive, but otherwise it is just that; an afternoon. I'm sorry you had that jading experience but it is no rule. – lucasgcb May 14 '19 at 21:33
  • @lucasgcb Where did I say it was a rule? I specifically recounted a particular experience. Your argument is a strawman. – Qix - MONICA WAS MISTREATED May 14 '19 at 23:25
  • 1
    @Qix Your experience is valuable input to show this answer is no silver bullet, however the way you've expressed this would give one the impression it's always a management facade that's detrimental and never useful. I'm simply letting you in on what I'm interpreting from your words, you are free to correct me. – lucasgcb May 15 '19 at 07:19
  • 2
    As a developer who's worked on a project for 8 years now, I can't think of anything more demoralising than a high-intensity coding project. – AJFaraday May 15 '19 at 15:44
52

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.

Diane M
  • 7,088
  • 3
  • 18
  • 35
  • 52
    From my point of view i have to disagree with the first bullet. There are some things you can only learn in long lasting maintenance projects. Especially things that will go wrong in the future if you dont handle them now correctly. For example maintaining documentation and version control directories. Some design decisions for the architecture (escpecially quick and dirty or "we can clean up later decisions). And so on... You can learn many things from long lasting projects. Working on the most shiny languages only imho isnt always the best. – some_coder May 13 '19 at 05:34
  • 8
    @some_coder but that can be boring as hell. – user1 May 13 '19 at 10:35
  • @some_coder but then this isn't a very pleasant lesson. If you learn from these mistakes, you may want to start over rather than trying to fix and correct something that went in a wrong direction. – Diane M May 13 '19 at 10:57
  • 11
    @ArthurHavlicek But if you don't stick with a project and fix the problems, you're just going to create the same problems in the next project. You don't have that "aha, that's what this is the right way to do it" moment until you have to deal with the consequences of bad decisions. – DaveG May 13 '19 at 14:05
  • 2
    @some_coder -- agreed, there are issues and lessons from long-term support on a project that can't be learned otherwise. But spend too long on a project and you find the standards at the same company have changed, and you're a generation or two behind on what's required for new work. – Rob Crawford May 13 '19 at 17:06
  • 6
    I'd also contest the first point in its generality. Small, short projects often don't go deep, whereas with long running projects you may need a year to get into the essentials of the whole thing in the first place (which is learning) and then you start slowly start to learn how to actually change the architecture - and really substantial change you often can only do with a long breath. I.e. you might use one year to get into business knowledge and special technologies available, prototype and then you go implement them and you learn from the data that comes back eventually. – Frank Hopkins May 14 '19 at 00:00
  • Similar for the generality of the second bullet point. In contrast to a small project it's possible for a large one to fall behind (the small one still can start behind, but likely the devs who set it up are not aware of it^^), but that's not an inherent property. Agree though, that both can happen when the projects are badly managed. And certainly people that are more attracted by small project "properties" (quick implementation/satisfaction) can feel things, e.g. learning, changing focus, is going too slow. – Frank Hopkins May 14 '19 at 00:04
  • I think the mistake is to bring the project as the problem, while the problem is truly the absence of change. 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. You can learn from design mistakes by coming in a long-lasting project toward the end, as well, you don't necessarily need to learn from your own mistakes. I made a small edit to clarify this for first bullet, which I believe is the most important. – Diane M May 14 '19 at 08:16
  • 1
    Ultimately, there is always something personal about motivation. My posts stands for individuals for which long-lasting assignments can be a problem. I believe this can be the case of these developers. If what you consider worth learning is the maintenance of long project ; then its likely you won't bring the issue of how long is the project to your manager. – Diane M May 14 '19 at 08:24
  • 1
    "My posts stands for individuals for which long-lasting assignments can be a problem" Sometimes the best way to deal with such a "problem" is by tackling it head on and learning, versus running away every time you see it. – dwizum May 14 '19 at 16:06
  • @dwizum You imply liking change is being a coward. This is a wrong and disrespectful assumption. – Diane M May 14 '19 at 16:41
  • You're putting words in my mouth. You seem to be advocating for change, and pointing out the advantages of change. That's fine, but if all you ever do is look for change, you're missing opportunities to learn/grow and be employed on long-lasting projects: running from every long lasting project will mean you're limiting your options. More importantly, doing so puts all of the onus on the employer to provide your ideal environment and keep you happy, instead of learning to enjoy the challenges in different types of environments. – dwizum May 14 '19 at 16:51
  • I hear that warning, but we're off topic. My career isn't what's discussed here. The dev's career either. They have strong perceived benefits to leave, that is employer onus no matter what. – Diane M May 14 '19 at 17:16
8

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.

AnoE
  • 9,001
  • 18
  • 37
  • Honestly, if one project is making money. If the company sells one product, then this is the least practical advice you could give. – AJFaraday May 16 '19 at 14:29
  • @AJFaraday, from OP's post, I get the vibe that he is working in a project-based consulting/dev company - many projects, not just one. – AnoE May 17 '19 at 10:32
6

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.

Juha Untinen
  • 3,367
  • 1
  • 17
  • 28
  • Good perspective. So is the suggestion to migrate to a modern stack? If so, you might want to highlight that as your suggestion to OP. Otherwise a good answer. – bob May 13 '19 at 13:08
  • 4
    While I agree that it is good to learn new stuff and somewhat necessary to learn about new stuff for a good developer, by no means is sticking with old and proven tech a definitive way to sink yourself. It depends a bit on the tech (whether it's just a hype that passed), but there are a ton of long lasting jobs to maintain existing projects with the tech that they were created in and while young motivated devs who are ready to jump the next hype train are sought after so are experts who know how to dig through and polish archaeological code artefacts. – Frank Hopkins May 14 '19 at 00:09
  • 5
    I don't like that this doesn't consider the perspective of the business. Throwing away money on a new technology stack that doesn't solve any business need is not effective. (Compare to just giving the extra money to the developers in salaries to keep them in place, demotivated as they may be.) Put another way: I would rather have my tank drivers twiddling their thumbs and feeling bored than start a war just to keep them happy. – Oddthinking May 14 '19 at 15:07
  • @Oddthinking The business should be even more considerate about the risks of using obsolete technology. Developers might grudge and warn, but they will still continue working. Unfortunately having a developer leave is a small risk compared to what using an old stack can do for the BUSINESS. A breach here, leaked credit cards there, having your 5 year business strategy stolen because of the old stack having vulnerabilities that are well-documented and oft exploited - especially EOL software. Marriott Hotel might be more conscious about using patched software in the future... – Juha Untinen May 14 '19 at 15:58
  • Now that PHP5 is EOL, while 60 %+ of the INTERNET uses that in their backend, I can only begin to imagine the kind of trouble we will start to see in a year's time. Simply because they haven't put the effort into updating deprecated tech into something modern. – Juha Untinen May 14 '19 at 16:01
  • 2
    @JuhaUntinen I think the point being made here in comments is, switch to something newer because it makes business sense, not because your developers have no attention span. Businesses exist to be in business, not to keep software developers happy. – dwizum May 14 '19 at 16:15
  • I would say the timescales vary a lot by domain. 3~5 years of C/C++ embedded or server-side coding is not the same as 3+ years on a web stack. As far as I can see you are lucky if a web stack is still relevant 1 year later :-p In my world there are still plenty of things 15 years old in production without better alternatives. When I get to learn are new design patters, working practices, tools, etc. e.g. TDD with Unit Testing, GitLab CI over my previous system testing and Jenkins. – TafT May 15 '19 at 10:35
4

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.
Farid
  • 149
  • 2
  • 17
    The last two points are really subjective. I wouldn't really like to work with customers if I'm forced to, I'll probably start polishing my CV. Similarly for the last point - I like my job as a developer, doing public speaking is transitioning me into a not-a-developer. There are some knowledge sharing sessions I'd enjoy leading but making that mandatory and probably not what I'd like is going over the line. – VLAZ May 13 '19 at 06:49
  • 6
    @VLAZ -- as I try to tell management: I didn't get into software because I'm a people person. – Rob Crawford May 13 '19 at 17:01
  • I have to disagree with all of this. I’m a software developer. I write code. If we can’t come up with a work experience where I right meaningful code, then we don’t need me there. – Cooper Buckingham May 15 '19 at 15:09
4

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.

Thomas Matthews
  • 1,173
  • 5
  • 9
  • Totally agree. You may be working on the same software for years, but calling/considering it one project is self-defeating. Progress has to be measurable. Splitting a project into manageable steps is a skill that should be encouraged in every developer –  May 14 '19 at 17:54
3

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.

rkeet
  • 1,794
  • 12
  • 20
3

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'.

Robin Bennett
  • 10,560
  • 2
  • 27
  • 36
1

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.
Kolappan N
  • 737
  • 7
  • 12
0

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.

Joe Strazzere
  • 382,456
  • 185
  • 1,077
  • 1,492