Fake Feedback. Sad!

This is a transcript and translation of a lightning talk I gave at Agila Sverige 2017 (Swedish), somewhat adapted to written form.

This concludes my little blog series on feedback. The first part was I don’t have a problem – YOU have a problem: When feedback fails and the second part was Appreciation: Keeping the pain out of feedback.

A lonely man enters the stage. He looks sad but determined. He grabs a microphone and speaks.

Hi everyone! My name’s Joakim. I have a confession to make: I’m an addict.

Yeah, I’ve been using feedback for many years now. And pushing it out to other people, creating new feedback junkies.

Let me tell you a story to show how I went wrong with feedback.

Continue reading

Appreciation: Keeping the pain out of feedback

Not all feedback is made equal. First of all, most of it is probably more damaging than helpful and shouldn’t be doled out in the first place. Either the words are wrong. Or it’s coming from the wrong person. Or the relationship is not solid enough. Or just bad timing. Or it’s the wrong technique altogether. Much can go wrong.

In some situations, though, feedback is requested or needed so what to do? I think it’s easy to forget that feedback can be pleasant instead of painful.

A thought experiment

Let’s conduct a thought experiment[1]. Let’s assume you’re on my software team at the office. And let’s say I ask you to come with me to a meeting room because I’d like to give you some feedback. How does it feel as you rise from your desk to go with me? Uncomfortable? Tense? Scary? I bet that it’s not an altogether pleasant feeling.

Rewind. Now, instead, I ask you to come with me because I’d like to give you some appreciation. How does that feel in comparison? Warm? Exciting? Joyful? I bet it’s a pretty positive feeling.

The magnitude of difference between these two situations might be surprising. Because both are feedback. Appreciation is a kind of feedback, right?

This experiment tells us two things:

  1. Feedback of any kind is associated with lots of emotions. Feedback is personal and sensitive.
  2. When we hear the word “feedback” we almost always assume that it’s the  corrective (weakening) kind, e.g. criticism, we’re going to receive.

Types of feedback

In theory, many people know that there are two major kinds of feedback; reinforcing, (encouraging) feedback and weakening (correcting) feedback. People often refer to these as positive and negative feedback, respectively, but this terminology is imprecise and I’ll avoid it here.

Reinforcing feedback means either adding something people want, e.g. praise, appreciation, attention, money or points, or removing something people don’t want, e.g. pain killers or lifting oppressive rules.

Weakening feedback means either adding something people don’t want, i.e. punishment, e.g. criticism, mockery, verbal or physical abuse, or removing something people want, i.e. penalty, e.g. distancing, two minutes off the ice or denying a child dessert after dinner.

Funny enough, our minds often assume feedback is always of the latter kind. That we should be corrected because we’ve not been good.

And our brains are probably right! Johanna Rothman, agile thought leader, writes: “Remember that feedback is not always negative!”[2]. Even an experienced leader like Johanna has to remind us that feedback shouldn’t only be of the corrective kind.

Corrective feedback seems to dominate – probably in practice but definitely in our minds. This is very unfortunate.

The effectiveness of reinforcing vs weakening feedback

We often treat corrective and reinforcing feedback like two equally useful tools. They are both good tools, we say. Although, as we saw above, our minds really focus on the corrections.

This equality is wrong because corrective feedback is less effective in the long run, psychologically speaking. Here’s a model I learned from Jesper Bedinger, certified psychologist at Affärspsykologi Sthlm (see graph below).


Assume we have an observable behaviour in our staff we’d like to improve. Without any feedback, it would deteriorate over time (the black curve). If we focus on correcting (weakening) the behaviour it quickly improves a bit but then gets worse again (the red curve). We have to keep coming back and repeat the action. If we don’t act, the staff will fall back into the same behaviour again. Correcting people’s behaviour is a never-ending struggle.

Instead, if we reinforce when the behaviour is working, for example by taking notice of it or appreciating it, we’ll see more of that behaviour. It won’t happen by itself, but with a few, timely actions you may end up with a self-reinforcing loop, where the behaviour is its own reward. So, aside from being more pleasant to both give and receive, creating a more positive and creative workplace, reinforcing desired behaviours is more effective.

Another reason for preferring encouraging feedback over corrective is handed to us by the great systems thinker Russ Ackoff, who said:

“Removing what you don’t want doesn’t necessarily get you what you do want.”

You could end up having other behaviours that are even worse.

Getting started

