[martin_ky]

I'm sure this article resonated with many engineers, not just from the game industry. What resonated with me the most, was the part about hiring a consultant, only to tell management what their employees have been telling them all along (for a ridiculous hourly rate of course). The simplified executive line of reasoning, why to rather trust an external entity over their own people, goes usually along these lines: "We do not take advice from our employees. We hired them for grunt work and we only expect them to follow orders. What could they possibly know that could benefit our high-level decision making. Afterall we pay them so little".

I consider the case, which the author describes, where the consultant actually talks to engineers, a happy day scenario. I was witness to a fast growing startup hiring a well known global consulting firm to help them set up company structure and processes. The startup was unable to do this on its own because of lack of leadership and unwillingness of the owners to empower their own people. The consulting firm sent over a couple of their junior consultants who consulted their 3-ring binder of best practices for the nearest matching industry category and gave their recommendations, which were followed quite strictly by a newly hired junior management. All without talking to a single engineer.

More often than not, employees are considered a necessary means to an end and treated as such, with the least amount of reward and care for which they are willing to work. Their sense of professional honor, responsibility and guilt is often exploited in an attempt to achieve higher output. Does the company's products or services suffer because of this? Of course, but nobody at the top cares as long as there is a metric that tells a good story. And when not, the lowest ranks are the first to be pruned and restructured.

[direfungasaur]

> The simplified executive line of reasoning, why to rather trust an external entity over their own people, goes usually along these lines: "We do not take advice from our employees. We hired them for grunt work and we only expect them to follow orders. What could they possibly know that could benefit our high-level decision making. Afterall we pay them so little".

It's not always that leadership ignores line-engineers just because they consider them stupid. Even obvious recommendations get tangled into the web of politics and personal favors. Sometimes the 'obvious solution' is also a play to get more power or influence for someone you're opposed to. That factors into how the advice is taken.

Part of the fiction management sells itself is consultants can cut across those organizational boundaries and find the 'right solution'. Sometimes having an 'impartial' voice echoing what others have already said is enough to convince you it's not just someone trying to poach your turf, it's actually good advice.

Further, our tendencies towards tribalism influence this process. We tend not to think of other employees as part of the same group - they are devs, or ops, or product. That builds an 'us vs. them' mentality that's hard to break. Bringing in an outsider tends to unify the group into us (the company/team) vs. the outsider (the consultant). That psychology helps us to justify bitter medicine like our team getting more work (which will help the company).

I tend to have a negative opinion of consultants, but someone pointed this aspect of group psychology to me in the past and it resonated.

[koffiezet]

> Part of the fiction management sells itself is consultants can cut across those organizational boundaries and find the 'right solution'.

Being a consultant, and knowing multiple others, I feel that not being part of the company "tribes", really allows you to more easily cut across those organizational boundaries you mention.

How many times I've heard of 2 technical divisions complaining about each-other where the main issue is the lack of communication and simply not knowing who to talk to in the other "tribe". Consultants however are part of their own little 'consultant tribe' across company tribe boundaries, who more easily bond together and talk about stuff like that. This means this group is more diverse and has more contacts spread throughout the organization, making them ideal to cut trough the bullshit. You also have the fact that when a company was happy about a consultant, chances are that when they need someone somewhere else, they'll hire the same consultant again, dumping them in a completely different group of people.

Yes this is 100% a social problem, but it's there, and a group of outsiders will address this more efficiently.

[martin_ky]

I think you hit the nail here with "poaching someone's turf" and the "tribalism" inside a company. I didn't mean to say that leadership considers engineers stupid. They hire them and trust them with solving complex technical problems. It just bothers me, they would often rather take a vague, generic management advice from a third party, who could not care less, over well intentioned, well reasoned, concrete advice, backed by concrete evidence from an engineer (or just do not act at all). This is just my colorful imagination, but I could almost 'hear' some managers thinking while dismissing an idea without giving reason: "I am supposed to manage you, no way you are going to tell me how to do my job". I've seen such behavior and I have no other explanation for it other than ego, office politics and 'cover my ass strategy'. This creates toxic environments and not just for the people working there. Productivity, quality and I'm 100% convinced that ultimately revenue and the ability to compete suffers from this as well.

[mdorazio]

In addition to what direfungasaur said about helping cut through political issues in a company, bringing in outside analysis can help for a couple of additional reasons. One is that individuals employees can be wrong. A change that engineers have been asking for might seem ok, but in actuality would destroy margins or otherwise be detrimental to the company as a whole if you look at broader information that might not be available to the engineers. Another reason is that if a company gets to the point where it's even considering bringing in outside help, it likely has a large number of issues that need to be prioritized. The one that a few employees have been making noise about might already be well-acknowledged, but is way down the list of Big Problems.

That's the "good case" anyway. In actuality, management consultants (the kind you're referring to) are usually brought in so someone can cover their ass and say "look, the smart, expensive people said we should do X!" regardless of whether or not X was a difficult solution to figure out.

[tonyarkles]

> A change that engineers have been asking for might seem ok, but in actuality would destroy margins or otherwise be detrimental to the company as a whole if you look at broader information that might not be available to the engineers

As someone who has been on both sides of this, the best advice I have for a manager in that situation is "if you say no, tell them why." As someone in a senior engineering role, to me, it's my responsibility to understand the forces at play with the product I'm developing, so that I can do my job. I accepted a long time ago that engineering is not just about being technically excellent, but also understanding how the product fits into the business. If the answer to engineering recommendations is just a flat "no", then that probably means that there's information that is keeping me from doing my job to my full capacity; I don't just throw out ideas without thinking about them, I take all of the facts that I have and come up with cost-effective solutions.

[hectormalot]

As a management consultant myself, another thing that clients tell me is that the ability to bring the message across in a way management understands and can act upon is typically valued.

I’ve of course heard the “you’re saying the same as what the engineers have been saying for years” at various points, and management might not always listen well enough to engineers, but I think people underestimate the importance of synthesizing their messages to get management to act