Live data from Hacker News

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

humza.sh

81–84 of 84 posts

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

#81
post #75
post #26

> If your past warnings were ignored and you do not feel that there are any politics / biases / prejudices in active play... Well that just about covers it, dunnit? This should be at the top, not the bottom, of the article. Not all of us are going to suffer bias and prejudice, but boy howdy, if leadership's feelings (aka politics) isn't the primary driver for engineers who say "toldjaso." But let's talk about that pr…

This unfortunately happens to many non-dominating persons.

Yes. Dominating persons are an impediment to effective teamwork.

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

#82
post #36

> 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 corpor…

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 histo…

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.

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

#83

Earlier quoted context omitted.

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

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

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

#84

Earlier quoted context omitted.

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

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.

Post reply on HN