Following post : An Eternal Argument: Can a non-Expert manage Experts?
“I read your post carefully and I have to say that I completely disagree. In my experience, any attempt to manage IT developers without also being a technical expert is doomed to failure for several reasons. For one, the developers have no one to talk to if they encounter serious technical problems and need further guidance – non-technical manager cannot provide this guidance by definition. For two, the manager is often unable to set the project goals correctly (I’m not even talking about monitoring the progress) because he doesn’t know anything about what his employees are actually doing and is lacking the technical language to inquire about it. And three, for all of the previous reasons and especially for lack of common language, developers do not respect non-technical managers because they feel that their higher place in the organizational hierarchy is unjustified. All this makes the functioning of the team less than satisfactory, so I think that the emphasis should be made not on better managerial skills for managers, but for basic managerial instruction of developers in order to prepare them for becoming leads and architects. I would really like to hear what you have to say about all this.”
It’s hard to argue against encouraging the technical personnel to acquire managerial skills 🙂 The benefits of having a Master of two domains over Master of just one domain are pretty obvious to everyone and should be pursued whenever possible. However, there is a very simple question to ask here: how many developers do you know who can successfully acquire (and practice!) managerial skills? And I’m talking not just what people think about Management (“telling people what to do”), but the full spectrum of managerial skills I’ve recently written about.
You see, the whole concept of people engaging in different occupations is based on their tendency toward their respective professions. People who are good with math and visual manipulation will naturally be good engineers, while those with great people skills can become great salesmen. There is nothing new here – you tend to do what you’re good at, unless you don’t really want to be happy. So regretfully, MOST engineers will not become good managers, while MOST managers will not be able to compete with developers in their level of control over technical details. This barrier may sometimes be overcome in certain education tracks, such as in my case – being a Technion graduate means being an engineer, even though managing people and projects was what I actually learned. So even though I don’t remember when I had my last opportunity for writing a line of code, I do know pretty well how it’s done, because I’ve studied it. But this is a rare case.
In most cases, there are basic differences in personality profile that do not allow developers and managers to mix their vacations easily. The most prominent of them is focus on macro vs. focus on micro. What I mean here is that technical projects require a very high level of concentration on small technical details, so the tendency to regard the micro level as the most important is one of the basic traits of developers. Managers, on the other hand, are much more used to see every action on several levels simultaneously, trying to judge not just its technical consequences, but also the social, the organization and the political implications. Basically, this is what managers bring to the mix what others don’t have – the ability to quickly jump between the levels, managing all aspects of teamwork simultaneously.
In regard to issues of common language and respect of the employees, I think that most managers out there will agree with me: no title or position can bring automatic respect to their holder. Respect is something one person feels toward another person, and there are many ways to earn it. When I was asked to manage a brainstorming project dealing with future developments in the military sphere, I could hardly rely on my very humble army experience when talking to guys who saw real action and who had extensive knowledge of different problems relevant to the discussed issue. I’m not even talking about being the only girl in the boy’s club 🙂 But after a few meetings, when I started to send them materials derived from the discussions, and they saw how their arguing turns into new knowledge because the process was properly managed, I received all the needed respect from them and from those who put their reputation on the line when they brought me in.
What I wanted to demonstrate with this example is that the problem with common language and respect between managers and developers has little to do with technical knowledge. People always respect other people who do their job well, so when managers are not respected – it just means that they’re doing something wrong as managers. They don’t have to solve the technical problems their employees encounter by themselves, because they have the resources to find the needed expertise elsewhere. They connect the developing team with the outside world, regulating the flow of resources inwards and outwards.
As what you asked for in your letter was not a proper point-by-point discussion, but knowing my personal opinion, I think this is it 🙂 I really hope it was useful to you 🙂