I’ve seen this cynical viewpoint before. Honest question—what do you know about management consulting? What specific management consulting decisions are you basing this theory off of and how common are they? And how much of consulting consists of much more boring activities like developing new supply chains and inventory systems, rather than Machiavellian strategizing?
I have no direct experience with management consulting.
My opinions are formed by: my own observations of office politics; reading Dilbert; reading Robin Hanson; listening to stories of my friend who is an IT consultant. But I trust the other sources because they are compatible with what I observe.
Maybe it depends on a company, and maybe the one where I work now is an unually dysfunctional one (or maybe I just have better information channels and pay better attention), but most management decisions are completely idiotic. What the managers are good at optimizing for, is keeping their jobs. Even that is not done by making sure the projects succeed, but rather by destroying internal competitors.
For example, one of our managers was fired because our IT support department was actively sabotaging our project for a few months and we had no budget to seek help elsewhere; so we missed a few deadlines because we even had no servers functioning, and then the guy was fired for incompetence. The new manager is a good friend with the IT support manager, so when he got his role, our IT support department stopped actively sabotating us. This was all he ever did for us; otherwise he almost completely ignores the project. He is praised as a competent leader, because now we succeeded to catch up with the schedule. That was mostly because of the hard work of our three most competent developers. One of them was recently fired, because we had too many people on the team. And that’s because the new manager also brought a few developers from his old team; they do absolutely nothing, officially because they are experts on a different programming language, but we secretly suspect they actually don’t even know programming, so they don’t contribute and mostly don’t even go to work, but now they are part of our budget, so someone else had to go. Why not pick randomly?
How is it possible that such systems survive? My explanation is that nerds are really bad at playing power games (actually so bad that they don’t even realize that such games exist or need to be played; they may even object violently, which makes them really bad allies in such games, which is why no one will even try to ally with them and educate them). Instead our weakness is the eternal childish desire to be praised by a parent figure for being smart. So whenever shit hits the fan, the developers will work extra hard to fix the problem—without even thinking about using that as a leverage to gain more power in the organization. Most nerds are too shy to ask for a pay raise, even if they have just saved the management’s collective asses. So the managers can afford to ignore the technical aspects completely as something that happens automatically at a constant cost, and can focus fully on their own internal fights.
A few months ago I was ‘jokingly’ trying to get my colleagues to expore the idea of what could happen if the developers decided to form a union. How the management would be completely at our mercy, because they don’t understand anything, are unable to hire a replacement quickly (it took them forever to find and hire us), and with the tight schedule any waste of time would totally sink the project. Even if we would use this power for goals compatible with the company goals, we could negotiate to remove a lot of inefficiency and improve our working conditions. But we could also all ask for a raise, and for the company this whole revolution would still be profitable. -- My colleagues listen to me, mostly agreed with some conclusions on an abstract level, and then laughed because it was obviously such a silly idea. They all live in the imaginary universe where your income and quality of life is directly proportional to your coding skills and nothing else matters. I was screaming internally, but I politely laughed with them. Now some of them are being fired, regardless of their competence and hard work, and more will follow. Har har. I don’t worry about them too much; it will be easy to find another job. But it will be more or less the same thing, over and over again. They had an opportunity for something better and they ignored it completely. Worst case, if the plan would backfire, they would be in the same situation they are now.
As Plato said, one of the penalties for refusing to participate in politics is that you end up being governed by your inferiors. That’s IT business in a nutshell.
Maybe it depends on a company, and maybe the one where I work now is an unually dysfunctional one (or maybe I just have better information channels and pay better attention), but most management decisions are completely idiotic
It is also possible that you aren’t aware of most of what your management does. I’ll take your word for it that many of their decisions that are visible to you are poor (maybe most of their decision are, but I’m not yet convinced). As for management consulting, I suppose that is an inferential gap that is going to be hard to bridge.
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.
I’ve seen this cynical viewpoint before. Honest question—what do you know about management consulting? What specific management consulting decisions are you basing this theory off of and how common are they? And how much of consulting consists of much more boring activities like developing new supply chains and inventory systems, rather than Machiavellian strategizing?
I have no direct experience with management consulting.
My opinions are formed by: my own observations of office politics; reading Dilbert; reading Robin Hanson; listening to stories of my friend who is an IT consultant. But I trust the other sources because they are compatible with what I observe.
Maybe it depends on a company, and maybe the one where I work now is an unually dysfunctional one (or maybe I just have better information channels and pay better attention), but most management decisions are completely idiotic. What the managers are good at optimizing for, is keeping their jobs. Even that is not done by making sure the projects succeed, but rather by destroying internal competitors.
For example, one of our managers was fired because our IT support department was actively sabotaging our project for a few months and we had no budget to seek help elsewhere; so we missed a few deadlines because we even had no servers functioning, and then the guy was fired for incompetence. The new manager is a good friend with the IT support manager, so when he got his role, our IT support department stopped actively sabotating us. This was all he ever did for us; otherwise he almost completely ignores the project. He is praised as a competent leader, because now we succeeded to catch up with the schedule. That was mostly because of the hard work of our three most competent developers. One of them was recently fired, because we had too many people on the team. And that’s because the new manager also brought a few developers from his old team; they do absolutely nothing, officially because they are experts on a different programming language, but we secretly suspect they actually don’t even know programming, so they don’t contribute and mostly don’t even go to work, but now they are part of our budget, so someone else had to go. Why not pick randomly?
How is it possible that such systems survive? My explanation is that nerds are really bad at playing power games (actually so bad that they don’t even realize that such games exist or need to be played; they may even object violently, which makes them really bad allies in such games, which is why no one will even try to ally with them and educate them). Instead our weakness is the eternal childish desire to be praised by a parent figure for being smart. So whenever shit hits the fan, the developers will work extra hard to fix the problem—without even thinking about using that as a leverage to gain more power in the organization. Most nerds are too shy to ask for a pay raise, even if they have just saved the management’s collective asses. So the managers can afford to ignore the technical aspects completely as something that happens automatically at a constant cost, and can focus fully on their own internal fights.
A few months ago I was ‘jokingly’ trying to get my colleagues to expore the idea of what could happen if the developers decided to form a union. How the management would be completely at our mercy, because they don’t understand anything, are unable to hire a replacement quickly (it took them forever to find and hire us), and with the tight schedule any waste of time would totally sink the project. Even if we would use this power for goals compatible with the company goals, we could negotiate to remove a lot of inefficiency and improve our working conditions. But we could also all ask for a raise, and for the company this whole revolution would still be profitable. -- My colleagues listen to me, mostly agreed with some conclusions on an abstract level, and then laughed because it was obviously such a silly idea. They all live in the imaginary universe where your income and quality of life is directly proportional to your coding skills and nothing else matters. I was screaming internally, but I politely laughed with them. Now some of them are being fired, regardless of their competence and hard work, and more will follow. Har har. I don’t worry about them too much; it will be easy to find another job. But it will be more or less the same thing, over and over again. They had an opportunity for something better and they ignored it completely. Worst case, if the plan would backfire, they would be in the same situation they are now.
As Plato said, one of the penalties for refusing to participate in politics is that you end up being governed by your inferiors. That’s IT business in a nutshell.
That was a very entertaining read thanks.
It is also possible that you aren’t aware of most of what your management does. I’ll take your word for it that many of their decisions that are visible to you are poor (maybe most of their decision are, but I’m not yet convinced). As for management consulting, I suppose that is an inferential gap that is going to be hard to bridge.
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.)
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.