Thanks for the Feedback: The Science and Art of Receiving Feedback Well

Author: Douglas Stone, Sheila Heen
This Month Hacker News 1


by afarrell   2018-11-10
> If what the OP said cannot be believed, even for the sake of argument, then there's no discussion to be had at all.


1) One can read a text with an eye toward the ways in which the narrator might be misinterpreting the situation and can hold in ones' head the possibility of that misinterpretation...while also making suggestions for how to grapple with the problem that the writer presents.

2) Taking as given the way OP presents their problem, you are correct that the co-founder is not acting in the best interests of the business. However, it is an unjustified leap to say that the co-founder does not care. There are a multitude of reasons why the co-founder could simultaneously care very deeply and be acting this way:

- The co-founder is mistaken on matters of fact about the problems.

- The co-founder is making a judgement call about maintaining product focus vs responding to customer requests...and making a mis-judgement

- The co-founder lacks skill at listening to and interpreting feedback[1].

- The co-founder is overcorrecting from making an opposite error previously in life/career.

- The co-founder is missing some other very important leadership skill.

Point is, it is possible for people to fail very badly and obnoxiously at something that they care a great deal about.


On second read, I think you might be using the phrase "does not care" in a way that isn't making sense to mean. Could you expand on what it means for someone to think they care about something but to not actually care about it?

[1] This is a skill. is a good book on it.

by afarrell   2018-10-22
> I don’t know if this is impostor syndrome

It is a question worth asking. Our industry talks so much about impostor syndrome that people forget that there are other sources of lack-of-confidence.

I'm going to go through and try provide a clear vision of what challenges you are running into. Based on my interpretation, I'll then write out what are hopefully some clear actions to take or concrete questions to resolve. However, if you think Ive missed the mark in my interpretation, please let me know.

> joined...a month ago

Oh, so you're totally new then. Cool.

> all on the order of maybe a few hundred lines of code

Lines-of-code can be a proxy for the scope of a problem when you adjust for language expressiveness, but it is a very rough one. What I'm hearing here is that you're used to taking on projects for clients which are a fairly meaty bit of their business and require you to write whole features fairly quickly...but probably doing greenfield development. Modifying code that has been running for a while in an established organisation is a bit of a different beast.

> I’ve also spent maybe a week more than I should have on a fairly simple feature, just from fighting with my tools and trying to figure out where to put a few sparse calls in the codebase. It’s really embarrassing.

So I'm hearing a mix of frustration at your developer experience and disappointment in yourself for running into that frustration. I'm guessing that before you had a toolchain you were very fluent with and now you are...not. Okay, this is a problem to solve. Not as in "this is a problem with you", just "this is a problem you've got to deal with". Ideally, you deal with it by scoping out the pieces required to fix your development environment and tacking them as engineering challenges. This process will be significantly accelerated by asking well-framed questions of your coworkers who have the same sort of development environment. Julia Evans has a blog post on how to ask good questions which you should absolutely go read right now.

> I think I’m riddled with fear that I’m just not good enough to

The cure for this is to get an idea of the specific capabilities that your job expects of you. Ideally, your company has some sort of regular review process where you are asked to evaluate yourself against these specific capabilities. Ask your manager (whoever you do 1-on-1s with) what that process is and walk through those questions with them now rather than later. Then you can turn this vague fear that you are not 'good enough' into a specific fear that you can't do X well. Then you can get advise or resources on how to do X.

> I don’t really know how to reach out to people

There is a fairly large basket of skills here and I've got to rush off, so I'll just say that these skills are learnable and there are resources out there which I'm sure others are linking in this thread.