Cascading messages effectively
It's not just shouting louder.
I needed to get a case-study on the web. Simple right?
I shot an email over to the team; “Hey, could you put this on the web and give me the URL please?”. I even remembered the attachment because I am a professional.
I went for a coffee, came back to a “Done” email with a URL. I went to check it, and voila I found the email I had originally sent up on the web and downloadable as an EML file.
EML? FML more like.
It’s easy to assume (and I did) that the person receiving the email is a muppet. However, now I see it as my problem. I didn’t communicate what needed to get done.
Information transmission
A (very) simplified view of leadership is that it’s “just” getting people aligned. You do some clever stuff and get a world beating strategy and then just tell people what to do.
The world beating strategy isn’t the hard bit; it’s the communication and alignment.
Information transmission is lossy. In my example the anaphoric this becomes something different in the minds of the receiver, now imagine trying to transmit a world-beating strategy!
You might think that the strategy is too complicated for mere employees. Perhaps they just need some instructions. Let’s see how that fares.
Chinese Whispers
Our goal is to give folks instructions. Let’s try that. The instructions are simple and cannot possibly be misinterpreted.
We need to reduce onboarding friction. Build a dashboard, add three onboarding emails, create an in-app checklist, run a webinar, and measure activation within 14 days.
Codex wrote some code to simulate this message being passed from C-level to VP Engineering, Director, Engineering Manager, Team Lead, and finally Engineer. At each level, the LLM is instructed to “preserve the work you believe matters most.”.
Each time it gets passed down there’s some embellishment / misunderstanding. Is onboarding referring to a user of the tool, or someone new joining the team?
Fictitious deadlines start to appear. One Team Lead decided that a prototype needed to be developed within 5 days. In another run, the dashboard needed to be launched in 7 days. Tech choices start to be made (Tableau? Google Data Studio?).
Here’s an example of the worst (my judgement) run.
1. Dashboard Development: Build a Tableau/Looker dashboard tracking completion rates (top 3) and user satisfaction – *primary metric*.
2. Email Sequence Design: Create three email sequences (role-specific & level-based) with clear CTAs and immediate value.
3. In-App Checklist Creation: Develop a user-friendly checklist focusing on core functionality – prioritize ease of completion.
4. Webinar Content & Logistics: Schedule and document a webinar showcasing best practices and the 80% completion threshold. Ensure accessibility.
5. Activation Tracking & Reporting Setup: Establish a measurable activation threshold (80% completion within 14 days) and implement automated tracking/reporting.
Essentially, we're moving from strategy to actionable steps. Let me know if you’d like me to elaborate on any of these points.
There’s no longer any mention of the reason we’re doing it (to reduce friction), just a series of instructions that are quite specific but lack context.
When you communicate by prescribing work, people can do the work whilst losing the judgement. It’ll sound aligned because people are saying “dashboard”, “email” and “14 days”, but when a trade-off appears the downstream folks lack the context. The instructions transmitted lost the intent.
Can we do better?
Radiating Intent
So let’s try transmitting intent instead of instructions. This time the message is:
Our goal is to help new users reach their first successful outcome faster. Success means more users achieve meaningful value within 14 days. We are willing to trade polish for speed, but not user trust. Do not optimise for feature completion; optimise for reduced confusion and faster time-to-value.
This not only communicates the “why” but it makes the trade-offs explicit. Each level of the hierarchy gets instructions to “preserve the objective, trade-offs and success criteria”. This does much better at preserving the intent.
Please prioritize optimizing the user journey itself, not specific outcomes or feature completion at this stage.
prioritize three areas for improvement... rank these based on potential impact and feasibility
Of course, intent can drift too. It’s not just as simple as passing this message altered down the chain. But it changes what you’re trying to preserve. Instead of hoping every noun survives the journey, you’re trying to preserve the decision-making logic. The downstream team may choose different work than you imagined, but if they understand the intent, they have a fighting chance of making the right trade-off.
But there’s a different danger here. When communicating intent and giving autonomy there’s an opportunity/risk that management may discover something different to what they had in their head is happening.
So, as ever, can we do better?
Back brief (the word is on the street)
Back-briefing is the extra loop where the receiver does not just pass the message on. They first explain what they think the intent is, what success means, what trade-offs matter, and what they are about to tell the next layer. The sender then gets a chance to say: yes, that preserves the intent, or no, you have distorted it, over-specified it, or missed the point. Think of it as ECC for cascading comms!
Here’s an example output.
Dramatically reduce the time-to-value experienced by new users, specifically focusing on minimizing confusion and accelerating their initial realization of meaningful value within 14 days.
Trade-off: speed over exhaustive feature completion, but not at the cost of user trust.
Immediate actions: journey mapping, baseline data collection, A/B testing framework, stakeholder alignment
The results were messier than the theory! Some runs became verbose. Some corrections introduced their own metrics and assumptions. But compared with plain instruction-passing, back-briefing repeatedly surfaced misunderstandings before they became the next layer’s starting point. The model had to name the objective, success criteria, and trade-offs before acting on them.
The most important thing - it changes the failure mode so that misunderstanding are surfaced earlier.
Conclusion
The engineering leadership lesson is not “write better instructions.” It is that instructions are a weak carrier for strategy. If you pass down a list of work, people will preserve the list even after the reason for the work has faded. Intent travels better, especially when it includes constraints like “do not optimize for feature completion.” But intent still needs an accountability loop. The back-brief is that loop.
This gives you a test; don’t ask “is everyone aligned?”. Ask folks to explain the goal back to you. What does success look like, and what trade-offs are they willing to make?
Good strategy should radiate intent, but good leadership checks what was received.