Here are some suggestions for giving feedback that will help to anchor desirable behaviours and enable change in less desirable behaviours.

Give feedback in the second person

One purpose of feedback is to keep desirable behaviours and to change less desirable behaviours in the person you are feeding back on. Who is the correct audience for this information? Is it the manager of that person?
Using the third person isolates you from the person, and can encourage the use of generalisations.

Consider:

Gina worked very hard on this project. She always seemed to be at her desk long after everyone else had gone home.

versus:

Gina, you are very dedicated. I remember, one Friday, I got home and realised that I had left my keys on my desk. When I came back to the office to get them, you were still there. It must have been half past eight.

Which feedback would have the most effect on you? Why?

Anchor desirable behaviours in the present

When you are giving feedback on desirable behaviours, use the present tense. Specific examples can be given in the past tense.
For example:

David gave a great presentation to the board. The audience loved it and gave him a round of applause

David gave a great presentation? Was it a fluke? Can he do it again?

Consider this alternative:

David is a great communicator. His presentation to the board captivated the audience for the entire hour, and received a spontaneous round of applause.

David is a great communicator. The fact that he is implies that he will continue to be a great communicator.

Address it to David:

David, you are a great communicator. The presentation you gave to the board was amazing, the audience was captivated. You really deserved that round of applause.

Which feedback would have the most effect on you? Why?

Anchor less desirable behaviours in the past, suggest alternative behaviours

Giving feedback about undesirable behaviours is difficult. We want to get the message across without appearing to be overly cruel or negative.

Geoff thinks that he’s the only one who knows what’s going on. He always tells people how to do their jobs

How does the person giving the feedback know what Geoff thinks? Does Geoff always tell people how to do their jobs? How do you think that Geoff will respond to this feedback?

Give specific, past examples of the behaviour, suggest a way forward:

Last week, Geoff asked me to do the monthly report, and then told me how to do it. I felt as though he was questioning my competence. If Geoff wants me to do the report, he only needs to ask me.

How will Geoff react to this one?

Address it to Geoff:

Geoff, last week you asked me to do the monthly report, and then you told me how to do it. This upset me, as it felt like you were questioning my competence. I’m happy to do the report, you only need to ask me.

Which feedback do you think would have the most effect on the way Geoff interacts with the person giving the feedback?

Feedback on this post is valued and encouraged

My current understanding of feedback was gained from my interactions with other great coaches, including Liz Keogh, Antony Marcano, Rachel Davies and more.
A special mention goes to Chris Pollard for really opening my eyes to the value of language and well-formedness when giving feedback to elicit change.

Admittedly, you will get underway faster, but that’s going to be very little comfort when you come to a grinding halt a few miles down the road.

These checks require very little in the way of skill or time. We should do them at least once per day, and preferably before every journey.
I don’t do these checks as often as I should, mainly because they are not habit and forming habits (good or bad) takes time and discipline.
If we were taught these checks as the first part of our driving instruction, it would seem unnatural to not do these checks before every journey. This is called Primacy and states that what is learnt first (good or bad) is hard to unlearn.

When learning to fly gliders, one of the first things I learned was the pre-flight check. This has the mnemonic CB SIFT CBE. To ignore this check would require a significant effort on my part. Even if I have already been through another, more comprehensive checklist, I will still run through this basic test before starting a flight, no matter what the aircraft. This significantly increases my chance of discovering a problem while I am still safe on the ground. Better to be on the ground, wishing you were flying, than to be in the air, wishing you were on the ground.

I know that writing software test-first leads to a better design and gives me a safety net within which to refactor. I know this in the same way that I know that I should check my oil regularly, but this is not the way that I learned to program. I still sometimes start writing code before I write the tests and find myself wishing I was down there, writing the tests first. It’s a hard habit to break.

Like the POWER checks, writing code test first is not difficult, it doesn’t take much extra time, and it pays benefits when we uncover problems before they get too serious. Until we unlearn the habit of jumping straight into the driving seat, we need the discipline to do our checks before hand.
Right now, I’m going to write two sticky notes. One for my car steering wheel that reads “POWER” and one for my computer monitor that reads “Have you got a test for that?”.