Where Technical Communication Breaks Down
Most technical communication doesn’t fail at the opening. It fails in the middle — and last Friday I watched it happen six times in a row.
I ran a 90-minute workshop where everyone took something they’d worked on recently and turned it into a sixty-second update. They delivered it to a small group, then came back together so I could listen and coach them on it live.
I polled the room at the start. Most of them present to senior leaders regularly. These were not beginners.
And almost all of them broke down in the same place.
The exercise
I gave everyone a prompt:
Pick one product, project, or process you worked on in the last six to twelve months. Then shape it into a sixty-second update using four beats: who it’s for, what the problem was, one thing you learned, and one thing you want them to do.
Then I gave them an example of my own:
If you know how to code and you’re curious about AI tools but don’t have the bandwidth, this one’s for you.
Eight months ago, San Jose Unified announced nine elementary school closures. My kids’ school was one of them, and families needed the information fast. A landing site was the obvious way to get it out — but I had one morning.
So I reached for Lovable, an AI tool friends and coworkers kept recommending. What I learned: I never had to open an editor. I described the closures and the schools affected in plain English, then asked for Spanish and Vietnamese versions. The site was live by noon. Parents checked the translations, and it went out to the community that afternoon.
If you’re short on bandwidth like I was, carve out one morning and build something small. You’ll know by the end whether the tool is for you.
Someone asked afterward what happened. Our school stayed open.
[Image: Poornima getting ready for a family bike ride — alt: “Getting ready for a family bike ride” — re-upload to WP media library]
These were first drafts, on purpose
Everyone had five minutes. Of course the results were a little muddled.
That was deliberate. In real life, we rarely get hours to polish a message. We get pulled into a meeting, or a senior leader asks for an update in ten minutes.
Those are the moments that matter most. And they’re exactly when we don’t have time to think about structure. That’s why it helps to have a framework you’ve already practiced, so it holds up when the clock is running.
What I saw
1. The nerves didn’t show. Even if people felt nervous on the inside, their delivery was conversational. You couldn’t tell from the outside.
That’s a great base to start from. It’s worth saying because most people assume nerves are the problem. For this group, nerves weren’t what got in the way.
2. They knew to start with the audience and the problem. Most people had a compelling problem they were trying to solve, and they cared deeply about it. The openings were strong.
3. The breakdown happened in the middle. As the story unfolded, the problem started to broaden or meander.
One engineer who works on chip bring-up opened with a new methodology that failed on its first real run. None of his team’s settings even made it into the build. By the end, the insight had changed: in falling back to the old method, they discovered it had been doing far more than it needed to and could be cut down.
Two different problems. The second one was the better story, and it arrived last.
4. There wasn’t a clear takeaway or action. By the end, the listener wasn’t sure what mattered, or what they were supposed to do next.
And that’s the part that matters most.
Why technical communication breaks down here
When I say technical communication, I mean explaining complex work to people who don’t share your context. That might be executives, cross-functional partners, or engineers working in another part of the system.
To be clear, not every technical conversation should be this concise. When you’re brainstorming or debugging with a small group, you may need extensive context, multiple possibilities, and a little meandering as you work toward an answer. That’s the point of those sessions: everyone is there to dig into the details with you.
But an update for decision-makers is a different kind of conversation. They need to understand what matters, why it matters, and what you need from them.
The middle is where the thread disappears
Most people can introduce the problem. The trouble begins as they explain what happened next. The story expands, a second problem emerges, and the original thread disappears.
So the listener starts picking apart the details — or gives you an assignment:
“Can you put together a doc on this?”
Sometimes that really means: “I didn’t follow, and I’m not going to say so.”
How many times have you done that work? And how many times did anyone actually read the doc?
Sometimes it goes unread. Other times, it generates another round of questions and assignments. Either way, a problem that may have had a straightforward fix turns into a rabbit hole.
This has nothing to do with your technical chops. It has everything to do with how you refine and deliver a message.
There are a lot of headwinds holding people back in our industry right now. But the ability to make your work clear to people who don’t share your context is one of the skills I consistently see separating people whose influence grows from those whose work remains overlooked.
[Image: Pull-quote card reading “The problem you end with is often more interesting than the one you started with” — alt: “Quote card on where technical communication breaks down” — create and upload]
What to do about it
Here’s what I noticed on Friday. The problem people ended with was often more interesting than the one they started with.
They weren’t simply meandering. They were discovering the real story as they told it.
So the fix isn’t to be more careful while speaking. Draft it once. Notice where you ended up. Then rewrite it so that’s where you begin.
Here’s your one thing for this week. Take something you worked on recently and draft sixty seconds on it. Then read it back and ask:
Did I end up somewhere different from where I started?
If you did, that’s not a mistake. That’s the real story. Move it to the front, and cut everything that was getting you there.
Try it, then tell me in the comments which problem you started with and which one you ended on.
Want to do this with feedback?
After the workshop, one attendee texted me: “I felt the transformation within the session itself.”
That’s what a single session with live feedback can do.
In the one-on-one calls I had afterward, two things kept coming up. The first was time: a six-week program with weekly classes and labs is a lot to absorb when you’re already stretched. The second was feedback. People didn’t just want more material. They wanted repeated opportunities to practice, hear what was and wasn’t landing, and try again.
So I redesigned the program around both. Confident Communicator Group Coaching now runs over three months, from October through December. The lessons are short videos you watch on your own schedule, while the live coaching and individual sessions give you consistent feedback as you practice.
Each month includes two video lessons with exercises, written feedback from me on both recorded exercises, two 60-minute group coaching sessions, and two 30-minute one-on-one sessions with me.
I’m keeping the group to five so everyone gets real attention and plenty of time to practice.
Find the real story, shape it clearly, and make it land.
