What you've got is in fact a people problem

Different bosses will react differently.

There are bosses who get violently angry and fire people. Nobody will trust that boss with honest feedback... ever.

There are the bosses who are simply dismissive of what their staff is already telling them. In that case, the boss is having this meeting to tell his staff "I ignored and forgot everything you told me previously, but this time will be different. I'm prepared to listen this time." That boss may be able to make good on the strategy in the article.

What is fascinating to me about technical people is the particular subculture that sincerely believes that technology will solve the people problem. I recently got into a long thread argument with someone on HN about this. The person was adamant that people problems can NOW finally be solved by designing technology to be able to handle adversarial and incompetent actors. But the problems that such software tries to solve are tightly defined in scope and cannot deal with actually messed up people or organizational problems. Unless engineers are willing to acknowledge people problems, they will keep banging their heads against the door when the organization isn't doing what it's supposed to do.

But it's far easier to acknowledge the people problem first and see if there is a solution for that, rather than trying to ram technological solutions through a people-shaped hole. And if the people problem can't be solved (i.e., it will often involve a change in culture and leadership style, or else a change in leadership, both of which are difficult), it may be best to give up anyway and wash one's hands of the whole mess. In which case, one just sits there going through the motions to pass the day and collect the pay. If they're motivated, they'll find another job, rather than try to fix the mess, and they'll likely be happier doing that too. This is also why it takes a certain non-technical skillset combined with technical skills to succeed in leadership roles. It's a completely different game to play.

I’ve also seen the reverse:

What’s presented as a technical solution is actually a process solution to address a people problem.

The consultant is being paid by management. S/he is beholden to them. If anything can be traced back to a group or individual, it will be, and it won't be pleasant for anyone who believed the request for honest feedback.

> your ICs won’t have the full picture. They really may not understand why certain priorities are set the way they are. You’ll need to take that as feedback for improving internal comms rather than “fixing” the perceived problem, and you certainly don’t want to make empty promises.

One time, my manager gave me negative ratings out of nowhere. In his review, he wrote that I rolled a feature a few days late. I chatted with him and explained that the delay was because of production freezes (see dates) and bureaucratic steps (see dates). He didn't want to hear it. I asked what the consequences were of the delay, did it affect a customer? Did it impact revenue? I knew it didn't because I was always checking in but I wanted to hear it from him.

It was clear the priorities were different. I asked what the priorities were. And he couldn't answer.

To the post's point about fixing internal comms, this manager did not WANT to fix internal comms because the internal comms would sound something like, "I just need everyone to finish everything within the quarter - by the exact date - regardless of any company-wide freezes or red tape - because I get scored on it by my boss. I don't want to be at the bottom of the stack rank".

Hard to have clear and precise internal comms when deadlines and deliverables are just a joke with no business value. They'll be found out.