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 futility of “I told you so” in software engineering teams
21–30 of 84 posts
Re: The futility of “I told you so” in software engineering teams
#22Any "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
#23So, 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
#24The 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
#25Re: The futility of “I told you so” in software engineering teams
#26Well 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
#27At 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…
Re: The futility of “I told you so” in software engineering teams
#28The 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
#29Say 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
#30This 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.