Comment by jareklupinski
2 years ago
that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent
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
> that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent
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?
>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.
> 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.