Your Technical Skills Aren’t Enough: Learning to Communicate Under Pressure

At a recent GDG Central Florida meetup at Tech Hub Orlando, we spent time talking about a skill that becomes especially important when you’re building and sharing ideas with other people. Whether it’s a hackathon pitch, demo, lightning talk, technical interview, or unexpected question, eventually you have to explain what you’ve built and why it matters.

That skill is communicating under pressure.

Not Angular.

Not cloud architecture.

Not even AI.

Communication.

More specifically: what happens when somebody puts you on the spot.

Maybe it’s a presentation. A demo. An interview. A meeting.

Or maybe somebody suddenly turns to you and says:

Javi, what do you think?

And somehow…the brilliant answer that was in your head five seconds ago has left the building. 😄

That was the idea behind my presentation:

👉 Pause. Think. PREP. — Communicating With Confidence in Tech

But while preparing the presentation, I realized something.

I wasn’t just teaching this. I’m learning it too.

¡Hola! 👋 I’m Javi, a Software Engineer at Design Interactive and Google Developers Group Central Florida Organizer. I’m working on becoming a better technical communicator, and I’m sharing what I learn along the way.

Being Good at the Technical Part Isn’t Always Enough

I’ve spent a lot of my career doing what developers do: Learning languages. Frameworks. Architecture. Cloud. APIs. New tools. And now, of course, AI has given us another giant box of things to learn. Technology moves incredibly fast. There is always another framework, another model, another device, another abstraction layer.

But one skill continues to be valuable regardless of what technology we’re using:

our ability to communicate.

During my presentation, I asked the audience to imagine something.

Suppose you’re technically a 10 out of 10.

You solve difficult problems. You write great code. You know your stuff.

But when it’s time to explain your idea, demo what you’ve built, speak with leadership, advocate for yourself, or answer a difficult question, your communication is a 3.

Does everyone around you experience you as a 10?

Or can they only see the 3?

That question has stuck with me. Because people can’t value what they can’t clearly see or understand. Doing good work matters. But eventually, we also have to learn how to communicate the value of that work.

You may already be bright.

Communication helps other people see that light.

At a hackathon or demo day, that can be the difference between having a great idea and helping everyone else understand why it’s great.

The Problem With Silence

One thing I’ve noticed about myself is what happens when I’m suddenly asked a question.

My first instinct is often to eliminate the silence.

Somebody asks:

What do you think?

And the brain immediately says:

QUICK! SAY SOMETHING! 😄

So we start talking before we even know where we’re going.

And then comes the wandering answer.

Well…you know…there are several ways we could probably approach this…

We’ve all heard it.

I’ve done it.

The mindset I’m working on now is surprisingly simple:

Silence is not weakness. Silence can be preparation.

A two-second pause can feel incredibly long when you’re the person standing in front of everyone.

But to everyone else, that silence probably feels much shorter. Your audience just assumes you’re gathering your thoughts!

So instead of immediately filling the silence:

• Pause.
• Think.
• Then give your thoughts somewhere to go.

That’s where PREP comes in.

PREP Gives Your Thoughts Somewhere to Go

PREP is a simple communication framework:

Point → Reason → Example → Point Again

• The first P is Point.
  What do I believe? State the main idea clearly.
• R is Reason.
  Why does my point make sense? Give the logic, facts, or context.
• E is Example.
  Make it real. Give people a story, experience, case, or something tangible.
• And the final P is Point Again.
  What do I want them to remember? Bring the answer back to your main idea and close clearly.

That’s it.

Point. Reason. Example. Point.

You don’t need to memorize an entire speech. You just need somewhere for your thoughts to go.

A Developer Example

Imagine you’re presenting and somebody asks:

Why did your team choose this approach?

Without structure, the answer could start wandering immediately.

With PREP:

• Point: We chose this approach because it let us build and validate the core experience quickly.
• Reason: With limited hackathon time, we wanted to spend less time on infrastructure and more time testing whether the idea actually solved the problem.
• Example: Instead of building authentication from scratch, we used an existing service and focused our time on the feature users would actually experience.
• Point again: That trade-off helped us get a working solution in front of people faster.

PREP didn’t suddenly make the answer smarter.

