junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune.
I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs.
I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.
I am hoping this will be an area I can eventually excel in. I was a senior PM for a while and decided I wanted to write code instead. Been going down this crazy career change for about 6 months now. Right now I am just trying to survive and learn the basics of software development.
When I was PM I certainly had the luxury of working with invaluable devs I could brainstorm with on ways to optimize a feature idea that maintained customer value in the shortest time possible. I need to learn how to become that invaluable dev I had.
(I wish you had gotten more thoroughly compensated for saving them a fortune.)
We are called Software Engineers, but what we really are is people who solve problems with code.
The important part is solving the problem. The fact we do it through the medium of code isn't that noteworthy.
If solving the problem requires knowledge from outside the domain of programming (Spoiler: it almost always does), then you learn what you need to from the relevant domain.
A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'
Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions.
Of course ideally everyone can contribute, but I think that's relatively rare.
I how ever could already experience a more open scrum process in which we all have a say.
For me it all started in an university project with four (incl me) people. I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic. She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process. Very good experience for me and we finished the project on time and exceeded expectations.
Experience flips this equation around. The PM is creating the roadmap based on my input and expertise to decide what will be the most valuable use of resources. You move from construction worker to architect.
It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet?
Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.