4 ms·

Only expressing yourself to another in private is not being candorous to the rest of the team. What does it mean to remember that you are talking to a person?

Only expressing yourself to another in private is not being candorous to the rest of the team. What does it mean to remember that you are talking to a person? I generally only talk to persons. That is, if I am talking, it is to a person. I also generally know when I am talking. I also think that if you are talking to a person, you must personalize it.

kimscott 11y ago
Well, if you are criticizing a person, then the rest of the team may not need to hear it. For example, if the person consistently makes sloppy mistakes, that's a conversatin that is better had in private. If you're just saying there's a typo on that slide, that's a correction of somebody's work not a critisim of somebody, and fine to do in public. If it's a debate about an idea that obviously needs to be in public. But a debate is very different than criticism in my mind. I agree it does seem ridiculous to say remember you are talking to a person :) But people forget all the time, and that is why they often say things in an overly harsh way. If you are talking to a person, it must be personal, but it doesn't have to personalize. If you say, I think that's wrong, and that is something somebody has worked on for a long time, they will take it personally so it is personally. But you haven't personalized--saying you're wrong or you're always wrong is personalizing unnecessarily. If you want I'll send you about 10 pages I've written on this stuff--would love your reaction, it's very helpful!
- 33W 11y ago
  Not the commenter above, but I would certainly be interested in reading your full thoughts on this! As an entry level developer I send feedback up the chain by default.
  - kimscott 11y ago
    Here is some more about what I mean by radical candor being HIP (Humble, Helpful, Immediate, In person, Private criticism / Public praise, do not Personalize). What follows are some additional thoughts on what that means. But, please don’t let the additional thoughts or the acronym paralyze you. Whatever you do, don’t sit there saying nothing trying to remember what I stands for. For the vast majority of people, the really important thing is to just say what you think. H is for Humble. You can’t care personally or challenge directly if you’re not humble. It’s really hard to care at a personal level about somebody if you feel superior. When one person feels intrinsically “better” than another, a good relationship is impossible. And, you can’t challenge directly and be open to the reciprocal challenge if you’re not humble enough to realize you may be wrong. The first time a person in a class I was teaching raised his hand asked me how to be humble, I sat there with my mouth open. It was all I could do not to break into the song from the 70’s show HeeHaw. “Oh lord, it’s hard to be humble, when you’re perfect in every way!” How to answer a question like that?? I didn’t take it seriously until about the 20th time somebody asked me. Finally, I realized it was a legitimate question and I needed to give a serious answer. The reason is that criticism does feel arrogant. How can you feel humble and tell somebody when their work isn’t good enough at the same time? It can feel equally arrogant to tell people when their work is great. I often bristle at praise because it sounds insincere or patronizing or somehow belittling. When somebody says to me, “I’m so proud of you!” I think, “Who are you to be proud of me?” It’s the fear of sounding arrogant that sometimes makes me hesitate to give praise to people properly. Ask questions: I’ve always found it really helpful to offer both criticism and praise in a spirit of inquiry rather than a spirit of self-righteous certainty. When criticizing, I try to keep top of mind the possibility that I may be wrong. The other person might learn something from my criticism--but it’s equally possible that I will learn something from their rebuttal to my criticism. Put another way, it’s always made it much easier for me to criticize somebody when I realize there are two benefits to doing so. One, I may be helping them to fix something that is wrong. Two, I am giving them an opportunity to fix my opinion, which is wrong. The same goes for praise: if you see something impressive, ask a question. How did you do that? What gave you that idea? Can you teach others to do that? etc. This shows that you are not some godly arbiter of what’s good and what’s bad, but a fellow learner. Power trips you up: Nothing is more corrupting to humility and to giving a damn than formal power. Part of what gives bosses trouble with humility is that they have a little bit of power. Part of what makes it hard for employees to be radically candid with their bosses is the power thing. Part of Google’s management genius was removing that power. But even if you don’t work at a company like Google, you can remember that you can easily get another job, and so find the courage to speak your mind. Don’t let yourself get too mad/hungry/tired: Most people find it harder to be humble when they’re mad, hungry, or tired.If I focus on managing my emotions it’s easier for me to prevent my ego from getting the better of me. “Left hand column” and “ladder of inference:” Chris Argyris developed a method useful for keeping oneself humble called the “left hand column.” The idea here is that what you are really thinking, which is often arrogant, leaks out into what you say. If you can be more conscious of what you’re thinking, and can adjust it, you can probably find a productive way to address it. For example if you are thinking, ‘Joe is a bozo and shouldn’t even be at the company,’ you’re not likely to be “HIP” when you criticize the typos you saw in his last ten presentations. However, if you realize what you’re thinking and dig a little deeper, you may realize that you’ve hit the bozo bit too fast. Or, you may realize you should be helping Joe to find a job that’s a better fit for him, not coaching him in a role he’ll never be great at. Argyris also came up with the “ladder of inference” tool. This can help you be humble enough to question your assumptions and get out of recursive loops as you judge people. “Ontological Humility:” Fred Kofman wrote a great chapter called Ontological Humility in his book Conscious Business. The idea is that when you remember your criticism may be wrong, it can help you to challenge others in a way that invites a reciprocal challenge, and helps you see things from the other person’s point of view.
