And I learned that doing it my way will get me fired because the manager has asked to do faster.
The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like:
"do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?"
document all that too of course ;) but then at least there is a chance for safety _and_ success
Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries.
If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen.
This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
I don't feel the need to get "buy in" for bad faith managers.
An overly broad statement which, my experience, is not true. Managers come in many shapes.
Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.