Hacker News Reader

Comment by mcv | Hacker News Reader

Absolutely. Sometimes executives need to feel the impact of their own poor decisions. Do not accept timelines from people who have no idea of the issues. If they fire you, they're firing the person who best understands their code. Don't let them bully you.

View on HN

That is a _very_ optimistic view of both the power dynamic at play and that level of accountability executives in that context would face. This is a company that previously had no developer - so being the person who best understands the code is not meaningful. If it was a company where that mattered, they wouldn't have survived without an engineer on staff. This is not a situation where the dev is going to have the actual power to "accept" timelines.

And in terms of accountability/feeling the impact of their poor decisions - the blog is already describing them throwing the engineer under the bus, telling them they need to pull their weight, blaming them for mistakes, etc. Management isn't going to feel the impact of anything. Theyve got a convenient fall guy right there and they're already setting him up to take the blame if stuff goes south.

Sometimes stuff just sorta sucks ¯\_(ツ)_/¯

You always have the power to accept timelines. And they have the power to fire you. Instead of trying to accept the impossible, I would persist in explaining the reality. They can reject your message, they can reject you, but they can't reject reality.

Be honest and look for someplace better if they refuse to accept it. That is in my opinion the only way to handle this responsibly.

The problem is that everybody has multiple responsibilities: if finding a new job is hard, and you've got rent to pay and a family to feed, you get into the territory of balancing the risks. Even so, I think it's always best to be clear and honest in your communication about timelines and expectations. If they reject them and insist on unrealistic timelines, point out the problems with those timelines, tell them it's their responsibility if it fails, so they can't blame it on you when it does fail.

I mean that's mostly true in theory - and we're assuming good faith from the author of the blog that they were honest and clear in their communications of course (definitely strongly agree with you on that point). But that's still a very optimistic view of the power dynamic. It's generally not meaningful to say that someone technically has the power to do xyz (rejecting a timeline) because nothing literally physically stops them from doing it when there are severe consequences (getting fired) that come from it.

Also, > tell them it's their responsibility if it fails, so they can't blame it on you when it does fail.

That's definitely not how any of this works. They can absolutely blame whoever they want and often have the power dynamic in place to get away with it. Especially in this case where they'll just say the author was given a senior title and a raise so it's on them to deliver and their attempts to shift the blame to management won't work to cover up the engineers failure to deliver etc. You just have no leverage as an engineer joining a company that doesn't care or doesn't need devs to the extent they go extended periods of time without a single one. And if you don't build that leverage within the company you pretty much have no option but to go somewhere else if put in a bad situation.

What also matters is how severe firing is for you. It's not the same for everybody.

> And if you don't build that leverage within the company you pretty much have no option but to go somewhere else if put in a bad situation.

I think that's often the better option, when the situation is that toxic. Better than staying.

Reply on news.ycombinator.com