The Conversation Before the Conversation

The conversations leaders regret aren’t usually the hard ones. They’re the easy ones we postpone.

New York, USA – Photo by Kevin Goldsmith – May, 2026

When I was a manager at Adobe, I had a senior engineer on my team whom I was lucky to have hired. He brought years of experience and a clear sense of where the platform’s architecture was breaking down. He kept trying to push some genuinely needed improvements, and he kept getting drowned out by other engineers who were louder, more emphatic, and very good at framing their priorities as emergencies.

I agreed with him. I just didn’t want to cause a confrontation with everyone else. He wasn’t argumentative, so disappointing him was the easier choice. He told me he was frustrated in one-on-one after one-on-one. I kept asking him to be patient. I kept telling myself I’d get to it.

By the time I decided to prioritize his work, he’d already accepted an offer somewhere else to lead an architecture group. It was a big loss for the team. He hadn’t given up on me. He’d just stopped believing the conversation he needed me to have was actually going to happen.

I lost him not from a wrong decision, but from not deciding soon enough. Delaying action was the cause.

Most regrets aren’t about the conversations we had

Leadership advice often focuses on how to have tough conversations, rather than when. Yet timing is where most leaders go wrong.

There’s a specific kind of regret most experienced leaders carry, even if they don’t talk about it. It isn’t the regret of having said the wrong thing. It’s the regret of not having said something earlier, when the situation was still small enough that a small conversation could have changed it. The senior engineer who should have been talked to before they took the offer elsewhere. The peer who should have been challenged on a pattern before it became a culture problem. The team that needed direct feedback before they decided you were absent on the issue that mattered most to them.

The phrase that gives it away every time is some version of “I knew earlier.” Usually followed by some version of “I didn’t have enough information yet.”

“I didn’t have enough information yet” is what we tell ourselves when we mean “I didn’t want to do this yet.”

Two costs that don’t show up on the same timescale

The surface question is when to bring something up. The actual tension lies between two costs that don’t show up on the same timescale.

The cost of being wrong is immediate and visible. You said something. The person was having a bad week. You damaged a relationship over what turned out to be nothing. I’ve done it. Most leaders have.

The cost of being right but late is delayed and diffused. The pattern hardens. The person adapts to the absence of feedback. The team makes up its own story about why nothing is being said. By the time the conversation is unavoidable, you’re no longer having the conversation you wanted to have. You’re managing the wreckage of not having had it.

Leaders tend to avoid the immediate, visible cost of being wrong, but quietly accept the bigger, invisible cost of waiting too long. Incomplete data isn’t a problem to solve; it is just part of leading.

Letting patterns persist teaches you to discount your instincts. Over time, this undermines your own judgment as a leader.

The conversation a manager didn’t have

A few years after the Adobe situation, I was at Spotify, and one of the managers reporting to me had a developer who wasn’t meeting expectations. The developer would get feedback, improve for a while, and then drift back. The manager kept seeing little signs of improvement and kept telling himself the next month would be different. He also wanted to be liked by everyone on the team, and the developer was friendly and well-meaning, which made the avoidance feel less like avoidance and more like patience.

After a few months of coaching him on how to handle it, I eventually scheduled a one-on-one with the developer myself. We had a direct conversation about where the gaps were, what specifically needed to change, and what would happen if it didn’t. The developer thanked me for the honesty, made real changes, and performed significantly better for years afterward.

If their manager had had that conversation earlier, the developer could have avoided months of struggle where they genuinely didn’t understand what they were doing wrong. The cost of waiting wasn’t borne by the manager. It was borne by the person who didn’t get the information they needed to do their job.

Five signals that the conversation is already overdue

When I find myself hesitating, I use a simple checklist to decide if it’s time for a conversation. There are five signals to watch for. If two or more are present, the conversation is already overdue. If only one shows up, I pay closer attention. Sometimes a single signal is enough to justify a check-in, especially if my gut says something is off. At the very least, I set a reminder to revisit and see if another signal appears. Acting early can be as simple as opening a small conversation or just staying intentionally observant.

The first is pattern, not incident. The same thing twice, with the same person or in the same situation. One occurrence is a data point. Two is the start of a trend you’re already discounting.

The second is distance. You’re hearing about the issue from somewhere other than the person involved, and the intensity of what you’re hearing is going up rather than down. Secondhand information getting louder is a leading indicator that the people closest to it have lost confidence that direct routes work.

