Technical sensitivity-essential for grass-roots technical managers

When talking about the capabilities of managers, we will immediately think of communication, authorization, decision-making, and other capabilities. However, for the grass-roots technical managers (such as team lead and line manager) in software development activities, I would like to point out another important capability that has been greatly ignored-Technical sensitivity.
What is technical sensitivity for grass-roots technical managers? Technical sensitivity: 1) engineers can quickly understand and solve technical problems, and 2) have the ability to balance multiple technical solutions, provide constructive comments and suggestions, and even make choices. 3) when engineers put forward technical ideas, they can be keenly aware of the significance to products and teams. 4) be able to reasonably allocate the work content of team members based on the individual differences and Skill Characteristics of team members and the overall development needs of team skills; 5) understand the quality of the project at the code level; 6) understand the complex nature of software development activities. Some of the content seems to be what engineers should possess, but why does it require grass-roots technical managers?
First, the grass-roots technical managers act as the contact persons of the technical team for the management in their daily work, in various meetings with product managers and project managers, they explained the technical problems affecting the project progress. This requires managers to be informed of the technical progress of the project in a timely manner. Obviously, these progress must be obtained from the engineer's mouth. In daily work, grass-roots technical managers should not only be able to understand the technical problems explained by engineers, but also have to master the key points of the problems. They should not be able to understand the problems explained by engineers, but will be forgetful afterwards. If the Grass-roots technical managers do not have this ability, it is easy to cause poor communication with the management and technical teams and affect work efficiency. (Note: I have met some grass-roots technical managers who have to explain the same technical problems to them in different time periods. The main task of opening a technical meeting is to let him understand the technical problems that have arisen, which is as inefficient as he can imagine)
Second, grass-roots technical managers may face the problem of selecting technical solutions from time to time in their daily work. The selection of large-scale technical solutions (such as system-level and subsystem-level) is usually done by architects, however, small-scale team-level technical solutions will become the work content of grassroots technical managers in many cases. When the team has more than one engineer with considerable technical strength, but there are significant differences in the design concept, they are likely to advocate different implementation solutions during the project implementation process, if the design scheme cannot reach consensus in a timely manner, the smooth progress of the project will inevitably be affected. At this time, the grass-roots technical managers must participate in the process and make the selection of the design scheme by using their technical capabilities and teams. In this case, even if the technical manager does not directly make a decision, it must ask some questions to help the team make a decision. The question may be: what is the development cost of each solution? What are the long-term and short-term benefits of each solution? Which of the following is more urgent? And so on. The question is entirely dependent on the technical capabilities of the grass-roots technical managers and the specific status of the project at that time, and there is no standard problem set. If the Grass-roots technical managers do not have this ability, they can easily lose their technical orientation, which is not conducive to maintaining an upward technical atmosphere in the team. (Note: I have seen some grass-roots technical managers who don't care about the disputes arising from the selection of technical solutions in the team. When making decisions, I decided on how many people supported each solution, rather than relying on their own technical capabilities to exert influence)
Third, engineers will propose one or more technical ideas at work. A very important job for grass-roots technical managers is to actively respond to these ideas to guide the development of the team's skills. This requires the Grass-roots technical managers to be able to identify various technical ideas and be keenly aware of the significance of ideas on products and teams. For ideas that can improve product quality and improve team efficiency, grass-roots technical managers should promptly affirm the ideas within the team and allocate resources for implementation. If the Grass-roots technical managers lack such capabilities, it is almost impossible for the team to have certain innovation capabilities. You must know that the direction of the engineer's efforts is largely related to the content recognized by the grass-roots technical managers. (Note: I think the Grass-roots technical managers are doing very poorly. They seem to only care about the project plan and progress)
Fourth, improving team skills is the core work of grass-roots technical managers. This requires grass-roots technical managers to consciously make up for the "short board" of team skills in their work ", arrange work properly by considering the characteristics and technical expertise of individual team members. In the technical management work, we are afraid to ignore individual characteristics and think that everyone can become a technical expert whenever they have the opportunity. In addition, project delays during software development activities can easily give people the illusion that "tasks are inaccurate." In fact, this is a manifestation of insufficient team capabilities. (Note: See the article "core content of technical management-improving team skills)
Fifth, design is the foundation of the quality of software products, but good design must be expressed through the "material shell" such as program code, therefore, the code quality will determine the final quality of software products (derived from professional embedded software development). For grass-roots technical managers, a true understanding of the quality of software products is not simply how many defects are discovered, or reading the so-called "Quality Report", but should be obtained from the product code. Because the software development team is responsible for delivering high-quality software products, it requires the Grass-roots technical managers to guide the technical management work according to the code quality. Otherwise, it will easily float the Quality Management surface. I think a very important task for grass-roots technical managers is to help the team form good programming habits. If there is no code-level understanding of the quality of the project, it is very difficult to guide the team at work. (Note: many grass-roots technical managers have never read the project code, but indirectly understand the product quality through the defect rate of the project, even wishful thinking in the dream of "high product quality)
Sixth, software development, as a mental-intensive job, has always been a great challenge for grass-roots technical managers to manage knowledge workers. In the process of facing and overcoming challenges, it is necessary for grass-roots technical managers to understand the complexity of software development (without "silver bullet") Well. Otherwise, it is easy to develop pure rate management theories, while ignoring the technical factors. Only by understanding the complex nature of software development can we express understanding and patience for engineers who are anxious to face technical difficulties, it also helps to distinguish the root cause of the problem from the management domain or technical domain. (Note: many grass-roots technical managers ignore the technical factors in management and use management methods to solve technical problems. The efficiency and effect can be imagined)
The technical sensitivity comes down to the requirement that the grass-roots technical managers should possess strong technical capabilities (never lose the word "strong") or have good insight into the technology. For the points mentioned above, the reader may think: the vast majority of grass-roots technical managers are technical backgrounds. Is there no technical sensitivity? I believe that many people do not!
It is a fact that many grass-roots technical managers are promoted from people with strong technical capabilities. However, since most of them have accumulated a relatively short amount of time on the technical path (less than 8 years), they did not have a deep understanding of the nature of software complexity when taking up management positions, not to mention having their own software philosophy, and failing to overcome technical difficulties. In addition, once a management job is held, the company is always willing to assume that they are competent in their technical skills and make up for their management skills. As a result, a considerable number of grass-roots technical managers do not have the same level of technical competence (management level is also average), and are not sensitive to technology.
Based on this situation, for those colleagues who want to become managers who have not yet reached the level of technical accumulation, my suggestion is: please do not rush to manage, otherwise, you will lose the technical growth space. Although taking a management position early can lead us to seize the opportunity, the hasty career development is in exchange for sacrificing our own future. In today's fresh society, few engineers know that the best technology is the most effective way to achieve successful technology management. The lack of technical sensitivity will make us pay a lot in the future, and we will also face a bigger dilemma on the road of career development (when the technology is not refined, the management is not good, what to compete? How do you prove that your management capabilities are outstanding ?).
The reason for this emphasis on technical sensitivity is that only grass-roots technical managers are more familiar with software development, and using common sense to manage complex software development is the most effective method. In reality, it is precisely because of the lack of common sense of grass-roots technical managers that they are doing performance management without understanding the capabilities of Engineers (can they be fair ?), If you do not know much about the technical details of the project, do you have a project plan (can it be reasonable ?), Quality control is performed without reading the project code (can it be effective ?),......
The emphasis on technical sensitivity does not mean that the grass-roots technical managers need to understand every technical detail for the managed projects, but emphasize that they should have a good technical accumulation. The technical accumulation here is not simply about how many projects he has experienced and how much code he has written (these are necessary), but about how to have a deep understanding of software development, and have their own ideas, because only these content can be universal to different projects.
Reading this, I believe some readers will ask: if managers do not have the technical sensitivity, can they succeed by making good use of technical talents? To some extent, this is a certain degree of deception. In my work experience, I have encountered a lack of technical sensitivity, but I have done a good job as a grassroots technical manager in technical management. Different from most people, such people have the courage to acknowledge their lack of technical capabilities and respect and trust the technical talents in the team. In fact, it is difficult to do this, especially for those who have strong control desires.
For grass-roots technical managers, what I want to say at the end is: what you get is not just power, but more responsibility-let the team members continuously improve their skills in happy work.