Management: Accept Feedback to Clear Your Blindspots

Pair of clouded eyes

I am working with an organization that has many teams that report up through a couple of layers of management. The teams happen to be contracted, though for other organizations I have not seen it make a difference. The management, particularly the higher level of this management, does not seek feedback for the decisions they make or that they are making.

If you are a manager, it is important for you to get feedback on the options you have for the decisions at hand. This will help you know if other options can be considered and to understand the impact of the decisions you are making. The amount and type of feedback you request is important. Without this feedback, you may be making decisions in the blind. When you make them without seeking feedback, you are missing information on whether your choices will have a positive or negative impact on the people doing the work.

Before we dive into an example, let’s look at a long-standing model of people and knowledge about interpersonal awareness. The model displayed below is called the Johari window. It was first presented in a paper in 1955, but was really fleshed out further in a book called Of Human Interaction by Joseph Luft in 1969.

The Johari Window*

There are things you and others know about you; this is the open area. You know some things about yourself, but others don’t. This is the hidden area. You can choose to disclose what you want. There are areas unknown to both you and others, this is the unknown area and shared discovery is how they become known. The important area for this post is the blind area. This is an area others can see about you; they know the information AND you don’t. The way you discover this is through feedback.

This feedback could be solicited (you ask for it) or unsolicited (you didn’t). I don’t recommend anyone give unsolicited feedback; it’s best to ask if someone is interested in receiving it.

As a manager, you need to be open to receiving and asking for feedback from others (yes including people that report to you) for several reasons:

  1. It models this behavior for others; if you would like people open to receiving feedback from you, then you need to lead by example.
  2. This is a mechanism in how you determine how well you are doing as a manager. Getting regular feedback, both formally and informally, from above, below, and your peers gives you a complete picture.
  3. This is also how you can find out if your decisions will impact others negatively. If these happen to be the people that report to you, it may reflect negatively on your performance. You can choose to learn about these negative impacts as you consider the options for decisions or after you made a decision and hear about it from a different path (like your boss or a customer).

I am going to run through a short example of why it is important to ask for feedback on decisions. This is an extremely simple example.

Imagine you have 20 or so teams that suddenly started going remote due to COVID-19. The week after everyone went remote you held an all-hands meeting of all your staff and contractors (so everyone involved in those 20 or so teams and then some) and you gave them some information about going remote and wanting to help create an environment of helping people work together.

It went well enough and so you decide you want have another at some point. 6 1/2 weeks pass and so you schedule the next one in the 3 days. Now remember, everyone reports to you. Teams scramble to accommodate this decree; it has really disrupted what they now have as work rhythms, something they had not acquired one week into going all remote. At that earlier point in time, it was much less of a disruption.

What may have happened if you had for some feedback on this plan from team members with interest in actually learning the impact? It most likely would have revealed it would interfere with planned work. Does this mean you should abandon the idea of having an all-hands? Not at all. What it does do though is open up considerations of when you could schedule it and how much lead-time would allow teams to fit this into their plans more readily.

This all-hands is a simple example. Is the negative impact unrecoverable? Not at all… But the signals it sends are probably worse. It signals that being present to listen to you as the ‘boss’ is more important than the actual work (which was free to being disrupted). This can lower morale. Given you have some layers of management between you and the teams, it also says it is OK for them to do the same. Hmmm… now this effect is multiplying. Most likely you were blind to these effects.

And depending on context how many other seemingly simple decisions are made without soliciting feedback on them before they are made?

Some will claim well ‘Inspect and Adapt’ that is the agile way… That may be true and I would also say that more important in this circumstance is building the project around a motivated team and supporting them. Sincerely reaching out for feedback on this decision (even if you still end up making the same decision) in itself helps reduce the deflated motivation.

* “The Johari window, a graphic model of interpersonal awareness”. Proceedings of the western training laboratory in group development, Joseph Luft, Harrington Ingraham, 1955

Using Economics to Encourage Testing Incrementally (or As You Go Along)

At TriAgile, I had an interesting conversation with a Product Owner. She described to me a problem where the testers could not keep up and their behaviors were actually holding them back. Let me describe her situation…

In her content development team, they had a couple of testers. They manually tested hyperlinks and other HTML/JavaScript/CSS elements towards the end of the iteration. While she would love to move to automated testing, there were some hurdles to get software approved for use, plus she had this whole behavioral mindset she needed to overcome. The testers on her team felt building and running tests incrementally as a developer completed work on acceptance criteria was wasteful. They preferred to do it after a story was completed by teh content developer; this then always put them being crunched. No matter how hard this Product Owner tried to convince them to do their testing as they go, they resisted. Her Scrum Master was also not providing any influence one way or the other.

As we discussed this at TriAgile, I finally settled on economics to help her understand the situation.

Suppose a content developer produced a defect that prevented a CSS library from working by using a faulty assumption (let’s say it was as simple as a misspelled directory in the URL). And let’s suppose this faulty assumption caused the error to be reproduced 10 times. And further, let’s say each time the person did this, it took them 10 minutes to implement each instance. Lastly, it took the tester 5 minutes to test EACH instance.  So let’s do some math. (All of the times are hypothetical; they could be longer or shorter.)

