The software industry changes extremely quickly. As a result there is a need for companies to be highly mobile and have the ability to respond to threats, clients, or market changes in a fluid manner. Because of this I have seen countless examples of the organization changing at the cost of the engineer, which is one of the many reasons why some software engineers have such utter disdain for “management types”.
We have all met at least one engineer in the past that had a bitter taste in his or her mouth for corporate leadership. Why? Trust. There is a level of trust that must come between all leader and follower relationships. This trust is one of the most important things in the company as it ultimately drives the output and quality of the company. Many times, either correctly or incorrectly, software engineers feel that they are the first ones to do the heavy lifting but the last ones to get recognition for doing so.
Here are a five things that will help to improve relationships with your developers:
Listen to everything and understand it before taking an action. Often times developers tend to “dumb it down” for the “manager types”, leaving out often pertinent technical details. If something doesn’t quite make sense, ask for more information instead of immediately passing judgment. Despite the fact that “dumb it down” implies lesser intelligence on the part of “manager types” it doesn’t actually mean anything of the sort. You wouldn’t expect a career software engineer to understand the intricacies of the corporate pro forma balance sheet so it only makes sense that he or she wouldn’t expect you to understand the intricacies of bit shift operations in a hashing algorithm.
Part of this item comes in the form of project management. If a developer states that it will take one week to complete a project then it will likely take a week to do the project. Before demanding a shorter time frame, throwing more people at it, or forcing overtime, understand what went into the estimate. You simply can’t make time out of nothing and, as the Mythical Man Month points out, adding more people to a software project will often increase the time it takes to reach completion.
2. Stick to your word.
If you tell people something, stick to it. If you can’t stick to it, make every attempt to explain why and to make things right. This applies from everything to projects to job role. I worked for a company at one point that had promised us over and over that a certain (bad) thing would not happen. Then it did. The senior management immediately lost all credibility and control of the organization.
3. Give recognition.
Unless projects are marveled at because of their ingenious engineering, engineers are often the last to be thanked but the first to begin work. My current company does a pretty good job of recognizing the hard work put in by their engineers however I have been in many situations (at other companies) where sales, marketing, senior management, and call center personnel were all repeatedly thanked for making a project a success but the developers that wrote the actual product were not even mentioned.
4. Promote education.
Engineering is a mental job. Most of what goes into designing and writing code takes place in a little box within the head of every engineer. When creating systems the complex relationships, object models, and business rules all come together in a mental map that allows engineers to simply transpose their creation to the screen. By promoting education employers can not only further the abilities of their developers but allow them to sharpen their skills. As Stephen Covey points out in The 7 Habits of Highly Effective People, one of the most fundamental things people can do is to sharpen the saw meaning, in a nutshell, take time to improve the self.
5. Foster downtime.
Despite the public perception, software engineers are just as social as the rest of us/you. They are not work horses that blossom under the constant crack of the whip. As with all people, downtime will often bring a much larger gain through employee happiness. Studies have shown that a happy and secure employee is always going to be more productive than a pressured and tired one.