Avoid these risk communication anti-patterns
Vol II 06/52: Ever wonder despite communicating risk every week to leaders, projects still slip and risk blindsides you? Look for these anti-patterns to improve your risk communication system.
All systems have patterns - good and bad.
As Systems Thinkers, Technical Program Managers are always looking for patterns within systems, processes, frameworks, projects, teams etc. Opportunities to make things better, more effective.
The most common approach to communicating risk is the traffic lights system.
🟢 Green - everything is on track.
🟡 Yellow - it is either a showstopper or nothing, we are unsure and worried.
🔴 Red - team is blocked until this is resolved.
Even something as simple as green, yellow, and red, there are patterns that make this simple system ineffective.
Every TPM must understand and look for these patterns to ensure teams are communicating risk effectively.
Let’s take a look at three Teams all marching to the same deadline reporting on multiple work streams:
Team A is reporting majority green no issue, a few yellows and reds.
Team B is majority reporting yellow with few greens and reds
Team C is reporting a mix of greens yellows and no red.
There are a few observations we can draw about these teams:
Team A seems confident in the work to be done; clearly they have a plan to get to the finish line baring some unknowns along the way.
Team B is dealing with a high amount of uncertainty. This could mean either the scope or path to ship is not well understood.
Team C seems to have a good balance of scope understood with team encountering uncertainty which is yet to be determined as risk.
If I was to ask you to assess the state of each team’s progress, Team A might seem like better off than B and C and C is doing better than B.
Let’s add another layer to these team’s risk reporting:
Team A has majority of their green workstreams landing on the same day, the deadline.
Team B has a good number of their yellow workstreams with dates and their reds as TBDs.
Team C has majority of their yellow items as TBD for deadline.
Ah, now this makes things more interesting:
Team A is a red flag. Something I learned from a phenomenal Apple Engineering Leader, this pattern always points to “Something is wrong here”. With everything landing on the same day can mean either the teams are just Hail Marying it to deadlines, they haven’t thought through dependencies properly and this may obfuscate true red level risk. This “greenwashing” effect points to a weak psychological safety and/or micromanagement issue where teams might be tempted to report things green when in effect they should be yellow or red because they are afraid or worried about voicing the truth.
Team B is very risk averse or “living on a prayer of hope”. I have encountered a number of these engineering leaders who would be overly cautious when it comes to communicating risk. Most often they are channeling their own anxiety of ambitious deadlines or high expectations from senior leadership even when their engineering teams are telling them things are going to be okay. On the flip, this team could be “we are not sure how we will solve this but we are confident we can figure this out and still hit the deadline but we are just making you aware.” A great example is resource gaps often being portrayed as “we will onboard more people and make up for lost time.” (Brooke’s Law).
Team C is trying not to “rock the boat”. Either because of previous experiences or leadership style, when engineering teams downplay certain risk (ex: no date to completion) for me it is always an indication of a past experience or culture of fear. Perhaps they pushed back on overly ambitious expectations from leadership and are burned out from reporting the craziness of the plan or a past project went super wrong and reporting red brought the wrath of leadership onto the teams.
So, how do we fix this situation? Here is how to break through these patterns:
Team A - Dig deeper into the dependencies and work streams to breakdown the work further. Report on more intermediate milestones to show better view of the progress.
Team B - Dig deep into the yellows and where there is truly no road blocks, move it to green. Emphasize and work with the engineering leader to set gates and heartbeat milestones to assess teams confidence level. When things truly look uncertain, go red. If teams have a plan, it doesn’t follow the Team A pattern, stay green.
Team C - Flip the TBDs to red and start digging into what is preventing teams from identifying dates or targets for the work. Begin reporting resolve by dates and communicate clear asks from leadership when you are blocked on decisions.
Risk communication is a key skill for Technical Program Managers. Aside from these anti-patterns, it is critical that there is a unified definition of what each of the colors mean.
You will be surprised how often we assume that there is some universal understanding of what these color represents; why not? after all, its as simple as red, yellow, and green but something considered red by one can be yellow for another while green for someone else.
Hope this helps.
Until next time 👋!
🏽🏼 Building Romes + Functionly
This is not a paid advertisement or sponsorship. Just an amazing collaboration that I am excited to share.
A while back, I wrote a series of posts on the different team topologies that I have encountered in the tech industry for Technical Program Management teams.
Well, the great folks over at Functionly loved my posts so much they turned my designs into ready to use org chart templates.
Functionly is the org building toolkit for every leader. Import employees, build detailed org charts, plan new hires and roles, analyze custom data and share with ease. Start for free - https://www.functionly.com/pricing
Check out their main template library page: https://www.functionly.com/org-chart-templates
Here are the direct links to the four org chart designs I shared in my post:
If you are looking to see how TPMs might fit into your organization, checkout Functionly’s ready to go templates for you to experiment and test out your org design ideas.
Enjoy 😉 !
🤔 How was this week’s newsletter?