I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal.

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.

You have to be present in the meeting. All the places I have worked - and I have worked in many over 15 years - do not allow this. You need to be in a startup to be close enough to have this kind of impact. Agile just makes this situation worse. It's incredibly frustrating to be see the value you can add, but having no ability to make it happen.

Can't have pesky engineers with their pedestrian technical concerns mess with the business decision makers' thought process. A good engineer takes whatever the creative, smart visionary comes up with and implements it down to the smallest detail.

It seems like this value you brought in is "outside" the ___domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no?

(I wish you had gotten more thoroughly compensated for saving them a fortune.)

If your only skill is being able to write code, your skillset is relatively weak.

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.

Software engineering requires understanding enough of the reason behind requirements to know when the requirements could be simplified or should be augmented. I would even argue that understanding business needs and translating them into practice is the fundamental role of software engineering.

This requirement might never have reached a software engineer in many organizations, and perhaps that's what I mean. So part of the mastery is ensuring you are around to provide solutions when business needs are being deliberated. That's fair.

An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.

Your use of "spec" here is a weasel word to make your point. There are many kinds of specs. The spec here is "users need a physical copy", the organization was intending to solve it by using the services of another business and a bunch of other expensive and complicated stuff that I was considering as categorically different from software.

Business is not outside the ___domain of software engineering. "building the right thing" is more important in engineering than "building the thing correctly". If the proposed solution or problem to be solved misses the mark, most of the potential value has been lost, and excellent execution will not be able to recoup that.

Thank you for the story, I definitely understand now. I am also relieved that you were compensated for this critically important pivot! /s

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 hope you are joking: “I, a paid employee, have a wonderful solution to our problem that will save the company a lot of money, but I won’t tell you if you don’t pay me even more.” I think the answer to that would be something like “hmm, if you aren’t willing to do your job for the salary we already pay you, I don’t think there’s any reason to pay you at all.”

This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer).

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.'

It's kind of a self-fulfilling prophecy though.

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.

If the structure of a work place is very strict, then yes this is 100% true.

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.

> 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.

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's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :)

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.

There are some teams that only work on high impact projects. If you feel that your current team is only doing work that's not valuable, you need to change teams or at least let your manager know to change your project. Ask for projects that you think will bring revenue to the company. Revenue = impact or increase in productivity of other engineers (this may involve writing an internal tool, etc.)

As stated by a previous head of product, great senior engineers can choose to switch jobs and instantly become a great PM.