Ttdfjt

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?

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. — May 13 at 5:37
What was the original estimate for the project? Was it 4 years, or significantly less? — 2 days ago

score 150 · Accepted Answer · 2019-05-13 05:59:21Z

150

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:

Have a formal 1:1 meeting with the engineers who are demotivated. Listen to their problems / complaints.

Ask them for how they think the problems can be resolved without moving them out from the current assignments.

Think and reflect back.

edited May 13 at 5:59

answered May 12 at 16:42

Sourav Ghosh

15.8k167695

3

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 at 13:45

31

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
2 days ago

6

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
2 days ago

1

No growth opportunity or tangible deliverables, yes, they can be the cause (along with possibly not feeling valued).

– Helen
2 days ago

1

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
yesterday

|
show 4 more comments

PixelomoPixelomo 2,3951022 · Accepted Answer · 2019-05-13 01:42:13Z

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.

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? — May 13 at 8:51
Maybe Pepsi and Pizza... but yes, fantastic suggestion. It's also sometimes known as a "google day". — May 13 at 10:22
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 — May 13 at 14:27
+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. — May 13 at 15:07
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. — May 13 at 16:59

score 50 · Accepted Answer · 2019-05-14 17:26:59Z

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.

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. — May 13 at 5:34
@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. — May 13 at 14:05
@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. — May 13 at 17:06
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. — 2 days ago

AnoEAnoE 6,5221128 · Accepted Answer · 2019-05-13 13:22:07Z

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.

Honestly, if one project is making money. If the company sells one product, then this is the least practical advice you could give. — 8 hours ago

Juha UntinenJuha Untinen 2,76211224 · Accepted Answer · 2019-05-13 06:20:30Z

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.

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. — May 13 at 13:08
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. — 2 days ago
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. — 2 days ago
@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... — 2 days ago
@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. — 2 days ago

FaridFarid 491 · Accepted Answer · 2019-05-13 03:20:52Z

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.

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. — May 13 at 6:49
@VLAZ -- as I try to tell management: I didn't get into software because I'm a people person. — May 13 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. — yesterday

Thomas MatthewsThomas Matthews 49524 · Accepted Answer · 2019-05-13 16:39:16Z

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.

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 — 2 days ago

rkeetrkeet 1,357816 · Accepted Answer · 2019-05-13 09:07:54Z

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.

Robin BennettRobin Bennett 1,289127 · Accepted Answer · 2019-05-13 13:33:50Z

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

KolappanKolappan 16227 · Accepted Answer · 2019-05-13 12:30:56Z

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

The tech stack has become old and the developers want to work and learn new technologies.

The project is too big and has become difficult to maintain.

The product is really mature and there is not a lot to do besides simple maintaining it. These works can be repetitive.

They simply want to do something new.

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

Migrate the project to newer technologies.

Split the project into microservices.

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.

You can try doing something new with the internal development process. If CI/CD is not yet implemented, implement it.

Split project into microservices is an huge topic and must carefully planned and executed — 2 days ago
@Vokail Agreed. But if the big project is a cause for this problem, then splitting might help. — 2 days ago

Joe Strazzere 260k1347581073 · Accepted Answer · 2019-05-12 17:32:02Z

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.

score 150 · Accepted Answer · 2019-05-13 05:59:21Z

150

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:

Have a formal 1:1 meeting with the engineers who are demotivated. Listen to their problems / complaints.

Ask them for how they think the problems can be resolved without moving them out from the current assignments.

Think and reflect back.

edited May 13 at 5:59

answered May 12 at 16:42

Sourav Ghosh

15.8k167695

3

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 at 13:45

31

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
2 days ago

6

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
2 days ago

1

No growth opportunity or tangible deliverables, yes, they can be the cause (along with possibly not feeling valued).

– Helen
2 days ago

1

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
yesterday

|
show 4 more comments

PixelomoPixelomo 2,3951022 · Accepted Answer · 2019-05-13 01:42:13Z

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.

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? — May 13 at 8:51
Maybe Pepsi and Pizza... but yes, fantastic suggestion. It's also sometimes known as a "google day". — May 13 at 10:22
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 — May 13 at 14:27
+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. — May 13 at 15:07
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. — May 13 at 16:59

score 50 · Accepted Answer · 2019-05-14 17:26:59Z

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.

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. — May 13 at 5:34
@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. — May 13 at 14:05
@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. — May 13 at 17:06
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. — 2 days ago

AnoEAnoE 6,5221128 · Accepted Answer · 2019-05-13 13:22:07Z

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.

Honestly, if one project is making money. If the company sells one product, then this is the least practical advice you could give. — 8 hours ago

Juha UntinenJuha Untinen 2,76211224 · Accepted Answer · 2019-05-13 06:20:30Z

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.

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. — May 13 at 13:08
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. — 2 days ago
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. — 2 days ago
@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... — 2 days ago
@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. — 2 days ago

FaridFarid 491 · Accepted Answer · 2019-05-13 03:20:52Z

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.

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. — May 13 at 6:49
@VLAZ -- as I try to tell management: I didn't get into software because I'm a people person. — May 13 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. — yesterday

Thomas MatthewsThomas Matthews 49524 · Accepted Answer · 2019-05-13 16:39:16Z