> absolutely everybody's job in the company to make sure it is profitable
Absolutely and categorically it is not. That is complete nonsense. Why should an employee care? Unless there's some profit sharing scheme in place that would benefit the said employee and they took advantage of that scheme. And even then, employees typically (and I'd even say in the vast majority of cases) have very few and tiny levers to pull to affect company profitability. So you typically you get nothing if the profit is x and nothing if the profit is x+n and even if you get some of that n you can't really affect the absolute value of n. Why should you care about n again? Oh, right, so the company doesn't go under and/or lays you off. That shit may have worked 20-30 years ago when company loyalty and upwards mobility was a thing.
> It really isn't, your job is to make a great product.
You're conflating work with responsibility. Let me ask you this: How many product managers does it take to make a product?
Its interesting that a lot of the replies here are railing against the idea that software devs are used as cogs in a machine, yet at the same time all replies are arguing that a dev should only be a cog in the machine, and any further context/awareness/action outside of being a cog should either not be expected or make the dev eligible for an outsized reward.
So to zoom in on your reply:
> Why should an employee care
Because they are paid to make the company profitable, and if they fail to do so they may not continue to be employed. I'm not sure why this is controversial. This requires no profit sharing to be in place, because it is simply the job that is required of the employee. It is probably by far the most general description of a job that is not: "the thing you do for money".
It may very well appear that the employee has no direct influence on company profitability, but since this is nearly impossible to measure objectively the next best thing is to try to make sure that he or she does by listening to signals coming down the hierarchy of management. Your PO telling you to hack a thing together is such a signal, and should be listened to. You warning about a giant pile of tech debt is a signal you should send to your PO, that he/she should listen to.
The OP's scenario has a product manager telling you that what they need is for you to finish feature X quickly so the company can be profitable.
In a well-working organization, that absolutely means that you, as an engineer should look into how to do X with the least amount of effort, hush things up, and ship it. The PM is the one that has to decide into hushing or not things, you are the one to decide how.
The problem is, every single organization where the PM insists on you to hush isn't well-working. It's easier to win the lottery than it's to find exceptions here. On those problematic organizations the PM will use your results to improve their curriculum and will absolutely throw you under the bus when the hushed product behaves like a hushed product. And everybody will be happy with kicking you down.
Also, if the product has any kind of safety impact, it's not the PM's job to decide about it anymore. It's yours.
> Absolutely and categorically it is not. That is complete nonsense. Why should an employee care?
They don't have to care, they are just there to do a job. If your company values a release now more than a more stable one later, it's not on you to refuse to do that.
Absolutely and categorically it is not. That is complete nonsense. Why should an employee care? Unless there's some profit sharing scheme in place that would benefit the said employee and they took advantage of that scheme. And even then, employees typically (and I'd even say in the vast majority of cases) have very few and tiny levers to pull to affect company profitability. So you typically you get nothing if the profit is x and nothing if the profit is x+n and even if you get some of that n you can't really affect the absolute value of n. Why should you care about n again? Oh, right, so the company doesn't go under and/or lays you off. That shit may have worked 20-30 years ago when company loyalty and upwards mobility was a thing.
> It really isn't, your job is to make a great product.
Nope, that's the product manager's job. Here, a Wikipedia link, just for you: https://en.wikipedia.org/wiki/Product_manager