The third is workarounds. You or someone else has started routing around the person or the topic. The team has quietly redistributed something. A peer has stopped looping them in. You’re choosing different agendas for your one-on-ones to avoid the area. The organization is adjusting before anyone has said anything out loud.

The fourth is cognitive load. You’re spending real mental energy on the avoidance itself, not on the underlying issue. You’re scripting the conversation in the shower. You’re rehearsing it on walks. The thing the situation costs you has stopped being the situation and started being the management of it.

The fifth is inflation. The version of the conversation you’re rehearsing keeps getting bigger. Three weeks ago, it was a casual check-in. Now it’s a serious sit-down. Soon you’ll be thinking about whether HR should be in the room. The seriousness of what you’re imagining is rising even when the situation hasn’t dramatically changed. That’s a tell that your own waiting is now the major factor in how the conversation will go.

This framework doesn’t tell you what to say. It reminds you that if you’re hesitating, your decision is already made. You’re just delaying action.

How to have the earlier version

Once you’ve decided the conversation needs to happen, the goal is to keep it small and recoverable.

Lead with observation, not interpretation. “I noticed X” lands very differently from “I’m worried you’re Y.” The observation can be discussed. The interpretation feels like a verdict.

Make the time deliberate, but small. Not a calendar invite labeled “feedback.” Not an ambush in the hallway. A brief, intentional opening that signals this is a conversation, not a performance review.

Be specific about what you noticed and nonspecific about what it means. The whole point of the earlier conversation is that you don’t yet know what it means. That’s why it’s still cheap.

Be willing to be wrong out loud. Something like “I might be reading this wrong, and if I am, tell me, because that’s also useful information.”

If you feel nervous before starting, a quick mindset shift can help: remind yourself that your goal is clarity, not confrontation. Take a moment to ask yourself: What do I actually see or notice? What outcome would I like? How can I make this feel like a two-way conversation rather than a verdict? Naming even one intention, such as “I want to help” or “I’m trying to understand”, grounds your approach. Sometimes, just taking a breath and framing your purpose before speaking builds confidence to begin.

If any of this sounds like nonviolent communication, it should. If you haven’t read that book, it’s worth your time.

Four ways the earlier conversation goes wrong

The first failure mode is saving it for the regular one-on-one next week. Timing kills it. By the time the slot comes up, you’ve reattached to the avoidance, and the conversation becomes a calendar item instead of a decision.

The second is loading the conversation with everything you’ve been holding back. The earlier version is supposed to be one thing. If you’re stacking up six months of accumulated observations, that’s a different conversation, and the person on the other end will receive it as an attack rather than a check-in.

The third is soft-pedaling to the point where the person doesn’t realize what you said. This is the one I struggled with the most. I’d say something like “I think it’s about time you might start considering how you communicate with the rest of the team,” when what I actually meant was “your communication style is alienating people and they’ve stopped listening to you.” I wrapped the message in so many caveats that the person would walk out thinking they’d received a polite suggestion for some future quarter. I’d walk out thinking I’d addressed it. Both of us were wrong. I’ve gotten better at this out of necessity, but I still catch myself, especially in writing. When I review something I’ve drafted, I now ask whether someone reading it would understand they need to do this now, or whether they’d read it as a suggestion they might think about at some unspecified later point. If it’s the second one, I will rewrite it.

The fourth is routing the conversation through HR or a formal process when it’s actually a relationship conversation. The minute it becomes procedural, you’ve changed what conversation you’re having, and you’ve lost the version that was still recoverable.

As a manager, I rarely regret the challenging conversations I had. My real regrets are the easy conversations I kept postponing, only to watch them become hard.

Why the wait feels responsible

There’s a reason this pattern is so common, especially among newer leaders. Raising something soft feels disloyal. It feels like questioning someone’s competence over a concern you can barely articulate. Most leaders would rather be wrong about timing than risk being wrong about the read. So they choose silence and call it patience.

The person on the other end almost always senses it. They see the workarounds. They notice the topic that doesn’t come up. The silence is louder than the leader thinks, and the absence of feedback is often interpreted in the worst possible way. If someone on your team is upset that other people seem to be routing around them and they don’t know why, that’s often what’s happening. The team adapted before anyone told them that the team was adapting.

