> 1. Ask (“Can I give you some feedback?”)
> 2. State the behavior (“When you X…”)
Yes, please do this when giving feedback
> 3. State the impact (“…the result is Y.”)
Your conversation partner might hear an immediate accusation out of this. Your statement will never be objective. Rather talk about yourself as in "... this is how I perceive your behavior".
> 4. Encourage effective future behavior (“Keep it up!” for positive feedback ...)
Yes, it's great to get positively reinforced.
> “Can you change that?” for negative feedback
If you do this to me after 5 seconds of conversation, I will shut off and not take any advice from you. This is bossy.
Tell your conversation partner what their behavior makes you feel like. Formulate a wish for the future. You're not entitled to "change" people. Tell them how you would like to be treated.
If you want to change people, then give them positive reinforcement. If you try to "change" others by negative feedback, they will likely do less of everything and try not to be caught doing anything because it might be the "wrong thing".
> If you want to change people, then give them positive reinforcement. If you try to "change" others by negative feedback, they will likely do less of everything and try not to be caught doing anything because it might be the "wrong thing".
Which is why Manager Tools emphasizes that this form of feedback should be used first exclusive with /positive/ feedback for quite some time (months) before using the format for negative feedback. And that, once started, positive feedback should outweigh negative feedback 3-1.
I see this as a proxy for building trust with someone. Positive feedback tells me that I am appreciated by this person, and that they care enough to let me know. If I trust that someone cares about my needs, then I am less likely to hear "negative" feedback as blame, or doing the wrong thing.
You sound like you want to prolong the feedback into some sort of collaborative discussion, instead of getting to the point. Quick feedback is meant to be ... Quick ... To save both parties from too many negative feelings
You can’t end your feedback with “Can you change that?” and then think “Boom, done in seconds”. No, we’re absolutely not done? You just asked me to commit on the spot to something I potentially haven’t thought about before you just brought it up. I haven’t had a chance to reflect or even to respond. And you think we’re already boom, done?
Edit: If you want to actually be done, you could end with something like “I would appreciate if you were mindful of this going forwards”. Then you’ve said what you need to say, and your feedback stands by itself regardless of how the other person reacts to it.
I think what irks me about this question is that changing your behavior is one of the hardest things you can do, and there are probably all sorts of complex causes for the behavior. If you’re demanding an immediate commitment you probably get a lie in response. The behavior will continue, everyone involved will feel even worse about it, and it will feel more awkward the next time you have to bring it up.
I also find these very blunt - this is what I would say if the person I was exerting my authority and the person I was talking to really had no choice, but I was being polite about it.
I would soften them a lot if I wasn't in a position of authority, or if I wanted to genuinely engage with that person.
Also in any case, I would say precisely what it was about:
"Can I give you feedback about X?" so that it doesn't induce anxiety and the person has a realistic idea of what they are being asked before they decide,
and,
"[You're doing good work, and] it would be better if you did Y" to reiterate and reinforce the goal.
It has been a while since I read the book, do they give a reason for step 1? Because it feels like there is only one possible answer to that question, which makes it feel a weird to me now.
Yes: practically, it just might not be a good time, and emotionally, it prepares the person to accept the feedback. Less so in the book, but definitely on the podcast, they really emphasize that the question is genuine; if someone says no to the question, then you accept the no and move on.
They also emphasize that you should give /only/ positive feedback for quite some time before starting to give negative feedback. That would probably go a long way to soften things enough that one feels they can say no when appropriate.
(There's a whole set of things to do if the direct /always/ says no, of course)
"State the impact" is the part I have the hardest time with. My first impulse is to judge. When I try to phrase it as a feeling instead, I feel vulnerable doing so.
> "Your conversation partner might hear an immediate accusation out of this. Your statement will never be objective. Rather talk about yourself as in "... this is how I perceive your behavior"."
Feedback should almost always be based on data. For example, you should never say stuff like "When you do code reviews, you are often rude". This is, as you say, a perception. What you should be saying is: "When you do code reviews, people often come to me and complain that they feel offended." This is not a perception, this is data. Then you can say: "Please try changing your behavior so that people don't feel offended." At this point you can also start a conversation about why other people feel offended, but it is optional.
> If you do this to me after 5 seconds of conversation, I will shut off and not take any advice from you. This is bossy.
Feedback is not an advice. Sometimes it can contain advice, but more often it doesn't. Feedback is about telling you that you should change some behavior or it is about reinforcing a behavior. Advice is different: that's thinking about how to change or keep the behavior. Managers should absolutely differentiate between the two.
Advice is also optional, while in a workplace, if the subordinate doesn't meet expectations, there will be bad consequences.
> You're not entitled to "change" people. Tell them how you would like to be treated.
True. The manager is not entitled to change people, but 1) he is entitled to tell her subordinates what the expectations are 2) the subordinates are actually entitled to know what the expectations are. The manager should never say stuff like 'you are X', she should always talk about behavior ('you are doing X').
> Tell your conversation partner what their behavior makes you feel like.
I think you're applying the rules of non-violent communication incorrectly. There will always be negative feelings during negative feedback -- what's happening is that someone is told that what she has been doing in the past was not up to expectations. This is necessarily difficult. If it is not difficult, the receiving party likely didn't understand it, most likely because the manager has wrapped the feedback in a 'shit sandwich' (saying many good things and wrapping the hard things in the middle of them), most likely because the manager is not able to have difficult conversations. Difficult conversations are fine though: that's how we all learn and develop.
----
Example: I want someone to stop breaking unit tests by submitting code without running them locally. I can say that "You are often submitting code without running the test locally, for example in the last month you did this 5 times. Can you please stop doing that and not clog the CI servers unnecessarily by not running the test before opening a pull request?"
How would you do this with positive reinforcement? One option is to always pat the person on the back when she's not breaking the build, but that's an ineffective workaround, and I'd even say it's dishonest with the person.
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.
> 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
That way you force a serialization standard upon everyone. I'd rather force a formatting standard upon everyone and get the benefit of readable code with any tool e.g. also code reviews in version control. There's hardly a way to read code "the way I like it" in a webapp.
that's exactly what I mean by standard serialization format - format of code exchanged between people and programs. You can always rely on the standard way (for example the one presented here) when reading code on github or when you open it in your text editor by default, and then if you have another way you prefer that it be formatted, you can use a program to format it that way for you while you work on it - however when you commit it, it's formatted the standard way not your special way.
We've conflated how the code is stored with how it looks. We need to separate these. That's one of the problems with equating code with text: they're different things. Code is data (or objects), text is a way to represent code.
I don't know if they are totally separate. Say you like to see XMLHttpRequest and I like to see xml-http-request. If I type xml-http-request, how can a piece of software know how to translate that to XMLHttpRequest?
It's not just variable casing; it's any situation where one coding style distinguishes two things which look the same in another coding style. And I think there's a lot of such cases.
I find these terms strange. I have to pay for the high resolution and SVG but still have to check for right violations.
For a payment of 5$ (compare stock photo prices), I expect the right to use it
He's obviously concerned about being sued by, for example, McDonald's because you made and used a logo having golden arches in the shape of an "M" with on a red background with text "McDonald's" at the bottom. There's no way he can detect or prevent every such possibility.
If you pay to use Illustrator, that doesn't automatically ensure that anything you create using Illustrator doesn't infringe on another's trademark. Stock photos are different because they are generally rights cleared (depending on the license you purchase.) This isn't a stock logo repository, this is a construction kit.
A different from a picture, since it may have been trademarked. At least in theory, a picture is free from copyright violation claims if it's been taken independently, but a trademark may be violated even if the logo was independently generated.
At least, that's my understanding of the relevant law (IANAL).
I couldn't see a purchase option was it present? I had the feeling it was in the terms in case he decided to do it later.
The image element resource licenses are listed in the Resources section. Most of them appear to be relatively permissive licenses though some require attribution.
I get the impression it's a nice little side project, and mostly for fun. I guess he didn't what to go to the expense of purchasing licensing rights for stock images or searching out high quality resources which are in the public domain.
The most valuable feature from rebase to me is, that the one who commits to a feature branch, also "merges" the branch to the current master. So right after you finish your work on a branch, you can rebase even before having it reviewed by another person. When it's good to go, the actual merge is fast-forward.
That's exactly it. In one sense, it's just a better, less annoying form of merging. You get to sequence your commits on top of the current upstream (literally re-basing) without a merge commit that makes little sense in context. Then the ff-merge to master is also clean. I don't understand why anyone would be against this.
It's not that anyone is against it when it's possible to do it cleanly. But there are cases when that isn't true. Sometimes the branch is not ephemeral, so rewriting it becomes messy and risky.
I frequently find myself fixing or extending some open source project that my own systems depend on. Usually upstream will eventually take the patch, sometimes they might not. But I can't wait around to find out -- my own "master" branch gets deployed and lives a life of its own.
When upstream does get around the merging the changes, and I pull from upstream, the merge is 100% safe and clean because git sees my own commits coming back again. But if instead the changes were rebased, the chain of history is broken and git needs to go into conflict resolution mode. If I've changed other things since, I get a mess.
All of this gets even worse if you have things like continuous integration servers and git-based deploys. Those systems will happily deal with merges and break when you go and rebase a branch they've already seen.
Actually, I think the article's point was that big feature branches should be merged --no-ff so that they would not be a fast forward commit. That way you can whack them out of master easily if needed. You can still rebase right before the merge -- I would.
