Hacker News Reader

Comment by nine_zeros | Hacker News Reader

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

View on HN

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.

> but managers aren’t acting in good faith

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.

Why is asking for requests to be in writing an "act of bad faith"? Literally cna't see a single outcome that would be an act of bad faith here.

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.

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.

Reply on news.ycombinator.com