Non-Technical Issues
When I was just starting my career as a developer, I was often found myself stressing over the technical aspects of software development tasks, wondering if I would be able to come up with a solution to the problem at hand. As someone who lacked experience, I worried that I would end up with a business requirement that I just would not know how to meet. As I gained experience and matured into a full stack developer, I began to realize that these fears were largely unfounded. For any given technical requirement, there was always some solution I could develop, or often as not, find someone else who had already had developed a similar solution for a similar requirement. For things technical now, my primary concern is making sure I choose the best approach among many to get the job done.
However, in recent years and increasingly so, I end up with the dilemma of non-technical problems. These are primarily problems of communication, responsibility, and business process (or lack thereof). Often times I’ve found myself writing the code to facilitate a particular business process, only to find out that the business process has changed, the person or persons responsible have moved on, or someone decided an off the shelf solution would be sufficient(which is almost never the case).
Consequently, I think this is where the mature software engineer or project lead has to develop a completely different, but not un-related, skillset. There are inherent limits to our ability to solve non-technical problems due to the positioning of IT staff within the company or organization and the scope of our responsibility, but use some techniques to help mitigate these roadblocks and obstacles.
First, identify issues that are business process, or workflow problems. There is a tendency among developers to try to code around a whole in a business process or find a complex technical solution to a simple workflow issue. If you find yourself with a task that seems harder than it should be, take a step back and discern whether a small tweak to the requirements or constraints might not make all of the difference in the world. A good business analyst can help with this if one is available to your team.
Second, make sure you are communicating well. When you think you’ve gotten your point across and that you understand your customer completely, you’d better check again. People are complex beings who each communicate in their own way. Learning to pickup on their differences and when a statement coming from one person may differ greatly from the intent of the same statement from another can be difficult, but is essential for long-term success.
Third, understand motivations. This is especially important if there are multiple stakeholders or if you are working alongside contractors or vendors. If you find yourself wondering why the director of department X or the liaison with vendor Y is not playing ball, it is often because their goals or concerns are not being addressed.
And finally, remember the prayer of serenity. There are some problems you, as technical staff, cannot solve. Start with the steps above to identify what can resolve, understand that some things are beyond your scope, and learn to tell the difference.