Developer Experience is the most important driver behind productivity, engagement, and job satisfaction. Therefore, improving the perceived experience of their engineers should be the top priority for engineering leaders at all levels.
However, the reality often looks different as other stakeholders and conflicting short-term interests make other topics seem more relevant, pressing, or urgent. In this article, I will highlight the alarm signals for engineering leaders pointing to neglecting developer experience for too long.
Most engineering leaders ever had the fortune to experience working in an environment with outstanding developer experience. This makes it even more challenging to recognize the need for developer experience investments.
From my experience as a tech lead, engineer, and consultant in various companies, I realized that the warning or alarm signals for issues around developer experience usually could be found in the behavior of engineers early on. Therefore, I will highlight perceivable strategies and coping mechanisms that indicate developer experience issues.
Alarming Strategies
The article “An Actionable Framework for Understanding and Improving Developer Experience” by Michaela Greiler, Margaret-Anne Storey, and Abi Noda lists a couple of individual and team strategies engineers and their teams follow to improve developer experience or find their way around issues. Some of them certainly are good, but others are pretty alarming. So let’s look at those:
Job Crafting
Job crafting is not taking the job description too seriously but working on other things just because they need to be done. This is something you want to have in small startups. You need flexibility because stable roles that are required for the future need yet to be discovered.
However, the problem arises when many people do not work on what they were hired for. Especially when those people do not enjoy this work but do it because it needs to be done. If you find most of the people on your team doing work they were not hired for, and that they do not enjoy, that can be the first indicator of a DevEx issue.
Even if people enjoy their work (many engineers enjoy working on tooling, automation, or refactorings), keeping an eye on this is crucial. Suppose too much work falls into this category. In that case, the risk is that product evolution does not happen, which at some point will cause pressure to deliver, which in turn damages developer experience.
Taking Risks
Again, you want people to take risks and make decisions even when uncertain. This is especially true in startups. However, when there are processes and rules, and you find your people constantly ignoring, bending, breaking, or circumventing them, it is time to reflect on the usefulness of these processes and regulations and if they benefit your engineers’ experience and productivity.
Of course, it is significant that people take risks to move forward. The bad thing is that they have to. Not everybody feels comfortable taking risks; the danger is that some courageous individuals are covering for a systemic issue.
In extreme cases, work gets only done by bending the rules or not at all. Only very few people will manage to stay highly productive in this environment, which takes a lot of energy.
Local Improvements
Local improvements are better than no improvements. Or are they not?
When people find local improvements for systemic issues, this for sure reduces their pain for the moment. However, this is not beneficial for others and might compensate and hide systemic problems.
For engineering leaders, this means they should look carefully if a local improvement indicates an opportunity for a global improvement. Local improvements for global aspects can increase complexity.
Workarounds and Being Pragmatic
When I saw “Workarounds” as a strategy in the paper, my heart stopped for a second. For me, workarounds are coping mechanisms, at best. The problem with workarounds is that they hide the issue, and people (especially non-engineers) start believing that there are no problems because engineers found ways around them.
However, some people use their creativity to work around those problems (and engineers are particularly skilled in finding viable solutions for tough problems, right?). The issue with this is: It leaves less creativity for the actual job and prevents the removal of the problems. Even worse, more senior folks are usually better at finding and exploiting workarounds. This leaves more junior folks struggling with broken processes and unable to improve anything.
The same is true for too much pragmatism. You want people to be pragmatic and find good enough solutions. However, especially when people are on the brink of reducing their engagement (see next section), their good enough often isn’t good enough in terms of “will lead to company success” but more a good enough as in “allows me to close the ticket”.
Leaders, therefore, should keep an eye on the pragmatism of their engineers and where it comes from.
Alarming Coping Mechanisms
If you have been in engineering leadership long enough, I am sure you have seen most of the following mechanisms engineers apply to cope with horrible developer experiences. These mechanisms are connected, and it makes me sad to see companies where leadership believes there are more important issues to address.
We hire motivated and engaged folks who are not only in for the money but also because they believe they can impact the company’s trajectory and maybe even society through their work. Coping mechanisms come short before giving up on this goal. In many companies, we find disengaged, unmotivated, unproductive, and cynical engineers and employees in general. They came there not because they were hired as such but because they were converted into this state by the system they are in. The good news is: This isn’t a one-way street. By investing in developer (and employee) experience, companies can turn this around and regain their employees’ engagement, motivation, and productivity. Of course, it is even better to recognize the signs early and stop the decay.
Most coping mechanisms boil down to reduced engagement on the one side and the risk of burnout on the other, but they come from a different angle. Therefore I will discuss them all to raise awareness for the issues around them.
Focusing on Personal Projects
When people do not experience enough success in their work, they tend to compensate for this through more success in their personal time. The risk is that they spend more time coding on private projects just because they need the win, not because they find it refreshing or relaxing. If this is the case, they might neglect other personal responsibilities or needs, which is a sure path to burnout.
Thus, as much as leaders might like it when their engineers work on side projects and contribute to open source, it is essential to understand whether this comes from joy or the need for success in a work-related field.
Procrastination
This coping mechanism is not in the paper but something I have observed countless times: Instead of working on the most critical topic regarding value for the company, engineers find other, smaller tasks where they can succeed faster.
The risk is essential tasks not being done or delayed. Furthermore, procrastination might give a short positive feeling, but the long-term knowledge not to work on vital things can damage the self-esteem and satisfaction of engineers.
Working Overtime
Motivated and engaged employees who are passionate about the company often try to compensate for systemic issues or issues around developer experience by working more and harder.
This can lead to developer productivity staying roughly the same in the short term. However, inevitably this leads to frustration, burnout, and employee churn, which all damage productivity long-term.
Leaders should be alert when people work overtime, which becomes a habit. Their overwork might cover the real problems long enough for them to become too big to be hidden anymore. This will frustrate and burn out those who tried to compensate for the issues in the first place.
No Longer Speaking Up
When people stop complaining, all is good. Right? This, at least, is what one senior executive once told me. The truth could not be further away.
When people stop complaining, but the problems they complained about do not magically disappear, they either do not care anymore or are too afraid to raise concerns. Both cases are a reason to worry.
You hire the smartest and best engineers you can get for the compensation you are offering. You want them engaged, motivated, and committed to their best work. You do not want them to resign mentally and do as they are told.
Reduced Engagement
When people just do their job at the bare minimum, this can be another sign of serious developer experience issues. Humans need something they can be proud of. And ideally, given the amount of time we spend at work, our work should be something to be proud of, too. Thus, employees are intrinsically motivated to deliver the best work they can. If they don’t do so, the reason often is a loss of belief: The belief that the environment allows them to do their best work or the belief that their work even matters.
No matter the reason, the consequence is clear: When people are disengaged, productivity becomes highly unlikely.
Gaming the System
A friend once told me they are forced to estimate tasks for “random reasons”. As he saw that there was never enough time to invest in reducing technical debt or work on things that would have made them more productive and work more enjoyable, he started to overestimate.
Instead of “estimating” the day that the task really would have taken, he estimated a week, leaving him with four days to invest in the things he thought were critical.
The paper shares a similar story; I have heard this many times. So, this is not an exception. I also have heard the product manager or team leads started not to trust estimates anymore and therefore pressured engineers to estimate smaller. Yikes!
While the example is about estimates (and I do not believe in estimates), the point with “Gaming the system” is that If the system needs to be gamed to be productive and do the right things, the system is broken.
Gaming the system might initially feel smart, but it is a sign of reduced engagement (“I do not care for the system/company, I just want to do my job”). It leads to distrust from others and a waste of time and money for those who develop the system and believe people follow the rules.
When you, as a leader, see somebody gaming the system, try to find out why they believe the system needs to be gamed. Tremendous developer experience opportunities can be found in this discovery.
Leaving
When people cannot cope with the problems and issues they experience daily, they will eventually leave. This is the last and most decisive signal your employees will send you.
Unfortunately, in that case, it is too late for the specific employees who sent that signal. However, it is not too late to take action to improve the developer experience again.
When the number of leavers increases, this is a sign that something is off in the company. Of course, there will always be somebody who finds a better opportunity, wants to switch careers, or has another external reason to leave. But: When the most engaged, motivated, and committed engineers (or employees in general) quit, and when this happens more frequently, it would not be wise to look for external reasons. The likelihood that your company has severe problems in the culture, employee satisfaction, processes, and structures is close to 100%.
Take every leaver seriously and discover what internal factors led to them resigning. With leavers, a lot of knowledge will also go. Even worse, this can further demotivate those who remain, who might also consider leaving.
What to do?
All these alarm signals sound bad, and you might find yourself in a situation where you were able to recognize some (or all) of the above signs. The good news is that this can be fixed or improved, which is cheaper than letting the issues go unaddressed. — Issues of this kind, when unaddressed, tend to get worse and damage the company further.
If you are unsure where to start, I offer you a free 30-minute discovery call to discuss your situation and see how I can help you improve the experience of your engineers and their productivity and satisfaction along the way.
Investing in developer experience means investing in company success, employee satisfaction, and engineering productivity. — There isn’t a better and more rewarding investment for most companies I have seen and consulted in the past.
Conclusion: Commit to Developer Experience
Understanding and responding to the alarm signals of declining Developer Experience is crucial. As an engineering leader, these signals, from unusual coping mechanisms to alarming strategies, can provide insights into systemic issues that may hamper your team’s morale and productivity.
Instead of overlooking these signals, see them as opportunities to enhance your team’s work environment. Investing in Developer Experience lays the groundwork for team satisfaction, productivity, and long-term company success.
Challenging as it may seem, help is always available. Ready to boost your team’s developer experience? Schedule a free 30-minute discovery call today and embark on this transformative journey. As the saying goes: The best time to invest in Developer Experience was yesterday. The second best time is now.
Which of the above signals do you see in your team? What are you doing about them?
One Comment
> “good enough often isn’t good enough in terms of ‘will lead to company success’ but more a good enough as in ‘allows me to close the ticket’”
I love that distinction. So many in technology let the perfect become the enemy of the good, and fixing that often comes without helpful guidance. Recognizing that there are different kinds of “good enough” is helpful.