Communicate Using Three Layers of Information

I've joked about writing Buzzfeed-style clickbait titles for JIRA tickets:

Partly, clickbait titles give me an easy way to search the database, or type a few words in my browser bar, to pull up the right issue quickly. The JIRA ticket itself had steps to reproduce, an explanation of why it was important, and an annotated screenshot for people to understand when they got to the same place I had.

Partly, it gives us a convenient shorthand to help us remember whether it's this log out issue or some other one that we're talking about.

Partly, this makes the developers interested to investigate and pick up the issue.

It was only later that I learned that people have described these three parts (title, description, details) in the same way in lots of places:

Lure, context, and detail

Giles Turnbull describes creating different layers of information as lure, context, and detail in The agile comms handbook. This whole (short and great) book is about how to communicate in ways that move as fast as the work does on an Agile team while still being effective for busy people to consume. Lure grabs the attention of busy people and gets them interested in knowing more. Context gets people to the point where they know just enough. Detail is for people who need to know more and have the time to follow a link to another page, read a whole PDF, etc.

Why, how, what

Simon Sinek describes it as why, how, what in this TED Talk on "How great leaders inspire action". He gives the example of an advertisement for Apple, where starting with the why is much more inspiring and motivating than starting with the what. Getting people to buy into your vision will ensure that they follow along to the goal.

Title, executive summary, and list of issues

When we worked together, Martin Hynie taught me to write weekly test reports with a title, executive summary, and list of issues, with the idea that the executive summary should be enough for the busy person to understand, but that less busy and more curious people would want the detail in the list of issues.

Intent, location, details

Maaret Pyhäjärvi describes the ensemble (mob) programming practice of communicating at the highest level of abstraction (intent) before being more specific about where we're going (location) or if necessary, mouse clicks and keystrokes (details). Giving keystrokes and mouse clicks to someone who knows how to operate the software is frustrating, but so is giving a high-level explanation to someone who's never used the software before. Expressing intent first can lead to better action, even if another member of the ensemble has a different action in mind than you do. Being able to identify when to jump between the levels is key for effective communication, and the skill I think is hardest to build while learning to ensemble.

Title, lede, and body

In the content management system I tested for New York Public Radio, article pages were broken down into title, lede, and body, presumably reflecting something every journalist learns on their first day at a newspaper. On the website, title and lede were displayed on the homepage and tag pages. You'd only see the body once you clicked in to read the article.

I read so many JIRA tickets and Slack messages that only contain the lowest/detail level of information. Teams do need that detail, and that's often where a team member's mind is when they're trying to explain the issue. Giles Turnbull identifies why this is the default: that detail layer of information already exists. Creating the others layers takes more work.

But being able to zoom out and answer the kinds of questions you'd expect in a refinement meeting ("Who will benefit from this? How does it work now and why does it need to change?") is just as important a part of this communication. It helps you prioritize the work. It helps the team understand how what they're doing fits into the bigger picture. Trust your people to click into a Slack thread or open an attachment.

Learning how to write the lure and the context is a separate technical skill that needs to be recognized and built. I practice writing this blog in (hopefully, often) this style: a title that gives you a clue what I'm talking about, headers that give you enough to takeaway if that's all you read, and words in sentences for the rest.

How did you learn to break down your communication into different layers? Which of these breakdowns resonates most with you? Where are you practicing communicating this way?