How to Structure Your Presentation to be Clear and Convincing

Have you ever sat in a meeting where you felt bored?

You had to endure a presentation where the speaker read several paragraphs per slide, all in monotone.

Some rando in the room kept asking useless questions, prolonging the presentation.

You felt like you didn’t need to be there after the first 5 minutes.

This article is about how you can give awesome presentations, not awful ones. When you implement the tactics in this article, your will not feel like they want to leave. You’re going to learn how to craft an exceptional presentation that makes people remember you in a good way.

You’re going to learn how to engage the audience. You’ll learn how to make your message stick. And you’ll learn how to make your presentation clear and convincing.

Begin with the End in Mind

Ok, so you’re going to give a presentation. First, think about the why you’re giving this presentation.

  • Are you trying to get approval for an engineering design?
  • Are you gathering support from non-technical people for a new project?
  • Are you looking to get promoted or get a raise?
  • Are you speaking publicly, perhaps at a conference, and want to inform other engineers and increase your notoriety?
  • Are you pitching to investors for your startup?

Of course, you should also consider who your audience is. You’ll have different material for engineers at your company versus a general audience at a TED talk.

When you begin with the end in mind [1], you realize the stuff you can cut out. You see the people you need to invite (and the ones you don’t).

Sometimes, you might realize you don’t need a presentation or meeting at all. And that’s OK! Congratulations, you just saved your company $500.

No matter what your goal is, your job will be easier if you create a friendly environment. Give the audience a reason to listen to you, present your information clearly, and highlight how your ideas benefit them. Then they will be happy to make a decision that benefits everyone.

Your Main Message

Now that you have a goal, decide 1-3 main messages you want the audience to remember. The fewer, the better.

For example, imagine Steve is a software engineer responsible for his company’s iPhone app. He wants other engineers and UX designers to remember his app when creating new designs.

He decides on two main messages of his presentation:

  • “Design with iOS users in mind”
  • “Test end to end on an iOS device before launching”

As Steve crafts his presentation, the content will be focused around these two messages. He won’t spend time going off onto tangents, and he can remind others if their questions are sufficiently off-topic. As he repeats his messages, he also reminds the audience how these ideas will benefit everyone. Better designs, fewer problems, happier users–everyone wins.

By the way, if you’re doing a design review, it’s best to provide the design as a separate document and circulate it beforehand. If your slides are more like an essay, and all you do is read from them, skip the presentation and write a document instead.

Structure for Clarity

Now that you have your main messages, it’s time to design your presentation.

Most engineers use Google Slides, Microsoft PowerPoint, or another piece of software for creating slides.

Slides should be a complement to your presentation, not the focus.

You want the attention to be on you, not the screen. As soon as people concentrate on the screen, you lose their attention.

Less attention -> more dumb questions

Now that that’s out of the way, there’s no single right way to structure a presentation. One possibility is:

  • Intro
  • Section 1
  • Section 2
  • Section 3
  • Conclusion

Sounds pretty simple, right? “Chunking” your information into sections helps people remember it. Better than slapping some random info on your slides and meandering through your topic in no apparent order.

Another powerful structure follows a story. You can talk about a problem, and how your design solves it at each step, resulting in happy users. Just like the Hero’s Journey.

  • Intro
  • Background and problem begins (Act 1)
  • Problem gets more challenging (Act 2)
  • Solution (your awesome proposal, Act 2-3)
  • Conclusion

People love stories. Stories are memorable and give meaning to otherwise meaningless events.

If you structure your presentation like a story, make sure it has:

  • Characters (Engineers, customers, components of a system)
  • A challenge (a customer problem, a technical challenge)
  • A climax (how you solved or will solve the problem, often dramatic)
  • A resolution (how the characters improved after solving the problem)


The intro section should be short. Maybe 1-3 slides.

The first slide has the presentation’s title and your name. Super simple. You can create a crazy, memorable design, but that’s not necessary for more informal talks.

The next 1-2 slides are optional. They might have the objectives and key messages. But maybe not. Why?