One of the most effective ways to break this cycle is to foster a culture where people feel safe raising concerns early. Encourage openness by regularly asking for feedback, and make it clear that surfacing issues is valued, not penalized. Reinforce through your actions that bringing up problems will be met with curiosity rather than punishment. When people see this modeled consistently, it becomes easier for them to speak up, and the leader’s burden to spot and address every issue alone becomes lighter.

The rest of the team is watching too. If they see someone struggling and nothing visible is happening, they will invent a story. The story is rarely flattering to the leader. When the team starts adjusting around someone, your reputation is already adjusting too.

The human cost compounds. Each round of avoidance makes the next round easier to rationalize. After enough cycles, the leader is no longer avoiding a conversation. They’re avoiding their own role.

When waiting reaches the next level up

A few newsletters ago, I talked about a different version of this same mistake from my first CTO job. A conflict was building between the engineering and product teams over prioritization. The engineers kept flagging serious technical debt. The product team kept prioritizing new features. The same tension came up every planning cycle, and the engineers felt they were raising something real only to be overruled every time.

The chief product officer and I both saw it. We had a good working relationship, and we both did the thing that felt responsible. We coached our own sides and told ourselves we were giving the teams room to work it out. What we were actually doing was giving the problem room to grow.

Letting teams resolve their own conflicts is often the right call. The mistake was not noticing that this one had stopped resolving and started compounding.

Eventually, the conflict reached the CEO, not through me, not through my CPO peer. Someone from another part of the organization noticed the issue and mentioned it to him in passing. In our next one-on-one, the CEO said something that has stayed with me. “If it’s getting to me, that means it’s not being handled. And if it’s not being handled, I’m going to feel obligated to step in. I will do a worse job at it than either you or the CPO, because I’m further from the work.”

The cost of waiting wasn’t a number. It was my CEO doing a piece of my job in front of everyone who could see it. The harder cost was with my own engineers. They had been raising the technical debt problem for a long time, to their managers, to their directors, and eventually to me. My silence taught them something. The person who was supposed to have their back on technical health wasn’t visibly in the room on it.

A while after the dust settled, an engineer who’d been part of the original group left. In his exit conversation, he mentioned how long it had taken to resolve this problem, which was one of the reasons he started looking. Once the issue was resolved, he was already in loops with other companies.

The earlier version would have been small. A shared prioritization rule. An agreed-on tech debt budget. One joint planning session with the CPO. Cheap, slightly awkward. The version I actually had came after the CEO was already involved, with both teams dug in and a leader above me watching whether I could run my own organization.

What changed

Earlier in my career, my default was to wait. The reasoning sounded responsible. Get more data. Give people the benefit of the doubt. Don’t overreact. Don’t be the manager who pounces on one bad week.

What’s changed is the recognition that the data is rarely the bottleneck. The bottleneck is usually the willingness to be wrong out loud. Once you stop treating uncertainty as a reason to wait, the cost calculus inverts. The earlier conversation is almost always cheaper, even when you’re wrong.

The shift wasn’t from “wait” to “act fast.” It was from “wait until I’m sure” to “act when I notice.”

I used to think I was being patient. Most of the time, I was just being slow.

A test for this week

Pick the three people or situations you’ve been quietly avoiding bringing something up about. For each one, run the five signals: pattern, distance, workarounds, cognitive load, and inflation. If two or more are present, you’re not waiting for the right moment. You’ve already missed it. The right move is to schedule the smaller version this week, before it becomes the bigger one.

If you’re leading a remote or distributed team, pay extra attention: these signals can be subtler when you are not sharing physical space. Patterns may only show up in tone or delays in messages. Distance might appear as silence in group chats or people dropping off video calls quickly. Workarounds could mean people are excluded from smaller Slack threads or side meetings. Your own cognitive load might show as rereading written updates or hesitating to add an item to an agenda. Inflation often happens invisibly as issues compound without hallway conversations to surface them. Adapting your awareness to the remote context is key: be intentional about checking in, ask more frequently, and actively look for shifts that may not be obvious through a screen.

Performance management is something you do every week. Performance reviews are the box you file at the end. The earlier, smaller conversation is the actual work. Everything else is documentation of what you should have addressed sooner.

The conversation before the conversation is the cheapest version. Every version after gets more expensive.

To hear an extended discussion of this topic, please listen to my recent podcast episode: The Conversation Before the Conversation.

