In the end, HOW you deliver feedback matters. Personally, I have three important characteristics for a feedback.

Point 1 : "Be Specific". I can not stress this enough. Please point out specific observable behaviour.

Point 2 : Frame feedback in terms of team/organisational goals. Every team has a purpose within the organisation. It's a team game and every team member should know the feedback in context of the team game. Individual feedback, team context.

Point 3 : Cite the past but look for future changes in behaviour. You can not change the past but you can influence the future.

For example, "Hey John! When you do X, it helps the team achieve Y. Please continue doing so!" or "Hey John! When you do Z, it lets the team down. What can you do differently?".

Completely agree that HOW matters so much!

To me and probably many others (albeit often subconsciously), point 3 comes across as blaming, overly-generalized, and lacking in personal (and group) accountability for your experiences.

What about something like,

"Hey John, the last time you did X, Y happened, which had Z consequences.

I felt { disappointed / let down / concerned / irritated / worried / angry / $whatever_emotions_came_up_for_YOU }.

Other team members reported feeling $emotions.

What was going on there for you?

How can I / we help you to avoid X in the future?

Do you have any ideas about what you could focus or work on in order for Y not to happen again?

Here are some specific requests I have for you in order to avoid this kind of thing in the future: $requests "

The edgy part about this for many people is taking ownership for their experience, we live in a society with a lot of deconditioning around this . Nobody else but you is responsible for how you feel. John didn't let you down, you had expectations about what he was going to do, and to your assessment, he didn't meet those expectations (that's also a reasonable thing to say, I think -- I would give more detail and context about specifically how those expectations weren't met). That you felt one way or another about this has nothing to do with John, and there's a lot of subtle and overt problems that can arise in a relationship when we attribute our experience to another person with our language.

I also mention that it sounds overly-generalized because saying "when you do X" has an implicit assumption that he will continue doing X in the future, and isn't really all that specific about why X has certain consequences - I think it's better to use specific situations in the past when X happened and to talk about what came up when that occurred. This is basically what I'm hearing you say in Point 2 :)

edit: fixed variables, wording

I used to see a therapist who told me to do that, and eventually I realized it was a bullshit idea and I should not be working on reframing my expectations of colleagues so I was OK with them actively lying about work, so I quit and it was fantastic.

You can try and change yourself to make things work, but it's not always the right or even healthy way to approach a problem.

The point isn't to lower your expectations, the point is acknowledge that the way you feel is under your control and it's up to you to do something about it. So if your coworkers let you down, they don't make you feel let down, your own expectations make you feel let down. How you fix that is your responsibility.

You can try and help your colleagues, you can rely on them less, or you can quit your job. Blaming your colleagues and making them responsible for your feelings means feeling shitty and feeling powerless to feel better.

> John didn't let you down, you had expectations about what he was going to do

This is where we disagree. John did let you down. It's OK to blame him. It's OK to be a normal person that reacts to other people's actions and not some kind of zen robot. And recognizing that someone else's behavior causes you to feel shitty doesn't make you powerless to change.

John did let you down, but he didn't make you feel let down. You can blame John for letting you down, but you can't blame John for you feeling let down.

You are responsible for your own emotions. Recognizing that doesn't make you a zen robot. You can still feel. But don't put those feelings on other people and make them responsible for making you feel the way you want to feel.

You can recognize patterns for your emotions, like "I get sad when people make fun of me", but that doesn't mean that you have to be sad when people make fun of you. Recognizing the distinction is what gives power to change.

And sure, there are limits. The feelings that arise when tortured for example are rooted in physiology and near unavoidable. But I suspect that John didn't let you down by waterboarding you.

Even Vulcans can't quite manage this level of emotional control. Complete personal responsibility for one's own emotions is a nice ideal, but humans are not stoic robots. People are responsible for their behavior and its effects.

To add on to this. Following these steps will often avoid the problem described by GP. If you can't find specific actions to praise, then there is a good chance the recipient will feel the praise is hollow.

What are good things to say, if one is to give feedback but cannot think of anything to praise?

