Product Pressure
In most tech companies, the product team is dictating the majority of the day to day life of the development team— the “what” and the “when”. That is, which new features, bug fixes and in which priorities.
This makes sense, as they are the ones gathering requirements and input from all stakeholders, such as external users, internal users, management, sales, finance, bizdev, qa and developers. They have the big picture and it’s their job to work on the most important things at every stage of the company, from a startup struggling to find product market fit, through growth phase to a corporate with thousands of employees. They have to work on important topics as well as urgent topics without neglecting certain areas or departments.
What could go wrong?
The only reason developers exist is to serve the business, represented by the product. The purpose of development teams in a business is not to have fun and not to learn. It’s great when they do happen and they’re beneficial for the business, but they are not the reason.
Naturally, for a startup fighting for its life, features and bug fixes are almost the only things that matter. But for more mature companies, there is both room and need for working on mere technical topics.
Developers are mostly motivated by autonomy, mastery and purpose. There are more things the affect of course, such as compensation and work-life balance, but they are not determined by the product. Decreasing any of these three will result in unhappy developers.
Autonomy
We already saw that product present problems that developers have to solve, and sometimes insist on the actual solutions, which leaves the developers mostly the time estimation and the quality. Estimation is sometimes also taken out of the equation, as clients are waiting and sales have already given them a certain date. When there is a room for estimation, developers might negotiate for the scope or the quality and try suggesting alternative solutions, partial or complete, which affect the time. Quality is hopefully kept high within the estimation, meaning, developers do not do bad work just to finish quickly, leave the code in a good state and cover with automated tests. But in some cases, product will insist on partial testing in order to release fast and deal with bugs and regressions later.
Purpose
Purpose is given by the product. They have to explain the context of their request, who will benefit from it and by how much. The problem begins when predictions fail time after time, and the expected results are not achieved after the change has been implemented by developers. This has more impact when features are not presented as testing, but rather things that will work for sure, because there is a detailed business canvas. Several sequential failures, especially for projects that involved a lot of efforts, will surely make developers question the purpose, specifically, the competence of product or the business.
Mastery
Mastery can be substantially reduced, when product decides what and when to work on each topic and developers do not invest in their professional growth at work. This is sometimes called “feature factory”.
Let’s list more tangible reasons for demotivation.
Accumulating technical debt: developers must deliver new features, so they have no time to work on engineering topics, such as: upgrading libraries, refactoring code to make upcoming changes easier and faster, improving the build process, efficient local development environment, documentation and more.
The problem with technical debt, is that, it makes future development slower, then product is frustrated with the development velocity. Moreover, developers are frustrated because they have to continuously work around problems without fixing them.
In case there are official dedicated learning and experimenting hours, such as “Friday lab” or “afternoon education”, developers feel the pressure to deliver and continuously skip them in favor of normal work.
Questioning knowledge sharing and technical workshops — when developers learn, they are not delivering new features. The feature factory is idle. The benefit of course, is it will allow more productivity in the near future but there is pressure to deliver right now.
Not allowing time to prepare for hiring — besides the actual interviewing, hiring requires more preparations, such as a precise job description, defining screening questions, writing home challenge and reviewing it. If these activities are considered a waste of time, the results of the hiring process will not be ideal.
Diminishing tech leadership — if all developers, tech leads and team leads are expected to take part only in the feature factory, there is less or no time for people building. Leaders (but also developers of course) have to invest time in strategic thinking, innovation, preparing for 1:1 meetings, personal growth plans, mentoring, pair program, process improvements and more.
Employment relationship is a case of mutual value, where expectations of both parties are met. The employer gets features built and the developer gets compensated. But developers might have more expectations, such as to keep learning, exposure to new technologies, tools and processes. They have their own long term personal vision and after a while, if not fulfilled, developers are demotivated and start looking for a place that can be satisfied. Many developers will not want to stagnate, may it be due to personal curiosity, wish to professionally grow and maintain or increase their market value.
Remember, there will always be that important client we mustn’t lose, some kind of deadline and this feature we want to test with the users.
Don’t neglect technical aspects.
