The VP Isn’t Ignoring You - Jan Schulte
SubscribeSign in
The VP Isn’t Ignoring You<br>Why your best technical arguments go nowhere, and the frame that fixes it.
Jan Schulte<br>Aug 03, 2026
Share
You’re three sentences into explaining why the caching layer needs a rewrite when you notice it: The VP’s eyes have drifted to their laptop. Not rude, exactly. Just that specific kind of done-listening people do when they’ve already decided a conversation doesn’t apply to them.<br>Strange thing is, you gave the same explanation to two senior engineers last week. They leaned in, asked good follow-up questions. Nobody reached for a laptop.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.
Subscribe
So it’s not the idea. And it’s probably not you. Something happens to your explanations specifically in that room, and it’s not what you’d guess.<br>Here’s what’s actually going on. When you talk to another engineer, you’re both running the same internal checklist: is this well-factored, does it reduce complexity, will it hold up under load. You don’t have to explain the checklist. You both already have it.<br>The VP has a checklist too. It’s just a different one: does this help us win new customers, does it reduce downtime, does it cost less to run?<br>When you walk in and start talking about clean abstractions and best practices, none of it maps to anything on their list. It’s not that you’re talking in difficult terms. Instead, none of your sentences resolve to a number they’re already tracking. So the meeting just slides past you.<br>This isn’t unique to VPs, either. Remember when you first started coding? Software development lifecycle, version control, design patterns. None of it meant anything until you had enough context to see what problem each one solved.<br>You weren’t stupid before you learned that. You just hadn’t built the checklist yet. The same thing is happening here, in the other direction. They haven’t built your checklist, and you haven’t built theirs.<br>So, if you want VPs and other business people in the company to listen to you, start with this:<br>During the next engineering discussion about style guides, technical feasibility, elegance, whatever it might be, stop litigating technical points. Instead, start asking if any of these talking points move a needle the business side cares about (uptime, reliability, new features, and so on).<br>Run your team’s decisions through questions like these:<br>Does this style guide argument actually change our shipping speed?<br>Does rewriting this in [language] improve reliability, or just satisfy taste?<br>Does this refactor buy us velocity, or just tidiness?<br>That’s the yardstick. Once you’re using it, you’re not just answering the VPs better in meetings. You’re running your own team discussions differently, because half the arguments that used to eat an afternoon don’t survive first contact with “does this move a number.”<br>Here’s the part that’s easy to get backwards, though: it’s not that VPs can’t follow technical reasoning. They run cost-benefit models all day. Every hire, every vendor contract, every roadmap quarter gets put through the same if-this-then-that logic you use to argue for a refactor. They’re not less analytical than you. They’re running the same kind of analysis, just pointed at a different system. Not the codebase. The P&L.<br>So “speak their language” doesn’t mean dumb it down. It means aim the same rigor you already have at a different variable. Not “this abstraction is cleaner,” but “this cuts incident response time by 40 percent, and that’s what’s been costing us in support escalations.”<br>Next time you’re in the room, you say it plainly: “We improved reliability this much. No downtime last week.” That’s a sentence they can act on. Downtime means angry customers, and angry customers eventually cost you, whether that’s an SLA payout or a customer who churns.<br>You haven’t changed what you believe about good code. You’ve just started pointing it at a number someone else is already watching.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.
Subscribe
Share
Discussion about this post<br>CommentsRestacks
Ready for more?
Subscribe
© 2026 Jan Schulte · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app<br>Substack is the home for great culture
This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts