
The futility of “I told you so” in software engineering teams - shs7777
https://humza.sh/2020/07/24/the-futility-of-i-told-you-so.html
======
TheCowboy
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 feedback and input from both
directions.

If an engineer did try to warn but didn't communicate that clearly, then I
would see that as an area where (if I were a manager) we could see a tangible
benefit by helping this person improve their communication skills. Improving
communication skills isn't something a person does in a vacuum but within an
environment that facilitates constructive feedback.

Dismissing previous warnings by default using this reasoning seems contrary to
a so-called "data-driven" culture, and a great way to build miscommunication
into a culture.

~~~
flukus
> 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](https://www.youtube.com/watch?v=67QsrpNH96Q)

~~~
aeternum
How do you handle input that does need to be dismissed?

I've seen entire teams stall out and become stuck in perpetual design loops
due to 1-2 members constructing endless 'what-if' scenarios. Engineering
involves tradeoffs, there is rarely a single perfect solution.

There are also times like when attempting to find product-market fit when
pointing out all the possible problems is close to useless. There are so many
unknowns that the most important thing is often to get your product out there
and start validating your assumptions and collecting data.

~~~
flukus
> How do you handle input that does need to be dismissed?

Hierarchy. You need someone to make the calls and the team to follow them,
even if it's going to be wrong. That should be enough to break any perpetual
design loop and move forward. Ultimately this hierarchy will exist anyway, the
person paying you gets to decide what you're going to do or delegate that
decision to someone else. Soliciting feedback along they way is important, but
ultimately you need some decision makers.

> There are also times like when attempting to find product-market fit when
> pointing out all the possible problems is close to useless

This is building solution and then finding the problem which can be entirely
avoided.

------
protomyth
_Your “I told you so” only highlights that you need to construct stronger
arguments._

No, sorry. Most places don't allow people time to construct stronger
arguments. Most experienced people have a gut feel for what is going to go
wrong. We are pattern machines, and they are feeling the pattern. That would
be part of the definition for experience. Decent decision makers have worked
on the skills to ask questions when experienced people have those gut feelings
and figure out the arguments that lead to the feeling.

Further, that sentence just ticks me off. You were warned. You didn't like the
warning, and got bit. Don't blame the person telling you it was going to be a
problem. Blame yourself for not having the skill or desire to understand the
warning, work out what the experience was telling the person, and gaining some
knowledge. Failure is a great teacher, but internalizing the experience of
others is way cheaper.

I remember when CRC cards were so useful for the role-play to walk different
scenarios through the system. It would bring out the experience and show where
things might go off the rails. It was like a read-through of a new play.

~~~
m463
[https://blog.codinghorror.com/but-you-did-not-persuade-
me/](https://blog.codinghorror.com/but-you-did-not-persuade-me/)

------
deathanatos
> _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 corporate workplaces are especially insidious for the
original person ever learning _anything_. The additional work implies a scope
change, or tickets slipping into the next sprint, which is implicitly frowned
upon. You're supposed to be a team player, so when something does — as
predicted — break, _you_ fix it (not the original person) as it now needs to
get done, and the company doesn't really care who or how the job gets done so
long as it is done. (Or, even, the breakage is in your area of expertise, and
even more knowledge — and work — is required to fix it than to have avoided it
in the first place, enough so that now you're the one who _must_ take care of
it.) But, what has the original person learned? Half the time, even if gently
prodded, "Hey $coworker, I've taken care of Y here to fix the Z breakage." is
just left unresponded to in chat. Did they read it? Who knows. In person is
usually just a "Oh, okay." But do they _understand_ that _this_ is what they
were warned about, and that it has cost me time, which causes me to be
stressed and frustrated? Who knows. (And all the "emotional intelligence"
stuff suggests that one must simply suppress that stress & frustration, as
emotion has no place in the workplace.)

But… I do agree that outright saying "I told you so", IME, rarely results in a
positive impact. But, I'm not sure what does.

~~~
XorNot
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.

~~~
flukus
> The real trick is that caring about anything in the modern corporate
> workplace is a mistake

If I could go back 20 years and give myself one piece of mental health advice,
this would be it.

~~~
Brian_K_White
This is an "I told you so" to myself. For all of my carreer I avoided big
corporate companies because I just assumed I would hate it, even though at
least in the past it maybe sounded more glamorous and I could probably make a
lot more money. Recently, through no action of my own, my company was sold to
a much larger company. Well I was right.

And you have nailed the essential heart of it I think. You just have to not
care about what you're doing, how well it could be done, or what tools you're
using to do it.

Which is just no way to live.

But you still have to excel and look good somehow, even with no freedom of
movement to excel IN. All you can do is do the pre-scribed wrong things, well.

~~~
aahortwwy
> You just have to not care about what you're doing

You do have to care, you're just mistaken about what it is people in big
corporate companies are actually doing. What they're doing is advancing their
own careers and those of their network.

> how well it could be done

Reflected in the rate of advancement, which can be actively maximized through
effort and attention.

> what tools you're using to do it.

The "work" is in fact one of several tools used to advance the career. This is
why it is so frequently performed with little care or love. Often it only
matters to the career to the extent that it can be declared "done." Most
companies lack mechanisms to tie what happens later back to the original doer,
so the marginal benefits of care and quality to the career are low.

If you care about the actual "work" and craft it's best to find a place with
little to no concept of advancement, in my opinion.

EDIT: Some people really are just phoning it in for a paycheck, and who can
really blame them? Others who may appear to be lazy or careless simply have a
different set of priorities. If those priorities offend you but the person is
nevertheless succeeding, probably a good idea to move away from that
environment.

------
klyrs
> 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.

~~~
loopz
This unfortunately happens to many non-dominating persons.

~~~
klyrs
Yes. Dominating persons _are_ an impediment to effective teamwork.

------
barrkel
If you feel like you're saying "I told you so" often, you should leave.

Either you're not in a position to have your opinions count, or you've given
up fighting for them and are burning out.

(A third option is that you're deluded, and are forgetting about all the times
where what you told people didn't come out true. Watch for that, and be more
humble.)

~~~
setpatchaddress
Fourth option from TFA:

> Your “I told you so” only highlights that you need to construct stronger
> arguments.

All of these may be true. They're not necessarily a reason to leave.

~~~
fennecfoxen
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?"

~~~
jiofih
That is often a futile exercise on team dynamic platitudes. What do you
imagine would be a good / actionable answer for that question?

~~~
twelve40
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.

------
ironmagma
While this is common wisdom on software teams, and it’s good rookie advice,
it’s also good to know if people are feeling the need to shout “I told you
so!” on any kind of repeated basis. It’s not only a sign that there’s
something wrong with the proclaimer; it’s a sign that there’s something wrong,
period. Maybe the team isn’t listening to well-reasoned arguments, or maybe
there isn’t any way to get good enough data to make a decisive argument ahead
of time, and the team should listen to its individual members’ intuition more.
In the absence of objective* data, intuition is actually quite valuable and
it’s important not to discount it.

* objective is key, because if there’s too much data, you can find some that says anything you like.

~~~
jrott
I told you so is totally a sign that things are wrong and it being said a lot
is really signaling to the manager of that team that they need to dig in and
figure out what is actually going on. Whenever I've heard it's always someone
that knows there is a problem and either can't figure out how to fix it or
they don't feel listened to when they've come up with solutions for it and so
they've just checked out.

------
m0xte
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.

------
makach
Some times a "I told you so" is absolutely justified. You fight so many times
for your common cause, but only in futility. Even when make the best case you
can make, still you are not being listened to.

I agree that considering your role and position is the correct thing to do.

------
WesolyKubeczek
That 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.

~~~
em-bee
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.

------
ex_amazon_sde
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.

------
yongjik
Sometimes 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?

~~~
loopz
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".

------
ziml77
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.

------
nwmcsween
Blaming the person that could see the issue isn't really ideal here, but it
depends if the person stated that will never work without any technical merit
or if given a break down of the issues and technical problems but
management/leadership ignored it then you're damn right you get to say I told
you so, hopefully with a PoC showing that it works with said issue.

------
bryanrasmussen
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.”

~~~
goatinaboat
_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.

~~~
bryanrasmussen
I don't think I've given you enough premises here for you to deduce that.

------
ramenmeal
I struggle a bit with this on my team. I work with some people who have
impressively strong work ethics, and they devote a lot of time into their
arguments with examples, PoC's. Might just be signs of burn out, but it can
feel "futile" to even try to make the argument in the first place.

------
jmchuster
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.

~~~
lstamour
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.

~~~
jmchuster
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.

~~~
lstamour
Here’s a talk about some of Ray Dali’s ideas, one of the ways the Bridgewater
system works is by voting and recording the outcomes of votes for longer term
weighting/analysis:
[https://www.ted.com/talks/ray_dalio_how_to_build_a_company_w...](https://www.ted.com/talks/ray_dalio_how_to_build_a_company_where_the_best_ideas_win?language=en)

~~~
jmchuster
Very interesting to get a data point on this. It takes a new employee 18
months to adapt to this work style, and then 25-30% never adapt. I'd imagine
that is impossibly impractical for most companies, ignoring even the cost of
moving your company to such a system in the first place.

I could also see the much more limited decision space being a factor in this.
You're talking about when to put in money, when to take it out, where, and how
much. And you can clearly see how well it worked out in the end. I wonder how
effectively such a system works when applied to the software space.

I do believe that the principles he talks about as being very valuable, so
actively stress testing all of your beliefs, and then collective decision-
making (sounds like wisdom of crowds). And I guess you'll never truly reach
idealized collective decision-making unless you implement a system like this.
So if you decide that's the most important thing, and the majority of the
impact of your work is in the decisions that you make (e.g. once you decide to
purchase this stock, implementation is trivial), then I guess it makes sense.
But I think in software, the ratio of decision-making to implementation is
skewed heavily in the opposite direction, lots of decisions are being made in
parallel by your thousands of employees, and the impact of each individual
decision is much smaller than at his hedge fund. Getting into the habit of
pulling multiple to a whiteboard might already get you close enough for such
circumstances.

There also seems to be an aspect of judging each other on the company's key
values. So then you can get constant feedback from every meeting you're in,
how much you live up to the values that your company believes in, and your
opinion is then weighted based on how well you match those values. Again, I
would question how valuable it is to do this and in what contexts. I
personally tend to believe more in the idea of leaders espousing company
vision and values, almost like a preacher in a church.

------
francasso
I find people that self describe as Engineering leaders disturbing

------
jawns
The best "I told you so" is the silent kind.

An "I told you so" is always preceded by a challenge to your authority. The
other person should have had reason to believe that you knew what you were
talking about, but they foolishly ignored you.

But saying those words turns YOU into the jerk.

It's much, much better to have other people around you judge the situation for
themselves and make the determination that you were right.

Even if nobody actually says that you were right and they were wrong, in a
healthy organization your respective track records will be noted.

------
notacoward
Explicit "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 associate that idea with you, but that's not really
important. The important thing is that the next time people are about to same
mistake (which almost always happens), your objection will have the weight of
shared experience and analysis behind it.

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.

~~~
notacoward
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.

------
cbanek
> If your past warnings were ignored and you do not feel that there are any
> politics / biases / prejudices in active play, it is time to introspect,
> reflect, and ask:

> “How will I make my case differently next time?”

For me, this usually comes down to "Who will I make my case to next time?" \-
IE, if you aren't listening to me, making messes that I told you would happen,
then expecting me to clean it up, it's time to go. And before someone asks,
this has happened more times than I can count.

You can never fully discount politics / biases / prejudices and in general
(not just personal bias, but technological bias), I find these are the most
obvious answers to how a team makes decisions that are against its own best
interest. It very rarely comes down to "I made my argument wrong." If
anything, on a good team, even if you make your argument wrong, other people
will pick up on it and help to correct the wrong parts, and keep the right
parts.

------
majormajor
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.

------
bxparks
Things are not so black and white in most non-trivial projects. The team could
conclude that there is an 80% chance of success, while you may think there's
only a 40% chance of success. If the project fails, does that mean you were
right? It's entirely possible that the correct estimate was indeed 80%, but
the universe rolled the dice into the 20% zone. Saying "I told you so" may not
be the most constructive response.

On the other hand, if you are consistently right 9 times out of 10, and the
team isn't listening to you, then, yeah, maybe it's time to find another team.
But be careful of selective memory: it could be that you are always predicting
failure, but you only remember the times when the project failed, not the
times when the project succeeded and you were wrong.

------
contingencies
In an engineering context, people should convince others with evidence. A test
case showing an objective improvement would be ideal. Pontification about the
relative merits of disparate approaches is irrelevant. This can be avoided by
having an benevolent dictator / architect make those decisions. While step one
is getting the job done (executing even a bad plan is superior to no working
product), I have noticed that sometimes the most efficient way to get the job
done is to defer it until later, when the problem space is better understood.
Tradeoffs are the great beauty of engineering and perhaps why the field
successfully holds the attention of so many minds.

------
JoshuaDavid
> If your past warnings were ignored and you do not feel that there are any
> politics / biases / prejudices in active play, it is time to introspect,
> reflect, and ask: > “How will I make my case differently next time?”

Most of the time someone says "I told you so", and aren't listened to, they'd
say that the people who didn't listen to their warnings didn't listen due to
either politics or bias. Even in the case of politics or bias, though, "how
will I make the case differently?" is still a valid question (it's just that
the question is now also accompanied by "is this really the hill I want to die
on?").

------
shmerl
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.

------
edw
Sometimes the best thing that could possibly happen is something not working.
How many times did Twitter bump up against its inability to scale on the way
to being successful? (Yes, maybe a bad example.) What if someone had said, “Oh
it’s never going to scale, we shouldn’t do this“? History has shown that if
there is a need or a desire, people will find a way to satisfy it. There are
good problems to have and bad problems to have – make sure you are not on the
side of trying to avoid having good problems.

------
yomly
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

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

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

~~~
opless
Sometimes the solution is 'not to do that bad thing' and quite often there's
no going back from that.

~~~
thephyber
Agree, but if you are the person to say "I told you so", you aren't in a
position to influence avoiding that condition. Also, the individuals in the
project have the potential to learn from the failure even if the
project/company doesn't survive.

Obviously there are life critical systems where this shouldn't even be
possible, but hopefully there are tests and trials that filter broken
products/services before life is put in harm's way.

------
NestedLoopGoBrr
Sometimes “I told you so” is the last form of catharsis available to an
engineer ground down by politics or bias making them unheard or ignored.
Speaking from experience on that one.

------
drewcoo
Personal problem? Maybe rethink your approach, but maybe it's a . . .

Systemic problem? Figure out how the team can collect and act on feedback
better, then again is it . . .

The best of all possible worlds? Maybe you're not personally inadequate. Maybe
the system works as well as it can given whatever constraints. Maybe this
problem is not such a problem after all.

------
voodootrucker
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.

------
pdimitar
> _“How will I make my case differently next time?”_

By leaving the company, 90% of the time. If you are repeatedly ignored and
then also ridiculed for pointing out that you saw the failure coming then that
team's leader is very likely beyond reason.

Life is not that long. Move on to greener pastures.

------
gcpwnd
Maybe I am grumpy but OP doesn't construct strong arguments either. I assume
that under certain circumstances psychology would give some arguments against
this form of communication.

------
roydivision
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.

------
smashah
Bad take. Team should listen. If you don't like the communication style of
someone so much so as to ignore them then fire them.

------
Brian_K_White
Why isn't it the managers job to be the communication expert and know how to
listen to their engineers? It is.

------
ghthor
Communication is a 2way street. If this was my manager I'd never try and help
them make decisions again.

------
nopeNopeNooope
I work in storage, and this comes up a lot. I say "It won't reliably hit that
target", and people think they know better.

Then it works a good chunk of the time, and when it fails most of the time,
nobody is paying attention.

But one day, it doesn't just nip over the line, it hits the wall, and it fails
hard in production.

This isn't because I'm bad at making arguments, this is because every software
developer has seen a few seconds where their storage device could hit X in a
benchmark that isn't applicable, but it confirms their mental model of how
this device works.

It takes a long time to actually test these devices well enough to _SHOW_
someone how this will fail, and they'll usually argue with you about how
you're wrong for weeks.

Better to just let them note your objections on the record, hit the wall with
their face, and then point out your objections were well noted.

------
jimbob45
Usually if an “I told you so” is an option, it means you either didn’t fight
hard enough, weren’t convinced yourself, or didn’t have enough evidence to
present a compelling argument. If none of those apply, then take solace
knowing you’re the best programmer to have ever been and stay silent and
humble.