If you’re goal is to persuade people, don’t explicitly state that. Your job is to create a friendly atmosphere where they can willingly understand your information. By showing them how they’ll benefit from your proposal, they will happily make the decision on their own. Your objective in this case is to provide information, and you can have a single-slide intro.

You can also do a longer intro where you provide background information about your topic. For Steve the software engineer, he might start with a few slides explaining how the company’s iOS app is used. Of course, that might be enough content for a longer section.

Main Sections

This is the meat of your presentation (sorry, vegans).

At the start of every section, you can optionally put a slide that has nothing except a title for the section. Sections don’t need to be formal, but you as the presenter know the key points you want to make in each part.

As you create your slides, keep hinting or explicitly stating your main messages. Use images to highlight key points. It’s OK to have slides that have 1 sentence on them. In fact, this is an excellent way to emphasize your main messages.

Make things easy to understand. I like to keep slides simple, almost minimalist. The clearer and concise you can be, the easier your info is to understand.

If you’re telling a story (or multiple stories), let your voice take the lead. Tie the story back to your main messages. Use your body to emphasize the story, and point to the slides as a supplement. The audience should not be reading the story. They should be listening to it, and watching it.

In the main sections, you can add things like AutoCAD drawings and flowcharts. Depending on your purpose and audience, you might go deeper into the technical details. Keep relating why your info matters to the audience.

When there are non-technical people in the room, try to take as little time as possible on the highly technical details. People in sales and marketing don’t care how you solved a problem. They care about the results. They care about why your solution will help get more customers. Talk about that and they will gladly listen.

For example, Steve the software engineer is talking to a group of UX designers. The UX designers don’t write code, but they do want to help create a great product. Steve takes screenshots of the app and puts them in the slides. Some slides have nothing but a screenshot. He talks about design problems that the team had, and briefly how he helped solved them. Steve uses the pictures and diagrams to answer questions. He avoids posting code snippets, since they wouldn’t help get his message across.

Also, make sure your graphs are easy to interpret. Good graphs make objectively show how fantastic you are. Bad ones confuse the audience.

Should I add jokes?

Humor is great! Get your audience in a good mood and they’ll like you more for it. They’ll pay more attention. They’ll remember your message.

People make decisions with their heart, then justify it with their brain. If you can get someone to like you, you can get them to agree with you. No matter how logical someone acts, they’re still human.

If you can add a joke into your presentation and it sounds natural, do it! Most (but not all) environments would welcome a little humor. Don’t worry about seeming immature.

And finally, don’t overdo your humor, and don’t force it. This is a presentation, not a standup routine.

Making Slides Not Suck

Creating slides is a topic worthy of a whole other article. The main idea is don’t distract the audience.

Remember what I said about slides earlier? Slides are a compliment to your presentation. Your physical body and voice should drive the meeting, not your slides.

First, put as few words as possible on each slide. One sentence per slide is enough. Have a bulleted list, and make it quick to scan. Eyes are drawn to text, and you don’t want the audience reading more than listening.

Second, use images. Images can be used to highlight key points. don’t use animated gifs, or anything that would be too distracting. Having 0 or 1 image per slide is usually enough.

Your slides don’t need to look perfect, but they should be easy to understand. Don’t clutter your slides with tons of information. Break your information into multiple slides. And like I said, try to get down to one sentence per slide.


In your conclusion, remind your audience about your main messages. This is a very short section–3 slides is usually enough.

Recap your main messages. Remind the audience how they can benefit by remembering your info or following your recommendation.

If you have a call to action, put it here. Include your contact information if necessary. Finally, open the meeting up for questions.


Additionally, you can add an appendix to your slides after the conclusion. This is where you would put material that would answer common questions following your main presentation. For example, Steve the software engineer might add a graph about customer behaviors.

You can also add material that doesn’t fit elsewhere the presentation.

As you create your slides, practice speaking your presentation and time yourself. Make sure you don’t go over your allotted time. Give your voice energy–don’t speak in monotone–and use hand gestures. I’ll say it one more time: slides are a compliment to your presentation, not the focus.

Putting effort into your presentation will make the audience much more engaged. Soon, you’ll be having people come up to you afterwards complimenting you on what a great presentation you gave.