But indeed can think of things the other person could do better / improve upon. (However, maybe only "criticizing" isn't so nice)

> Cite the past but look for future changes in behaviour.

I've heard this referred to as "feedforward" before (as opposed to feedback). Instead of saying "last time you did X, you made a mistake and should instead do Y" you phrase it "next time you do X, make sure to do Y". It's subtle, with the goal of avoiding defensiveness.

FWIW I strongly agree with this comment. I have painful experience from not doing each of these things at various times.

You should write a book for managers, and every page should just be this comment repeated for 200 pages.

> So "we need to work harder" for behind plan

That will just get me angry. If you screw up your commitments that’s on you. Own up to it and talk to your stakeholders. Don’t make me work harder for your mistakes.

Reminds me of the story of the pilot who is being nagged repeatedly to expedite descent by ATC. "Don't you have speed brakes?" says the ATCO with exasperation. "Yes" comes the reply "But those are for my mistakes not yours."

So you can never make mistakes in your commitments?

I do. Sometimes I work harder to compensate, some times I apologize. But then it’s my mistake so I can negotiate with myself.

Sometimes working harder is warranted. Some salesperson screwed up, and it’s not really possible to reneg the multi million dollar contract. “I’m sorry guys, what can we do?”

FWIW, as the manager I don't feel I own the commitment date, the team does. That process has a 'content' aspect to it as well in the form, "by this date, this content, by this later date this additional content". But I understand the angst against managers who "manage up" promising impossible dates and "blaming down" when the dates aren't met. I learned early on as an individual contributor that "getting it in writing" was essential to protect myself and personally vowed never to inflict that pain on anyone that works for me.

I think this works, but only in cases where two things are true:

- the team is actually responsible for the date—often, there's massive asymmetric pressure to aim for less time - if it's an actual deadline, the team has the autonomy to adjust scope to hit it

In my experience, the worst situations happen when estimates are treated like deadlines. An estimate has to have uncertainty. Without some way to manage uncertainty, you'd have to pad estimates out to like the 99th percentile to hit them consistently, but people read estimates as averages and push back against that. If teams are consistently going over estimates, it's a problem in how you do estimates, not how you're working. (Which is also why evaluating people's performance based on how well they hit estimates—which seems common on a lot of teams—is completely misguided. Estimating is a nice skill to have, but it matters far, far less than the quality of the work people actually do!)

On the other hand, a deadline is only a deadline if you're willing to adjust scope to hit it. If there is a real deadline and it looks like we might not hit it, the answer isn't "try to be more productive" (which is all that "work harder" actually means!). Instead, we should figure out how we can change what we're focusing on and what we're concretely building in order to still hit the underlying goal as well as possible with the time remaining. If we're working towards an estimate rather than a deadline, we might still adjust scope and focus, but the first step would be adjusting and sharing a new estimate.

But if the culture is that estimates are hard commitments and you can't adjust the scope or the timeline, the work environment is going to be absolutely miserable, people will get stressed out for no real reason and the quality of the work is going to suffer. People will do whatever it takes to technically achieve estimates, even if that means cutting corners everywhere, sweeping bugs under the carpet, not spending any time to iterate or improve on the system and indefinitely putting off engineering work that has a small cost now but gives a massive medium- to long-term benefit in productivity. A month or two into this process and you move towards a death march that burns everyone out and, on the time scale of months, accomplishes substantially less than a less aggressive approach would have.

I'm currently working with a team that has this problem to some extent—of course, the managers think of it as "accountability" and "a focus on delivery"—and in a bit over a year, they've built a codebase that already feels like a legacy mess, while accomplishing what would have been like eight months' worth of work with a better engineering approach. It's pretty frustrating to see and I'm trying to change things, but not sure whether I'm going about it effectively.

I don't disagree with you, but as you accurately infer this is a management problem not a team problem. When folks start becoming managers of managers this becomes a bigger focus of their job.

I see the whole "agile" movement as a response to this problem. In an effort to mitigate the "error bars" of an estimate a process that iterates over 2 week sprints allows for estimate corrections during development. It isn't obvious to everyone but this is just upping the sample rate on the estimation signal to get a better handle on the noise and thus the signal to noise ratio.

This comment ended up as a bit of a rant, on a topic where you have way more experience than I do. Sorry about that! At this point, I'm just using this as a chance to gather my own thoughts on the subject, and I figure I'll post it just in case I get some interesting responses.

-------------

Yeah, that's a great observation on Agile. Smaller but more accurate estimates + cheaper small course corrections.

The dual is that the rest of the organization needs to adapt too—good short-term estimates don't necessarily give you good long-term estimates! So we need loosely coupled, self-sufficient teams that don't depend on accurate estimates from other teams.

I've always hated formal Agile processes (especially Scrum) but I have to work with teams that use them, so I did a bunch of reading about it. The goals and even a lot of the concrete ideas behind it made a lot of sense! It's just that every single concrete instance of the process fell short. I've seen several concrete failure modes in practice:

1. Scrum-flavored micromanagement. People (not necessarily formal managers) use the process to dictate exactly what everyone else needs to work on at practically a daily granularity.

2. Siloing. People are incentivized to only work on "their" tasks—ad hoc collaboration with teammates, trying out speculative design ideas and experiments, figuring out better ways to do something, all get in the way of finishing your tickets, which makes you look flaky in inevitably awkward group meetings.

3. Loss of context. People see that the process helps the team switch priorities, so they switch focus every sprint. Couple this with micromanagement, and you get individuals moved around on wholly unrelated tasks. Too much context switching adds a lot of mental overhead and makes it much harder to build anything with a coherent design and vision (either from a product or from an engineering standpoint).

4. Performance mismeasurement. The whole process is supposed to help the team with estimates. Tracking metrics the process generates and treating them as a way to measure individual performance (whether formally, or just through peer pressure) doesn't work well and is awful for morale.

I haven't seen it, but I bet it is possible to have a Scrum process—or, more likely, something lighter like Kanban—that avoids these problems. But I believe that even idealized Agile processes put too much weight on consistency for its own sake. Making consistent incremental progress helps with estimates and, I suppose, makes the team somewhat easier to manage, but none of that matters nearly as much as, say, quality of work and impact!

