Searching for Signs of Developer Discontent
Recognition of a job well done in software engineering, or arguably any profession, is intriguing. Rock stars are rewarded for their achievements in building software with leading others in their quest to build software. One aspect that we never really prepare new managers for is the complexities of the human systems they support.
Building scalable enterprise applications is certainly not easy. Comprehending the hidden mysteries of the programmer psyche is far more challenging. Even more so when attempting to gauge their job satisfaction. Often we charge into battle at the point of no return. The signs are there long before, but we quite often don’t follow the route to the final destination. Here I ponder how to monitor themes of displeasure as an alternative to the knee-jerk reaction tactic, and consider if we are initiating the rescue mission too late.
No More Heroes
To determine if we are engaging in timely heroics, we need to first scrutinise the behaviour of dispirited developers. Having regular catch ups with your engineers is imperative in the quest to track their levels of fulfilment. This may sound obvious, but I’ve certainly seen on both sides of the line that this notion is not always apparent. In fact one junior developer recently exhibited extreme surprise that I was putting in a regular catch up at all.
Amazement aside, getting the most out of a 1–1 on either side requires skill and practice. There is a temptation to use such sessions as a general status update. Managers should be mindful that this could be a diversion strategy. People normally love talking about themselves. If they are focusing on tasks, they may be showing reluctance with discussing issues.
Single open questions are the key to breaking that cycle. We tend to ask multiple at once to extract all we need. Perhaps it’s out of impatience to identify a solution. Adoption of a more laid back style is imperative to extract issues early. Ask one question and wait. Embrace the silence. There may be a temptation when vexations are voiced to immediately react with reassurance. But getting to the route of the problem relies on listening and understanding their perspective.
A Sign of the Times
As managers, we know we need to listen. One of the key responsibilities we should focus more on is identifying and rectifying issues. So why are we still missing the signs?
Humans struggle to deal with awkward conversations. We actively avoid discussing uncomfortable matters and will sweep them under the rug. If they are out of sight, they are also out of mind. Once we find out about issues, great or small, we need to do something to address them. Actions speak louder than words.
As managers we need to ask ourselves why we are in denial. There are several reasons that could be at play. Perhaps it is easier to ignore the predicaments we see, especially if you are powerless to fix them. Potentially we become disconnected with such problems, especially if we have never needed to carry out the originating task or function.
Some reasons may be less innocent. We all have aspirations and agendas. Managers, like engineers, can become engrossed in deliverables and miss the big picture. It can be challenging to dedicate time to addressing a pitfall for someone else that may contradict your own viewpoint. Participating in meaningful conversations to grasp their differing perspective is vital in our role in empowering programmers. If you project an agenda, or worse contradictory opinions over time, people will be less likely to raise concerns.
Measure for Measure
Once managers engage and begin listening, it’s important to monitor issues and their occurrences. Managers are certainly not infallible, and grievances can arise again. If you are not able to rectify a particular issue, measuring how often it arises is critical to ensure your developers don’t become frustrated.
Use your regular catch ups with disgruntled directs to identify the key themes of conflict. If they are becoming more regular points of discussion, it’s a strong hint that the issue is not being addressed. Not everyone is going to yell their issues from the rooftops. If you’re waiting for that point to sort out their problems, you are running the risk of them leaving.
You never really understand a person until you consider things from his point of view…Until you climb into his skin and walk around in it.
Atticus Finch, To Kill a Mockingbird
Continuous improvement should apply to people as well as processes. Any issues you discover are productivity blockers for the developer in question that we should be attempting to alleviate. Try alternative approaches to rectify the concerns raised. Encourage your people to raise all burdens, regardless of your own affiliations. Only then can you empathise and take a walk in their shoes.
Thanks for reading!