- jsprogrammer 11y ago
  >Well, if you are criticizing a person, then the rest of the team may not need to hear it. Perhaps. Everyone cannot hear everything. There is just not enough time to process it all. Each must be able to work on their own pieces. However, I would say that any time things are being said in private, there is the opportunity that candor is being lost to the rest of the team. I can believe that people can forget that they are talking to a person. I'm just having a hard time imagining what that would be like. I think I get what you are saying about personalizing things. I want to say that the rule should be, "Don't treat your perceptions as reality, they could be wrong." You can send me anything you've got.
Tenhundfeld 11y ago
>What does it mean to remember that you are talking to a person? Your interpretation is overly literal, IMO. In the context of giving critical feedback, it's easy to focus on the problem, the specific area you want to correct, and reduce the person on the other side to just being the cause of the problem. For example, you're a team lead and have a developer on your team who routinely writes buggy code and shipped a broken feature last release, which caused a kerfuffle with a major client. When you meet with them to discuss what happened, in your mind, you're not talking to "a person". You're talking to the developer who caused this big problem you have to deal with. In your mind, you are handling a problem, not talking to a person. It's easy to forget that the developer is a person with a lifetime of experiences different from yours, a different perspective, different strengths and weaknesses, different insecurities, different stuff going on in their personal life. You need to remember they are "a person" and as such, entitled to a modicum of dignity and respect. So, sure, address the problem with radical candor, but remember this problem does not define the entirety of the person. In other words, treat them how you would want to be treated, because I assure you, their life is just as important to them as yours is to you. At least, that's my interpretation. And if your response is still, "Duh, that's obvious," then maybe you're just better at giving critical feedback than most people. I haven't been on the receiving end myself, but I have often seen managers give feedback that is belittling and reduces the entire worth of a person to a single mistake.
- jsprogrammer 11y ago
  >Your interpretation is overly literal, IMO. I did not give an interpretation. I asked a question. I don't think a description of what it means to remember you are talking to a person was given even though it was claimed that one should do it. If I should be doing it, I need to know what it is. Then, I can see if I am actually doing it, and if I am not, start doing it again. I think it is an entirely reasonable question. >In the context of giving critical feedback, it's easy to focus on the problem, the specific area you want to correct, and reduce the person on the other side to just being the cause of the problem. Certainly. People are generally not the causes of problems, so looking there is probably a waste of time. I think the far more effective strategy is working to eliminate the problem and modify processes to ensure that the problem never happens again. Any problem, in a corporate context, is a failing of the entire team, not any individual. >It's easy to forget that the developer is a person with a lifetime of experiences different from yours, a different perspective, different strengths and weaknesses, different insecurities, different stuff going on in their personal life. Maybe our difference is on how easy this is. I don't think that is very easy to forget. All you need to do is realize that you are a person with all of those things and that you are not that other person. >I haven't been on the receiving end myself, but I have often seen managers give feedback that is belittling and reduces the entire worth of a person to a single mistake. I think it's a rampant problem. I guess people just want to blame others rather than make things better? I seem to detect instances of it all the time, that seem to be casually accepted by most. For example, General Motor's response to a faulty piece of equipment they were using in their cars was to fire the engineer who designed it. Almost no mind was paid to the fact that GM's process allowed critical parts to be wholly designed and signed off on by a single individual.

