The futility of “I told you so” in software engineering teams • Hacker News Board

Re: The futility of “I told you so” in software engineering teams

#31

Post by ziml77 » Fri, Jul 24, 2020, 11:36 PM UTC

thinkingkong wrote: post #21

TheCowboy wrote: post #10

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If their reasoning was presented initially and matches up with what was the cause of the problems, then yes, they did tell you so and you should probably take note. Otherwise you're letting yourself or other managers off the hook every time. The culture should support…

This is why I like written designs and soliciting feedback. Everything is going to have tradeoffs and teams need to get better about explicitly stating them vs rounding these blind corners and shrugging.

Even if it's not a full design in writing, important decisions should have a trail. It can be hard to adhere to that, but it's very useful. Life if there's something that you think could bite you, but a manager is very pushy about their way, write it down in an email as a question asking for confirmation. I've had to go back to emails like that, sometimes to actually confirm to the person who made the decision in the first place.

Re: The futility of “I told you so” in software engineering teams

#32

Post by majormajor » Fri, Jul 24, 2020, 11:37 PM UTC

A lot of the discussion here seems to rest on the idea that there is a "right" option that was ignored in favor of a "wrong" option.

I've rarely seen that be the case. Setting aside politics - the "right decision" would be bad for a team with a very influential manager, say - there's still plenty of extra nuance to purely technical choices.

"This will break at some point but probably by then we'll have gotten a lot of value of it and we can afford to fix it then."

"This might break but there's a 70% chance it won't and it would cost twice as much to do it the safer way."

"This will probably break in this specific way, but we don't understand the alternative technology well enough to even predict the odds of it breaking."

And so on.

Bad leaders aren't often transparent about all those sorts of considerations, so if you find yourself in that situation, be wary.

But if you aren't making your arguments in a tradeoff-aware way, your "I told you so" may not be very useful.

Re: The futility of “I told you so” in software engineering teams

#33

Post by thephyber » Fri, Jul 24, 2020, 11:37 PM UTC

g051051 wrote: post #27

yomly wrote: post #24

At Amazon you had "disagree and commit" and (used to have) "vocally self critical". The commit part is actually very important - once the TEAM makes a DECISION everyone is on board with it and runs with it. You don't half ass it or sabotage it. But if it does go wrong, the decision maker should have the strength of character to acknowledge "you were right" These two factors held in tension and taken at face value (ra…

It's difficult to "commit" to something that is clearly and utterly wrong.

The faster it fails, the faster you might have an opportunity to point out the failure points and suggest the correct solution.

Re: The futility of “I told you so” in software engineering teams

#34

Post by bryanrasmussen » Fri, Jul 24, 2020, 11:38 PM UTC

