The futility of “I told you so” in software engineering teams(humza.sh)
humza.sh
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
83 comments
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.
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.
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.
> 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
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
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.
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.
> 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.
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.
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.
If a person has experience but finds that their credibility isn’t what they want it to be, maybe something else is up.
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
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
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.
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.
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.
* objective is key, because if there’s too much data, you can find some that says anything you like.
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.
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.
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.)
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.)
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.
> 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.
> 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.
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.
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?"
"During planning, I expressed my concerns that [bad thing that happen] might happen. Is there something I do to raise this matter more effectively in the future? Do we need to improve communications more generally?"
That is often a futile exercise on team dynamic platitudes. What do you imagine would be a good / actionable answer for that question?
It's hard to believe, but I've worked with some managers who actually listened, and they (she in my case) would say, let's work together to build a stronger case next time, I'll help you because you have some strong points here that are clearly not being heard because you are new OR need to polish up your argument and I'll help you. The alpha "better luck battling it out next time" attitude of the TFA's author just speaks for his own surroundings, there are places where people really help each other, managers included.
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.
> 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?").
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?").
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.
I agree that considering your role and position is the correct thing to do.
I find people that self describe as Engineering leaders disturbing
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
> 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.
If I could go back 20 years and give myself one piece of mental health advice, this would be it.
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.
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 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.
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.
This has not been my experience at a big tech company(well, amazon)
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
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
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.
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...
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?
Yes, but a path of heartache if the interfaces between systems aren't robust.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
Congratulations, you’ve invented Bridgewater’s controversial “evidence based” decision making systems as put forward by Ray Dalio. From what I’ve heard, the controversial part is that they often ignore evidence when it doesn’t suit their case/etc. and that employees can be uncomfortable/unused to being recorded all the time.
Recording what everyone says? I can't imagine many people would go for that. If a company decided to actually be serious about trying to implement this, I'd imagine you'd first have to implement "all meetings must produce documented meeting notes", then add on "all suggestions must be brought up in relevant meetings" and then finally "all suggestions in documented meetings notes must be aggregated and then evaluated". So this might be a format that works for things like board meetings or I guess parliamentary sessions or court sessions where you have official stenographers and record keepers, but you can't really hold up every random meeting a company has to this standard. But it does seem like it would tend to work better on formalized/standardized meetings.
So if we're talking about trying to handle the case where engineers need to keep on saying "i told you so" maybe something like agile would be a closer fit to this, since you already have formalized meetings at a specific cadence. Then you also have the concept of retrospectives that are supposed to be documenting everyone's suggestions, so then maybe you say that you need to document planning meetings in the same way. So you say that the planning meeting must produce documented notes, with a comprehensive list of everything that was suggested, and then a list of everything that was agreed on. Perhaps giving a formal time and space for such suggestions also helps better surface them outside of snide side conversations. Doesn't cover all cases, but maybe it has potential to fall on the 80 side of 80/20.
Now, if you actually implement it all perfectly, would it actually help improve decision making? Probably? But I'd imagine that you'd then trade off for other things that are more valuable. Personally, my preference tends to be towards getting good people that you trust, having a clear shared vision for the company, then letting them run wild on their own to execute on that vision.
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.
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...
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.
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.
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
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
It's difficult to "commit" to something that is clearly and utterly wrong.
The faster it fails, the faster you might have an opportunity to point out the failure points and suggest the correct solution.
Sometimes the solution is 'not to do that bad thing' and quite often there's no going back from that.
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.
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.
But what if you're the one who's wrong?
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.
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.
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.
> 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.
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.
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.
Say it in your head. When you run out of fingers to count them on, walk out the door.
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.
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.
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.
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.
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.”
> 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.
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.
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.
From that I deduce it was something she was told a lot.
I don't think I've given you enough premises here for you to deduce that.
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.
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.
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.
1) We’re going to make a thing, but you disagree about how we should do it, so you must be not a team player, shut up, you’re ruining the spirit.
2) We’re incompetent doofuses and we’ve broken the thing as you have predicted, but you’re still guilty because you weren’t persuasive enough.
gloating about being right is no better.
both cause disagreement and disunity in the team.
a well working will allow for mistakes and learn from them:
so one person sees a problem, but everyone else disagrees. the team acknowledges the disagreement but goes ahead anyways. when the problem becomes real, the team decides together how to deal with it.
let this happen a few times, and the team will learn to pay more attention to those kind of signals.
at no point anyone is being being ridiculed for being wrong, noone gets defensive and noone gloats about having been right.
sometimes it is useful to go the wrong way to convince yourself that it is wrong. because the team is always united they are much faster to change course when needed. they don't waste time arguing.
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.
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.
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.
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.
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.
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?
Like, when services randomly fail to start up, and instead of fixing the bad config, people write docs saying you should try the command multiple times ... what are you gonna do?
You grit your teeth and chew on it, until those times you know you're right. You then keep escalating to Director level if need be. Though nowadays there's so many leaders (chefs), you just play them against eachother and bring some popcorn.
The trick is to NEVER grumble about uncertain stuff, but ONLY suggest stuff that should work. 4-5 years later, they'll implement it with no mention of you, but you will have been "heard".
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 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.
> “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.
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.
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.
Why isn't it the managers job to be the communication expert and know how to listen to their engineers? It is.
Communication is a 2way street. If this was my manager I'd never try and help them make decisions again.
> 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.
> “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.
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.
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.
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.
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:
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 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.
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.
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.