Don't be afraid to provide detail when communicating to leaders
In the desire to lift things up to a high enough level for executives the temptation can be to aggregate up all detail. Here's where that can go wrong.
As I shared in Don't "bucket" work together when planning and, as any person who works with data can tell you, aggregation can be a problem.
Categorising and classifying information is part of the sense-making process but also when used in communication can end up hiding important information that is essential for decision-making.
Aggregation in a data context describes summarising all of the items within a given classification, often by summing or averaging or other summarising mathematical function.
In this context, I am more liberally using aggregation to describe grouping up of similar information under a single category - for instance to make a point about there being a need for a significant amount of security investment someone might group up all of the security initiatives under the single banner of security.
The problem from a decision-making perspective could be that there’s a range of important and unimportant information grouped together. There might be some details such as specific risks or important controls which needs to actioned urgently which might be best communicated on their own, not hidden away behind a category or hidden in an appendix slide.
A common misconception of communicating effectively to senior leadership is that there is no patience for detail. That misconception likely can be blamed on leaders, most who at some point have probably made a throwaway comment about the amount of detail being presented to them. Its hard to blame people for thinking after such chiding ‘well I won’t do that again’.
Leaders also often provide terrible examples themselves so we shouldn’t really expect anything different. For example the obsession of grouping up seemingly everything into 4-5 ‘pillars’. Leaders love pillars and exchange them like baseball cards. “Here’s my 5 pillars for our Marketing Strategy”
“Oh great Bob, here’s my 5 pillars for this year’s Tech Strategy”
Bob help us.
What this all often results in, in an attempt to remove detail, is the grouping up of similar information into more coarse categories, i.e. aggregation. This can be appropriate in some scenarios, so this is not to say never do it, just be intention about when. For instance, it maybe adequate for describing trends within groups of people or collections of companies. These might be good use of aggregation.
For other decision-making it will be the details which communicate the imperative for a given decision. I love security examples because the stakes can often be easily articulated. For instance there maybe controls which maybe important for mitigating a possible avenue for attack. What might be at risk and what could be compromised and some perspective on the likelihood of that being exploited maybe pertinent details for the urgency might be critical to ensure this is a decision made now rather than later along with the many other maybe less critical items it was grouped with.
Details of the specific experiences of users of your software maybe also compelling when shared as a story of the degree of human impact specific issues are having. Detailed statistics that help quantify that further (a good use of aggregates, mind you) to help communicate the scale of that humanised issue.
Like with anything, there’s no one-size-fits all rule that addresses all cases. The art is in selecting what details are important and when some aggregation is adequate. Its about applying judgement and thinking about what the audience needs to know to help them see what you see.
Have you seen examples where information that is useful for a decision to be made is been neatly tucked away in a less useful aggregate? What are some examples?