The futility of “I told you so” in software engineering teams
humza.sh
humza.sh
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.
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
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.
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.
If a person has experience but finds that their credibility isn’t what they want it to be, maybe something else is up.
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
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.
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.
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.
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.
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.
If I could go back 20 years and give myself one piece of mental health advice, this would be it.
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.
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.
There's plenty of leeway for choosing solutions and who's responsible for what kind of failures.
I for one have spent a while trying to make sure I just have to throw an exception(with increasingly better messages), and somebody else needs to solve the problem
Say W sends a message to Y but doesn't record the message was sent Y or wait for any sort of ack (say a process that drops a flat file to an FTP server that gets deleted after 7 days). Now someone finds out Y is missing a bunch of things. Who's fixing it and who should be fixing it?
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.
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.)
> 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.
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.
"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?"
* objective is key, because if there’s too much data, you can find some that says anything you like.
Say it in your head. When you run out of fingers to count them on, walk out the door.
I agree that considering your role and position is the correct thing to do.
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.
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.
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.
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?
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".
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.
From that I deduce it was something she was told a lot.
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.
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.
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.
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.
"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.
> “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.
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.
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.
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?").
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.
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
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.
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.
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.
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.
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.
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.