To learn more secrets of giving awesome presentations, subscribe to the blog. Stay tuned for more articles about:

  • How to speak to keep their attention
  • How to make slides not suck
  • How to stay on track (and within your time limit)

If you see “You are following this blog” — great! You’re already subscribed.

Emily Williams helped inspire some of the material.

[1] For more on this idea, see Stephen Covey’s book, The 7 Habits of Highly Effective People

Posted in Uncategorized | Tagged , , | Leave a comment

Is Objective-C Still Relevant?

In the world of iOS development, Swift is on the rise. But what about Objective-C? Is ObjC still relevant? Are Objective-C fans clinging onto a band that broke up 20 years ago?

This next song is called TheVariableThatTookUpMoreCharactersThanTheLineLimit

My take: Objective-C is not going away anytime soon. But if you’re just starting iOS development, learn Swift.

Objective-C is so pervasive in iOS that it’s impossible to completely remove it. Apple continues to maintain libraries written in Objective-C, so we should expect Objective-C to be treated as a (mostly) first class language in iOS.

At other companies, legacy code remains. Some of Google’s iOS apps are completely written in Objective-C.

Further proof that there are still opportunities for diehard Objective-C fans: StackOverflow conducted a survey in February 2020. On average, Objective-C developers make more money than Swift developers ($64k vs $58k).

But for new apps, Swift is the future. I bet a Swift developer could outpace someone writing in Objective-C. Furthermore, features like SwiftUI are exclusively for the new kids.

If I was building an app from scratch, I would choose Swift.

Posted in Software | Tagged , , , | Leave a comment

How to Get Promoted as a Software Engineer (Even During Tough Times)

“Congratulations,” my manager smiled. “You’ve been promoted.” Despite the toughest job market since the Great Depression, coronavirus, working from home, two reorgs, and two different managers, I finally succeeded at getting a promotion (and a raise).

Many people assume, “I’ll work hard, keep my head down, and eventually The Company will recognize me.” Other people believe getting a raise is impossible. They blame anything and everything, repeat the same anecdotes, but never ask “What if I…?”.

When you work hard but get a 0% raise

I did not get promoted for working 80 hours a week or for being a yes-man. I was promoted for prioritizing the right projects and making them succeed.

I wish I had a nice little story that goes from point A to point B.  Instead, promo was a compilation of many behaviors and small accomplishments over the years. I hope that engineers can learn from my good behaviors, and senior engineers can correct me when I focused on the wrong thing. I recommend these behaviors in both easy times and tough times.

Standard disclaimer: don’t take my advice.

My Strategy

My promo journey began two years ago. Google has a rubric about the behaviors and accomplishments it expects from its engineers. I looked at the rubric and thought to myself, “What would it take for me to do those things at the next level, L5? And how do I prove that I did them?”

Every week, I had a 1:1 with my manager. I told him that I wanted to work towards promo. And every week, I would ask questions like:

What things should I keep doing?

What should I do differently?

How can I help the team?

How can I help you?

How can I help our product area in general?

What would it take to get to the next rating?

In other words, I was saying both directly and indirectly, “If I did X, would that give me a promotion/raise?” Then I got my manager’s commitment to proceed, and I aimed to make those things happen.

Make It Happen

I use the phrase make it happen deliberately.  It doesn’t have to be me that works on a specific project. Ramit Sethi says you have two options. “You can do it, or you can cause it to get done.”

For example, the Snapshot page has 65 engineers that have contributed a small amount of code. All their features need tests. Most did not have any. Over time, the bug list grew longer, and I realized we were driving down the road to disaster.

Since it’s infeasible for me to manually fix everyone’s bugs, I built a framework and provided guidance. I followed up by asking everyone to take responsibility for their own code (and their own tests). Thanks to the framework, the system began to scale without any single engineer being the bottleneck.

Sometimes, this “glue” work involved working outside my main codebase. Sometimes it meant non-coding tasks like documentation, attending meetings, and writing emails. A beginner programmer would think, “That’s not my job.” In contrast, I thought, “This is necessary for the ecosystem.”

With extreme ownership and a “make it happen” philosophy, I became an engineer that others trust to handle important projects. Managers love being able to hand off an important project and trust that the engineer independently makes progress.