Working with the CEO

Close Enough to Influence, Independent Enough to Be Honest

Carmel, USA – Photo by Kevin Goldsmith – April, 2026

Recently, four people I mentor brought me different versions of the same problem in the span of a few days. One CTO was dealing with a founder-developer who still had strong opinions about how software should be built. Another had an operator CEO who was hands-off on technology until something broke, at which point they overreacted. A third had just discovered that their CEO was making decisions affecting their team without consulting them. And a fourth was trying to figure out how to respond to a CEO who had vibe-coded a prototype and couldn’t understand why the engineering team needed more than a few days to build the production version.

Stepping back, there are some familiar patterns here: each scenario involved a disconnect between the CTO and CEO on expectations, communication, and decision-making. Whether the CEO was too hands-on, too removed, or making unilateral decisions, the shared challenge was finding the right balance of influence, alignment, and honest partnership. These patterns are common for technology leaders, and recognizing them early helps you map your own challenges and approach.

Four people. Four different situations. All with the same core question: how do you build an effective relationship with your CEO?

This led me to reflect on my own experiences. I’ve reported to about half a dozen CEOs across companies of different sizes and stages. Every one of those relationships was different in ways that mattered. Not just because of personality, but because of what the CEO cared about, what they expected from me, and how much room there was for honest disagreement. The lesson that keeps coming back is that this relationship is something you have to build deliberately. It doesn’t just happen because you’re both competent.

Why this relationship is different

To understand why these relationships are challenging, consider how the CTO-to-CEO relationship is asymmetric, setting it apart from other working relationships. The CEO hired you (or chose not to let you go when they joined). They can fire you. They set your compensation. They determine how much room you have to operate. That part isn’t different from any boss-employee dynamic. But they also depend on your judgment in domains they often can’t evaluate themselves. They need to hear things honestly from you. And they have very narrow windows into your part of the organization: a weekly one-on-one, a staff meeting, maybe a few ad hoc conversations. That’s it. What they understand about your world comes almost entirely through what you choose to surface.

You need to be close enough to influence, independent enough to be honest, and aligned enough to execute even when you disagree. If you’re too close, you become a yes-person and stop adding value. If you’re too independent, you look like you’re running your own company inside the company. If you suppress every disagreement in the name of alignment, you let the company make avoidable mistakes.

When this relationship breaks, it rarely stays contained. The exec team senses it. The board senses it. Your directs sense it, and they start hedging. If the CRO sees you disagree with the CEO and still get respected, they’ll feel safer doing the same. If they see you get shut down, they learn to keep quiet. The CTO-CEO dynamic models what honesty and partnership look like for the entire leadership team.

Different CEOs, different problems

Each CEO has distinct attitudes and preferences, which present unique challenges. However, CEOs can be grouped by shared traits, which create distinct dynamics.

The founder-developer CEO still has strong opinions about how things should be built. When your CEO built version one, they have opinions wired differently than those of a CEO who came up through sales or marketing. Some of those opinions are gold. Some of them are artifacts of how they used to build things. Your job is to figure out which is which without being dismissive. I’ve worked for a founder who was a brilliant product mind and an exceptionally fast developer, but whose approach to building code worked well for a solo builder and wasn’t something you’d want to build an engineering organization around. Navigating that meant figuring out which areas they cared deeply about and which areas they’d acknowledge they didn’t know well. You push forward where you have room and tread carefully where you don’t.

I also worked for a founder-developer CEO who was very narrowly technical rather than broadly so. Deeply knowledgeable in specific areas, but without a full picture of the platform. That created a different challenge: they felt qualified to weigh in on technical decisions, and in their areas of depth, they often knew more than I did. In those areas, I deferred completely. In the areas where they didn’t claim expertise, I had more room to work.

The operator CEO, as is most common in my experience, is hands-off when it comes to technology. That seems freeing, but it isn’t. These CEOs lack context to judge severity, timing, or reasons for failures, and swing from ignoring problems to overreacting. A surprised CEO makes poor decisions. With this type, proactively build context: provide regular, concise updates, link technical health to business outcomes, and alert them before problems escalate.

Visionary CEOs, usually founders, bring constant new ideas and a strong drive for innovation. Their entrepreneurial mindset fuels company growth, but following every idea can drain focus from the core business. If you always say yes, you’ll be overwhelmed; saying no all the time may sideline you. Find areas to invest in, leveraging credibility so you can advise the CEO when an idea isn’t feasible right now.

The challenge isn’t finding the ‘best’ CEO type. The real test is recognizing who you’re working with and intentionally adapting your approach to make the relationship work.

The four foundations of CEO trust

Every successful CEO relationship I’ve seen shares four key foundations: competence, candor, commitment, and context. These consistently determine whether the partnership is strong or fragile.

Competence seems obvious, and technical leaders often assume it. But to a CEO, it’s not just technical depth. It’s your ability to translate technical details into business reality, deliver results, and spot problems early. CEOs judge competence by outcomes, not by engineers’ standards.

Candor is the hardest foundation to build and the easiest to lose. CEOs are surrounded by people who have incentives to shade the truth. If you become one of those people, you lose the thing that makes you most valuable. But candor without judgment is just complaining. Candor means: here’s the real situation, here’s what I think we should do, and here’s what I need from you. It also means telling the CEO when they’re wrong in your domain, and doing it in a way they can hear. Privately. With data. With a proposed alternative. Not in front of the board. Not in a group setting.

Commitment is what separates senior leaders from everyone else. Disagree and commit is easy to say and genuinely hard to do. It means your team never hears you undermine the decision. It means you run at it with full effort, not with one foot out the door waiting to say, “I told you so.” If your team can tell you disagree with the decision you’re executing, you’ve already failed the commitment test. Your behavior teaches the organization whether decisions are real or negotiable.

Context is the one most people miss. Competence, candor, and commitment can all be undermined if you and the CEO are operating from different mental models of how the business works. Building context means constantly translating between the engineering and business worlds. “We need to replatform” means nothing to most CEOs. “Our current architecture limits how fast we can ship features customers are asking for, and that’s contributing to churn” means everything. Building context goes both ways, though. You need to understand what the CEO is dealing with that you don’t see: board pressure, investor expectations, competitive moves, and how the rest of the exec team is pulling on them. When the CEO makes a decision that seems wrong to you, the first question to ask is: What context do they have that I don’t?

Making the relationship work day to day

Weekly one-on-ones with the CEO are non-negotiable. Protect them. If the CEO cancels frequently, that’s a signal you need to address directly. Use that time to pre-wire. Nothing that comes up in a staff or board meeting should be the first time the CEO hears it from you. Lead with conclusions, not context. Tell them what you think, then offer the supporting detail if they want to dig in.

Handle disagreements deliberately. Raise concerns before decisions are made. Bring data, not just opinions. Frame feedback as “here’s what I see and what I’d advise” instead of “I disagree.” If overruled, commit fully. Execute as if it were your idea. If it fails, you’ll have standing to revisit, having genuinely tried.

I learned about handling disagreement the hard way. At one company, I saw us heading in a direction I disagreed with. I raised my concerns. They were heard. We kept moving in that direction. I continued advocating until another member of the exec team pulled me aside and said, “This one’s over. This is the way we’re going now.” I hadn’t read the room. The decision had been made, and I was still arguing. I had to shift fully into execution mode, and I should have gotten there sooner.

Watch for the strategic vacuum. If you’re the only person on the exec team thinking past the current quarter, writing strategy documents, doing competitive analysis, pushing the team to plan for what’s coming, that’s both valuable and dangerous. Valuable because somebody has to do it. Dangerous because if the CEO isn’t co-owning that work, it can create resentment on both sides. If you’ve come from companies with more structure and you’re now at a place that doesn’t operate that way, the instinct to fill that gap is strong. But your current company exists because whatever they’ve been doing has worked for them so far. If you feel yourself becoming the lone operator, surface it directly: “I notice I’m driving a lot of the longer-term strategic thinking. I’m happy to do it, but I want to make sure we’re aligned on that being part of my role.”

When trust is eroding

By the time most leaders recognize that trust has eroded, it’s often too late. Here are the signals.

Signs the CEO is losing confidence in you: they start asking your directs for information instead of you (and not in the healthy way where you’ve pre-wired those relationships). They bring in outside advisors or consultants for things that should be your responsibility. Your one-on-one gets shorter, less frequent, or more transactional. You find out about decisions affecting your team after they’ve been made.

