Live data from Hacker News

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

humza.sh

21–30 of 84 posts

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

#21

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.

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

#22
In Amazon big incidents are investigated.

Any "I told you so" should be followed up: if people warned about a risk it's very useful to investigate why they were not listened.

If nobody warned - that's a bad sign for the whole team - and people will start asking why that happened.

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

#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 of a past suggestion, go back and evaluate why it was wrong/right and why it got accepted/missed. Then, you adjust your processes to increase the rate of rejecting bad ideas while increasing the rate of accepting good ideas. But that sounds like it'd be hard to implement, and it's much more enjoyable to just get to act smug and superior.

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

#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 (rather than virtuous politik doublethink) can lead to good team dynamics on a team full of mature people IMO

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

#25
I think it's important to make it clear when you were against a plan that ended up failing exactly how you said it would. Because otherwise you can end up taking the blame. No one is going to try to pin it back an you as not arguing well enough. If you're not a jerk about being right, it could even benefit you since it will be on peoples' minds to not tune your objections out next time and to listen to your alternatives.

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

#26
> If your past warnings were ignored and you do not feel that there are any politics / biases / prejudices in active play...

Well that just about covers it, dunnit? This should be at the top, not the bottom, of the article. Not all of us are going to suffer bias and prejudice, but boy howdy, if leadership's feelings (aka politics) isn't the primary driver for engineers who say "toldjaso."

But let's talk about that prejudice! As a woman in tech, most often my "toldja" isn't about not making my case. I know this because there are men who will speak up, and repeat my case, and get listened to when I wasn't. And they get the credit! The good ones deflect that credit to me, so I'm allowed to cherish a moment of quiet smugness. Most often, though, it's up to me to kick somebody in the proverbial ankles to remind them that I'm still here, providing value in this specific way.

And to respond to another commenter. If politics is why you aren't getting listened to, leaving is a fine option. If bias and prejudice is the reason, the problem is industry-wide and "just leave" is tantamount to "you people don't belong here." I am not having that.

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

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

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

#28

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.

Agreed, shared, written feedback on a design provides a public record, meaning there is never any need for expressing "I told you so" because the record is there. If you were right about something and your feedback was ignored, it stands there as testament.

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

#29
After 25 years of doing this crap, I really think the issue is that no one wants to hear “I told you so” because it undermines the hierarchy of fragile egos hiding all the shit that is on fire.

Say it in your head. When you run out of fingers to count them on, walk out the door.

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

#30
Having worked on some SLAM algorithms, it's important to make a prediction, then perform an action, then measure the results against the expected results.

This process provides data and feedback about the accuracy of your model. If you ignore past predictions, you gain little insight and repeat the same erroneous process.

Post reply on HN