Skip to content

Storytelling for Technical Projects

Storytelling in technischen Projekten

This story might sound familiar to you

You are facing a technical problem. It might be small, like a piece of technical depth that desperately needs to be tackled. Or it might be a huge liftover, such as transforming a legacy bare metal solution entirely into the cloud. You have a solution in mind, and know exactly how to implement it technically. But you are facing one of the biggest challenges as a technical person: You need to convince your stakeholders or even your management to approve your solution.

What you probably do...

As a technical person, you might sit down and write together a pristine technical proposal - Entirely focused on pure facts. You calculate server capacities, list up-time percentages, tally up maintenance hours, and present a bulletproof, logical case. You talk about throughput, latency reduction, and clean code principles.

What will probably happen...

Management does not listen to you or your proposal. Or worse: They nod politely, but deep in their hearts, they are not convinced and do not let you know about it. All they see on your slides are costs, migration risks, and potential downtime. To a non-technical stakeholder, a list of architectural facts reads like a financial risk rather than an opportunity. You speak engineering; they speak business risk and bottom lines. And that is the moment when you realize that you have not convinced your stakeholders. You have not achieved your goal. Your project will not be implemented. And you are frustrated.

But here comes the solution - At least it worked for me

Sayings like "A picture is worth a thousand words" or "Facts tell, stories sell" are not just empty phrases. They are true.

I have learned that the best way to convince stakeholders of a technical solution is to tell a story. A story that is easy to understand, relatable, and memorable. A story that connects the technical solution to the business goals and values of the stakeholders.

Because let's be honest, you probably remember the first time you saw your first great love much more clearly and vividly than you do the year Rome was founded, right?

That's because we can remember things much better when emotions are involved. ( By the way, that's a great life hack, even for learning )

And stories are transmitting emotions. They are a powerful tool to engage your audience, create empathy, and influence their decisions.

Following are some of the techniques I used to tell a compelling story for a technical project. I hope they will help you too.

Set the scene

Instead of blank slides with bullet points, I start with a fixed theme or a recurring motif. For example I went with a "space exploration" theme for a cloud migration project. I used images of rockets, planets, asteroids and astronauts to illustrate the story.

In my presentation I also used metaphors and analogies to explain complex technical concepts in simple terms. For example you could easily think of space shuttles as a metaphor for cloud servers, or asteroids as a metaphor for dangerous obstacles in the migration process.

Setting a scene

Choose a hero

Emotion comes - oftentimes - through personal relationships. That's why I chose a hero for my story: The "Captain" of the spaceship. In my case it was my avatar dressed as a space captain. The hero is the one who oversees the mission, faces challenges and makes decisions. The hero is also the one who represents the stakeholders and their interests. By giving a face and a name to the hero, I made it easier for the audience to relate to him and empathize with his situation.

So instead of saying "We have identified the following risks" you could say "The captain has identified the following risks for our mission - But do not worry, he already has a plan to mitigate them."

Our hero, the captain of the spaceship

Our hero, the captain of the spaceship

Clear structure

Every story needs a clear structure, conflict and resolution. Otherwise the audience can easily get lost or bored. I inspired myself from the Mc Kinsey SCR structure, which is a simple and effective way to make the presentation crystal clear. It consists of three parts: Situation, Complication and Resolution.

The situation describes the current state of affairs and the context. While listening to the situation the audience should be able to understand the problem by themselves.

The complication describes the challenges and obstacles that prevent the hero from achieving his goal. The audience should feel the tension and urgency of the situation. It must be clear, that there is urgent need for action.

The resolution describes the solution and the benefits that the hero will gain by implementing it. The audience should feel satisfied and convinced that the solution is the best one.

In some cases, especially when comparing multiple solutions you can also extend the structure to: Situation, Complication, Possible Solutions, Recommendation. This is especially useful when you want to show that you have considered different options and that you have a clear preference for one of them.

Attention

The SCR structure is not a rigid formula, but a flexible framework that can be adapted to different situations and audiences. The key is to keep the story focused, relevant and engaging, not to blindly follow a framework.

You never get a second chance for your first impression

A long time ago, I worked in two fields that were very different from IT. After finishing school, I worked in sales and as an assistant chef. But what both jobs have in common is this: You only have a few seconds to make a good first impression—whether it’s on the plate being served to a guest or on the phone, where the customer decides whether or not to make a purchase.

And the same goes for presentations. According to scientific research, we have about 3 seconds to determine whether the person you’re talking to will continue to listen to you actively. This may be different for a first encounter than for existing relationships, but regardless, you need to make a good first impression.

So: Start with an attention-grabbing background image, a catchy title and a clear introduction. You could use a hook, such as a question or surprising fact, to pique the audience’s curiosity.

But in my point of view the best is to introduce them into the setting of the story and the hero. Make them feel like they are part of the story and that they have a stake in the outcome.

For example, you could start the slide with a space background and a rocket taking off. The title could be "Mission: Migration to the cloud" and the introduction could be "Today, I would like to take you on a journey. A journey to a completely new world, where our applications can run in the cloud. A journey that will require courage, skill and teamwork. Are you ready to join me on this mission? And who is best suited to lead this mission? Our hero, the captain of the spaceship, who will guide us through the challenges and opportunities of this migration."

Do not lose yourself in the story

Although it is great to tell a dramatic story, you should not lose your focus and key message. Remember: You are still wanting to convince your stakeholders or managers of something.

So make sure, that your story is always tied to the technical situation and do not tell stories just for the sake of telling stories. You should always have a clear purpose and goal for your story. You should also avoid exaggeration or distortion of facts, as this can undermine your credibility and trustworthiness.

Concluding Summary

In the enterprise environment, technical excellence alone is rarely enough to get large projects approved. Even the best architectures and cloud migrations end up gathering dust in a drawer if they come across as a string of dry risk assessments.

By bridging the gap between raw code and compelling storytelling, you take your stakeholders along for the ride. You transform what seems like an obstacle (the budget or the complexity) into a milestone on a shared journey—and that’s exactly what turns a "no" into a resounding "Let’s do it."

Cui honorem, honorem

Last updated: