As a software engineer, the time will come when you’ll eventually be expected to present something you’ve worked on. You might be asked to write a blog post or a white paper, or you may be asked to give a talk either internally or publicly. In either case, the goal isn’t just to present information, it’s to craft a compelling story around the work you’re presenting. 

Luckily, you can use the same framework regardless of the presentation medium. Like any good story, technical presentations entail an introduction, a body, and a conclusion. However, there is specific information to include in each section that helps keep the audience engaged.

The introduction: Describe the problem

Whether you are writing or speaking, your challenge is to encourage the audience to stick with you until the end. You might have come up with a novel solution that will benefit a lot of people, but that doesn’t matter if you can’t get people to pay attention. That’s why the introduction should immediately hook your audience by stating the problem your work has addressed.

For the majority of software engineers, the technical problem area and its subsequent solution will be the most interesting or pertinent aspect as it is likely the part that everyone can relate to. This captures the audience's attention, whether they've encountered the same issue and seek a solution or are curious about how they'd handle it.

The body: Explain what you did

Once you’ve explained the problem, it’s time to describe what you did to address it. This is the bulk of your content and should contain specific details about the journey from identifying the problem to implementing a solution. While there is no set formula for what belongs in the body, there are some commonalities you might want to include, such as:

1. The data you gathered to verify the problem. Technical audiences are data-driven. Any numbers you can share that first signaled the scope of the problem are helpful.
2. The experiments you conducted in search of a solution. The first attempt to solve a problem rarely succeeds. Sharing the things that didn’t work is often just as interesting as what did.
3. The constraints you worked within. Every project has some constraints that limit the scope of the solution, whether that be a deadline, a budget, or something else. Take the time to explain these constraints. This helps the audience understand why you chose one approach over another in addressing the problem. 
4. How you validated the solution. After trying several potential solutions that didn't work out, how did you determine that this one was successful? How did your solution end up bringing a better outcome and can you illustrate this change with data? 

Overall, the body describes the path from the problem to the solution. By the end, readers grasp the problem's scope and why the solution you pursued was chosen over others.

The conclusion: Present your results

You just took the audience on a journey of explaining a problem and what you did to address it. The conclusion is the exclamation point that wraps up your presentation for the audience. To do that, you’ll need to cover three points:

1. The results of your work. How did your project (or company) benefit from the solution you found? Generally, you’ll share before-and-after data to show what changed. This is where tables and graphs are helpful to illustrate the results.
2. The impact of your work. While the numbers show tangible changes as a result of your work, there are often second-order positive effects that are worth mentioning. For example, if you successfully decreased the production error rate, a second-order effect is the reduction of on-call hours required to maintain the application. This boosts engineer productivity and satisfaction allowing more time for feature development instead of frequent production issues.
3. Lessons learned from the experience. Here you can address what you learned throughout the process and how it will benefit your work going forward. This also serves as a summary of what the audience should take away from the presentation.

Your conclusion wraps up the journey you’ve taken the audience on and should leave them feeling informed.

Final thoughts 

The ability to present technical information, in writing or as a talk, is a skill that all software engineers need to develop eventually. Promotion into staff+ levels typically requires the ability to communicate clearly to engineering leaders. The framework presented in this article is just one way to organize your content, a starting point that you can adapt to your own needs. Overall, weaving the important parts of your solution into a coherent story is a skill that will serve you well throughout your career.