Comment by andai
2 years ago
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first).
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.
> 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.
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.
This sounds like possible malicious compliance.
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.
"Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good.
I don't feel the need to get "buy in" for bad faith managers.
2 replies →
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?
2 replies →