You lost them before you got there
You had the data, analysis and recommendation. They still didn't hear you.
I had this movie in my head: walk into the meeting, give the leaders all the context, build the case piece by piece, and at the end they’d say “Hell yeah, Mateja. Smart. Right decision.”
Instead I ended up standing outside the meeting room sulking. We never even got to my ask. Somewhere in the preamble I’d lost them, and I didn’t see it coming.
What happened?
The test
If someone only heard your first sentence in a meeting, would they understand why you’re talking?
Most engineers fail this test. Not because they lack clarity of thought, quite the opposite. Because they’ve been trained to start with context instead of the point. You know this pattern, don’t you? You’ve probably done it yourself. I know I have.
Engineer starts speaking. Background first, then more background, then some data, and finally the thing that actually matters. By which point, the PM is mentally reviewing their inbox and the exec has already moved to the next meeting in their head.
Leadership doesn’t want to hear the story of Frodo going to Mordor and back. They want to know: did he throw the ring in the pit? If not, why not, what’s the plan, and does he need resources to sort it out?
The first sentence should answer one question: why are we talking about this?
First sentences that pass the test:
“This feature will take 6 weeks, not 2.”
“This deployment will break mobile clients unless we coordinate the rollout.”
“We need three more engineers or we’re missing the deadline.”
Compare with how engineers actually start these conversations:
“So, yesterday I was working on the authentication service and ran into some issues with the session handling...”
“I wanted to talk about the roadmap and some of the complexity we’ve been discovering as we dig into the requirements...”
“There’s been some discussion about the deployment process and coordination with other teams...”
These openings don’t tell you anything. They promise that eventually you’ll get to something important. Maybe. If the meeting doesn’t run over.
So this isn’t a listening problem, but a communication structure problem.
Two languages, one room
I started thinking about this after reading First Minute for a book club, a book that formalizes the whole problem into a structure. Turns out the pattern is common enough to warrant its own book. Which means you’re not uniquely bad at this. You’re just doing what everyone does. Maybe not after reading this.
Engineers communicate the way engineers communicate. Thorough. Sequential. Everything on the table before you reach the conclusion. That’s not a flaw, it’s what makes you good at building systems, writing design docs, reviewing code.
But leadership operates on different constraints. Less time. More context switches. They’re not reading your design doc. They’re in a meeting with ten other things pulling for their attention. Their default is conclusion-first. Bottom line up front. What do you need and why.
Two different languages. Both internally consistent. Neither wrong. And yet here we are.
The problem is when you use the engineer language in a leadership context. Context-first works when someone chooses to read your work, they can skim ahead, reread, control the pace. Documentation, design docs, pull requests: all fine there.
It fails in real-time conversations.
When you start with context in a meeting, people don’t know where you’re going or why they should care. Are you raising a problem? Proposing a solution? Just providing an update? By the time you arrive at the conclusion, you’ve lost most of them.
But changing this is hard. Starting with the conclusion feels risky. That’s an assertiveness problem as much as a structure problem.
The situations can be simple stuff:
Should we attend this conference?
Should we give a talk there?
Should we even have this meeting?
Sometimes it’s bigger: should we spend a quarter on refactoring and ship no features?
I’ve been shut down in both. And lived to tell the tale, obviously.
Imagine you’re about to propose something you know will get pushback. Something that challenges the current direction, asks for resources people don’t want to give, or requires a change nobody asked for.
The instinct: build up to it. You might reason: if they understand the reasoning first, they’ll follow me to the conclusion. If I lead with the conclusion and they might just say no with a snap decision, case closed, no fair hearing. At least with context I give myself a chance to be understood.
The logic is understandable. It’s also backwards.
You’re not giving them context so they’ll understand, you’re hoping context will function as pre-agreement. Unfortunately, they’re not tracking your reasoning step by step, building toward your conclusion with you. They’re waiting. And by the time you get there, they’ve been waiting long enough that the attention is somewhere else.
Even if you give them all the context in advance, they’re still going to challenge. Context-first just means the challenge comes after you’ve already lost half the room.
This plays out in individual conversations. But the bigger cost is what it does over time.
The reputation you don’t know you’re building
Some people believe communication doesn’t actually matter and that if you’re good enough, the work speaks for itself. That you get promoted on technical merit alone. It can happen, just maybe not to you or when you’d like it to happen... or never.
The higher you go, the better you need to be at communicating. Not just technically. With leadership, across teams, with people on other teams who don’t share your context. There are exceptions — engineers who got to senior levels on pure technical output — but they’re rare enough that betting your career on being one is essentially playing the lottery.
Unless you feel lucky, it’s easier and better to work on the communication.
This pattern of going context-first doesn’t just make you less effective in the moment. It damages your credibility over time.
Over half your work time is spent communicating, verbally, in writing, in meetings. Every one of those interactions leaves an impression: it shapes how people see you, your credibility, your judgment, your potential. Believe it or not, poor communication is one of the major gates to promotion, especially into leadership. Not technical gaps. Not bad judgment. Communication.
You’re building a reputation in every meeting. The question is what kind.
When you consistently bury your point, people stop listening to your openings. They know you’re going to take a while to get there, so they tune out until you do. Except now you have to work even harder to get their attention back, and sometimes you never do.
The cruel part? You walk out of the meeting without what you came for. You were the most prepared person in the room, you brought the data, did the analysis and came up with the recommendation. You still got ignored.
Structure undermines you before you get to the point. The language you use once you’re there is its own problem.
Same information, different order
Start with the conclusion, then back it up.
“We’re going to miss the launch by three weeks. We’ve finished 60% of the work with 40% of the time left. I looked at three options: cut scope, bring in more people, or push the date. Here’s what I recommend and why...”
The problem lands in the first sentence. Data follows. Recommendation after that.
This isn’t dumbing it down. If they want to dig in, the frame is already there. If they agree, you’ve saved everyone five minutes of preamble.
The exception (there is one)
Sometimes you do need to establish context before the point. When the audience doesn’t have the background knowledge to understand the conclusion or when the problem is so unexpected that leading with it would be confusing.
Knowing how much context to give requires knowing your audience, especially what they already know, what decisions they’re focused on, what’s actually on their mind when you walk in. That’s a different skill, and it starts before the meeting.
Ask yourself: does the context enable understanding, or is it just preamble?
We went through this when we wanted to replace our in-house authentication with a third-party identity provider. For months we’d been struggling to get resources to implement SSO. Other providers already had it built in. We were slowly losing ground every time a potential customer asked about single sign-on and we had to explain why we didn’t support it.
We couldn’t walk in and say “we’re bringing in a third-party authentication provider, it costs money, kthxbye.”
That conclusion without context would have landed as an unnecessary expense. The reaction would have been: why do we need this when we already have something that works?
One sentence of context changed the frame: “We’ve been losing enterprise deals because we don’t support SSO, and building it in-house would take six months. Here’s what I recommend.”
Same conclusion. One sentence of setup. Completely different reception. Context is one sentence, not three paragraphs.
Next time try this: cut your opening and start with your second sentence. Would anything of value be lost? If not, there you go. Drop it.
Before and after
Before your next meeting, write down your first sentence. Does it contain the point, or does it contain setup?
If it’s setup, put the conclusion first. If someone only heard that sentence, would they know why you’re talking? If yes, you’re done. If no, try again.
This feels unnatural at first. You’ll feel like you’re being too direct, too blunt, like you’re skipping important information. You’re not. You’re putting the important information first. The rest is still there, you’re just not making people wait through setup to get to it.
Standup: “Login is broken in staging. I’m fixing it now, should be done by noon.” Not: “Yesterday I was working on authentication and ran into some issues with the session handling that I’m still debugging.”
Architecture review: instead of opening with “I’ve been looking at our infrastructure and thinking about how we handle growth,” you open with “Our current setup breaks at 5x our current load. We need to fix it before Q3.” Everything else follows from that.
Stakeholder update: “We’re two weeks behind schedule because the API keeps changing.” Not: “There have been some challenges with the integration work and coordination with the backend team.”
I’ve been in every one of these meetings. On both sides... and caught myself jumping in and cutting engineers off to get to the point faster. Not good. I stopped, I decided to coach them instead.
Here’s a thought: If you’re already using AI tools for code and emails, you can use AI for this too. Paste what you’re about to say, ask it to restructure it conclusion-first. Takes thirty seconds.
Say the thing
When you’re about to speak, stop. What’s the one thing others need to know? Start there.
Your first sentence is not a warm-up, an introduction, or context for the thing you’re about to say. It is your point. Say it.
Most of us fail the test because we think communication is about being thorough. It’s not. You can be completely thorough and still get ignored. Being thorough means you covered everything. Nobody said they were listening.
Now the tough question: what are you optimizing for, being right or being heard?
why I shouldn’t
that.
why I shouldn’t.