Signs you are losing trust in the CEO: you start building a case file of bad decisions, collecting evidence for an argument you haven’t made yet. You explain the CEO’s decisions to your team in ways that distance you from them (“the CEO wants us to” instead of “we need to”). You spend more energy managing around the CEO than working with them. You stop bringing up problems because you don’t think they’ll be heard.

If you catch yourself translating the CEO’s decisions into something your team can stomach, the relationship needs attention. You’re not a translator. You’re supposed to be a partner.

Understanding the human side

Most CEOs at growth-stage companies are under a lot of pressure from the board and investors that the rest of the exec team doesn’t fully see. They’re being evaluated quarterly. When a CEO takes a struggling function under themselves or suddenly elevates the priority of something that seemed peripheral, it’s often because that issue has reached the board level or they are concerned it will if it isn’t handled.

Understanding that pressure doesn’t mean excusing bad behavior. But it does mean adjusting your approach. A CEO isn’t going to blame the board, just like you aren’t going to blame the CEO to your team. If you sometimes see unusual behavior or weird pressure, there may be something going on that you don’t have visibility into. The best CEO relationships I’ve had are those in which the CEO trusted me enough to say, “The board is aware of this, and they’ve raised the priority.” Even when they can’t share that, recognizing the possibility changes how you respond.

When it’s time to go

Sometimes the relationship can’t be fixed. If the CEO consistently overrides you in your domain without engaging your reasoning. If your values don’t align with how to treat people or make decisions. If you’ve surfaced the issues directly multiple times, and nothing changes. If you’re staying because of inertia or compensation rather than belief in the direction. Those are signs of a role fit problem, not a relationship problem.

If you’re not that far gone, repair requires both sides. Be direct: “I think our working relationship isn’t where it needs to be, and I’d like to talk about what we can do about it.” That is a very hard sentence to say, but it is the only honest one. Propose specific changes. “I’d like us to use our one-on-one to pre-wire any staffing or budget decisions before they go to the broader team.” That’s actionable. “We should communicate more” is not. If you agree on specific changes, give it 90 days of real effort before deciding whether it’s working.

If you’ve done the work and the trust still isn’t there, leaving is a reasonable decision. It’s not failure. It’s recognizing a fit problem. The worst outcome is staying in a broken CEO relationship and letting it erode your judgment, energy, and your team’s trust. And if you’re feeling that the trust has broken down, they’re feeling it too. Every CEO I’ve worked with, when that alignment is gone, they’re already thinking about who comes next. By the time you’ve decided it’s not repairable, they’ve probably already made that decision and may already be interviewing.

What I got wrong early on

Earlier in my career, I thought the CEO relationship was mostly about competence. Deliver results, and the relationship takes care of itself. That turned out to be incomplete. Competence is table stakes. The relationship lives or dies on candor, commitment, and shared context.

I also used to think that disagreeing with the CEO was inherently risky, something to be done sparingly and carefully. Over time, I learned that the opposite is true. A CEO who doesn’t hear honest pushback from their CTO is flying blind. The risk isn’t pushing back. It’s not pushing back. You just have to do it the right way.

Working with founder-developer CEOs taught me something specific. Their technical opinions aren’t obstacles to manage. They’re signals about what the CEO values. Learning to distinguish between “I built this, and I’m attached to it” and “I’ve been watching customers, and I see something you don’t” made me a much better partner to founder-CEOs.

The CEO relationship is the highest-leverage relationship in your career as a technology leader. It determines your scope, your influence, your ability to protect your team, and whether you can do the job you were hired to do. If you want a starting point, ask yourself four questions before your next one-on-one: Does the CEO hear the truth from me? When we disagree, do we have a reliable process for working through it? Do I understand what they’re dealing with that I can’t see? And does my team see a partnership when they look at us, or a hierarchy?

If the answer to any of those is uncomfortable, you have work to do. And that work starts with you.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Working with the CEO: Close Enough to Influence, Independent Enough to Be Honest.

Originally published in my newsletter at: https://kevingoldsmith.substack.com/p/working-with-the-ceo

Talking to Executives: That’s Not a Derailment, That’s the Meeting

Why being understood matters more than being right

Seattle, USA – Photo by Kevin Goldsmith – February 2026

When I was starting out at Microsoft, I nearly derailed my first executive presentation over the word “avatar.”

We were building virtual world software, and I used “avatar” the way the industry did. The VP stopped me, insisting it wasn’t the right term based on its dictionary definition. I pushed back, stating it was accepted industry usage, and asked to move forward. He agreed, but became distant for the rest of the presentation.

