A while back, I stood in front of a room at Tech Hub Orlando during a GDG Central Florida meetup and talked about something I had been thinking about more and more.
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 became the idea behind my presentation:
Pause. Think. PREP.: Communicating With Confidence in Tech
But while preparing the talk, I realized something: I wasn’t just teaching this. I’m learning it too.
¡Hola! 👋 I’m Javi, a Software Engineer and GDG Community 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, tools, and whatever new thing shows up next.
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.
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 shouts:
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 everyone is looking at. But to everyone else, it usually feels much shorter. Your audience probably 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
- P: Point
What do I believe?
State your main idea clearly. - R: Reason
Why does my point make sense?
Give the logic, facts, or context. - E: Example
Make it real.
Give people a story, experience, case, or something tangible. - P: 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 in a meeting and somebody asks:
“Should we automate this repetitive process?”
Without structure, the answer can start wandering immediately.
With PREP:
- Point: Yes, I think we should automate it.
- Reason: We’re spending too much engineering time on repetitive manual coordination.
- Example: Last sprint, the process required several back-and-forth messages and delayed testing.
- Point again: So I recommend we automate the workflow and measure whether it reduces that overhead.
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:
The PREP Framework Infographic: A quick reference created for meetings, demos, interviews, presentations, leadership conversations, and those unexpected questions. Download it here.
There are plenty of places where PREP can help in tech: Meetings, team discussions, performance reviews, architecture conversations, demos, interviews, leadership conversations, pitches, 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, build prototypes, generate diagrams, prepare presentations, and sometimes produce 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?
- 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.
AI may help us produce more. It doesn’t remove our responsibility to understand what we are building or explain why it matters.
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 PREP:
- 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.
- 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, pitching something you built, 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.
This Is Part of My Own Journey
I’m still learning this myself, and that’s part of why I want to write more about technical communication.
I’ll be sharing frameworks, experiments, infographics, lessons from speaking, successes, and probably a few failures 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. And in an industry moving faster every year, I think that skill is going to matter more, not less.
What part of technical communication is hardest for you: presenting, explaining a complex idea, thinking on the spot, storytelling, or simply knowing when to stop talking? 😄
¡Hasta la próxima! 👋
Javi
Software Engineer | GDG Community Organizer
techno-logic.us