Ursula K. LeGuin had an essay in her collection Languages of the Night (can't remember exactly which essay) where she said “Nobody who says, ‘I told you so’ has ever been, or will ever be, a hero.”

Re: The futility of “I told you so” in software engineering teams

#35

Post by flukus » Fri, Jul 24, 2020, 11:39 PM UTC

TheCowboy wrote: post #10

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If their reasoning was presented initially and matches up with what was the cause of the problems, then yes, they did tell you so and you should probably take note. Otherwise you're letting yourself or other managers off the hook every time. The culture should support…

> The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot.

It's also extremely dismissive of experience. Sometimes you just know an idea won't work out because you've been down that road before. You can't just distill 20 years of experience into strong counter arguments for every proposal, it's just too time consuming, especially when you've got other stuff to do. But our industry severely under values experience.

It's similar to other useless platitudes like "present solutions not problems". It sounds good on the face of it but ignores that solutions take much more of a time investment than seeing problems does, seeing a problem is merely the first stage of a solution.

And trying to get rid of "I told you so" leads to "consensus" decision making, which is it's own workplace cancer: https://www.youtube.com/watch?v=67QsrpNH96Q

Re: The futility of “I told you so” in software engineering teams

#36

Post by XorNot » Fri, Jul 24, 2020, 11:46 PM UTC

deathanatos wrote: post #17

> Your “I told you so” only highlights that you need to construct stronger arguments. Most of the time I'm not been listened to and should have been, I feel like it is out of apathy or laziness, not out of whether the argument was sufficiently strong. My request "this will not work for X reasons" is almost always followed by "and Y is what we need to do", but Y implies … additional work. The culture of current corpor…

The real trick is that caring about anything in the modern corporate workplace is a mistake. Unless you hold equity and board position in the company, then you are completely replaceable at any time for any reason.

The only thing you should be doing is ensuring that the chain of decision making is documented so blame flows upwards. And exercise some discretion in ensuring you get away from managers with a track history of poor decision making.

Workers don't own the company, and they have almost no power (nor the time to engage in the politicking which would give it) within the decision making structure there. Look after yourself first, and plan to leave when people who do think they have an ownership start making bad decisions.

Re: The futility of “I told you so” in software engineering teams

#37

Post by dropit_sphere » Fri, Jul 24, 2020, 11:52 PM UTC

XorNot wrote: post #36

deathanatos wrote: post #17

> Your “I told you so” only highlights that you need to construct stronger arguments. Most of the time I'm not been listened to and should have been, I feel like it is out of apathy or laziness, not out of whether the argument was sufficiently strong. My request "this will not work for X reasons" is almost always followed by "and Y is what we need to do", but Y implies … additional work. The culture of current corpor…

The real trick is that caring about anything in the modern corporate workplace is a mistake. Unless you hold equity and board position in the company, then you are completely replaceable at any time for any reason. The only thing you should be doing is ensuring that the chain of decision making is documented so blame flows upwards. And exercise some discretion in ensuring you get away from managers with a track histo…

This really is the answer. In the past I would have regarded this as horribly cynical, but not so now. You're not being paid enough to risk your career by crusading for truth, or to go down with the ship.

None of this means you can't or shouldn't do good work, even somewhere badly managed. Do good work, polish your resume, and disappear without a trace.

Re: The futility of “I told you so” in software engineering teams

#38

Post by shmerl » Fri, Jul 24, 2020, 11:56 PM UTC

Arguments aren't always going to help, even strong ones. They can go against inertia, lack of will to get into some ideas and so on. So whether you resist to say "I told you so" or not, don't expect to always be able to prevent such kind of outcomes simply with argumentation. Some just learn the hard way.

If they are at least willing to learn from their own mistakes, one time will be enough. And if not, no amount of arguments will help anyway.

And, you totally should be critical to those who didn't listen when they could. Don't simply shift the blame on the arguments.

Re: The futility of “I told you so” in software engineering teams

#39

Post by 29athrowaway » Fri, Jul 24, 2020, 11:58 PM UTC

TheCowboy wrote: post #10

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If their reasoning was presented initially and matches up with what was the cause of the problems, then yes, they did tell you so and you should probably take note. Otherwise you're letting yourself or other managers off the hook every time. The culture should support…

If you are not receptive to what someone has to say, that does not mean that the person delivering the message has bad communication skills.

Some mediocre excuses to not be receptive are:

- Because you are superficial.

- Because that person is not important and therefore you don't have to listen to that person.

- Because you only want to be seen talking to important people.

- Because ignoring people makes you feel important.

- Because you do not want to admit that you do not understand what is being said to you.

- Because it is not that person's job to be thinking about that.

- Because you perceive people that care about data as "negative people".

All of these are lousy excuses. Real organizations leverage the combined thinking power of each member.

"We don't hire smart people to tell them what to do, we hire smart people to tell us what to do" - Steve Jobs

"It doesn't matter whether a cat is white or black, as long as it catches mice" - Deng Xiaoping

Re: The futility of “I told you so” in software engineering teams

#40

Post by lstamour » Sat, Jul 25, 2020, 12:00 AM UTC

jmchuster wrote: post #23

The common problem with "I told you so" is that you ignore all the other times where you told something that was wrong. So, if we went back in time and magically implemented everything you ever suggested, we'd probably end up worse off. So, maybe we want something like, everyone keeps track of every suggestion and every idea they make, then once we have determined we have enough information to fully judge the quality…

Congratulations, you’ve invented Bridgewater’s controversial “evidence based” decision making systems as put forward by Ray Dalio. From what I’ve heard, the controversial part is that they often ignore evidence when it doesn’t suit their case/etc. and that employees can be uncomfortable/unused to being recorded all the time.