
My rating: 4 of 5 stars
The book covers in details on how sociology is as important, or more important, in software development as technology. So much so that it is stated that "The major problems of our work are not so much technological as they are sociological". Although many tend to say that the problem is "political" it is argued that it is more "sociological".
One key reason the authors indicate is the reason for failures of projects is that we are trained to organize our solution space into modular pieces such as software routines, circuits or other units of work. While this is fine for software, we tend to carry for the same modularization with people and this leads to failure.
When managers realize that they have more "people worries" than "technical worries", managers tend to lookout for a technical whizbang that promises to automate away part of the work, rather than trying to address the "people worry". This is partly because one is schooled in "how to do the job" rather than on how to "manage the job". This may not be true of the white collared MBA graduates, but they do not know "how to do the job". It is important to know both (how to do and how to manage) to a reasonable extent.
It is stated that the IT people tend to think that they are in some kind of High-Tech business, whereas they need to accept that the only ones who are really in the High-Tech business are the researchers who made the fundamental breakthroughs in those areas and not us who use that technology.
We are in a situation where it requires us to have a lot of human communication. The better we communicate the more success we can meet and the worse we communicate the more the failures we will encounter. Despite this we tend to focus on the technical rather than on the human side of work, not because it is more important, but because it is easier to do so. To quote the example provided by the authors "Getting a new disk installed is positively trivial to figuring out why Horace is in a blue funk or why Susan is dissatisfied with the company after only a few months." Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of work.
While many strategies and processes adopted in the manufacturing production work well for the IT industry as well there are many other strategies that are not suitable for the IT industry. The following have been quoted
The second chapter is about a wrong comparison between production and software development. In a manufacturing production environment it makes sense to:
1. Squeeze out error. Make the machine (human) run as smoothly as possible.
2. Take a hard line about people goofing on the job.
3. Treat workers as interchangeable pieces of machine. (Although it is not as easy as it is made out to be)
3. Optimize steady state. (Don't even think of how the operation got up to speed, or what it would take to close it down)
4. Standardize procedures. Do everything by the book.
5. Eliminate experimentation - that's what the folks at the headquarters are for.
Doing the above in a software development firm will be detrimental as it would dampen the spirits of the people and focus their attention away from the real problems at hand.
Instead the following approaches should be adopted
1. Quota for errors. Since software development is a thinking job it is likely that people will make mistakes occasionally and this should be pardoned, not punished. Fostering an atmosphere that does not allow for error simply makes people defensive and kills all creativite efforts.
2. Everybody needs to be encouraged to think and take decisions. All decisions cannot be dictated from the top and the lower rungs asked to just follow instructions. It is a sure shot recipe for failure. (This is a statement that was made before the advent of techniques like Kaizen. With Kaizen even the person on the lower most rung of the production shop floor can be expected to think and contribute to improved productivity.)
3. In software development it cannot be assumed that one person an be replaced by another. Every individual is different and it is important for the manager to understand the abilities and disabilities of the individual and use her accordingly.
4. A project in steady state is dead. There should be continous dynamism in the projects for it to be successful.
5. It is as important to think about the tasks as it is to do them. Sufficient time should be spent in analyzing on how a task should be accomplished so that it is be done well and not just done.
A lot of these are what is adopted by agilists.
The other big topic that is covered is provision for private space vs public space. While the book recommends provision for private space as opposed to public space, it appears this has been concluded based on study of workers who are involved in creative work and require the peace and quite and very limited interaction with others. It will not be necessary and actually be detrimental in scenario where a lot of interaction is required between the various stakeholders.
The ills of overtime, effect of the environment provided to the employees are discussed in detail.
Another beautiful section that I found discussed the how Christopher Alexandar espoused the essence of architecture. He has suggested that instead of master plan for the building meta-plan should be followed. The meta-plan will have three parts
1. A philosophy of piecemeal growth
2. A set of patterns or shared design principles governing growth
3. Local control of design by those that will occupy the space
Under the meta-plan, facilities evolve through a series of small steps into campuses and communities of related buildings. By respecting the shared principles, they retain a harmony of vision, but not a sameness. Like mature villages they begin to take on an evolved charm. This is what Alexandar calls "Organic Order". This is further described as "This natural or organic order emerges when there is a perfect balance between the needs of the individual parts of the environment and the needs of the whole. In an organic environment, every place is unique and the different places also cooperate, with no parts left over, to create a global whole - a whole which can be identified by all who is part of it". Alexandar quotes the example of how the colleges of Oxford St. Johns, Trinity and others share a similar plan of having an entrance on the main road and an opening to the river behind, but have their individualness.
Christopher Alexandar states that "The natural or organic order emerges when there is a perfect balance between the needs of the individual parts of the environment, and the needs of the whole. In an organic environment, every place is unique and different places also cooperate, with no parts left over, to create a global whole - a whole which can be identified by everyone who is a part of it."
One cannot but wonder at the uncanny resemblance to the microservices pattern that is becoming prevalent in today's software world.
Stressing the importance of people in the IT industry the book states "The final outcome of any effort is more a function of who does the work and not how the work is done. Yet modern management science pays almost no attention to hiring and keeping the right people. Any management course you're likely to take barely gives lip service to the aspects". This again harks back to the Agile principle of people over processes. The authors suggest these measures for success:
1. Get the right people.
2. Make them happy so that they don't want to leave
3. Turn them loose
This is what is mentioned about leaders and leadership "While they sometimes set explicit directions, their main role is that of a catalyst, not a directory. They make it possible for the magic to happen." It is argued that leadership can even be displayed by somebody who is not authorized by the organization. They just make things possible. It is argued that Leadership and Innovation are directly proportional, better the leadership more the innovation.
This is what the book has to say about "human capital" and how the Wall Street pressure leads companies to have a poor policy about managing this. It is argued maintenance of the "humans" is considered as an "Expense" rather than as an "Asset" in accounting terms. "There is probably no hope of changing the view that Wall Street takes of treating investment in people as an expense. But companies that play this game will suffer in the long run. The converse is also true: Companies that manage their investment sensibly will prosper in the long run. Companies of knowledge workers have to realize that it is their investment in human capital that matters most. The good ones already do."
A section of book is devoted to how after having the right humans, a set of "jelled" teams are important for the success. Some suggestions for creating "jelled" teams are as follows:
1. Defensive Management: Do not be too defensive, be prepared to take risks.
2. Bureaucracy: Burdening the team with lots of paperwork.
3. Physical Separation: Keeping the team members in physically distant locations such that the chances of meeting is less is a big killer of teams.
4. Fragmentation of Time: Expecting the members to work in more than one project at a time.
5. The Quality-Reduced Product: A cost reduction in msot cases results in a reduction of quailty and most teams are asked to reduce the cost. The team ends up feeling bad about delivering a sub-quality product.
6. Phony Deadlines: Setting aggressive deadlines to pressurize the team only leads to negativity all around.
7. Clique Control: The upper management cannot ever jell as a team as each one wants exclusive hold over what they are doing.
The detrimental effect of overtime is stressed once again. Overtime means a few people end up working overtime while others are whiling away their time and this is a sure shot way of ensuring conflicted teams. It is also stressed that all the team needs to be involved in defining the goals and not just the upper management. Another strategy which would prevent teams from jelling is having competition within the company.
One very interesting discussion is around how people have resistance to any change. It is stated that it is given that most people will refuse to change for various reasons. The people can be put in the following buckets:
1. Blind Loyalty (Ask no questions, just change)
2. Believers but Questioners
a) Skeptics ("Show me")
b) Passive Observers ("Whats in it for me")
c) Opposed ("Fear of Change")
d) Opposed ("Fear of Loss of Power")
3. Militantly Opposed (Will Undermine and Destroy)
And the way to succeed in introducing a change is to win over questioning people to accept the change is by not challenging the old order, instead tactically getting them over.
The books ends a highlight on importance of keeping the team engaged in activities requiring them to exercise their intelligence in an IT organization.
A wonderful book for all to read.
View all my reviews
No comments:
Post a Comment