3 ms·

> Feedback should almost always be based on data I do agree with you here. What I wanted to express is that you should hold back on interpretation. If you talk

> Feedback should almost always be based on data I do agree with you here. What I wanted to express is that you should hold back on interpretation. If you talk about your own perceptions, it allows other interpretations to also be valid. Thank you for the example on clogging the CI servers. Indeed, I would find it hard to turn this into positive reinforcement. Also I would agree that it's dishonest in not telling them. I guess I would try to highlight my own pains with their behavior like "I was blocked five times in deploying because of your failing tests. Please run your tests locally first.". I would always want to give them the opportunity to take my perspective and understand my reasoning.

sz4kerto 6y ago
> What I wanted to express is that you should hold back on interpretation. Yes, agreed. Also, if you interpret then say explicitly that 'my interpretation / perception / feeling based on fact X is Y, and feel free to disagree with the interpretation'. Eg. "Maybe you just simply forget checking things locally -- do you think it would help to set up a commit hook or do you have other ideas about we could help you not breaking the build?" So you 1) declare the facts (breaking the build too often), there's no argument about those 2) state your expectations as a manager (this has to stop), the person can disagree but it's your decision as a manager to set expectations 3) offer one or more possible interpretation, the person can agree or disagree 4) offer your help, the person can take it or not