How to get started? Here’s an example: You are peer reviewing source code from your less experienced team mate. As an experienced developer you have high standards on the type of code you write and want to see from your team. For example, you really want to see high cohesion in the functions; that they’re short and do just one thing. As you review your colleague’s work you notice that most functions are long and complicated – too long in your book. But instead of complaining about long functions and giving lectures on cohesion you find a few functions that you really like. In the review you express your liking of those functions and clearly explain what you like about them and why that matters to you. The next time you look at code from your team mate, what do you think has happened in the area of function length? My guess is that the method cohesion is much higher. This gives you an even better opportunity to appreciate the work. And so on. After a while, your team mate writes better code. That’s how it works!

Turn up the good
–– Woody Zuill

The next time you feel inclined to give feedback to someone, check to see if your opinion is really called for. And if it is, maybe the right thing to do is to find what’s good and appreciate that?

Or even better, why not start by thinking about what you really believe is valuable behaviour and start looking for those?

[1] Credit for this thought experiment goes to my colleague at Adaptiv, Måns Sandström
[2] Building a Team Through Feedback, Johanna Rothman (2012)

I don’t have a problem – YOU have a problem: When feedback fails


Have you ever given feedback to someone coming away with the feeling that it actually made things worse? It could be a matter of tool selection.

A friend of mine, let’s call him Michael, had the following experience some time ago in a regular standup meeting. During the standup, Michael noticed that there were a few features that were ready to deploy to customers, but nobody on the team took on the task. Michael got increasingly uneasy. Finally, before the meeting ended, he asked: “Have you noticed that there are a few features waiting to go out? So who will deploy those?” Nobody answered. Instead, one of the team members, Karen, sighed and rolled her eyes. Michael was lost for words. He felt confused, embarrassed and a bit insulted.

In this situation, many people would ignore what happened, hoping the situation will resolve itself. Sometimes it does, but often the resentment remains under the surface, leading to other symptoms, like unwillingness to help, passive aggressiveness, cynicism or similar dysfunctions. Better to attack the issue head on.

Continue reading

Modern Agile meets Design Thinking

This is a guest post by Sigrun Tallungs (@tallungs). The original was written in Swedish and published on this blog earlier. That post, in turn, was a response to my post on Modern Agile.

What I like about Modern Agile is that it shines a light on what really hurts today, beyond the traditional focus on pumping out software features. Modern Agile aims to understand how we create value. Here’s how: Someone has to love what we create (”Make people awesome”). And for us to succeed we need to feel safe and reduce the risks involved (”Make safety a prerequisite”). Since we cannot figure out in advance what people really need, the way to go is to carry out a great number of experiments. That’s is basically all Modern Agile is – but that’s a lot!

Since its birth, the agile movement has engaged software developers but relatively few others. To face the challenges of today we need to involve all parties in the business surrounding the service or service eco-system we are developing. It is the co-operation of all these people that needs to be agile.

Continue reading

Modern Agile möter Design Thinking

En gästkrönika av Sigrun Tallungs som en fortsättning på mitt tidigare inlägg om Modern Agile.

Det som jag gillar med Modern Agile är att det riktar strålkastarljuset på det som gör ont idag, det som ligger bortom funktionerna. Modern Agile siktar in sig på konsten att förstå hur vi skapar värde: Så här ungefär: Någon måste bli nöjd och glad av det vi bygger (”Make people awesome”) och för att lyckas måste vi alla vara trygga och minska riskerna (”Make safety a prerequisite”). Och eftersom vi inte kan räkna ut i förväg vad folk blir glada av så måste vi sjösätta väldigt många experiment. Det är egentligen allt innehåll i Modern Agile. Men det räcker ju å andra sidan långt.

Under de 15 senaste åren är det ju mest systemutvecklare som engagerat sig i att förbättra utvecklingsmetoderna. Men för att lösa de utmaningar vi har idag krävs fler kompetenser från alla delar av den verksamhet som finns runt en tjänst. Det är samarbetet mellan alla dessa som behöver vara var smidigt och agilt. Men frågan är hur man ska engagera de kompetenser som har för vana att jobba jämförelsevis traditionellt?

Continue reading

My Take on Modern Agile

The cover version

I’ve had some good experiences using the Modern Agile model for explaining agile thinking to people. For reasons laid out below I use a somewhat adjusted version of the model (words in italics have been altered from the original), like this:

  1. Make users successful
  2. Create a setting for great teamwork
  3. Deliver value continuously
  4. Experiment and learn rapidly

If you’re interested in why I feel that Modern Agile is important and why I have adjusted it for my own purposes, please read on.

Continue reading

Why You Should Avoid Using Projects in Software


Organizing work around projects does not fit any form of work that is creative, open-ended, and patterns-based, relying on human ingenuity and judgement to create value. This is most notable in research, creative jobs, and development in all its forms; be it organizational change, personal growth or software development.

Continue reading