What do engineers never talk to their bosses about, but should?

Depends on whether or not the boss can be trusted.

I've had bosses where the only thing they ever heard from me were optimistic status updates on work in flight.

I considered them completely untrustworthy -- one for lack of competency and one for being a clumsy power seeker.

But in general I would only talk to my boss about issues that (1) I'm OK with my boss telling other team members that I said what I said about it, (2) I'm OK with my boss having input on what course of action to take on the topic, and (3) I trust that the conversation is unlikely to be interpreted in some negative way for me.

- That governance by fear is a sure way to kill motivation, creativity and to have passive employees who do not dare to fix things.

- That supporting a competitive environment between employees is a sure way to kill motivation and creativity.

- That the people going the extra mile to ensure a stable production environment gets acknowledged for their effort.

- That throwing people under the bus makes you look really incompetent as a manager.

- That having an island of free speech within a bad corporate culture will keep the good engineers around.

- That one of the prime objectives of a boss is to shield employees from insane and impossible demands from other departments.

At least at big corporations it should be about all the corporate double talk and broken policies/promises.

Edit: why downvote? This has been my experience. If we dont talk about it, then it will never be fixed.

In short, it's the small talk that isn't so "small"

Regardless of whether you're an "engineer" or not, you need to have an understanding of what your management chain views both the goals of the company, the goals for your team, and how whatever it is you do fits into that

Those conversations should be organic and natural, but far too many folks (especially those of the "engineering" bent) either never ask, or ask only obliquely during annual reviews

Not having an understanding of how what you do affects the organizations units you are in is one of the greatest contributing factors to employee restlessness and complaining

If you know why you're there, you're more likely to stay - or to find a team where you'd be a better fit

"Despite our recommendations, Kubernetes is actually not needed here"

Most bosses are aware of the issues, so an engineer playing a rebel and bringing them up wins nothing. The only way to attract attention is to leave.

Feedback on how I am doing as your manager.

This isn't a dictatorship, it's a partnership. What can I do to change/help you?

Most of my team is quiet on this sort of thing. Perhaps it's cultural? (Is this common for individuals who grew up in eastern Europe?)

Their career aspirations and what they need from their managers for that.

Skepticism about tech/ideas that management likes.

As a manager I would love to know what they are struggling with and what barriers I need to move for them.

For whatever reason, engineers think that because they can't get things done it's a reflection on themselves or their skills when that's often not the case.

There are no general rules, different people will have different problems.

For me: It was promotion and payrise-- as I was too scared I would be "found out" for not being good enough, which meant I didnt get either for many years; until I quit.

I talk about things they can change (for example our teams are multi-disciplinary, so I might feel we need to rebalance resources depending on the project.) We also don’t have a formal review process, so I ask for feedback on what I need to do differently and what I should keep doing.

How they are uncomfortable dealing with a certain difficult "team member".

I don't know if the "should" because this kind of discussion smells like trouble for all parties involved.

a) Their work load - whether they will burn out or become a lazy bum. Neither extreme is good.

b) What the next job level entails and how to get there. Whether to take the career path of being an individual contributor, manager, architect, tech-lead manager, etc.

c) Compensation, equity, and how RSUs, ESOPs, etc. work.

d) Alternate, overlapping fields of work - in case of software developers, how can they explore product management or running tech programs.

Tech debt

Coping strategies

“Who is your favorite Scientist?”

Career development/advancement and a raise.