Making Complex Topics Stick (Part 1: Content)

Updated: January 31, 2021 Updated: Strategy

When one of my colleagues read Cloud Strategy for the first time, he summed it up in one word: accessible. He commented that most books end up being shallow or dry, so he was positively surprised to find one that’s neither. Naturally, I was happy to hear that–after all I aim to share in-depth content (including containers, serverless, hybrid cloud architectures) packaged in an approachable and engaging read.

Architects have a tendency to go “meta” over time. I am certainly not immune to that, and for authors going meta translates into writing about how you write. So, besides writing accessible books I also want to write about what’s behind making complex technical topics (of which cloud computing certainly is one) neither dry nor shallow. I see a booklet titled “Presenting Like an Architect” on the (distant) horizon, but I’ll start with this blog post mini-series as a suitable form of procrastination from finishing Platform Strategy.

Presentation Styles

My team mates and I are seasoned IT leaders who routinely present complex topics to customers, which gives me a good sample space for effective presentation styles. Given my team mate’s diverse backgrounds, presentation styles also vary significantly, which reminds me of my base rule of presenting:

Present in a style that suits you, not some other person.

So, it’s not so much about having a wide stance and a deep voice (which interestingly does influence people), but more about amplifying what naturally works best for you. You’re not Steve Jobs, you’re yourself.

Storytelling – Hot or Not?

One aspect that positively stands out in our team’s presentations is storytelling. As experienced leaders (mostly former CIOs, CTOs, Chief Architects) we have a lot of good stories to tell. And those are the stories that customers want to hear: what did you do? what worked? what perhaps didn’t work? what did you do about it? Those are the insights that customers can’t get from the marketing brochures, but they can get them from seasoned IT leaders who have led major cloud transformations.

Stories do more than share experience—they also build credibility and evoke emotions. They make what you are sharing relatable. That’s why in my architect workshops I routinely encourage attendees to bring their statements to life with stories, for example by sharing concrete experiences. Perhaps you have “experience in scaling distributed systems” but your audience is more likely to be interested in how you got a system consisting of 30 different microservices to scale to 1000 requests per second.

However, while many sing the praises of storytelling, stories also have limitations. That great cloud migration story from 6 or 7 years ago might no longer be that relevant. AWS Lambda was barely released back then, multi-cloud was a non topic (yeah, the good-old-days…), and pre-trained-machine-learning-models-as-a-service were still mostly science fiction. Nothing in IT lives forever, not even stories.

Second, hearing a story might pique your interest but it might not give you enough information to understand whether or how what’s being shared applies to your situation. Perhaps additional circumstances influenced the outcome. Or maybe the organization in the story was just lucky.

As an architect or seasoned IT exec you therefore need more than just a story–movies tell a lot of stories but we don’t take away terribly much from them. That’s my pet peeve with many customer case studies, which seemingly have a customer go from zero (slow, expensive, intransparent, bogged by legacy) to hero (instant, elastic, low-cost) just with the apparent use of a single software product. Perhaps architects are not the key audience for those reports.

Stories are engaging but they don’t tell the audience whether what is being shared will work for them.

So, I started to realize that being a good storyteller isn’t sufficient when discussing complex topics like cloud migrations. And, as any good architect would do, I thought about a better framework.

The Ingredients of a Professional Presentation

Few things in professional IT are simple enough to be packaged into 3-step-recipes, but sometimes we get lucky. Over time I have come to realize that my successful presentations are often anchored in three key elements:

Sharing Actual Experiences

Whatever you share should be anchored in actual experiences. Real experiences make great starting points for customer conversations. That’s, for example, why all my colleagues in AWS’ Enterprise Strategy team have run actual cloud transformation. Likewise, few people annoy me more than my former colleague who was always eager to share “his deck” on how our company practiced engineering innovation without him ever having pushed a line of code. You might be able to fake it for a little while but your audience is bound to find out soon – the latest after they ask you one or two questions.

Mining Mental Models

Alas, your experiences don’t necessarily apply to your client’s situation. Mr. or Mrs. X certainly did lose 40 lbs just by following the late-night commercials miracle diet, but if you look closely, you’ll see a “results not typical” or “your actual mileage may vary” disclaimer at the bottom.

To save your clients from feeling like they’re watching late-night television, you need to evolve your stories into mental models or “mechanisms” as we like to call them at AWS. You can see a mental model as a generalization of a specific experience that describes why something happened. Such models will appeal to architects who tend to look for causality (see my related post). Perhaps your experience would only work in specific industries or organizations of certain sizes, or only if the IT operates in the cloud. A suitable mental model will include these aspects.

Packing a Punch

Last, your audience (hopefully) isn’t a bunch of robots. As human beings, they want to be engaged. In my architecture workshops I ask someone give a brief (1-2 min) presentation on a technical topic and then have a person from the audience repeat what was said. Both presenter and listener routinely were at awe about how low the retention was, even from someone who was actively and carefully listening. Now extrapolate that to a 30 or 40 minute talk - people might remember just a few bits and pieces.

