I was rather surprised to find these passages – copied below – in Fred Brook’s book “The mythical man-month” that was written a long time ago. I was browsing it again after a decade. So I thought I should collect my thoughts on this.
This particular organizational structure has caused me untold grief because as a technical lead I found the gap between these two groups too yawning to bridge. The two groups want to tear each other’s guts out at every meeting. Pure hatred !!
I have been specifically told by an MNC that a manager who has a large team will always get a better appraisal than a tech. arch. who builds systems with the assistance of a few. The top management is scared of equating the two groups for fear of antagonizing the project managers.
The general position “member of the technical staff” is a good way of merging the two groups. But the only way to completely abolish the difference is by making both groups work on project management as well as technical tasks, which is a tall order.
The other way is to encourage people to gain years of experience in their chosen field before moving up the ladder. This creates specialists. People in our companies don’t want to specialize in any field. So a business analyst is not a requirements expert. She should be. Actually no one is an expert requirements architect. So one of the most important fields is left without an expert. That hurts project success.
A project manager is not an expert in Earned Value Management or Statistical Process Control. Once we have specialists we will have humble people. Humility is a great leveler. Expertise gives confidence.
Plan the Organization for Change
Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the battle is thickest.
Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.
The barriers are sociological, and they must be fought with constant vigilance. First, managers themselves often think of senior people as “too valuable” to use for actual programming. Next, management jobs carry higher prestige. To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a “member of the technical staff.” Others, like IBM, maintain a dual ladder of advancement, as Fig. 11.1 shows. The corresponding rungs are in theory equivalent.
Figure 11.1. IBM dual ladder of advancement
It is easy to establish corresponding salary scales for rungs. It is much harder to give them corresponding prestige. Offices have to be of equal size and appointment. Secretarial and other support services must correspond. A reassignment from the technical ladder to a corresponding level on the managerial one should never be accompanied by a raise, and it should be announced always as a “reassignment,” never as a “promotion.” The reverse reassignment should always carry a raise; overcompensating for the cultural forces is necessary.
Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people.
Whenever talents permit, senior people must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. Doing this surely is a lot of work; but it surely is worth it!
The whole notion of organizing surgical-type programming teams is a radical attack on this problem. It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.
Furthermore, that structure is designed to minimize the number of interfaces. As such, it makes the system maximally easy to change, and it becomes relatively easy to reassign a whole surgical team to a different programming task when organizational
This is the first edition of these focused, short and interesting presentations that I have attended. I missed the previous two. It was refreshing but mostly it was dominated by youngsters in the audience. That is reflective of the milieu prevailing in Chennai where Computer games, hollywood movies and Mc Donald’s are considered fit only for the young. It would be more fun if such gatherings have a mixed audience from all age groups.
I don’t know why management of firms that deal with financial data tend to be very conservative about new technology in my part of the world. There are varied reasons for this but the lack of experience of executives is high on the list. The vision to support large-scale deployments of mission critical software is just not there.
MindSpace 