4 ms·

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If thei

The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. If their reasoning was presented initially and matches up with what was the cause of the problems, then yes, they did tell you so and you should probably take note. Otherwise you're letting yourself or other managers off the hook every time. The culture should support feedback and input from both directions. If an engineer did try to warn but didn't communicate that clearly, then I would see that as an area where (if I were a manager) we could see a tangible benefit by helping this person improve their communication skills. Improving communication skills isn't something a person does in a vacuum but within an environment that facilitates constructive feedback. Dismissing previous warnings by default using this reasoning seems contrary to a so-called "data-driven" culture, and a great way to build miscommunication into a culture.

thinkingkong 6y ago
This is why I like written designs and soliciting feedback. Everything is going to have tradeoffs and teams need to get better about explicitly stating them vs rounding these blind corners and shrugging.
- coderintherye 6y ago
  Agreed, shared, written feedback on a design provides a public record, meaning there is never any need for expressing "I told you so" because the record is there. If you were right about something and your feedback was ignored, it stands there as testament.
- ziml77 6y ago
  Even if it's not a full design in writing, important decisions should have a trail. It can be hard to adhere to that, but it's very useful. Life if there's something that you think could bite you, but a manager is very pushy about their way, write it down in an email as a question asking for confirmation. I've had to go back to emails like that, sometimes to actually confirm to the person who made the decision in the first place.
flukus 6y ago
> The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. It's also extremely dismissive of experience. Sometimes you just know an idea won't work out because you've been down that road before. You can't just distill 20 years of experience into strong counter arguments for every proposal, it's just too time consuming, especially when you've got other stuff to do. But our industry severely under values experience. It's similar to other useless platitudes like "present solutions not problems". It sounds good on the face of it but ignores that solutions take much more of a time investment than seeing problems does, seeing a problem is merely the first stage of a solution. And trying to get rid of "I told you so" leads to "consensus" decision making, which is it's own workplace cancer: https://www.youtube.com/watch?v=67QsrpNH96Q https://www.youtube.com/watch?v=67QsrpNH96Q
- aeternum 6y ago
  How do you handle input that does need to be dismissed? I've seen entire teams stall out and become stuck in perpetual design loops due to 1-2 members constructing endless 'what-if' scenarios. Engineering involves tradeoffs, there is rarely a single perfect solution. There are also times like when attempting to find product-market fit when pointing out all the possible problems is close to useless. There are so many unknowns that the most important thing is often to get your product out there and start validating your assumptions and collecting data.
  - flukus 6y ago
    > 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.
29athrowaway 6y ago
If you are not receptive to what someone has to say, that does not mean that the person delivering the message has bad communication skills. Some mediocre excuses to not be receptive are: - Because you are superficial. - Because that person is not important and therefore you don't have to listen to that person. - Because you only want to be seen talking to important people. - Because ignoring people makes you feel important. - Because you do not want to admit that you do not understand what is being said to you. - Because it is not that person's job to be thinking about that. - Because you perceive people that care about data as "negative people". All of these are lousy excuses. Real organizations leverage the combined thinking power of each member. "We don't hire smart people to tell them what to do, we hire smart people to tell us what to do" - Steve Jobs "It doesn't matter whether a cat is white or black, as long as it catches mice" - Deng Xiaoping
underwater 6y ago
In my experience a well reasoned and methodical "that won't work" is far less common than plain old grumbling. The cliche of the curmudgeon developer exists for a reason. There are a lot of people who default to picking holes in any plan. They don't acknowledge the times they were wrong (and the project succeeded) or the fact that complaining about a solution doesn't actually help the problem get solved.

thinkingkong 6y ago

This is why I like written designs and soliciting feedback. Everything is going to have tradeoffs and teams need to get better about explicitly stating them vs rounding these blind corners and shrugging.

coderintherye 6y ago
Agreed, shared, written feedback on a design provides a public record, meaning there is never any need for expressing "I told you so" because the record is there. If you were right about something and your feedback was ignored, it stands there as testament.
ziml77 6y ago
Even if it's not a full design in writing, important decisions should have a trail. It can be hard to adhere to that, but it's very useful. Life if there's something that you think could bite you, but a manager is very pushy about their way, write it down in an email as a question asking for confirmation. I've had to go back to emails like that, sometimes to actually confirm to the person who made the decision in the first place.

flukus 6y ago

> The idea that the person "needs to construct stronger arguments" seems to put the blame on the person with foresight when circumstances can vary a lot. It's also extremely dismissive of experience. Sometimes you just know an idea won't work out because you've been down that road before. You can't just distill 20 years of experience into strong counter arguments for every proposal, it's just too time consuming, especially when you've got other stuff to do. But our industry severely under values experience. It's similar to other useless platitudes like "present solutions not problems". It sounds good on the face of it but ignores that solutions take much more of a time investment than seeing problems does, seeing a problem is merely the first stage of a solution. And trying to get rid of "I told you so" leads to "consensus" decision making, which is it's own workplace cancer: https://www.youtube.com/watch?v=67QsrpNH96Q https://www.youtube.com/watch?v=67QsrpNH96Q

aeternum 6y ago
How do you handle input that does need to be dismissed? I've seen entire teams stall out and become stuck in perpetual design loops due to 1-2 members constructing endless 'what-if' scenarios. Engineering involves tradeoffs, there is rarely a single perfect solution. There are also times like when attempting to find product-market fit when pointing out all the possible problems is close to useless. There are so many unknowns that the most important thing is often to get your product out there and start validating your assumptions and collecting data.
- flukus 6y ago
  > 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.

29athrowaway 6y ago

If you are not receptive to what someone has to say, that does not mean that the person delivering the message has bad communication skills. Some mediocre excuses to not be receptive are: - Because you are superficial. - Because that person is not important and therefore you don't have to listen to that person. - Because you only want to be seen talking to important people. - Because ignoring people makes you feel important. - Because you do not want to admit that you do not understand what is being said to you. - Because it is not that person's job to be thinking about that. - Because you perceive people that care about data as "negative people". All of these are lousy excuses. Real organizations leverage the combined thinking power of each member. "We don't hire smart people to tell them what to do, we hire smart people to tell us what to do" - Steve Jobs "It doesn't matter whether a cat is white or black, as long as it catches mice" - Deng Xiaoping

underwater 6y ago

In my experience a well reasoned and methodical "that won't work" is far less common than plain old grumbling. The cliche of the curmudgeon developer exists for a reason. There are a lot of people who default to picking holes in any plan. They don't acknowledge the times they were wrong (and the project succeeded) or the fact that complaining about a solution doesn't actually help the problem get solved.