So, to make your message sticky, you need to make it memorable. Packaging what you learned into a catchy slogan or a punchline increases the odds significantly. Punchy slogans like “Don’t Run Software You Didn’t Build” (a chapter in Cloud Strategy) or “If you carry your existing processes into the cloud, you’re unlikely to get a cloud. Instead you’re getting another data center.” have become a bit of my trademark.

The following table summarizes the three elements, nicely spiked with -ilities :-)

Time for a Pizza Break

That’s enough theory, so let’s look at a concrete example. Many people have heard the story of Amazon’s two-pizza teams, sometimes labeled as one of Amazon’s secrets of success. The essence of the message is that making smaller teams allows you to scale independently and maintain a high pace of innovation. This memorable story (who’d write about “not too big teams”?) is part of many slide decks and is routinely delivered chronologically, i.e. “one day we decided that teams should be no larger than what can be fed by two (large-size) pizzas”.

However, the story leaves an engaged audience with many questions: will two-pizza teams work in any company? How do I implement them? What else has to be in place for this to work well? Are there pitfalls? No better place than here than to inject my favorite words of wisdom from Barbara Minto’s Pyramid Principle:

The way to ensure total reader attention, therefore, is to refrain from raising any questions in the reader’s mind before you are ready to answer them.

This rule applies to presentations just as well. You can play with suspense a little bit, but your audience likely came to have their questions answered, so don’t overdo it–your talk isn’t a murder mystery. So, as presenter you’re liable to answer those questions. That’s best done by “diving deeper” into a mental model that explains what “two pizza” teams really look like and what they need to be effective.

I tend to add two main aspects:

Smaller Units Come in 3 Dimensions

First, I remind the audience that not just teams are smaller, but their deliverable and release cycles also:

1. Smaller teams (“2 pizza teams”)

2. Smaller deployment artifacts (“microservices”)

3. Shorter iterations (“agile sprints”)

So we can see that it’s not just about team sizes, but also about architecture and ways of working. Depending on the scope of the talk, you could also inject thoughts on team autonomy in here (as I have done in the chapter “Control is an Illusion” in The Software Architect Elevator), or delve deeper into microservices architectures.

The “model” doesn’t have to be visual but it can help make it more memorable:

Next, I often like to offset the apparently great idea with a common pitfall–after all architecture is the business of trade-offs:

Optimize Globally

Many organizations are used to optimizing locally – per system or per department. For them, making smaller pieces then runs the risk of optimizing those smaller pieces. This micro-optimization is bound to cause friction and also runs the risk of ignoring your customer, who can’t see all your little optimizations. That happens when you call customer service and they have to put you on hold to transfer you to another department (notice how I snuck a mini-story in here?). When slicing your IT (systems/people/schedules) into smaller pieces, you should therefore implement compensating mechanisms to achieve end-to-end optimization. This can be done via additional transparency (operational tools like CloudWatch, NewRelic, etc) and clear success metrics.

We can now understand the context in which smaller teams operate, what enables them (a cloud platform and high levels of automation), and what pitfalls to watch out for. These aspects go a long way in helping the audience assess whether and how the model can apply to them.

The Punchline

Last, I package the mental model of local vs. global optimization into a punchy slogan to make it memorable:

The sum of local optima is rarely or never a global optimum.

Testing Our Ingredients

To test that our three core elements of Experience, Mental Models, and Punchlines are valuable and necessary ingredients, let’s do what architects would do: delete a line of code and see if our automated tests pick it up. In our case this would mean omitting one or two of the elements. The results tell us that three legs make a much better stool than two:

• Just sharing experiences is entertaining but not necessarily insightful
• Focusing on mental models alone will make your talk academic and appear disconnected from reality
• Relying solely on clever slogans will make your audience wonder whether they are attending a stand-up comedy rather than a talk geared towards a C-level audience

As so often, the balance and linkage between all three elements is the magic sauce for a professional presentation that is credible, engaging, and memorable.

Aristotle Knew All This Long Ago

Before I get too proud of this simple framework, I have to reveal that it relates very closely to one of the oldest frameworks for effective communication. Aristotle’s Modes of Persuasion from some 2300 years ago also shares three core elements: ethos, logos, and pathos.

My three elements and Aristotle’s model match up in a relatively straightforward way:

So, have we found a long-winded way to determine that Aristotle was right? Not so much—rather, we reasoned about how to package complex technical topics so that they “stick” with the audience.

Delivery

After thinking about the ingredients of a good technical presentations, it’s time to do some cooking, i.e. describe how we use these techniques in the delivery of the presentation. We’ll cover that in the next post.

Make More Impact as an Architect

The Software Architect Elevator helps architects and IT professionals to take their role to the next level. By sharing the real-life journey of a chief architect, it shows how to influence organizations at the intersection of business and technology. Buy it on Amazon US, Amazon UK, Amazon Europe