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 🙂
Related articles
AnyaWorkSmart 
Let’s consider this from another angle: Imagine three successful, well-respected project managers: One has spent the last twenty years managing highway and bridge construction projects for various heavy construction companies. One has spent the last twenty years managing disaster relief projects for the United Nations and NGO’s. And one has spent the last twenty years managing the openings of new casual dining restaurants for various national chains.
Now imagine that you are an executive for a software company with a line of course and campus management solutions that you market to universities. Which of these candidates would you hire to manage the software development project for your next product?
Hi Dave,
The answer is pretty simple: I would hire the one that will show the most learning potential during the screening process, regardless of his or her previous experience. This is exactly my point in this post: there are people who can change domains freely and be successful everywhere they go and there are others who stay in the same domain their whole life and remain mediocre. Previous experience is relevant ONLY as much as it tells us about who the person actually is: an achiever, an average or an underperformer and it can also tell us if they have already experienced a transfer of their skills into a completely new domain. In my previous posts (“artist/scientist/craftsman” and “expert vs. non-expert“) I also described a system that can give us some clue about who is likely to be more successful when transferring to a different field.
It also seems to me that our own experience of dealing with people from different industries could be misleading in this situation. It’s pretty natural to assume that a Construction Manager would be the most conservative and the less used to working with IT-developers and university Deans, that the Disaster Manager is the most flexible due to his global encounters and the Restaurant Manager knows more about sales and client management, which supposedly makes him perfect for introduction of the company’s services to its clients. Actually, before talking to each and every one of them about their actual experiences on their jobs, we can assume nothing of the kind. When we at least know what Type of Experts they are – then we may make assumptions about their potential for our specific projects.
Hi Anya,
There are two basic ways to fill a position: promote from within, or hire an external candidate. Obviously, if there are no internal candidates with the needed qualifications, the organization has two alternatives: train an internal candidate or hire someone from the outside with the needed qualifications. That begs the question, what are the qualifications for managing this particular team?
Virtually every authority on project management will tell you that project managers spend most of their time communicating. Thus, any successful project manager should be skilled at communication. However, every domain has its own vocabulary, and the terminology in one domain may have a completely different meaning in another domain. In addition, culture matters, and domains tend to develop cultures that are somewhat consistent across organizations. If you bring in a project manager whose experience is entirely within another domain, will she be able to communicate effectively with this team? How will the team members feel about losing productivity while they teach their new PM about the work to be done? How will they feel toward senior management, after they bring in an outsider who doesn’t add value rather than give one of their peers a chance? Will some of those who were passed over become “flight risks?” Will others be alienated while the new PM adjusts to their culture?
I wouldn’t hire any of these three candidates. Developing a new product is already a high-risk project. Why assume unnecessary risks, and alienate the team by bringing in a manager who has to learn the business on the job? Better to train a current employee, or else find a candidate who can be an effective member of the team on their first day. Because the goal shouldn’t be to make the manager successful; it should be to make the team successful.
Well … it depends.
Under the old Bureaucratic model as described by Max Weber, and under the Scientific Management approach as described Frederick W. Taylor, the Boss was supposed to “know his rule” better than anyone in order to guide and supervise the activities of the apprentices under his charge. (Under those models it would not have been “her” charge).
That has proven to be a bad approach to complex projects.
In modern projectized team-oriented organizations, the Project Manager must be an expert in Project Management (with all the skills and competencies PM requires), but does not need to be an expert in the domain.
The expert is the practitioner.
A good team leader or project manager will not solve every problem for the team, but will help all team members frame their problems and focus their attention on what really matters to the project, and make the best decision close to the spot.
John Fox does not need to be a better passer than Peyton Manning.
I agree that any attempt to manage an IT project under the old hierarchical model will lead to failure, at least 85% of the time, regardless of the expertise or knowledge of the PM.
– Francisco “Fungus” Laborde
I’m not sure Risk Management works like that Dave – risks do not sum up linearly. Every possible step in this scenario has its own risk, not necessarily lower than the others. You can hire an experienced software manager, who worked in a big company, and see him try and apply his ways on your agile team – good luck with that 🙂 Regarding promotion from the ranks – there is no arguing that this is the best way when you have someone appropriate, but what if you don’t (as is usually the case)? I’m sure you’ve heard about the Peter Principle before 🙂
Completely agree with you, dear Fungus. Your knowledge of theory is impeccable as always 🙂