The implication of my story for management consulting is: if this company (assuming that I have described it correctly) would ever hire a management consulting company, why would they decide to do it, how would they choose the specific company, what task would they give to the company, and how would they use the results?

My model says that they wouldn't hire the management consulting company unless as a move in some internal power struggle; the choice would most likely be done on basis of "some important person's friend works for the consulting company or recommended the company"; they would give the company a completely false description of our organization and would choose the most uninformed and incompetent people as speakers (for example, they might choose one of those 'programmers' who doesn't contribute to our project as the person who will describe the project to the consultants); and whatever reports the consulting company would give to us, our management would completely reinterpret them to fit their existing beliefs.

In other words, I have no direct information about the management consulting companies, but I have a model of their customers; and that models says that in the market for management consulting the actual quality of the advice is irrelevant. (Unless companies like this are a minority on the market.)

It is also possible that you aren't aware of most of what your management does.

The upper echelons don't invite me to their meetings, so there is always a chance. But when I tried to socialize with some of the lower managers, the story is usually that the higher managers mostly sabotage their work by "hit-and-run management". It works like this: the higher manager knows nothing about the project and most of the time doesn't even care. Suddenly they become interested in some detail (e.g. something got wrong and the customer complained to them, or they just randomly heard something and decided to "be useful"). So they come and start micromanaging to optimize for that detail, completely ignoring all the context. Sometimes they contribute to improve the detail, sometimes the detail would be fixed in exactly the same time even without their contribution; but in the process they usually do harm to all other things.

For example, imagine that there are five known minor bugs in the program, and there are five programmers working on them. Under usual circumstances, all five bugs would be solved in a day, one bug per programmer. But the customer complained about one of the bugs on the phone, so the big boss comes and makes everyone work on that one bug. So at the end of the day, only one of the five bugs is fixed, and the big boss leaves, feeling victorious. (From his point of view the story probably reads: "Without my oversight, this department produced a software with an error that bothered the customer, but thanks to my heroic action, the whole problem was solved in a single day. Yay for being agenty!") Meanwhile, the things that would allow us detect and fix the bugs more reliably before they even get to the customer, such as automated testing or even using written test scenarios, are ignored for years (this is not an exaggeration), no matter how often the programmers complain about that on meetings.

Another issue is that the managers never cross-check the information they get. That makes "being the first one who has an opportunity to tell managers their version of the story" critical. For example, we need some work done from the IT support department. The support does step 1 of 10, then reports to managers "it's done" and stops working on the issue. The managers are happy, the programmers keep waiting... a few months later the topic gets mentioned at the meeting, the manager is like: "so, you guys were happy to have this problem solved so quickly, right?", the programmers are like: "wtf, we keep waiting for months", the manager is: "wtf, the problem was already solved months ago", the programmers: "no way!", the manager: "okay, let's call the support on the phone", the support: "sure, the problem was solved months ago... oh yeah, yeah... well, it wasn't solved completely, there are still a few details missing (such as steps 2 to 10), but the programmers never complained about that so we thought that way okay", the manager: "guys, seriously, why don't you communicate more clearly", the programmers: "well, the steps 1 to 10 were clearly described in the specification we had to write for the support department", the support: "well, we were not sure you really needed that"... And the next time again we need something, the support again mostly ignores it and reports the work as done, and no manager bothers to verify. Similarly when we get incomplete specifications, etc. Many people in the company use this opportunity to not do their work, report it as done, and later use some half-assed excuse. Only the programmers have to write the code, otherwise the customer would complain. Anyone else only generates internal complaints, which are not taken seriously by the management.

Somewhat related to this: imagine that you would manage a project where three employees, A, B, C, each have to do one aspect of the project, and the next one can start their job only after the previous one has finished. For example: specification, programming, testing. And you would have 10 days to deliver the results to the customer. Well, I would certainly create internal deadlines, e.g. A must deliver their part on day 3, B must deliver their part on day 6, C must deliver their part on day 9, and there is one day reserve. If on the day 4 the employee A tells me he is not ready and will probably not complete it even today, I would treat that as an impending crisis; because every delay caused by A means less time for B and C. -- Instead, our managers simply write into their private calendars that on day 10 we need to deliver the product to the customer, and they feel their work is done. The person A usually takes 8 days to do their part, and even then they often give an incomplete work to the B, who will work like crazy the remaining 2 days, and the part of C is usually skipped (C is testing, this is why we then have so many bugs reported by the customer). The managers start being active on day 10, usually when they return from lunch, and start reminding everyone that today is the critical day we need to deliver the product to the customer. The employee A has their work already finished, so there is no pressure on them; all pressure goes to B and C. And this keeps happening again and again, every few weeks, for years. If you try to speak with the managers about it, they tell you "yes, we are aware of the problem, and we are working on solving it". Just like they told you a year ago.

Another failure mode typical for our company is the following: there is some work X that needs to be done, but none of our employees is an expert on X, and we can't solve the problem using google (also we have other work to do). We keep reminding the management that we would need some expert on X; either a new employee, or at least an external consultant that would spend a day or two working with us. There are two ways this can end. Option 1 -- a year or two later the management finally tells us they will invite the external expert, but only for an hour or two, because the expert is very expensive. We keep waiting. A week or two later we are told that the expert already was here. "Really? Who did he talk with?" No one knows, but after another week we find out it was someone irrelevant who knows nothing about our project or about X. "So what did he ask the expert?" Most likely, it was something different that either doesn't apply to our project, or is so simple that we could have answered that ourselves. "So what did the expert answer?" Sorry, we forgot. Nope, no one took notes. Then the management says: "Okay guys, we already did what you wanted, now please stop making excuses and finally do the work we were supposed to deliver to the customer a year ago." Option 2 -- a year or two later an expert on X is hired. Everyone in the team celebrates. However, the next day the person is given a task to work on some completely unrelated Y. Why? For some reason management suddenly believes it is the highest priority of the day, although it is something we could have solved without the new guy. So the new guy works on Y and doesn't have time for X. Then the new guy is told to work on Z, et cetera. A few months later the new guy is annoyed and quits, because he wants to specialize on X, but he was given no time to do that here; so our problems remain unsolved. Then the management says: "Okay guys, we had an expert on X here, now please stop making excuses and complete the work."

Eh, I could go on like this for days. The point is, I don't believe there is some higher wisdom there. Other than the fact that we get government projects because of political connections, so the actual quality of our product is irrelevant as long as it works and is completed more or less on time; and even that is often a problem.

Open Thread, Dec. 28 - Jan. 3, 2016

by [anonymous] 1 min read27th Dec 2015145 comments


If it's worth saying, but not worth its own post (even in Discussion), then it goes here.

Notes for future OT posters:

1. Please add the 'open_thread' tag.

2. Check if there is an active Open Thread before posting a new one. (Immediately before; refresh the list-of-threads page before posting.)

3. Open Threads should be posted in Discussion, and not Main.

4. Open Threads should start on Monday, and end on Sunday.