If you asked a bunch of leaders at any level, if they would like to know when their teams first know when work efforts start to miss their targets – I expect all hands would be raised. Similarly, if you asked any knowledge worker (at any level) if they would like more feedback from their boss, all hands would be raised.
From your perspective as a leader, you wonder why you don’t hear about problems until they are serious in nature. In a similar vein, strong professionals (at any level) wonder why they don’t get feedback until they have failed.
So why do these types of communication happen at a rate that is so low, from a practical matter it seems they don’t happen at all? If organizational excellence has a dependency on effective communication, helping teams be successful with project challenges, and improving team member performance — why is there a vacuum? More importantly, how do we fix it?
Leaders often strongly believe they promote early warnings of work efforts not proceeding as planned, but actually encourage the opposite.
Project warnings don’t happen
Scrum Masters and project leads want to let their leadership teams know when something isn’t working well and run into obstacles. Likewise, those leaders want to know. In fact, they ask for it – and sometimes demand it. However, many leaders unwittingly encourage teams not to advise them when the results aren’t matching the plan until it is too late to correct it. If you are a leader and you are thinking, “My team knows to tell me when projects aren’t going well” – actually, they probably don’t. Here is a simple exercise you can do right now to test. Without looking at your notes, try to recall the last few times your team told you something wasn’t quite as planned. As you are recalling situations where you were informed think about these questions. Was it challenging to resolve? Did it take a large effort to recover? Did you have to use your influence to get extra support from other areas? Were there impacts on other efforts? If the answer is yes to any of these – then you aren’t being informed early enough.
![](https://www.jasongoldfeder.com/wp-content/uploads/2022/04/Iterations-not-all-done-3.png)
There are many reasons this is happening. One common reason is what I call, ‘the fallacy of recovery’. This is where a team member with good intentions after falling a bit behind, plans to try and catch up in the next sprint. They want to fix it without raising any red flags or calling attention to the fact their committed vs completed efforts for that iteration didn’t align. If you as a leader unwittingly encourage this as a culture, it will happen at a larger level across several team members. As a result, this further compounds the issue and every day that passes makes recovery more and more challenging.
Considering they aren’t that far behind they believe they can recover by working extra hours, canceling vacation, calling in some help from others, or other common methods of recovering their work. As a whole, the team thinks they can just get more work done with the techniques above in the next sprint (or iteration) and catch up. Or worse, push it to the next program increment and stack up work even more. Look at the diagram on the left. You can see the iterations and a couple of stories or work efforts that didn’t quite get done. This isn’t terribly bad and seems fairly easy to recover. The team planned for extra work in the second two iterations but ultimately weren’t able to get them done.
![](https://www.jasongoldfeder.com/wp-content/uploads/2022/04/Iterations-not-all-done-second-pi.png)
The team sees the work planned vs the work completed and starts self-correcting. They just stack it up and do everything they can to get it done. The situation gets worse, not better. They are able to get more work done, but more often than not, the velocity of work done won’t be enough to complete the missed work and planned work during subsequent iterations.
That’s when the team raises the red flag and lets you know there is a problem. Recovery is a large effort. Leadership is engaged at a level of detail not desired by anyone but perhaps needed to recover. What you see on the right is a picture of what you see as a leader instead of the picture above. The team is now seriously behind, overworked for four iterations, and unable to recover on their own without significant help and major replanning for the next program increment.
Another common reason leaders don’t hear from their teams when projects are not progressing as planned is a bit more complex. I like to call this, ‘leadership instinctive over-correction. Leaders having many experiences like the one above, hear that a project is not on target — and prepare to engage. They know from experience that a significant correction will be required and their deep engagement will be required. Unfortunately, that experience elicits a common response – how do I engage and what do I need to do to help the team? Leaders who were promoted for their fantastic work as individual contributors may carry over habits that made them successful and miss-apply them as leaders by jumping in and saving the day. Less experienced leaders respond by blaming or ignoring the messenger. Another common response is telling the team not to bother them with trivial issues. All of these teach professionals at any level never to share bad news.
How do we fix this?
To summarize the issue, leaders often strongly believe they promote early warnings of work efforts not proceeding as planned, but actually encourage the opposite.
The resolution of this ineffective environment rests with leadership.
- Push the reset button
Just as in any change in process, you need to set expectations first. Share that you are looking for early warnings when things aren’t right. Provide positive feedback when you get early warnings and don’t engage unless asked. - Set the expectations
Tell the team how and what to share. Tell them to let you know they identify an issue or ‘”feel like something isn’t right”. Share an example and let them know you would much rather know when things aren’t quite right and then how you fixed it – than find out about it when it is too late. - Give the teams the method
Have the team share with you the size and scope of the issue, the frequency of updates until the situation improves, and whether or not any actions from you are requested. Ask for potential impacts on other efforts and options to recover that were discarded (just as important as the option they picked). - Close the loop
Thank the team and ask them if they need any help. If they say no, respect the answer. Let them own the outcomes. Don’t help behind the scenes or get involved because you want to add value. Your value is added by trusting the team and giving them confidence.