Even if nothing from the Agile process makes it into formal performance evaluations, the ceremonies almost seem designed to create peer pressure around it. And that affects day-to-day job satisfaction a lot more than mere performance reviews. Although maybe this is another thing that goes away if you have high-trust teams that are legitimately self-organizing the way Agile is supposed to be... But I'm not sure even that would compensate for the pressure implicitly exerted by the structure of the process.

I bring this up because over-emphasizing consistency imposes a cost on people—individuals get a lot less flexibility in how they work, and end up feeling stress when they're less productive than normal. I tend to think an ideal environment should embrace inconsistency day-to-day and even week-to-week or month-to-month but that requires massive differences in culture. If a team pulls it off, the process starts mattering a lot less!

Yea, different personalities have different motivations. I find that if I receive positive feedback, it doesn't motivate me it only encourages me to take it easier. If I receive negative feedback, I will double down to fix the issue, but my morale will suffer.

What's most important is that the feedback is IMMEDIATE. Tell me after a presentation what I flubbed. Don't tell me after a quarter that my presentation skills are lacking.

> "this team is killing it" for ahead of plan

Why do you think telling your team this is useful? https://www.psychologytoday.com/us/blog/about-fathers/201202...

I'm not sure I understand the purpose of the linked article. There are a few important distinctions, most notably (from the article itself):

> "We praise drawings ... because we want our kids to continue to work hard, and to do good work... But what we really want to teach our children... is that they should do good work because of the satisfactions it provides."

While I understand how this could apply to children (if not necessarily agree), we don't manage teams to have fun, we do want to encourage them to do good work.

As for the wider question, if a team is doing really good work, why not give credit where it's due? I feel like not acknowledging when people are putting in extra effort is a great way to discourage them from doing that.

I think the case with children is the same as with adults. We don't raise children "to have fun". Some would say we raise children to have a meaningful life for the parent, and I would hope for the children as well, i.e. "to do good work" as you say.

Like others have said, effect of praise would be very specific to individuals, but some have said praise hasn't helped them much. It definitely has not helped me, so here is my reasoning as to why you should not praise a good team. For me, stop the praise, tell me how to be better, and show me you care about me improving, and care about me on a personal level. Yes, I know that when I work hard and give you good output, it helps company, I don't need people to tell me that I worked hard. I can see it (If your company prevents your employees from seeing the effect of their output, thats the problem, don't say praise is necessary. The boss should not try to be the feedback loop). The reverse pavlovian effect can kick in otherwise: If it doesn't come when I am working hard, I feel bad. Also, the boss does not control reality, so becoming my feedback loops is bad, because he can warp reality based on his perspective.

It looks like this is highly specific to individuals though, the above works for me.

> Like others have said, effect of praise would be very specific to individuals, but some have said praise hasn't helped them much.

My understanding is that they were mostly referring to "fake" / superfluous praise, which I too respond quite badly to. But I think there's a big range between that kind of praise and no praise at all. Personally for me (and my guess is that for many people), if no matter how hard I work that's never acknowledged and I always get suggestions for improvement, that would create frustration and a feeling of unreasonable expectations from the company.

I would assume all this is highly specific to environment, just as much as the individual. Have you worked in an environment where nobody cares whether you do a good job, and success and quality are not recognized? You start to define your own success, which may be very different from what the business actually needs.

Obviously, working in an environment where you are not appreciated would make you feel bad. If you think praise is going to make the difference for your employee between being appreciated and not, that is insulting.

Celebration is important. But praise is cheap. Maybe some managers think its okay to just say "great job" + more praise, and then implicitly say next piece of work please, but I don't think it is.

I find it useful to acknowledge when the team is performing beyond expectations. That has been in response to early feedback I received in management roles from team members that when they were putting in extra effort they didn't feel it was "seen" and so it demotivated them to put in extra effort.

Maybe your employees have been conditioned to expect praise when they work hard, and do not currently have the opportunity to develop their intrinsic motivation to do good work.

Just because drug addicts become needy without their supply, doesn't mean they should juice up. Analogously, just because people become demotivated due to lack praise (or other reasons), does not mean praise is necessary to boost their performance. It might just be a sign there is an unaddressed problem.

Why do you imply that Alfie Kohn's ideology is the only useful one?

Along these lines, it's worth reading The Culture Map by Erin Meyer. It gives some interesting insight into how different cultures approach management and decision making. I think it also applies when thinking about people from within the same culture to some extent.

“We need to work harder” is not the kind of manager I like. The best ones just set a great example and work harder and put in overtime themselves and the rest of the team are usually are sympathetic enough to follow.

Overtime shouldn't be the solution. Team member shouldn't be put into overtime by social pressure.

Overtime is a sign that the team is badly managed and/or understaffed.

Indeed, but that’s already the case if the manager goes around and says that we should work harder.

Pretty sure the best answer is to do both. You need to ask your teammates to help if it's really important.