Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Totally missing from the article is any notion that the tool or thing you're trying to push might not actually be a great idea. The assumption seems to be that the author was Right (TM) and all that remained to address was the challenge of getting others to see the one true path.

If you're trying to convince others to make a change, and they're pushing back, listen to those concerns and revisit whether or not the change you're advocating makes sense. Maybe it does and they will come to see that, but you should also be open to considering their points of view and might change your opinion once you do. It's a two-way thing.



My thoughts exactly. In particular, a lot of the reason for the best process (which is not too different from what the author lays out in this article) is not to enable adoption in the case that the change is a good one, but rather minimizing the damage in the case that it turns out not to be the case. Having a dictatorial leader issue directives that all turn out to be exactly correct is annoying, but not horrible, and probably will NOT actually result in rebellion, as they say. On the other hand, using that method for a decision that turns out to be the wrong one, at least for that team and that project, will maximize the damage. Getting the right process for minimizing the damage of a bad decision is much harder, and much more important, than the relatively simple one of enabling a good decision.


The article addresses that in the starting paragraphs: there was no real opposition, just an unwillingness to compromise on how to do it.

> Everyone agreed we should have Figlets, but nobody agreed about its configuration.


Then Figlets was not a solution by itself. Just an implementation detail. By analogy, you can't say "we need a graph data structure", agree on python as a language, then consider the actual computer science an implementation detail that is being bickered over.

For a code review tool, "details" like CI integration, approval process, deployment integration, etc. are the solution. Figlets is just a shortcut for a big piece of that. Figlets could even be a blocker for certain features (like being to review code without a VPN connection).


The article is predicated on the suitability of the tool to be adopted, in the first paragraph, so he omission seems fine.

Obviously there are cases where the tool being pushed isn’t right, but that’s a completely different albeit important discussion.


The opposition might have good reason to opposing you, despite you being convinced you are right initially. As in, while you are pushing for that thing, be willing to listen to them, especially to those in roles different then your role, in case you are just about to cause them problems. You will just do more damage otherwise.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: