91–100 of 180 posts
* Say yes first. Acknowledge everything and say what you agree with.
* Use the phrase "tell me more." Use this to get context in a nonconfrontational way (as opposed to "why" which can get people in defensive mode).
* Avoid using "but". People don't like to hear it and it makes them forget the past before it. Everytime you want to use but, see if you can use "and" or "at the same time", or nothing, and almost always the result is better.
Rather than jump to calling out something as wrong, it can be helpful for mutual understanding to first ask questions framed in the terms of the apparent misconception, even if it sounds wrong to your mind or risks making you look stupid. Sometimes you'll find that there was actually no mistake, and other times you may make a positive contribution in a way that's more collaborative than adversarial.
This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
The other side of this is how nearly every engineer is going to trash talk the prior coders, when they inherit a codebase. So I already know to ignore it.
This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
I think there a counter point that if someone else had not deferred or neglected pointing out something was wrong there would be less wrongs to discover.
It’s certainly socially easier and nicer to avoid pointing out flaws but it doesn’t always result in better technical solutions.
This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
> we never got the time to fix it The older I get the more convinced I become that this is Learned Helplessness. "We didn't have time." is essentially the same dodge as "C'est le guerre" was in France. "We don't have time" is a conversation killer. "We are working on that bit by bit" is essentially the same statement once you've subtracted the helplessness. Nobody is ever gonna schedule time for you to have integrity…
The solution is almost always to put pressure on the industry and the system’s administrators and designers to improve it (as govt recently has been trying to do after SolarWinds fiasco)
This phenomenon is EVERYWHERE and once you read this you can’t unsee it — check this out:
I just don't agree. Much better to set a culture where people are encouraged to put their ego aside and accept being corrected immediately and politely. The repetition and fast iteration is good for learning.
This. Let's please not make engineering another field where our first concern is whose feelings are hurt. There are, of course, better and worse ways to raise concerns. "Why did you do it this way? It seems to me that . . . " leaves the conversation open to the possibility that there is good reason for something you don't understand. And if there are major problems, it might be better to privately approach someone (a…
Sorry, but everybody should be doing this in every job, and in all walks of life, all the time (however, like anything, there are limits).
Concern for other's feelings isn't weakness, nor should it be a second thought - it's a common courtesy.
This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?
The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them.
Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
Earlier quoted context omitted.
This. Let's please not make engineering another field where our first concern is whose feelings are hurt. There are, of course, better and worse ways to raise concerns. "Why did you do it this way? It seems to me that . . . " leaves the conversation open to the possibility that there is good reason for something you don't understand. And if there are major problems, it might be better to privately approach someone (a…
Whether someone's feelings are hurt should be a primary concern. That doesn't mean you cannot correct people making errors, you definitely should. But if you're hurting people's feelings regularly you are bad at providing feedback. I notice the only "softening" of the message you suggest is to allow pushback if you happen to be wrong. It seems you are more likely to cause persistent fixes by treating people as people…
No.
Whether shit gets done is the primary concern, when the primary reason we get together, is to get shit done.
Earlier quoted context omitted.
Whether someone's feelings are hurt should be a primary concern. That doesn't mean you cannot correct people making errors, you definitely should. But if you're hurting people's feelings regularly you are bad at providing feedback. I notice the only "softening" of the message you suggest is to allow pushback if you happen to be wrong. It seems you are more likely to cause persistent fixes by treating people as people…
> Whether someone's feelings are hurt should be a primary concern No. Whether shit gets done is the primary concern, when the primary reason we get together, is to get shit done.
But often it's not. Often the people who like dishing it out are the most easily affronted if you tell them they are in the wrong.
Don't get me wrong: I actually agree with you. It's just an unfortunate reality that working with people means dealing with people and feelings are a part of that.
It's hard to establish mutually respectful relationships where both parties are equally able to be straight shooters and actually get things done. When it happens, it's wonderful.
But in most workplaces, that's just not reality. So it's very often the case that taking the time to try to not hurt feelings in the first place is more efficient than dealing with the damn idiotic fallout.