Afterward, my boss’s boss pulled me aside. “If the VP wants to talk about a word, that’s what you talk about.” I was never invited to present to that VP again.

I was two years out of university. It was a painful lesson.

I’ve made a lot of mistakes in executive communication over the years, and I’ve been on both sides of that table long enough to understand why they happen. Before I was someone people presented to, I was terrified of the same thing. When I started at Adobe, my director was in San Jose while I was in Seattle. I’d see him present to the broader organization occasionally, but the first time he called me directly, I nearly froze. He just had a question about something, but I picked up the phone, heard his voice, and thought: “I’m talking to the director.” It felt enormous and scary.

I also know what it feels like to be on the receiving end of that anxiety. A few years later at Adobe, I was now a Director. A team that joined my organization set up a meeting to introduce themselves when I visited their office. I came to the conference room expecting to sit around the table and talk. Instead, I walked in to find a polished deck waiting for me, the whole team lined up, ready to present. It was the first time anyone had ever built a slide deck just for me. I felt guilty, honestly, because it was obvious they’d spent serious time on it, and I had just breezed in thinking we’d hang out. I understood immediately why they’d done it. But I also wanted to tell them: I’m just Kevin. You don’t have to do this.

The key: Executives are just people with different responsibilities. The anxiety you feel walking into that room is completely understandable, and mostly unnecessary.

What I learned the hard way from that Microsoft VP is that when you speak to executives, every word carries weight. The core tension is that you are closer to the work than they are. You’re the expert in your domain. But that doesn’t make you the expert in the room. You’re there because the thing you’re working on matters to them, not necessarily in the way it matters to you. Executives have the broader business context. You have the deeper technical context. They’re optimizing for risk, clarity, and decision making, not technical elegance.

Executives aren’t there to hear your whole presentation. They’re there to get something specific, and that something is usually part of a much larger set of conversations they’re having. If you give them a complete tour of your work and none of it is what they came for, they’ll interrupt you. Or they’ll check email. Or they’ll leave. Not out of disrespect, but because they have other things to do, and this meeting didn’t give them what they needed.

A framework: the four C’s

Before any executive communication, whether it’s a meeting, an email, or a Slack message, run through four questions.

Clarity. Are you using language that cannot be misinterpreted? Not your team’s language, not industry jargon. Plain language. Define terms the moment you use them, or don’t use them at all.

Context. Have you situated your topic inside the broader business picture, as best you understand it? You won’t have all their context. That’s fine. Show that you’re thinking past the narrow scope of your project. The executive you’re talking to is probably thinking about two other projects and how yours intersects with them. Meet them there as best as you can.

Consequence. Have you made it clear what happens if a decision is made or not made? Don’t assume the stakes are obvious. Say something like: “If we get the help we need, I’d put our odds of delivering on time at 70%. Without it, 30%.” That gives them something to act on. They’re not going to intuit the downstream implications of your team’s situation. You have to surface them.

Control. Are you demonstrating command of your subject, including its risks and trade-offs? Executives have usually been where you are. They can tell when someone is leaving something out, whether intentionally or because they haven’t thought it through. Either reading is bad for you.

If you skip answering one of these four questions, they’ll go hunting for the answer. That’s when the interruptions start and when you lose control of the room.

Calibrating your technical level

One common challenge in executive settings is explaining topics at the right level of technical detail for your audience. This challenge is called technical calibration: making sure your explanations match what your audience understands and needs, not just what is technically accurate.

Overexplaining occurs when you dive deeply into technical details with an audience that lacks the same technical background or expertise. For example, if you are a developer or a frontline engineering manager presenting to a mixed-background group, most will not be technical. If you go straight to implementation specifics without first gauging your audience’s familiarity, you risk losing them. I have seen this happen when I wanted to give team members exposure to the executive team. Despite my advice to focus on the business context, they presented too much technical detail. As a result, my peers disengaged—not out of disrespect, but because the level of information wasn’t appropriate for them. It can be tough to watch, especially knowing how much effort goes into preparing.

Under-explaining happens when you assume the audience shares your technical context and use unexplained terms or reference internal systems without clarification. Under-explaining can make your message opaque to executives, even if they don’t say so. Executives may not interrupt to ask, but will quietly disengage if they can’t follow the discussion. Clear technical calibration helps prevent this by defining terms and providing just enough context.