kimscott 11y ago

Well, if you are criticizing a person, then the rest of the team may not need to hear it. For example, if the person consistently makes sloppy mistakes, that's a conversatin that is better had in private. If you're just saying there's a typo on that slide, that's a correction of somebody's work not a critisim of somebody, and fine to do in public. If it's a debate about an idea that obviously needs to be in public. But a debate is very different than criticism in my mind. I agree it does seem ridiculous to say remember you are talking to a person :) But people forget all the time, and that is why they often say things in an overly harsh way. If you are talking to a person, it must be personal, but it doesn't have to personalize. If you say, I think that's wrong, and that is something somebody has worked on for a long time, they will take it personally so it is personally. But you haven't personalized--saying you're wrong or you're always wrong is personalizing unnecessarily. If you want I'll send you about 10 pages I've written on this stuff--would love your reaction, it's very helpful!

33W 11y ago
Not the commenter above, but I would certainly be interested in reading your full thoughts on this! As an entry level developer I send feedback up the chain by default.
- kimscott 11y ago
  Here is some more about what I mean by radical candor being HIP (Humble, Helpful, Immediate, In person, Private criticism / Public praise, do not Personalize). What follows are some additional thoughts on what that means. But, please don’t let the additional thoughts or the acronym paralyze you. Whatever you do, don’t sit there saying nothing trying to remember what I stands for. For the vast majority of people, the really important thing is to just say what you think. H is for Humble. You can’t care personally or challenge directly if you’re not humble. It’s really hard to care at a personal level about somebody if you feel superior. When one person feels intrinsically “better” than another, a good relationship is impossible. And, you can’t challenge directly and be open to the reciprocal challenge if you’re not humble enough to realize you may be wrong. The first time a person in a class I was teaching raised his hand asked me how to be humble, I sat there with my mouth open. It was all I could do not to break into the song from the 70’s show HeeHaw. “Oh lord, it’s hard to be humble, when you’re perfect in every way!” How to answer a question like that?? I didn’t take it seriously until about the 20th time somebody asked me. Finally, I realized it was a legitimate question and I needed to give a serious answer. The reason is that criticism does feel arrogant. How can you feel humble and tell somebody when their work isn’t good enough at the same time? It can feel equally arrogant to tell people when their work is great. I often bristle at praise because it sounds insincere or patronizing or somehow belittling. When somebody says to me, “I’m so proud of you!” I think, “Who are you to be proud of me?” It’s the fear of sounding arrogant that sometimes makes me hesitate to give praise to people properly. Ask questions: I’ve always found it really helpful to offer both criticism and praise in a spirit of inquiry rather than a spirit of self-righteous certainty. When criticizing, I try to keep top of mind the possibility that I may be wrong. The other person might learn something from my criticism--but it’s equally possible that I will learn something from their rebuttal to my criticism. Put another way, it’s always made it much easier for me to criticize somebody when I realize there are two benefits to doing so. One, I may be helping them to fix something that is wrong. Two, I am giving them an opportunity to fix my opinion, which is wrong. The same goes for praise: if you see something impressive, ask a question. How did you do that? What gave you that idea? Can you teach others to do that? etc. This shows that you are not some godly arbiter of what’s good and what’s bad, but a fellow learner. Power trips you up: Nothing is more corrupting to humility and to giving a damn than formal power. Part of what gives bosses trouble with humility is that they have a little bit of power. Part of what makes it hard for employees to be radically candid with their bosses is the power thing. Part of Google’s management genius was removing that power. But even if you don’t work at a company like Google, you can remember that you can easily get another job, and so find the courage to speak your mind. Don’t let yourself get too mad/hungry/tired: Most people find it harder to be humble when they’re mad, hungry, or tired.If I focus on managing my emotions it’s easier for me to prevent my ego from getting the better of me. “Left hand column” and “ladder of inference:” Chris Argyris developed a method useful for keeping oneself humble called the “left hand column.” The idea here is that what you are really thinking, which is often arrogant, leaks out into what you say. If you can be more conscious of what you’re thinking, and can adjust it, you can probably find a productive way to address it. For example if you are thinking, ‘Joe is a bozo and shouldn’t even be at the company,’ you’re not likely to be “HIP” when you criticize the typos you saw in his last ten presentations. However, if you realize what you’re thinking and dig a little deeper, you may realize that you’ve hit the bozo bit too fast. Or, you may realize you should be helping Joe to find a job that’s a better fit for him, not coaching him in a role he’ll never be great at. Argyris also came up with the “ladder of inference” tool. This can help you be humble enough to question your assumptions and get out of recursive loops as you judge people. “Ontological Humility:” Fred Kofman wrote a great chapter called Ontological Humility in his book Conscious Business. The idea is that when you remember your criticism may be wrong, it can help you to challenge others in a way that invites a reciprocal challenge, and helps you see things from the other person’s point of view.
