I didn’t mean that there’s no such thing as management—just that there’s no such thing as management in general. Competent management takes deep knowledge of a business, or at least a type of business.
Well, in my experience, the most competent IT manager was not a programmer (as far as I know). But it most likely helped that he had a natural-science background, as opposed to whatever it is that most managers study (Master of Bullshit and Absurdity, probably). Thus he wasn’t the annoying kind of manager who believes that 1) all problems are imaginary and 2) all problems can be solved by insisting that you think positively.
On the other hand, a frequent failure mode is to take a skilled programmer and say “from now on, you are the manager”. This is how a few companies tried to revert stupidity. Sometimes it worked, sometimes it didn’t, because managing people is a different skill from writing code.
I have seen coders who became good “laissez-faire” managers. But I have also seen coders who became terrible managers, because being introverted they avoided communication with the rest of their team, the junior team members sometimes didn’t even know what to do, and they received no help. I have also seen coders who started micromanaging their teams, insisting that everyone use the most complicated technology and most complicated design patterns regardless of the junior team members’ real skills; who probably felt an unconscious need to compete with their subordinates, which could be rather depressing for the subordinate.
In worst case, the existing top management was not able to tell a difference between competent and incompetent coder, so they promoted the most loyal one who stayed with the company the longest time (which was actually the most incompetent one, and many of his former colleagues left the company precisely to avoid having to work with him). Imagine Dunning–Kruger effect turned up to eleven; the team leader insisting that his colleagues avoid all design patterns and best practices because he didn’t understand why it was useful, and if he didn’t understand something then obviously it had to be useless. He was removed from the function a few months later when literally every coder complained. This is an illustration of a meta-problem: if you do not have the deep knowledge of business, how do you find a person who does?
Yet another problem is a person who did programming 10 or 20 years ago, and now is only a manager. Sometimes they actively resist every innovation in the field, because hey, we didn’t have all that fancy stuff in the stone age, and we still managed to develop a fully working application. (Except it wasn’t online, didn’t support multiple platforms, didn’t run on multiple servers at the same time, didn’t communicate with multiple databases and other systems, didn’t allow multiple users to operate on the same data in the same time, had 10 dialogs instead of 1000, didn’t support mouse or flexible screen size, etc. But those are just trivial details, right? By the way, why does it take you guys so much time?) Of course, there is also a reverse-stupid pattern, where the manager insists on using the latest fashion, so you have to work with halfway-finished tools full of errors, and in a few months you will switch to yet newer fashion.
So, my conclusion is that there is such a thing as management in general, but a part of it is the awareness that you must learn the business processes at your company on a level necessary for managing them. For example, when managing programmers, you don’t have to write code, and you don’t even have to read it. But you should be aware of what your programmers need to do their work (e.g. specification, various tools), and make sure they get it. Don’t treat technical problems as mere psychological problems that will miraculously fix themselves when you do a half-assed attempt to motivate your people. Communicate with all stakeholders regularly, but be brief so you don’t waste their time. Sometimes inconspicuously cross-check the information you get, to prevent people from pulling your leg. Understand planning fallacy, etc. -- Seems easy, but in my experience most managers don’t do that.
Analogically, if tomorrow somehow I would get a task of managing a team of experts in something I don’t have a clue about (e.g. a group of surgeons or rocket scientists), I would: ask them to give me a high-level outline of how they imagine things should be done, the time estimates for individual steps (I would try to add a reserve when communicating this to my superiors), and I would ask them what inputs do they need to do each step successfully. Then I would try to make sure they get the inputs, which would mean communicating with people responsible for these inputs and their managers. Every day or two, I would show them the high-level outline and ask if this is still realistic, or if it needs to be updated; and I would accept the bad news without punishing the messenger. (But I would keep a log of “which things cause repeated changes in our plans”.) This would be a quick start, and then I would try to learn more about how their jobs look like in near mode. -- Seems like an obvious stuff, but it isn’t. Many managers are instead like “oh, this is my big chance; I have heard a youtube speech about the power of positive thinking, so now I am going to teach them how to do their jobs properly”.
I didn’t mean that there’s no such thing as management—just that there’s no such thing as management in general. Competent management takes deep knowledge of a business, or at least a type of business.
Well, in my experience, the most competent IT manager was not a programmer (as far as I know). But it most likely helped that he had a natural-science background, as opposed to whatever it is that most managers study (Master of Bullshit and Absurdity, probably). Thus he wasn’t the annoying kind of manager who believes that 1) all problems are imaginary and 2) all problems can be solved by insisting that you think positively.
On the other hand, a frequent failure mode is to take a skilled programmer and say “from now on, you are the manager”. This is how a few companies tried to revert stupidity. Sometimes it worked, sometimes it didn’t, because managing people is a different skill from writing code.
I have seen coders who became good “laissez-faire” managers. But I have also seen coders who became terrible managers, because being introverted they avoided communication with the rest of their team, the junior team members sometimes didn’t even know what to do, and they received no help. I have also seen coders who started micromanaging their teams, insisting that everyone use the most complicated technology and most complicated design patterns regardless of the junior team members’ real skills; who probably felt an unconscious need to compete with their subordinates, which could be rather depressing for the subordinate.
In worst case, the existing top management was not able to tell a difference between competent and incompetent coder, so they promoted the most loyal one who stayed with the company the longest time (which was actually the most incompetent one, and many of his former colleagues left the company precisely to avoid having to work with him). Imagine Dunning–Kruger effect turned up to eleven; the team leader insisting that his colleagues avoid all design patterns and best practices because he didn’t understand why it was useful, and if he didn’t understand something then obviously it had to be useless. He was removed from the function a few months later when literally every coder complained. This is an illustration of a meta-problem: if you do not have the deep knowledge of business, how do you find a person who does?
Yet another problem is a person who did programming 10 or 20 years ago, and now is only a manager. Sometimes they actively resist every innovation in the field, because hey, we didn’t have all that fancy stuff in the stone age, and we still managed to develop a fully working application. (Except it wasn’t online, didn’t support multiple platforms, didn’t run on multiple servers at the same time, didn’t communicate with multiple databases and other systems, didn’t allow multiple users to operate on the same data in the same time, had 10 dialogs instead of 1000, didn’t support mouse or flexible screen size, etc. But those are just trivial details, right? By the way, why does it take you guys so much time?) Of course, there is also a reverse-stupid pattern, where the manager insists on using the latest fashion, so you have to work with halfway-finished tools full of errors, and in a few months you will switch to yet newer fashion.
So, my conclusion is that there is such a thing as management in general, but a part of it is the awareness that you must learn the business processes at your company on a level necessary for managing them. For example, when managing programmers, you don’t have to write code, and you don’t even have to read it. But you should be aware of what your programmers need to do their work (e.g. specification, various tools), and make sure they get it. Don’t treat technical problems as mere psychological problems that will miraculously fix themselves when you do a half-assed attempt to motivate your people. Communicate with all stakeholders regularly, but be brief so you don’t waste their time. Sometimes inconspicuously cross-check the information you get, to prevent people from pulling your leg. Understand planning fallacy, etc. -- Seems easy, but in my experience most managers don’t do that.
Analogically, if tomorrow somehow I would get a task of managing a team of experts in something I don’t have a clue about (e.g. a group of surgeons or rocket scientists), I would: ask them to give me a high-level outline of how they imagine things should be done, the time estimates for individual steps (I would try to add a reserve when communicating this to my superiors), and I would ask them what inputs do they need to do each step successfully. Then I would try to make sure they get the inputs, which would mean communicating with people responsible for these inputs and their managers. Every day or two, I would show them the high-level outline and ask if this is still realistic, or if it needs to be updated; and I would accept the bad news without punishing the messenger. (But I would keep a log of “which things cause repeated changes in our plans”.) This would be a quick start, and then I would try to learn more about how their jobs look like in near mode. -- Seems like an obvious stuff, but it isn’t. Many managers are instead like “oh, this is my big chance; I have heard a youtube speech about the power of positive thinking, so now I am going to teach them how to do their jobs properly”.