To technically calibrate, start by identifying your audience’s background and what matters to them. Focus your explanation on three areas: business impact, customer impact, and risk. These areas matter most to executives. Lead with what changes, who is affected, and what costs or risks are involved. Offer more technical details if requested, but always start with a clear context relevant to your audience’s familiarity.

Here’s something worth understanding about the translation problem. As a CTO, my job is to make complex technical realities legible to people who don’t live in technology. My peers on the executive team understand the broad strokes of engineering, but they’re not going to track a detailed architectural discussion, nor should they. I continuously hear fairly complicated things from people on my team, figure out what’s actually important in a business context, and translate them for my peers. That skill didn’t come naturally. I developed it by presenting to executives over the years and paying attention to what landed and what didn’t.

If you’re looking to move into senior technical leadership, this is not optional. The ability to translate your domain for non-technical peers is one of the most critical skills you can develop. In the first years of my career, I thought being technically correct was sufficient. What I eventually learned is that clarity and alignment matter more than precision. You can be right about everything and still fail to move anything if the people you’re talking to can’t follow you.

How to handle the room

A few more things worth knowing.

Lead with the conclusion. In written communication, especially, I see people bury the point. They walk me through everything that happened before telling me why they’re writing. Put the conclusion first. We have this problem. Here’s what I need. The background can follow, if I need it.

Plan to use half your time. If you’re given an hour, prepare for thirty minutes. You will get interrupted. Questions will go deep. Tangents will happen. If you’re done in half an hour and could have taken an hour, that’s a great outcome. It means you were clear and direct, leaving room for the conversation to go where it needed to. The executives you are presenting to will appreciate your brevity if it gives them time back in their day.

Say “I don’t know” when you don’t know. This is harder than it sounds. You’re in front of people who matter, and someone asks a question you can’t answer. The instinct is to approximate, to say it’s going pretty well, to give them something. Resist that. If you guess and you’re wrong, the next time they hear about your project from someone with the real information, they’ll wonder whether you were confused or covering something up. It’s more important for you to protect your credibility than your ego. If you don’t have an answer, commit to providing one as soon as possible after the meeting.

Treat interruptions as signals. If someone goes deep on something you considered minor, or starts a side conversation with the person next to them, that’s not a sign things are going badly. Something you said connected to a concern you’re not aware of. Stay with it. Follow it. Don’t try to reroute back to your slides. I’ve made this mistake. The executives started talking among themselves because something I’d said triggered a prior discussion. At a certain point, I was just standing at the front of the room waiting. I tried to bring them back because I was worried about running out of time. They didn’t have it. We ran out of time anyway. The deck got a “just send it over, sorry we ran out of time.” That is a common outcome from one of these meetings. Remember: your job in the room isn’t to get through your material at all costs—it’s to meet executives where they are and help them move things forward. If you do that, you’ve succeeded, even if the meeting doesn’t go as planned.

Executive brevity isn’t disinterest. Senior leaders in large companies can spend eight hours in meetings a day. They get direct because directness is how you survive that schedule. If they’re short with you, it probably just means they’re operating efficiently. Don’t confuse it with dismissal.

The view from the other side

Now that I’m regularly on the other side of these conversations, I recognize pretty quickly when someone is protecting their ego instead of informing me. When they get defensive about a challenge, when they oversell, when they’re more focused on how they look than on what I actually need to understand. And I recognize the opposite, too. When someone says, “I don’t know, but I’ll find out,” I trust them more, not less. When someone slows down and clarifies rather than powering through, I appreciate it.

What executives want from anyone presenting to them is to help them understand something so they can make a good decision. That’s it. You are not there to demonstrate your expertise. They already assume you have it. That’s why you’re in the room. You’re there to enable good decisions for the people you’re talking to.

Every word should either reduce ambiguity, increase alignment, or surface risk. Remember, every executive conversation is a chance to build trust and influence outcomes. Treat each as an opportunity to connect, learn, and shape direction.

Ask yourself one question before every executive interaction: Am I optimizing to be right, or am I optimizing to be understood?

The answer should always be the latter.

To hear an extended discussion of this topic, please listen to my recent podcast episode: Talking to Executives: That’s Not a Derailment, That’s the Meeting.

Originally published in my newsletter