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.

Feedback that fails

Other people, like Michael, reach for the only tool they know: Feedback. So he called a meeting with Karen to go over the situation and ask her to change her behaviour. He was determined to follow a well-known model of how to give feedback. He did everything by the book. Still, the following happened.

Michael: Can I give you some feedback?
Karen: Em… why? (suspicious)
Michael: Well, to help you improve.
Karen: OK…
Michael: This morning, when I asked who would take on the deploy task I saw you sigh and roll you eyes. It made me feel stupid and embarrassed.
Karen: Well, what do you expect if you disrespect us – the whole team?
Michael: What do you mean?
Karen: We’ve been deploying almost daily for 4 months. We are doing fine. I find that question insulting, to be honest.
Michael: Insulting!? It’s a normal question…

And so on. There is a high probability that this talk won’t end as Michael had hoped. He hasn’t reached Karen and he hasn’t improved their relationship. Quite the opposite.

What’s the obstacle here? What is Michael not seeing? My answer would be that he’s using the wrong tool. He’s using feedback to Karen when they actually have a relationship problem.

The key here for me is that it would have been equally plausible should Karen have booked the feedback meeting, where she might have said something like: “When you asked us who would deploy today at the standup, I felt you didn’t trust us and respect us enough to handle that ourselves.” That’s also quite reasonable. That we have two reasonable perspectives indicates that it’s not so clear-cut and one-sided that Michael wants to believe.

You don’t solve relationship issues with feedback.

Let’s be clear, you don’t solve relationship issues with feedback. Trust me, I’ve tried (just ask my wife).

Instead, you need to work out this issue together by talking about it. One way to do that is to have a relationship talk, a technique I learned at Tuff Leadership. In a relationship talk the objective is not to modify someone’s behaviour. The goal is simply to improve, or clean up, the relationship.

Having a relationship talk

First, instead of putting yourself above the person you think behaved badly, thinking (s)he needs correction, put yourself in his or her shoes. Try to figure out why the person behaved that way. What really happened in that situation? What did you say? Also, try to understand your own triggers, small things that you overreact about.

When you meet, talk to the other person like a grown-up colleague – even if you’re the manager. Start by asking if that person would be OK with talking about the event that is currently interfering. If (s)he says yes, you proceed by asking for their take on the matter. It’s important that you let the other person speak first.

When that person gives their perspective you listen actively, to understand. Make sure that person feels heard. Ask clarifying questions if you don’t understand. Paraphrase (say with your own words) what s(he) says to validate your understanding. Summarise.

When the other person has finished and you have heard and understood their point of view, you probably feel differently about the topic. And if you did your listening well, the other person feels much more calm and open. S(he) may now wonder about your perspective. Why did you get so worked up about that deploy task? Perhaps s(he) will even apologise for making you feel stupid, who knows?

Here’s the same issue we had before, but as a relationship talk.

Michael: This morning, at the standup, I noticed that nobody would take on deployment, so I thought I could help by asking who would do it. Then I heard an audible sigh from you and I think I also saw you rolling your eyes. I would like to understand what was going on. Can you help me?
Karen: Yeah, I suspected that. It was just that when you asked us who would deploy today, I felt you didn’t trust us and respect us enough to handle it. We’ve been doing this fine for four months now. Why wouldn’t we handle it this time?
Michael: Ah, so you felt I didn’t trust you? Hm, maybe even that I was policing you a bit?
Karen: Yeah, exactly! As our team coach you shouldn’t control our working process. You should guide us towards improving it.
Michael: OK, got it. Go on.

Karen: Listen, I’m sorry I made you feel stupid. I guess I overreacted a bit to your question. I think I’m a bit sensitive to criticism around the team, after all that happened last spring.
Michael: Thanks, that’s OK. And I’m sorry I was so controlling.
Karen: Cool. I’m curious, why did you feel the need to ask?
Michael: Thanks for asking. Do you remember that training we had last week about not starting new tasks before finishing the current ones? About keeping work in progress low? I think I felt I must have been utterly rubbish as a trainer…

This is not feedback. This is just having a candid conversation in a non-threatening way. After this kind of talk, the relationship is often even better than it was before the drama started. Also, it can often provide insights into how the two of you work. Perhaps you can now, in collaboration, find a way to deal with or even take advantage of your differences? The talk just turned into learning.

