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

https://humza.sh/2020/07/24/the-futility-of-i-told-you-so.html

by shs7777 • 6 years ago

76 83 6 years ago

ironmagma• 6 years ago

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• 6 years ago

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.

ramenmeal• 6 years ago

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.

barrkel• 6 years ago

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• 6 years ago

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.

Supermancho• 6 years ago

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

Often you raise an issue, which is ignored or underprioritized. Later, priorities may shift from upper management, to make it an actionable argument. Rarely do you get credit or a career boost (promotion, raise, addtl responsibility, etc) from the alignment of concerns.

eg Company wants to cut costs. Using AWS can save 60%. Company doesnt want to use AWS because they compete with Amazon. New president oks AWS to save cost next quarter. I told you so gets you nothing.

fennecfoxen• 6 years ago

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

bfuclusion• 6 years ago

Yes, and no. In the best case you improve your communication skills and become a more valuable employee, in which case you should consider leaving to get more comp. If you don't make improvements, then you're not really able to be effective, and you should consider leaving because there might be a better fit elsewhere.

JoshuaDavid• 6 years ago

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?").

makach• 6 years ago

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.

francasso• 6 years ago

I find people that self describe as Engineering leaders disturbing

TheCowboy• 6 years ago

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.

thinkingkong• 6 years ago

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.

coderintherye• 6 years ago

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.

ziml772• 6 years ago

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.

flukus3• 6 years ago

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

aeternum• 6 years ago

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.

threatofrain• 6 years ago

What matters here is credibility of which experience is only one contributor. Everything you say is mitigated or boosted by credibility.

If a person has experience but finds that their credibility isn’t what they want it to be, maybe something else is up.

29athrowaway• 6 years ago

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

underwater• 6 years ago

In my experience a well reasoned and methodical "that won't work" is far less common than plain old grumbling.

The cliche of the curmudgeon developer exists for a reason. There are a lot of people who default to picking holes in any plan. They don't acknowledge the times they were wrong (and the project succeeded) or the fact that complaining about a solution doesn't actually help the problem get solved.

jawns• 6 years ago

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.

edw• 6 years ago

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.

jimbob45• 6 years ago

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.

NestedLoopGoBrr• 6 years ago

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.

deathanatos• 6 years ago

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• 6 years ago

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.

dropit_sphere• 6 years ago

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.

flukus3• 6 years ago

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.

phyzome• 6 years ago

It's harder when you're designing something that matters and can hurt people if done badly, such as a medical records system or voting machines.

EsotericAlgo2• 6 years ago

The version of this that continually bites me is when someone is designing what is essentially a distributed system but doesn't know that's what they are designing. System W -> System X -> System Y -> System Z are connected with the assumption no guarantees or coherency checks are needed. Might as well just email spreadsheets...

8note2• 6 years ago

Isn't the usual assumption that team w is responsible for system W to work, team x for system X, etc? And you can figure out who needs to fix a problem when it comes up?

nopeNopeNooope• 6 years ago

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.

smashah• 6 years ago

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.

nwmcsween• 6 years ago

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.

ex_amazon_sde• 6 years ago

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.

jmchuster3• 6 years ago

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.

lstamour2• 6 years ago

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.

jmchuster3• 6 years ago

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.

yomly2• 6 years ago

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• 6 years ago

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

thephyber2• 6 years ago

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

throwaway987978• 6 years ago

But what if you're the one who's wrong?

yomly2• 6 years ago

If it is clearly and utterly wrong, why is it so hard for you to convince your team/business? /troll

Being charitable, sometimes the team/org needs to obtain the group learning. If you've had your say, then time will prove you right and people will remember.

If the team/org won't remember AND they just like to rain down decisions on you from above, why you working there...?

In any case communication is HARD. It's always easy to blame people for not listening, but you can't control other people, only yourself. So the most constructive thing to focus on is doing everything in your power to make it clearly and utterly obvious what you can see that no one else can see. That will stay with you and eventually teams will listen to you.

ziml772• 6 years ago

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.

klyrs2• 6 years ago

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.

_y5hn2• 6 years ago

This unfortunately happens to many non-dominating persons.

klyrs2• 6 years ago

Yes. Dominating persons are an impediment to effective teamwork.

m0xte• 6 years ago

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.

voodootrucker• 6 years ago

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.

majormajor• 6 years ago

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.

bryanrasmussen2• 6 years ago

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

vageli• 6 years ago

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

Maybe that's because they weren't in the position to make the choice and change the outcome. You can't be a hero on the battlefield if you never leave the barracks.

goatinaboat• 6 years ago

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.

bryanrasmussen2• 6 years ago

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

shmerl• 6 years ago

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.

WesolyKubeczek• 6 years ago

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• 6 years ago

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.

bxparks• 6 years ago

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.

protomyth• 6 years ago

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• 6 years ago

https://blog.codinghorror.com/but-you-did-not-persuade-me/

yongjik• 6 years ago

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?

_y5hn2• 6 years ago

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

gcpwnd• 6 years ago

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.

pdimitar• 6 years ago

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

contingencies• 6 years ago

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.

Brian_K_White2• 6 years ago

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

ghthor• 6 years ago

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

cbanek• 6 years ago

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.

drewcoo• 6 years ago

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.

roydivision• 6 years ago

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.

notacoward2• 6 years ago

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.

notacoward2• 6 years ago

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.

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

Related Stories