The holy grail for any team leader is to have her team motivated so that it maintains a high level of performance. But demotivation can occur and it is not that uncommon to occur even in the highest performing teams. The reasons why a developer gets demotivated can be numerous. What follows is five of the most common reasons developers get demotivated.
Being Too Pragmatic
There is such a thing as being too pragmatic. It is the state where code clarity and good practices are sacrificed in the name of improving/maintaining velocity. In this situation, technical debt is accumulated in the code base to the point that it might be irreversible. Technical debt can pile up to the point that it makes no sense to pay for it, both resource-wise and time-wise. Developers that are constantly being asked to produce technical debt, just to get new features out the door, will lose their motivation pretty quickly.
Having a dedicated up-to-date backlog for technical debt issues, which is visited regularly, is a good silver line between pragmatism and technical debt.
Parking Features For The Future
Usually, developers want to see their fruit of labor hit the end user, relatively quickly. The main reason for this expectation is the feeling of fulfillment and closure, which comes from knowing that their work provides value to the product. If their work is parked for a later release, which might be months down the road, their feeling of providing something valuable is postponed as well. When a significant amount of their work is piled to this future release pile, they usually do not see the point in working in something new, that they feel it is not going to provide any value in the short term.
Shipping features regularly, even if they are hidden with a feature toggle, will provide closure to the developer and she will know her work was not in vain.
Lack Of Guidance
Developers are usually slaves of habit. When they learn to do something in a certain way, they usually stick to it. The problem occurs when you put a team of developers, with different habits and views, on the same team. This team is bound to start flame wars for the simplest thing as variable naming. When a developer is constantly challenged for his decisions, her motivation is depleted quite rapidly.
In order to reduce such friction to the team, a set of clearly defined and definite rules, at least in the scope of a specific project, should be put in place in order to prevent flame wars. The rules should address as many points of friction as possible. From variable naming, the way a new service should be created, tools to use etc.
Lack Of A Clear Development Path
This is not a point that applies only to developers, it is a demotivation point for all types of employees.
When a developer enters an organization in a certain role, she shouldn’t be left in the dark about her career path inside it. Being in the same role (and salary) for a significant amount of time crashes morale like nothing else. This period may vary according to the person’s personal tolerance, but there is a breakpoint in all developers.
Having an organizational chart that clearly defines a development path for any new hire or existing employee, along with annual employee reviews, can greatly improve motivation in the organization.
Dated Technology Stack
Depending on the business an organization is in, its technology stack may vary. The one thing is certain across businesses is that developers like to use the latest and greatest libraries and tools. Having them work with old and sometimes deprecated technology, would be like forcing an F1 driver to drive a four-in-hand.
There are a lot of reasons why developers like the latest versions of … well, anything. One of them is that usually, the latest technologies make the life of the developer easier, cause they build on their previous mistakes and try to eliminate pain points. Another reason is that documentation and support for old and deprecated technologies are scarce if they exist at all, making the job of the developer either difficult or impossible. The main reason, of course, is that they cannot cash-in experience that they might have if they were using the latest technologies. Usually, the tech market demands talents with experience in the latest technologies (except for Banks etc.) and having no such experience puts them out of the market.
Updating the technology stack regularly will reduce the risk/cost of breaking changes and would certainly improve motivation.
In order to avoid having a demotivated team, to a degree, try to pay for your technical debt regularly; ship their work with a minimum wait period; have an extensive and clearly written Developers’ Guide; make sure to have a development path in your organizational chart and try to update technology stack regularly.