In general, a good engineer can unblock themselves and get things done without needing constant micromanagement.

A good manager notices this behavior.

In case the manager doesn’t recognize this, a good engineer makes sure their manager understands the truthful difficulty and impact of their work.

Communication is a Superpower

I believe communication is a superpower. I can’t be the most knowledgeable person on every topic. But, if I could convince the smartest people in the room to be on my team, we would be unstoppable.

Not all superheroes wear capes.

Despite my start as an ordinary, computer-loving programmer, I became known as a strong communicator. If a project involved talking with many people outside the immediate team, I was the go-to guy. I felt surprised when my manager complimented me on my communication skills. I simply used Dale Carnegie’s “How To Win Friends And Influence People” to guide my interactions.

Thanks to Carnegie, I have good relationships with my colleagues. When we had disagreements, they were always resolved amicably. I made positive impressions on other teams. Instead of criticizing, I suggested ways they could improve. I aimed to make life easier for my client teams and I genuinely wanted them to succeed.

Finally, I put a 30-minute weekly block on my calendar.  I devoted that time to thinking about perf and the bigger picture. I compiled a little bit of evidence every week in the 6 months leading up to promo. When it was time to write performance reviews, I was ready to go.

The Outcome

I was not nervous when waiting for my promo result. The result was uncertain, but I had done everything necessary, and I did not worry about the outcome. Worst case, I apply again in six months with a stronger review packet–or even appeal immediately.

When my manager told me I was promoted, I felt more relief than excitement. I had planned to take a nice vacation after promo, but Coronavirus held off a big celebration.

But it’s a pandemic? What did you do differently?

Tough times make getting promoted harder. However, the core principles remain the same. Understand what your team and organization needs. Tell you manager what you plan to do (and confirm it’s the right path). Then hit a home run.

Who will your manager promote when budget is limited? The person that proves they have helped the organization.

If you continue to think about the bigger picture, remain a trustworthy person, bring projects to completion, and make the people around you happy, you’ll be a level above everyone who keeps their head down and wishes for a raise.

The Downside

One of the worst parts about working at Google is “perf driven development”. You can get rewarded for solving a problem, but it’s harder to prove that you prevented a problem from happening in the first place.  A focus on metrics means activities that are hard to measure won’t get rewarded.

In my case, I chose projects that would look better for perf. There were some cleanup tasks that I wanted to do, but they kept getting de-prioritized.

Additionally, I could have bit off more than I could chew. I learned an effective tactic to avoid overcommitting. When my manager asked me to take on a new task, I would check my notes and reply, “That will require me to push X to next week. Is that OK?” We understood prioritization. Not all work has the same urgency and importance.

Promo is Easy (For Some)

Another engineer didn’t think much about promo. One day, his manager asked, “Do you want to go up for promotion?”

Engineer: “No”

Manager: “You are doing valuable work. I think you should apply.”

Engineer: “Okay.”

A few weeks later, the engineer was promoted to the same level as me without doing much differently.

So who knows if my intentionality and focus were necessary.

Posted in Software | Tagged , , | 2 Comments

The One Meeting that Changed Our Relationship

Our program manager (PgM) was a stern lady. She kept the project on track, and as a deadline neared, she grew more and more serious. I worked on the iOS client, and I felt like she was ignoring me in favor of the Android developers.

One day, I was scheduled to meet our PgM in person, alone, for the first time. She worked on another continent, so I had only seen her through a conference room camera. I expected her to berate me for not keeping the iOS client up to spec with Android. They have five engineers, and I’m working alone on iOS! No reasonable person could expect the two clients to be the same. I felt a sense of dread as the meeting approached. 

When I found our PgM in the conference room, she jumped up and greeted me with a smile and a hug. Immediately, she complimented me on my amazing work on iOS while everyone was focused on Android. She quickly offered to help me fix the list of issues plaguing the iOS client and barely asked anything of me. In less than 30 minutes, we had a game plan for the upcoming launch. A surprise to be sure, but a welcome one!

