> Creating new work

I am not talking about creating additional work, I am talking about solving problems not on management's radar screen. Some problems are only visible from the floor.

> The right way to grow is to learn how to work with the company to get important work into the roadmap.

That is not always possible because valuable things sometimes have to be demonstrated to be understood. Not all things can be explained in the abstract, sometimes you have to build the thing first before people understand how useful it is.

I agree with this sentiment. A good (software) engineer needs to have the discernment to know when to ask for permission, and when to ask for forgiveness.

Sounds to me like you're getting micromanaged.

I fail to understand how you manage to extrapolate my working conditions from a generalization of what soft skills are required to be a good engineer.

A software engineer only needs to make those judgement calls in a bad environment. In a good environment, such situations can be discussed in the open.

Well if in 80% of enterprises engineers do not talk in open that good vs bad environment hardly matters.

> A lot of engineers just want to work on whatever they want to work on most, but that’s a problem in the context of an organization trying to coordinate.

May be it's actually a management challenge to turn this enthusiasm into money?

What's a problem for one person makes an opportunity for another person.

It depends on the business. Many places have no idea wtf they want, and presented with something interesting they’ll ditch what they are doing to do it, because they don’t know why they are doing whatever they planned anyway.

The existence of this thread belies this. Running everything like a product is the fad today. It’s a fad because running a “product” means understanding its lifecycle and resourcing it as appropriate. But the mandate in BigCorp is to run printer ink fulfillment with the same methodology as an actual product, so lots of leadership time is spent thinking about toner or whatever.

It’s inefficiency created in the pursuit of efficiency via control.

You can't get important work into the roadmap while also complaining that people are trying to blow up the roadmap when they try to get important work into the roadmap.

Kind of a big problem here, as you're defining the right way as also the way that frustrates you (and assumingly others) the most.

It's not a problem, that's how you create software. You can put some of those initiatives on a "road map" if you want, but there must be space for them. 50% "slack time" is a good standard for software engineering. Your software engineers likely know better than your middle-managers how to spend that time.