The Manager Is The Problem

Something you never hear. Supposedly, the manager is responsible for a project's failure or success. . . but you never hear about employees being able to fix management problems.

Typically, by the time you get this far, the expression is heard as TheManagerWasTheProblem?. Manager rot is something employees typically can't fix, but I've been through a PassiveMutiny? that cost the company a couple of managers.

By EwDijkstra, <http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD648.html>:

[...] I hope that the above gives you some feeling for the programmer's task. When dealing with the problems of software design, I must also devote a word or two to the phenomenon of bad software manager. It is regrettable, but bad software managers do exist and, although bad, they have enough power to ruin a project. I have lectured all over the world to programmers working in all sorts of organizations, and the overwhelming impression I got from the discussions is that the bad software manager is an almost ubiquitous phenomenon: one of the most common reactions from the audience in the discussion after a lecture is "What a pity that our manager isn't here! We cannot explain it to him, but from you he would perhaps have accepted it. We would love to work in the way you have described, but our manager, who doesn't understand, won't let us." I have encountered this reaction so often that I can only conclude that, on the average, the situation is really bad. (I had my worst experience in a bank, with some government organizations as good seconds.)

In connection with bad managers I have often described my experience as a lecturer at IBM, because it was so illuminating. Just before I came, the interior decorator had redone the auditorium, and in doing so he had replaced the old-fashioned blackboard by screen and overhead projector. As a result I had to perform in a dimly lighted room with my sunglasses on in order not to get completely blinded. I could just see the people in the front rows.

That lecture was one of the most terrible experiences in my life. With a few well-chosen examples I illustrated the problem solving techniques I could formulate at that time, showed the designer's freedom on the one hand, and the formal discipline needed to control it on the other. But the visible audience was absolutely unresponsive: I felt as if I were addressing an audience of puppets made from chewing gum. It was for me sheer torture, but I knew that it was a good lecture and with a dogged determination I carried my performance through until the bitter end.

When I had finished and the lights were turned up I was surprised by a shattering applause... from the back rows that had been invisible! It then turned out that I had had a very mixed audience, delighted programmers in the back rows and in front rows their managers who were extremely annoyed at my performance: by openly displaying the amount of "invention" involved, I had presented the programming task as even more "unmanageable" than they already feared. From their point of view I had done a very poor job. It was at that occasion that I formulated for myself the conclusion that poor software managers see programming primarily as a management problem because they don't know how to manage it.

These problems are less prevalent in those organizations - I know a few software houses - where the management consists of competent, experienced programmers (rather than a banker with colonial experience, but still too young to retire). One of the problems caused by the non-understanding software manager is that he thinks that his subordinates have to produce code: they have to solve problems, and in order to do so, they have to use code. To this very day we have organizations that measure "programmer productivity" by the "number of lines of code produced per month"; this number can, indeed, be counted, but they are booking it on the wrong side of the ledger, for we should talk about "the number of lines of code spent".

The actual coding requires a great care and a non-failing talent for accuracy; it is labour-intensive and should therefore be postponed until you are as sure as sure can be that the program you are about to code is, indeed, the program you are aiming for. I know of one very successful software firm in which it is a rule of the house that for a one-year project coding is not allowed to start before the ninth month! In this organization they know that the eventual code is no more than the deposit of your understanding. When I told its director that my main concern in teaching students computing science was to train to think first and not to rush into coding, he just said "If you succeed in doing so, you are worth your weight in gold." (I am not very heavy).

But apparently, many managers create havoc by discouraging thinking and urging their subordinates to "produce" code. Later they complain that 80 percent of their labour force is tied up with "program maintenance", and blame software technology for that sorry state of affairs, instead of themselves. So much for the poor software manager. (All this is well-known, but occasionally needs to be said again.)

Other widely read Authors and Speakers

According to Jeffrey Liker, author of TheToyotaWay, Management at various levels needs to initiate and sustain and improve work processes. In one part of his book, he asked the companies adopting ToyotaProductionSystem whether "people are viewed as expendable labor and suppliers are viewed as sources of cheap parts...". A negative response, which is the reality in a lot of organizations, meant the company is not yet equipped to begin the lean journey.

But many still do so waving the banners of ToyotaProductionSystem

It's interesting to think about how this story conpares to the practice of XP.

Perhaps TheCultureIsTheProblem? have more applicability than TheManagerIsTheProblem?

As managers have to be skilled in RelationshipManagement, some of their bewildering behaviours become more rational when viewed in a SocialDynamics context.

I am of the opinion you see lot of dysfunctional behaviour in governments, possibly due to lower turnover rate (see RefactoringGovernment). And I have seen individuals became "normal" again once they have left their management posts in government.

See: PeopleAreTheProblem TheProcessIsTheProblem