Our PgM genuinely wanted both clients to succeed. We simply hadn’t communicated well until we had a face to face interaction. That afternoon, we solved the problem together as teammates, and we’ve had a good relationship to this day.

Posted in Psychology | Tagged , | Leave a comment

How do I make protocol methods optional in Objective-C?

Imagine you have a protocol in Obective-C.

@protocol ABCRocket

- (void)start;


What if you want to make some properties or methods optional? You can use the optional keyword.

@protocol ABCRocket

- (void)start; // Required


- (double)speed; // Optional


Not all objects to implement the protocol will have the -speed method. Trying to call -speed on those objects will crash the program, so we should check if the object implements -speed first.

if ([foo respondsToSelector:@selector(speed)]) {
      // Foo has the -speed method. Do something awesome!

It’s simple and easy.

Posted in Software | Tagged , | Leave a comment

A Quiz to Practice Big O for a Software Interview

Estimating big O is a crucial part of software engineering interviews. If you can write decent code, but can’t analyze big O, interviewers will mentally subtract points from your score.

Tips for analyzing Big O

  • Consider the worst case
  • Think about when n is very large. 2^n dwarfs O(n^2)
  • Drop constants (e.g. O(2n) -> O(n))

Quick Test

Here’s a quick test (answers at the bottom). For each question, write down the big O runtime of run(…).

Question 1

public int run(int[] input) {
  if (input.length < 1000) {
    return -1;
  for (i = 0; i < 1000; ++i) {
    input[i] = input[i] + 1;
  return 0;

Question 2

public void run(int[] input) {
  for (i = 0; i < input.length; ++i) {
    input[i] = input[i] + 1;

Question 3

public void run(int[] input) {
  for (i = 0; i < input.length; i += 2) {
    input[i] = input[i] + 2;

Question 4

public int run(int[][] input) {
  int sum = 0;
  for (i = 0; i < input.length; ++i) {
    for (j = 0; j < input[i].length; ++j) {
      sum += input[i][j];
  return sum;

Question 5

// Return a random number between 0 and m-1
public int random(int m); // O(1)

public int run(int[] input, int k) {
  int index = random(input.length);
  input[index] = input[0];
  if (k < 0) {
    return 1;
  return run(input, k - 1) + 1;

Question 6

// Return a random number between 0 and m-1
public int random(int m); // O(1)

public int run(int[] input) {
  return inner(input, input.length - 1);

public int inner(int[] input, int i) {
  int foo = random(10);
  input[i] += foo;
  if (i < 0) {
    return 1;
  return inner(input, i - 1) + inner(input, i - 2) + 1;

Question 7

// Return a random number between 0 and m-1
public int random(int m); // O(1)

public int run(int n) {
  int[] input = new int[n]; // Initialized to all 0s
  return inner(input, n - 1);

public int inner(int[] input, int i) {
  if (i < 0) {
    return 0;
  } else if (input[i] > 0) {
    return input[i];
  input[i] = random(10);
  return inner(input, i - 1) + inner(input, i - 2);

The answers are below this photo of young Alan Turing.

Photo of Alan Turing


  1. O(1). When n is large, the runtime is the same as when n is small (max 1000 iterations).
  2. O(n). Directly based on input.length
  3. O(n). Based on input.length. O(n/2) is equivalent to O(n)
  4. O(n^2). The outer loop is executed n times. What does each iteration of the outer loop do? It executes the inner loop n times.
  5. O(k). You could also say “O(n), where n is k”. The important thing is that the number of times the function is called is based on k. Executing one stack frame of run(…) is constant time.
  6. O(2^n). The runtime is like the number of nodes in a binary tree with n levels. The recursive function causes big O to grow exponentially. The branching factor is 2 because each stack frame calls inner(…) twice.
  7. O(n). input acts as a cache that limits the number of calls to inner(…). The recursive function only branches when input[i] <= 0. Therefore, the number of function calls is proportional to input’s length.

How many did you get right?

0-4 – I recommend brushing up on the basics of big O.

5-6 – You’re on a solid path. Keep practicing so you don’t trip up in an interview.

7 – Perfect score! Now’s the time to level up your practice with other data structures like trees and graphs.

Posted in Software | Tagged , | Leave a comment