Becoming a Business Leader, Not Just a Technical One
Stop treating business fluency as someone else's job
A few weeks ago, I was on a call with a CTO I mentor. His company was entering an acquisition process, and he wanted to walk through the technical due diligence deck he was preparing. We talked about it for a while, but the part of the call that mattered wasn’t about the deck. It was about everything around the deck.
Who was the acquirer, and why were they actually interested? How was the deal being financed? What were they really asking when they asked their questions, and what was the question behind the question? When does too much honesty hurt the deal, and when does too much polish hurt you later? What does a management carve-out actually mean for him personally?
He was ready to walk in and give a strong technical presentation. What he needed was a business presentation that happened to include technical content. Those are very different things, and the gap between them is what I want to talk about.
This gap shows up everywhere at the senior technical leadership level. Most directors, VPs, and CTOs are technically excellent and organizationally capable by the time they earn their titles. A lot of them hit a ceiling not because of either of those things, but because the conversation moves from “is this the right architecture” to “is this the right business,” and they keep answering the first question.
The framing of technical versus business has been done to death, and it’s not quite right. The issue isn’t technical versus business skills; it’s recalibrating technical instincts for business leadership. Senior technical leaders excel at correctness, but at the business level, the core task becomes selecting the right trade-off for the company’s goals, given what you know about the market, customers, cash position, team, timing, and the competitive landscape, which gives you the best shot at winning, not simply finding the correct technical answer.
There are a few instincts that have to give way. The instinct to give the complete, technically accurate answer runs into the need to give the answer the room can act on. The instinct to optimize for correctness runs into the need to optimize for commercial outcomes under uncertainty. The instinct to stay in your lane, because that’s finance’s job or that’s sales’ job, runs into the expectation that at senior levels you’re contributing to every lane, whether you feel ready for it or not.
If you don’t make the shift, the consequences are quiet, but they’re real. You become the person who gets consulted on technology and bypassed on everything else. You lose influence over decisions that directly shape what your team gets to work on. You become a cost center in your CEO’s mental model, not a growth driver. And your career caps out before you ever get the title you’ve been working toward. The ceiling between a senior technical leader and an executive isn’t a technical ceiling. It’s a business fluency ceiling, and most people don’t see it until they’ve hit it.
I got lucky. Before I made the move to director, I worked on a product at Adobe called Revel, which was structured like a small company within a big one. I sat at a table with finance, marketing, product, design, and business leadership, and we’d meet to discuss how the product was doing and where it was headed. That isn’t the kind of room you usually get into as a senior IC or first-line manager at a company the size of Adobe. Watching the marketing lead frame customer demand in commercial terms, listening to product and finance argue about positioning in ways that had nothing to do with the technology, getting asked for opinions on things outside my expertise: that’s where I started to understand what business fluency actually looked like in practice. I got to learn it as a participant before I was the one being held accountable for the outcomes.
When I took my first CTO role, I learned that reporting to a CEO is a completely different relationship than reporting to a CTO. Suddenly, I was in the room for conversations about pricing, sales strategy, competitive threats, and board dynamics. Nobody had prepared me for any of it. And what I noticed in those early exec meetings was that if I stayed in my lane, because I thought that a decision was clearly marketing’s call or sales’ call, people stopped turning to me. At first, they’d look to me for my take. Then they stopped, because I wasn’t contributing. My peers were all weighing in on each other’s areas, and I wasn’t. If I wanted to be a full member of the team, I had to know enough about those roles to participate. Nobody was going to train me. I had to train myself.
The thing that’s moved me from technical executive to company executive, across every company I’ve been at since, has been the same. Learning how the business actually makes money, where it loses money, who it competes with, and how every technical decision eventually translates into one of those three things. At a certain level, the best thing you can do for your technical career is stop treating business fluency as someone else’s job.
Four moves of business fluency
I think about this in terms of four moves: translate, trade-off, commit, and compound.
Translate. Every technical statement has a business equivalent. Learn to give both, in the order the audience needs. “We have scaling limits in our pipeline” becomes “we can handle thirty percent growth before we have to stop shipping features for a quarter to rebuild it.” “Our platform has significant tech debt” becomes “we’re paying roughly a twenty percent tax on every new feature, and that tax is growing.” This isn’t about dumbing things down. The business consequence is the part the room actually cares about, and many technical leaders bury it.
Trade-off. Every business decision is a trade-off between competing goods. Your job is to articulate the trade-off cleanly enough that the room can decide. Not “we should do A,” but “we can do A, which costs us B, or we can do B, which costs us A, and here’s what I’d pick and why.” The room rarely wants your recommendation first. It wants the shape of the decision first and your recommendation second. If you lead with the conclusion, people will start trying to reverse-engineer the alternatives you skipped over. Give them the shape, then give them your call.
Commit. Once the business makes a decision, your job is to deliver on it, even when the call wasn’t the one you’d have made. Disagreeing up the chain and then committing downstream is one of the most telling signals of executive maturity. People who keep relitigating decisions they lost are exhausting to work with, and at the exec level, it’s often disqualifying.
Compound. Business fluency is built, not granted. Every conversation, every meeting, every budget cycle is a chance to add to your understanding of how the business actually works. The leaders who get strong at this treat it as an ongoing practice, not something you acquire once and check off.
The point of the framework is that business fluency isn’t a personality trait or a talent you’re born with. It’s four learnable moves you can practice in any meeting starting tomorrow.
Where fluency actually gets built
The framework is the mind shift. The work happens in four contexts, where you can either build fluency or fail to do so.
The first is profit and loss, unit economics, and cost structure. What are your top three revenue lines? Your top three cost lines? What’s your gross margin, your burn rate, or cash position, your growth rate on each of those? You can get this from your financials. At a public company, the information is public and discussed quarterly. At a smaller company, it usually shows up in town halls, or you can ask someone in finance, and often they’ll share it. Understand your own function as a cost line: what does engineering cost per month as a percentage of revenue, and how does that compare to industry benchmarks? When the CFO is squeezed, those are the numbers driving the conversation.
Understand the unit economics specific to your business. SaaS has CAC, LTV, payback period, and net revenue retention. Marketplaces have take rate, liquidity, and repeat rate. Ad businesses have fill rate, CPM, and match rate. You don’t need to be fluent in all of them. You need to be fluent in the handful of words that describe your business. I’ve been a CTO in marketplacees, SaaS, and fintech businesses, and each had a different set of metrics I had to learn well enough to have meaningful conversations about how to move them forward.
What usually breaks here is engineers treating the cloud bill as fixed overhead rather than something they can influence, and leaders showing up to budget conversations with a list of things they want rather than a model of what each thing costs the company. When a developer asks why we don’t just use some expensive tool, the answer is rarely “no.” It’s “did you budget for it, what does it do to our margin, and what does it earn back in productivity or revenue?” That’s a conversation a developer rarely has to have. It’s one a CTO has to have constantly.
The second context is sales and customer-facing work. Get on customer calls, not as a prop and not as a demo unit, but as a listener. Understand what customers are actually buying, what they’re struggling with, and what they almost bought from a competitor instead. Understand your sales motion: inbound or outbound, product-led or enterprise, transactional or solution-sold. Each motion has completely different implications for what engineering should prioritize.
Support sales strategically, not reactively. If you’re flying to every customer because sales asked, you aren’t a CTO; you’re a very expensive sales engineer. If you never show up, you aren’t integrated. The skill is picking the customers and the moments where your presence actually moves the deal. And listen to the gap between what sales tells you customers want and what customers actually say. Sales reps will tell you a feature is critical because the customer mentioned it. If you were on the call and heard the customer say, “Yeah, that would be nice,” you can have a more honest conversation about priorities. Understanding your sales team’s compensation structure helps, too. Reps do what they’re comped to do. If they’re pushing hard for something that doesn’t fit the roadmap, nine times out of ten, it’s because their comp plan rewards closing the deal that needs it.
The third context is fundraising and investor relations. In a fundraise, the CTO’s job isn’t just to pitch the technology. It’s to make the technology risk understandable and bounded for investors who are evaluating a business, not a product. Investors care about four things from you: can the team build what the business plan requires, is the technical approach defensible, are there technical risks that could sink the company, and is the technology you’ve built valuable IP. Everything you say should serve one of those four.
Technical due diligence is an interview, but it’s also a negotiation. The questions you get asked tell you what the investor or acquirer is worried about. Listen for that. Questions about team composition are often about retention costs or headcount reductions. Questions about architecture often concern integration challenges or platform consolidation. Questions about tech debt are often about compatibility or cost-reduction opportunities. Be honest, but don’t oversell. “Infinitely scalable” is a lie you’ll regret. “We’re designed to scale, and we haven’t found a ceiling yet” is true, useful, and defensible. And know what kind of investor you’re talking to. A growth equity firm has different motivations than a strategic acquirer, which in turn differs from a PE firm doing a debt-financed roll-up. Your story has to fit their thesis, or there’s no deal.
The fourth context is strategy and resource allocation. Show up to strategic conversations with a point of view on the business, not just on the technology. If the executive team is debating whether to enter a new market, the CTO who says, “Here’s what it would take to build for that market” is adding value. The CTO who says, “Here’s what I’ve seen about the competitive dynamics in that market, and here’s my take on whether it plays to our strengths,” is a different kind of leader. If you only have opinions on the technology, you only get consulted on the technology. Learn to read a strategic plan. When the company says it’s going up-market, what does that mean for product, sales, customer success, and engineering? When the company says it’s focused on efficiency, what trade-offs are implicit in that?
The people around you
Your CEO almost certainly hired you, hoping for a business partner, not just an engineering leader. Most CEOs do. If you stay in the technical lane, you’re quietly disappointing them, even when your teams are shipping well. This is the gap that ends many CTO tenures prematurely.
Your peers, the CPO, CFO, CRO, CMO, and COO, are going to calibrate you in the first few exec meetings. If you only show up with technical answers, you get specialist treatment for the rest of your tenure. If you show up with a view on the business, you get peer treatment. Neither calibration is easy to undo once it’s set.
Your team is watching too. Engineers track what their leaders care about. If you only talk about latency, reliability, and architecture, you train your organization to focus only on those things. If you also talk about revenue, customers, and competitors, you train your organization to connect its work to outcomes. That’s culture-setting work, and most leaders don’t realize they’re doing it.
A few cautions. Some technical leaders swing too far the other way. They get excited about business fluency, start using financial vocabulary loosely, and make strategic pronouncements that their peers find presumptuous. Knowing the language well enough to follow the conversation is different from knowing the work well enough to weigh in on it, and it pays to be honest with yourself about where you actually are. And some of your senior engineers will read business-forward leadership as selling out. You’ll lose some credibility with the deep technical crowd. That’s a real cost, but it’s worth paying. You can mitigate some of it by helping engineers see how their work directly connects to business outcomes, but some loss is unavoidable.
What changed for me
I used to think business fluency was something I’d pick up naturally as I got more senior. That was wrong. Seniority creates the expectation of fluency, not the fluency itself. You have to build it on purpose.
I also used to think my job as a technical leader was to protect engineering from the business, to be the translator who kept the business from making bad technical decisions. That’s a useful function, and it’s also a way to stay in the technical lane forever. At some point, the job is to stop protecting engineering from the business and start representing the business inside engineering.
Working with directors and VPs preparing for CTO roles has changed my view, too. I used to think business fluency was something you either had or didn’t. Now I’ve watched people build it deliberately, one customer call, one budget cycle, one fundraise at a time. It’s not a trait you discover you have. It’s a habit you build, and most people who get good at it just put in the reps.
I used to measure my value by how good my technical judgment was. Now I measure it by how often my judgment actually changes what the business does, which is a different measurement and usually a more honest one.
The path from senior technical leader to executive isn’t a title change. It’s a change in what you pay attention to, what you walk into meetings prepared to say, and what questions you ask of your own decisions.
Here’s a test. In your last three exec-level meetings, how many of your contributions were technical and how many were commercial? If the ratio is nine to one, you’re still being read as a specialist, even if your title says otherwise. Pick one of the four contexts, P&L, sales, fundraising, or strategy, and go spend real time there this quarter. Not a lunch. Real-time. Sit in the meetings. Read the documents. Ask the dumb questions. Write down the words you don’t know and look them up later.
If you want to see your growth, keep a simple journal or running document for a month. For each cross-functional meeting, jot down notes about your contributions: Was it technical, commercial, or a blend? Did you ask at least one business-focused question? What business terms or concepts did you need to look up? Review your notes every couple of weeks to look for trends. Over time, you’ll notice your commercial contributions increasing, understand more business vocabulary, and start tracking your progress in a very tangible way. Even a quick end-of-week self-assessment can help you spot areas for improvement and stay motivated.
The shortcut is that there is no shortcut, but it compounds fast once you start. I was completely ignorant of corporate finance not that many years ago. Now I’m reasonably fluent, and the only reason is that I read the documents, asked the dumb questions, looked up what I didn’t know, and kept at it. After a while, the vocabulary stopped being foreign, and the conversations started making sense, and then it just started building on itself.
Your company doesn’t need another technical expert at the exec table. It needs a business leader who happens to be the strongest technical mind in the room. That’s a different job, and it’s the one you were hired for, whether anyone told you or not.
To hear an extended discussion of this topic, please listen to my most recent podcast episode: Becoming a Business Leader.
Thanks again for reading! If you find it helpful, please share it with your friends.
Buy on Amazon | Buy on Bookshop.org | Buy on Audible | Other stores
The example section - "Where fluency actually gets built" is very helpful.