Popular wisdom is that technical people make bad managers. There is always this tussle between the MBA and the technical person regarding who is less hopeless. For the technical folks, MBA stands for "Mediocre but Arrogant". The MBAs would have their own list of TLAs (Three Letter Acronyms) to describe a technocrat. Regardless of the appraisal of each community by the other, it is a fact that technical people eventually become managers at some point or other. It is only the very elite that stay as individual contributors. For the rest, professional life is a team sport, and we are required to do what it takes.
What ails the technocrat? Why can he or she not be a good manager? I am sure that a lot of them are great parents, very sociable, and responsible outside their professional lives. What happens to them when they enter the professional arena? There are many issues. I want to investigate two of them: i) project scoping, and ii) analysis of strengths and weaknesses of his team.
Suppose an engineer is asked to scope a project involving complex computer algorithms. Assume that he has a few junior engineers under him who will do the implementation of the project. This is what he will do: "The project requires me to implement features A, B and C. If I get these three features in, feature D, E and F should be easy as they are just extensions of A, B and C. Now that I will have a solid code base with features A through F already implemented, why not add G and H as well? After all these are just re-use and a bit of re-packaging of A through H. This will go on. So, while the requirement is for A, B, and C, he will plan for A through Z. When the junior engineers see this, they will be understandably outraged. When the top management sees this, it will be understandably elated at the prospect of over-achievement. At the end of the day, the junior engineers will get completely overwhelmed, and the manager will deliver less than the A-Z set that he had promised. Now, since he did not deliver on his promise, he will get the boot even though he might have delivered far more than the A-C that was initially requested.
What will a manager without technical expertise do in this scenario? Given the task of delivering A-C, he will go and negotiate for A-B. He will up-front claim that the schedule is too tight for A-C. He will promise A-B, take the task to his team and get its feedback. The team probably will get it done with time in hand. The manager will take the team out for a lunch of appreciation. In return, his team will volunteer to complete C as well. Now, he will show that he has exceeded expectations and earn a pat in the back.
The lesson here is simple. The goal is to exceed expectations. But the key is that expectations are what you define them to be. If you set lofty expectations, and do not get there, you are back to square one. Alternatively, you could set lower expectations and exceed them consistently. The smart manager knows this. The poor technocrat learns this over time.
The other problem the technocrat faces is that he scopes the project based on his abilities, and not his team's abilities. In the example above, our technocrat will go like this: "Feature-A is a variation of Dijkstra's algorithm, so should be done in half a day. Feature-B is an extension of A. So, it will not take more than one hour. Feature-C is just a knapsack problem. We can implement the existing greedy algorithm. This will take one day. We are implementing well known algorithms, so testing and verification should be minimal. The project should not take more than a week"
The first reaction of the junior engineer will be "What is this Dijkstra's algorithm? By the way, how is it pronounced??" Our tech manager will just lose it at this point. "Did you know that when I was in your position, I proposed a probabilistic algorithm that was better than Dijkstra? The dolts at the reviewing committee rejected my paper". The junior engineer will go "Ok. That is very impressive. But what the heck is this Dijkstra stuff?" Now, depending on the temperament of the techno-manager, he might choose to teach the whole thing to the engineer, or point the engineer to a book, or in the worst case, recommend to the top management that this guy is useless. Whatever he does, the result will be the same. The project will not meet the schedule.
The manager without technical expertise will have no clue about Dijkstra's algorithm or anything remotely similar. His scoping will first involve his engineers. The manager will use their feedback to create a schedule, which probably will run into months. Eventually, he will beat the schedule and take a handy bonus home. Here is a case where the technical manager's technical prowess works against him. On the other hand, the manager without the technical expertise uses his lack of technical knowledge to his advantage.
In summary, the most important thing for a manager is to meet the schedule. He either has to level-up his and his team's productivity, or level-down the expectations to achieve this goal. Technical managers probably do not get this trick. They are driven only by the level-up strategy and fall short every time. Secondly, the technical manager needs to understand that his team may not be as good as he is. This can often be a difficult situation. This requires the manager to know that he is way better than others. Many a time, if you are good, you do not realize that you are good. Things just seem so obvious to you. When the other person does not get it, you brand him as incompetent. The manager needs to have a measure of how good is "good enough" for his team members. He also needs to understand that some of his team members will become better over time. Those who do not get better are the real incompetent ones.
Technical managers can easily turn it around so that everything works in their favor. They have a huge advantage with their technical knowledge. On a black swan day, it is the technocrat who will be able to bail the company out. Managers without the technical expertise rely heavily on their team's competence and trust to get the job done. If either of the two (competence or trust) takes a hit, they will not have an exit strategy. Further, technical knowledge can be used to channel the thought process so that there is a balance between innovation and pragmatism.
Primarily, a technical manager needs to make an effort to connect with his team and understand its strengths and weaknesses. Maybe he should spend some time managing a team that is not in his technical domain. This will force him to rely on his managerial skills to get the job done. He may pick up the nuances of management, especially the ones related to understanding his team's strengths and weaknesses. When he comes back, he may not be the monster to his team that he previously was.
See more : Buy Best Price Buy Best Price Buy Best Price Roadworks HDTV Best Buy
ไม่มีความคิดเห็น:
แสดงความคิดเห็น