So first up, testing at the end: 10 x 10 minutes implementation + 10 x 5 minutes testing = 150 minutes. But wait, we now have to fix those errors. So presuming that great information got passed back to the developer and it only takes them 5 min to correct each instance, we need to add: 10 x 5 minutes fix time + 10 x 5 minutes retesting = 100 minutes.  So our total time to get to done is 150 + 100 = 250 minutes to implement, test, correct, and retest the work. Our Product Owner had actually said that this kind of error replication had happened multiple times.

OK, what would have happened if it happened incrementally? Well our implementation time is the same, but after the first implementation occurs it would go to get tested. If an error is found, it goes back to the content developer and having seen the error she or he was making, they can now avoid reproducing it. So the time would be something like this: 1 x 10 minutes implementation + 1 x 5 minutes testing = 15 min, then 1 reworked item x 5 min + 1 item retested x 5 min = 10 min, and finally 9 remaining items x 10 minutes implementation + 9 x 5 minutes testing = 130. Total time now is 160 min.

If the cost was $2/minute (assuming a $120/hour rate employee), you easily wasted

$250 – $160 or $90.

Now multiply this by however many teams are not testing as they go and how many times they have this happen.

Of course there could be items caught that are not recurring, but the fact of the matter is, every recurrence of an error that has to be backed out introduces a lot of waste into the system (defect waste for you Lean/Six Sigma types). Testing as you go and stopping ‘the line’ to prevent future defects from occurring saves money in the long run since labor time is what we are talking about.

In addition to this direct savings as calculated above, one ALSO has the queue time for each test that is awaiting to being tested before it can be OK-ed to produce value. In the first instance, this may be building up considerably, delaying production readiness. And suppose out of the 10 occurrences above, only 8 could be completed because we’re near the end of the iteration? Then we’re probably not going to get all of them tested and any fixes done in time. If we had been testing along the way, then if something didn’t get tested, we could talk with the Product Owner about releasing what was completed and successfully tested. Something of value is completed as opposed to deploying nothing. There is a real opportunity cost for this delay.

So there is something to be learned by each area with this. For the tester, testing completed work, even manually, incrementally keeps you from becoming a bottleneck to producing value. For the developer, giving developed items to the tester incrementally and getting feedback after each item allows you to correct along the way, possibly avoiding future errors. And for the business, having this occur incrementally actually reduces both the real and potential opportunity costs of the work.

TWEET Your Feedback


This post was prompted by Jurgen Appelo’s excellent post on giving a Feedback Wrap on Forbes.

I really like this post as it gives you an extremely useful way to express feedback in a manner that will help the receiver actually take action.  It also helps them become aware of future behaviors they may need to change.

Giving good feedback is important, whether it is to superiors, subordinates, or peers. Like Jurgen, I won’t claim to be perfect at doing this and more than once, I know I have provided useless and sometimes hurtful feedback. So to provide a bit of additonal advice as a wrapper around what Jurgen is recommending, I wanted to share an acronym I learned at Culture Camp DC 2012 from Chad Wolfsheimer of the Motley Fool.  The acronym is TWEET; here’s how it breaks down:

Take note of impact

This part is recognizing a meaning to the behavior you want to give feedback on; what is this behavior doing to you, others, a team, and/or the organization. If there isn’t any impact (or perhaps if it truly is trivial), then ask yourself is this feedback going to be useful?

Write down (organize thoughts)

Chad recommends writing down your thoughts, but he did offer up that due to the necessary timing you may not have this opportunity. None-the-less, take a mental step back and organize how you plan to present it; non-organized feedback will come across as a rambling complaint and not achieve what you want.  Using Jurgen’s Feedback Wrap technique is an excellent way to do this.


Before jumping and giving feedback, try to understand the context the other person may have. Empathy in this case is not only what they may be feeling emotionally, but also what their mental model may be on why they are exhibiting the behaviors they are. Trying to understand this may help give you insight into how to deliver it so that it is received well.

design it be Effective

Using the Feedback wrap as guidance to organizing it and any insights you may have gained through empathizing, think through how the delivery can be made effective.  After all, if the feedback is ignored or it spawns a defensive mechanism, it probably won’t likely alter the behavior you want changed.

Time it appropriately

We’ve heard how feedback should be timely; Chad recommends and I agree to think about timing. Often just after the behavior is exhibited is the right time, but at other times it may be worth making a determination as to the most appropriate time to deliver the feedback to maximize its reception.

On top of the two great ways to look at feedback that Jurgen and Chad have presented, I also recommend including inquiry.  Asking a few key questions can help you both empathize AND open up the recipient’s mind about the behavior you want to change. Be careful what questions you ask though; for example ‘Why’ questions may put the recipient on the defensive. Try and use open-ended questions as well as this prompts some thinking.  Here’s an example of a question that may work –

After you presented your critique of John’s database design, what did you notice about people’s reactions, and in particular John’s, to your statements?

If the person you are providing feedback hadn’t noticed anything, this question may prompt them to think through what may have been happening and help the recipient self-realize the impact. This makes your job much easier.

I’d avoid the following –

Did you notice how people felt dejected, and in particular John, after you critiqued his database design?

While that may be indeed what you noticed, it is your own mental model that produced that. Even if your recipient might come to the same conclusion, this closed question places her or him on the defensive and not in a place for self-reflection of their behaviors.

I hope you found this post useful, if you have any tips or tricks you use in giving feedback, feel free to leave a comment or tweet at me!