If you find yourself wanting to say “I told you so” too often, you need to ask yourself some questions, maybe you’re not in the right place.
The futility of “I told you so” in software engineering teams
71–80 of 84 posts
Re: The futility of “I told you so” in software engineering teams
#72Ursula 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.”
she said “Nobody who says, ‘I told you so’ has ever been, or will ever be, a hero.”
From that I deduce it was something she was told a lot.
Re: The futility of “I told you so” in software engineering teams
#73The 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.
Recording what everyone says? I can't imagine many people would go for that. If a company decided to actually be serious about trying to implement this, I'd imagine you'd first have to implement "all meetings must produce documented meeting notes", then add on "all suggestions must be brought up in relevant meetings" and then finally "all suggestions in documented meetings notes must be aggregated and then evaluated". So this might be a format that works for things like board meetings or I guess parliamentary sessions or court sessions where you have official stenographers and record keepers, but you can't really hold up every random meeting a company has to this standard. But it does seem like it would tend to work better on formalized/standardized meetings.
So if we're talking about trying to handle the case where engineers need to keep on saying "i told you so" maybe something like agile would be a closer fit to this, since you already have formalized meetings at a specific cadence. Then you also have the concept of retrospectives that are supposed to be documenting everyone's suggestions, so then maybe you say that you need to document planning meetings in the same way. So you say that the planning meeting must produce documented notes, with a comprehensive list of everything that was suggested, and then a list of everything that was agreed on. Perhaps giving a formal time and space for such suggestions also helps better surface them outside of snide side conversations. Doesn't cover all cases, but maybe it has potential to fall on the 80 side of 80/20.
Now, if you actually implement it all perfectly, would it actually help improve decision making? Probably? But I'd imagine that you'd then trade off for other things that are more valuable. Personally, my preference tends to be towards getting good people that you trust, having a clear shared vision for the company, then letting them run wild on their own to execute on that vision.
Re: The futility of “I told you so” in software engineering teams
#74That article reads as a piece justifying the bullies. 1) We’re going to make a thing, but you disagree about how we should do it, so you must be not a team player, shut up, you’re ruining the spirit. 2) We’re incompetent doofuses and we’ve broken the thing as you have predicted, but you’re still guilty because you weren’t persuasive enough.
gloating about being right is no better.
both cause disagreement and disunity in the team.
a well working will allow for mistakes and learn from them:
so one person sees a problem, but everyone else disagrees. the team acknowledges the disagreement but goes ahead anyways. when the problem becomes real, the team decides together how to deal with it.
let this happen a few times, and the team will learn to pay more attention to those kind of signals.
at no point anyone is being being ridiculed for being wrong, noone gets defensive and noone gloats about having been right.
sometimes it is useful to go the wrong way to convince yourself that it is wrong. because the team is always united they are much faster to change course when needed. they don't waste time arguing.
Re: The futility of “I told you so” in software engineering teams
#75> 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 pr…
This unfortunately happens to many non-dominating persons.
Re: The futility of “I told you so” in software engineering teams
#76Sometimes you can't even say "I told you so" because people refuse to understand that there is a problem. Like, when services randomly fail to start up, and instead of fixing the bad config, people write docs saying you should try the command multiple times ... what are you gonna do?
You grit your teeth and chew on it, until those times you know you're right. You then keep escalating to Director level if need be. Though nowadays there's so many leaders (chefs), you just play them against eachother and bring some popcorn.
The trick is to NEVER grumble about uncertain stuff, but ONLY suggest stuff that should work. 4-5 years later, they'll implement it with no mention of you, but you will have been "heard".
Re: The futility of “I told you so” in software engineering teams
#77Earlier quoted context omitted.
One can often take these to your manager or your team retrospective, and ask questions, turning it around to be forward-looking: "During planning, I expressed my concerns that [bad thing that happen] might happen. Is there something I do to raise this matter more effectively in the future? Do we need to improve communications more generally?"
That is often a futile exercise on team dynamic platitudes. What do you imagine would be a good / actionable answer for that question?
It's hard to believe, but I've worked with some managers who actually listened, and they (she in my case) would say, let's work together to build a stronger case next time, I'll help you because you have some strong points here that are clearly not being heard because you are new OR need to polish up your argument and I'll help you. The alpha "better luck battling it out next time" attitude of the TFA's author just speaks for his own surroundings, there are places where people really help each other, managers included.
Re: The futility of “I told you so” in software engineering teams
#78Explicit "I told you so" is a bad idea, but I've found that you can often guide people to it with other questions. For example:
"How might this have been avoided?"
"What lessons can we learn from this?"
"What else could we have done instead?"
BTW, this is an example of a general approach I've found useful. If you can lead people to the realization that their original solution is not the best one, they'll view you as a collaborator rather than a competitor. Emotional reactions matter. Too few will ever admit that their original idea was wrong or that the better idea was yours, but they might well realize it themselves. Over time and repetition, they'll become more likely to listen. It's kind of a shame that this extra work is so often necessary to overcome others' ego, but ... well, it is.
Re: The futility of “I told you so” in software engineering teams
#79Explicit "I told you so" is a bad idea, but I've found that you can often guide people to it with other questions. For example: "How might this have been avoided?" "What lessons can we learn from this?" "What else could we have done instead?" As the answers to these are explored, some people might realize that the approach or principle you had earlier espoused was worth keeping in mind next time. They might even asso…
Slightly more OT, the fact that this requires more work for less credit is exactly why I think "impact" based "meritocracies" are broken. As klyrs points out in another top-level comment, it's also often the result of discrimination. Many of the worst "never listens" folks I've worked with did listen to people of their own ethnicity (or from their own former employer) without requiring multiple rounds of softening up. I don't know how to fix that. My suggestion is only about how to work in the world-as-it-is to arrive at better technical decisions.
Re: The futility of “I told you so” in software engineering teams
#80Ursula 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.”
she said “Nobody who says, ‘I told you so’ has ever been, or will ever be, a hero.” From that I deduce it was something she was told a lot.
I don't think I've given you enough premises here for you to deduce that.