jsprogrammer 11y ago
>Well, if you are criticizing a person, then the rest of the team may not need to hear it. Perhaps. Everyone cannot hear everything. There is just not enough time to process it all. Each must be able to work on their own pieces. However, I would say that any time things are being said in private, there is the opportunity that candor is being lost to the rest of the team. I can believe that people can forget that they are talking to a person. I'm just having a hard time imagining what that would be like. I think I get what you are saying about personalizing things. I want to say that the rule should be, "Don't treat your perceptions as reality, they could be wrong." You can send me anything you've got.

Tenhundfeld 11y ago

>What does it mean to remember that you are talking to a person? Your interpretation is overly literal, IMO. In the context of giving critical feedback, it's easy to focus on the problem, the specific area you want to correct, and reduce the person on the other side to just being the cause of the problem. For example, you're a team lead and have a developer on your team who routinely writes buggy code and shipped a broken feature last release, which caused a kerfuffle with a major client. When you meet with them to discuss what happened, in your mind, you're not talking to "a person". You're talking to the developer who caused this big problem you have to deal with. In your mind, you are handling a problem, not talking to a person. It's easy to forget that the developer is a person with a lifetime of experiences different from yours, a different perspective, different strengths and weaknesses, different insecurities, different stuff going on in their personal life. You need to remember they are "a person" and as such, entitled to a modicum of dignity and respect. So, sure, address the problem with radical candor, but remember this problem does not define the entirety of the person. In other words, treat them how you would want to be treated, because I assure you, their life is just as important to them as yours is to you. At least, that's my interpretation. And if your response is still, "Duh, that's obvious," then maybe you're just better at giving critical feedback than most people. I haven't been on the receiving end myself, but I have often seen managers give feedback that is belittling and reduces the entire worth of a person to a single mistake.

jsprogrammer 11y ago
>Your interpretation is overly literal, IMO. I did not give an interpretation. I asked a question. I don't think a description of what it means to remember you are talking to a person was given even though it was claimed that one should do it. If I should be doing it, I need to know what it is. Then, I can see if I am actually doing it, and if I am not, start doing it again. I think it is an entirely reasonable question. >In the context of giving critical feedback, it's easy to focus on the problem, the specific area you want to correct, and reduce the person on the other side to just being the cause of the problem. Certainly. People are generally not the causes of problems, so looking there is probably a waste of time. I think the far more effective strategy is working to eliminate the problem and modify processes to ensure that the problem never happens again. Any problem, in a corporate context, is a failing of the entire team, not any individual. >It's easy to forget that the developer is a person with a lifetime of experiences different from yours, a different perspective, different strengths and weaknesses, different insecurities, different stuff going on in their personal life. Maybe our difference is on how easy this is. I don't think that is very easy to forget. All you need to do is realize that you are a person with all of those things and that you are not that other person. >I haven't been on the receiving end myself, but I have often seen managers give feedback that is belittling and reduces the entire worth of a person to a single mistake. I think it's a rampant problem. I guess people just want to blame others rather than make things better? I seem to detect instances of it all the time, that seem to be casually accepted by most. For example, General Motor's response to a faulty piece of equipment they were using in their cars was to fire the engineer who designed it. Almost no mind was paid to the fact that GM's process allowed critical parts to be wholly designed and signed off on by a single individual.