The SECOND most important skill for an engineer

Well after coding ofc.

If you like this article, you can support me !
Don't forget to drop a ❤️ and share it with someone who maybe interested.

They lied to me when telling me that being a software eng is 100% coding.
It's not.
It's also meetings, presentations, workshops, reviews...

Love it or hate it, it's still a part of the job. And to be honest, it's sometimes more important than your actual coding skills.

Cool, you know how to make LSP to talk to servers, but can you talk to people ??

Honestly, nobody cares if you are a 1203912x software engineer if you can't explain your thoughts and systems.

It shapes how other people see you, and how credible you are, and also gives you a more in-depth understanding of either:

• Other ways to solve a problem (by discussing with other engineers on a solution)

• The business itself (which equates to better architecture and design)

Knowing how crucial it is, I decided to start a mini-series on communication, with some personal stories, tips, and tricks from other devs, product managers, and resources to go further.

This week, as you chose in the last poll; more than 40% of you wanted an article on storytelling, and here we are!

Storytelling is the ability to tell a story to convey information, and insights or to entertain an audience.
I'm going to mainly talk about oral presentations, written texts will come later in the series.
The biggest mistake you can make when telling a story is giving TOO much backstory.

And in the spirit of respecting your time, I can't get a better TL;DR than:

• Be clear.

• Be direct.

• Be captivating.

You can also get the "TLDR" of each subtopic at the end of each section (marked by the "🎯 Takeaways" )

Context dumping or "how to bore your audience"

A personal story

Last year, I was refactoring a big chunk of our codebase, and I wanted some guidance on the best direction to take.
I talked with my manager, and the next week, there we were, a meeting with team leads, the engineering manager, even the CTO stopped by, and an external craftsmanship coach.

So of course, being the one with the most context and ownership on the subject, I started with the infamous "context sharing".
Explaining the existing system, explaining the problems, the stakeholders...
I'm passionate about this system, so at first people were a bit interested to see why I was found of the system, but as the braindead I am, I started talking and talking...

basically everyone after 10min on the call

Yeah, you guessed it, everybody got bored, and nobody seemed to really understand what we were doing.

I was getting frustrated because I couldn't share my passion, and couldn't get them on board.
And the more I was frustrated, the less clear my explanation became.
It took us all morning just to get through the existing system.
And took us the rest of the day to find a solution, but because most people either disconnected from the call or disconnected their focus, it was suboptimal.
I was also tired from talking all day, so I switched from open-mindedness to stubbornness, sticking to something I knew.

It was a disaster. I mean yeah all the participants learned something new but it waste of time and money.
We finally postponed the refactoring by a few months.

Learnings

Of course, I have no one to blame here besides myself.
My presentation was boring.
It's okay it happens to the best of us, and even though it was a disaster, I learned a lot of things.

Let's start with the elephant in the room

0 - Show, don't tell.

It's something I learned from making videos, but I didn't apply it to my workshop.

We had a full day for the workshop, we spent half of it just ruminating about the existing system, giving the sacred "context" to the other participants.
It was taxing on me (as I talked way too much) and on the others (they couldn't jump into the action)

When we "context-dump", we are underestimating the capacity of people to work without context and pick up pertaining information on the go.

Even movies, video games, and books don't give much backstory, we start directly with an established situation, and we get the flashback when it's needed to understand the lore.
It's the best part of the movie when we get the "aha" moment and actually understand what was happening all along.

Matrix starts directly with an action scene. We don’t know what’s happening but we know who to cheer

For instance, I should've prepared some graphs to explain the relationships between the subsystems, and some numbers on the losses due to legacy code.
And I also would just start with the "how to refactor it" and interject only when I see something that needs more context.
I need THEIR help, not the other way around.

🎯 Take-aways:

1. Show, don't tell:
   Either have graphs, charts, or images, already made to explain your point. Don't use your worst tool: "words"

2. Don't underestimate your audience:
   They don't need to know every detail of the project to get on board.
   And once you start dumping context, you never feel like it’s enough.

3. Pyramidal communication:
   Start building from the problem or your results, instead of building from the context. They'll have a better feel on what's at stake, and get them more excited.

4. Have references ready:
   If they actually need context or the backstory, either share documentation before the meeting, or reference it during the discussion.

1 - Passion is a double-edged sword

Yes, being motivated and passionate about a subject makes you more interesting to listen to, it gives more personality to the presentation.

But if you only rely on the passion, two things will happen:

• You'll get frustrated because people don't share your passion

• The next time, people will be less likely to listen to you.

We had a tool in my student video club called the "vibe chart".
We had a show every two weeks where we presented all the videos we made to the whole campus, with more than 800 spectators.

A picture of our last show. Thanks to galerie.pics for the picture.

We made 6~10 videos per show, and we always had an issue: "how to sequence them in the best way possible"

Well, it depended on the tone we wanted to give to the show.
Most of our shows looked something like this.

A “high energy” video is anything that will hype the viewer, like a music video, a party aftermovie or a funny video.

We "end up" with a bang, it's the hype point of the show.

But in the last show of our curriculum, we had a lot of videos, and we didn't want the show to feel "lengthy", so we put the highest energy at the beginning, middle, and end.

So always had the attention of the public.

🎯 Take-aways:

1. Nobody expects you to always be energetic and passionate, so don't force yourself, it'll show, and you'd be better off thinking a bit about your "vibe chart"

2. Don't rely on energy only. If you're telling a bad story, no matter how you tell it, it'll be bad. We have a saying in Morocco: "Don't put lipstick on snot"

3. Be clear. I noticed that the more passionate we are about a topic, the more "over the place" we are, and if we don't have structure to fall back on, we'll just be spewing nonsense.

2 - Interact.

We're not telling stories to ourselves, we are communicating with others.
The whole point of the workshop was to get the input of others, but I ended up talking most of the time. That's not good of course.

A simple way to interact is well, to ask questions.
Sometimes it's literally asking questions to the audience.
Like in workshops, asking the participants about their take on something. It's the whole purpose after all.
Sometimes it's talking about something that'll make them think on the way back home.

Some movies and books are made so that you can question your vision of the world.
Yeah Matrix is a cool action movie, but it raises questions that you can't stop yourself from trying to answer (Are we living in a simulation? How can we be sure? )

btw I quoted Morpheus from Matrix in one of my philosophy exams, I almost failed the year because of it

So you can take some tricks from them to make your presentations more appealing

🎯 Take-aways:

• Formulate problems as questions, and let people answer them.

• Break the 4th wall, you're not performing, ask the audience about their take.

Closing Thoughts

We are in an era where the attention span is drastically diminishing.
People are busier than ever, so if you want to make lasting impressions, respect their time and attention.

• Learn to get to the point

• Only share the relevant backstory

• Don't underestimate your audience

Next week, we'll go from talking to an audience, to talking to the frenemy of every dev: the product team.
So be sure to subscribe if you want