It made what I already knew easier for someone else to follow.

That’s an important distinction. Good communication isn’t about sounding smarter. It’s about making your thinking easier for another human being to understand.

I Turned the Idea Into an Infographic

When I started studying PREP, I wanted something I could keep as a quick visual reference instead of another page of notes.

So I created this infographic:

The PREP Framework infographic: A quick reference I created for meetings, demos, interviews, pitches, and those unexpected questions. Download it here.

Here are some of the places where I think PREP can be especially useful in tech:

Meetings, team discussions, performance reviews, architecture conversations, demos, interviews, leadership conversations, and those wonderful moments when someone unexpectedly asks for your opinion. 😄

The framework stays the same.

The situation changes.

Practice Communication Like You Review Code

Knowing a framework is useful.

Using it when your heart is racing and people are looking at you is another story.

So I’ve been experimenting with something else: recording myself on video for about 60 seconds.

And yes, listening to your own recorded voice can be painful.

Anybody ever hear yourself and think:

Wait…THAT’S me? 😄

But instead of watching a recording and thinking: “I sound terrible.”

I’m trying to treat it like reviewing code.

Look at specific things:

• Was my pace too fast?
• Did I use pauses effectively?
• What was my posture doing?
• Was I making eye contact?
• Did I sound confident at the end of my sentences?
• What worked?
• What should I refactor?

In the presentation, I summarized it this way:

Watch yourself like you’re reviewing code. But don’t watch yourself looking for reasons to cringe.

This isn’t judgment.

It’s data.

And developers know what to do with data.

We iterate.

Why Communication Matters Even More in the Age of AI

AI makes this topic even more interesting to me.

AI can help us generate code faster, create documentation, summarize meetings, and build prototypes, diagrams, presentations, and sometimes an impressive amount of software.

But faster output doesn’t automatically create better understanding.

Someone still has to answer questions like:

• Why are we building this?
• What problem are we solving?
• Why did we choose this architecture?
• What trade-offs did we accept?
• What did the AI generate, and what did we decide?

And most importantly:

Can we explain all of that clearly to another person?

The better our tools become, the more I think skills like communication, critical thinking, judgment, storytelling, and collaboration become part of what separates useful technical work from simply producing more stuff.

Maybe communication isn’t separate from technical skill.

Maybe it never was.

The Presentation Had a Little Secret

Near the end of my talk at Tech Hub Orlando, I revealed something to the audience.

The presentation itself had basically followed the PREP framework.

• My Point was that communication matters.
• My Reason was that people need to understand our work before they can fully appreciate its value.
• I gave Examples of how PREP could work in real technical situations.
• And then I returned to my Point:

Your technical skills matter, but people need to understand your ideas before those skills can have their full impact.

PREP wasn’t just something on a slide.

The presentation was the demonstration.

Confidence Usually Comes After You Start

One of the hardest things about improving communication is waiting to feel confident enough to do it.

I’ve learned that it often works the other way around.

You don’t become confident and then start speaking.

You start speaking — and confidence catches up.

For some developers, the uncomfortable place might be a microphone.

For someone else, it’s presenting a demo.

Maybe it’s asking for a promotion.

Introducing yourself at a meetup.

Speaking during an architecture discussion.

Or answering that unexpected:

What do you think?

When that moment comes, I’m trying to remember three things:

• Pause.
• Think.
• PREP.

Your ideas deserve to be heard.

I’m still learning this myself, and that’s part of why I want to start writing more about technical communication.

I’ll be sharing some of the frameworks, experiments, infographics, successes, and probably a few failures that I’m using along the way.

Because becoming a better technologist isn’t only about learning how to build better things.

Sometimes it’s about learning how to explain those things to another human being.

These same skills show up everywhere at DevFest Florida. You may need them while pitching a hackathon project, explaining an architecture decision, asking a speaker a question, meeting someone new, or presenting your work to a room full of people.

If you’re building, speaking, mentoring, volunteering, or simply joining the conversation, try PREP the next time someone asks you to explain your idea.

¡Hasta la próxima! 👋

Javi
Software Engineer | GDG Community Organizer | techno-logic.us

Join us at DevFestFlorida.com