Summing up, before giving feedback to someone, think about whether a relationship talk would serve you better. Using feedback when there’s a relationship problem simply doesn’t work.

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.

Unfortunately, the Agile Manifesto doesn’t really speak to people outside software. It was and is still an amazing story. A call to action that gave birth to a movement that changed the whole software industry. But as a platform for today it needs to be extended. Modern Agile is a good initiative that has gained recognition over the last year.

In his blog post My Take on Modern Agile, Joakim Manding Holm challenges the two vertically positioned sections of the Modern Agile model, i.e. ”Make people awesome” and ”Make safety a prerequisite”. The sections I want to discuss are the other two: ”Experiment and learn rapidly” and ”Deliver value continuously”. I view them as two sides of the same. The one goes with the other. When launching a service two things happen: 1. you get value, and 2. you learn a lot. Or you fail – and surely there’s valuable learning in that too.

What I feel is missing is an important element from Design Thinking movement: Empathy. This principle means going out into the real world to gain understanding of the problem space before narrowing on a solution. Walking in the users’ shoes. It’s about continuous learning that fuels the array of experiments we want to make so that we can view the services we create in use and learn from what we see.

Or the same thought put in other wording: Discovery and Delivery.  ”Discovery” (to study a problem space) and ”Delivery” (to make a change). Together these make up a continuous organisational learning circle, well-known amongst those who are studying how organisations evolve effectively.


In my opinion Design Thinking offers some of the most important thinking we need to include in the agile movement of today. But please watch out! Design Thinking is often misinterpreted as a concept. It is often presented as something that only highly specialised design agencies can do. That’s not true, quite the opposite. Everyone involved in development and every kind of development gains from the views of Design Thinking. Design Thinking is about how we as human beings act when we create something that did not exist before (at least not in that form and in that context). It’s design in the broadest sense of the word.

So, in my version of Modern Agile, I would let the insights of Design Thinking complete the circle in some way. I believe the discovery/empathise part is too weak in Modern Agile as it is now. We could adopt into the agile movement what we have learned in other fields today.

To conclude, I think Modern Agile is a very interesting approach and hope it is a start on something that will grow and mature to an expanding community. Maybe in the future, the agile movement can join the user experience movement and others and learn how we can make users awesome in a safe way, via empathy and experiments. In my eyes, this would indeed be a good future.

I’d love to hear your thoughts on this. Do you also like Modern Agile? Do you think the empathise/discover parts should be strengthened?

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?

Det duger liksom inte att komma med Agila manifestet till de grupperna. Agila manifestet är fantastisk story om hur en hel rörelse växte fram och förändrade branschen. Men som plattform tror jag den behöver kompletteras. Modern Agile är ett bra försök, som blivit rätt uppmärksammat sen ett år tillbaka.

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

When the manager’s out, the coaches dance on the table

I work as a software consultant and often in the role of a so-called “team coach” or “agile coach”. That’s basically just a hyped-up term for helping teams and departments to improve, to be more effective, and guide them on their way amongst a myriad of options. So coaching is great and many coaches I know are great, but there’s something bothering me. My opinion is that much of what I do is a kind of management – not of the people but of the work, and I’m getting more and more concerned about this. Should this really be the coach’s job?

Continue reading

Why CEOs Behave Like Cowards

“The times they are a-changin'”, as Bob Dylan put it and that’s more true than ever today. Software is eating the world. Every firm is a software company now, whether they understand it or not. We’re in what Steve Denning calls the creative economy, driven by customers with an infinite amount of information at their disposal.

In these times of upheaval you might guess that many companies are going through major internal reflection and restructuring. The general answer is sadly, no. Many companies are still by-and-large acting like product pushers to the ignorant masses. Almost every traditional company is still leaning on tenets of management created in the 1800s. Radical changes are far and few apart. As a result of this fundamental inability to adapt, the life expectancy of firms have dropped significantly, now less than fifteen years and declining rapidly (Fortune 500 companies).

I think it’s fair to say that many existing organisations are in desperate need for major redesign, not just structurally but dynamically, how they work to create value. Nothing happens. It seems to me that CEOs opt for a safe tactic, maintaining the system instead of fundamentally changing it. CEOs are playing not to lose instead of playing to win.

Now this made me curious. I mean, why is that? I mean, are they idiots or just incompetent? Hardly. Perhaps some other forces are at play?

Continue reading