You’ve just spent six months building something genuinely impressive. Maybe it’s a new data platform that consolidates five legacy systems into one. Maybe it’s a migration to cloud-native architecture that will save millions. Maybe it’s an AI capability that changes what your company can offer customers.
You walk into the executive team meeting. You show the architecture diagram. You explain the technical decisions. You’re proud of this work, and you should be.
The CEO nods politely. Then she asks: “But what does this mean for revenue?”
And you realise you’ve just given a fifteen-minute presentation that answered none of the questions your boss actually cares about.
This is not a communication problem. You communicate just fine with your engineering team, your peers at other companies, your conference audiences. This is a managing up problem. And it’s one of the most common struggles for technology leaders who report to non-technical executives.
What Managing Up Actually Means
Let me be direct about what managing up isn’t. It’s not manipulation. It’s not corporate politics. It’s not saying what people want to hear regardless of whether it’s true. Those are the cynical interpretations, and they make competent people avoid the concept entirely, which is a shame.
Managing up is understanding what your boss cares about and framing your work in those terms. Your CEO cares about four things: revenue, risk, competitive position, and customer satisfaction. Everything else is a subset of those four. Every technology initiative you run, every platform you build, every team you hire – it either connects to one of those four things or you can’t explain why you’re doing it.
That’s not dumbing things down. It’s translating them into the language of business outcomes. And it’s a skill, not a personality trait. You can get better at it.
The Translation Layer
Every technology initiative needs a one-sentence business case. Not a technical justification – a business case. Here’s the difference:
- Technical: “We’re migrating to Kubernetes to improve container orchestration and reduce infrastructure complexity.”
- Business: “We’re cutting infrastructure costs by 30% and shipping features twice as fast.”
- Technical: “We’re implementing a lakehouse architecture to unify our batch and streaming data pipelines.”
- Business: “We’re giving the sales team real-time customer insights that’ll improve conversion rates.”
- Technical: “We’re refactoring the monolith into microservices.”
- Business: “We’re reducing the time it takes to launch new products from three months to three weeks.”
You know this in theory. Most technology leaders do. But doing it consistently, in every conversation, in every email, in every slide deck – that’s where it breaks down. It requires a mental gear shift that doesn’t come naturally to people who’ve spent their careers thinking in terms of systems and architectures.
One trick that works: before every meeting with your CEO or the executive team, write down the one sentence that connects your update to a business outcome. If you can’t write that sentence, reconsider whether the update belongs in that meeting.
Frequency and Format
Most technology leaders under-communicate with their CEO. They wait for the monthly one-on-one, prepare a dense deck, walk through it in detail, and wonder why the CEO still doesn’t fully understand what the technology organisation does.
Monthly is not enough. Not even close.
What works better: a weekly touchpoint. It doesn’t need to be a formal meeting. A Friday email with three bullet points is often more effective than a monthly review. The three bullets are simple:
- What shipped this week – in business terms, not technical ones
- What’s blocked – and what you need from the CEO or the executive team to unblock it
- What’s coming next week – so there are no surprises
This does two things. First, it keeps your work visible in a way that monthly check-ins can’t. Executives have short attention spans for things outside their core expertise. If they don’t hear from you for four weeks, technology fades into the background. Second, it builds a track record. After three months of Friday emails showing consistent delivery, you’ve established credibility that no quarterly review deck could match.
Some CEOs prefer a five-minute standup instead of an email. Some want a shared dashboard they can check when they feel like it. The format matters less than the consistency. Figure out what your CEO prefers and do that. If you’re unsure, ask. That question alone demonstrates the kind of awareness that managing up requires.
Managing Expectations
I know “underpromise and overdeliver” is a cliche. It’s a cliche because it’s correct and because almost nobody actually does it consistently in technology leadership.
The temptation to be optimistic in front of your CEO is powerful. You want to impress. You want to show ambition. So when she asks how long the new feature will take, you give the best-case estimate instead of the realistic one. When the board asks about the AI roadmap, you paint the picture of what’s possible rather than what’s probable.
This feels good in the moment and creates problems in every subsequent moment. Technology timelines are inherently uncertain. Dependencies shift. Key people leave. Requirements change. If you promised eight weeks and it takes twelve, you’ve damaged trust even though twelve weeks was perfectly reasonable.
Build in buffer. Communicate early when things slip. Don’t wait until the deadline to explain why you’re going to miss it – flag the risk as soon as you see it. A CEO who hears “we might be two weeks late because of an integration issue, and here’s how we’re addressing it” three weeks before the deadline can adjust. A CEO who hears “we’re late” on the day it was supposed to ship feels blindsided. Surprises destroy trust faster than anything else.
When Your CEO Micromanages Technology Decisions
If your CEO is getting involved in vendor selection, questioning architectural decisions, or insisting on specific features, there’s a reason. And the reason is almost always that they’ve been burned before.
Maybe the last CTO overspent by $2 million on a platform that never delivered value. Maybe a critical system went down for 48 hours and the CEO had to explain it to the board. Maybe they approved a technology strategy they didn’t understand, and it turned into an expensive mistake. Once that happens, trust is broken, and a CEO who’s been burned on technology will micromanage until they feel safe again.
You can’t fix this by arguing for autonomy. You fix it by earning it back. Start with small, visible wins. Pick a project with a clear business outcome, a short timeline, and a high probability of success. Deliver it on time. Then do it again. After three or four visible wins, most CEOs will start loosening their grip. They’re not trying to control you – they’re trying to protect themselves from another bad outcome.
This is frustrating when you know you’re competent and the micromanagement feels unwarranted. But the trust deficit isn’t about you personally. It’s about the role and its history. Rebuild the trust, and the space to operate follows.
Our guide on presenting to the board as a technology leader covers the mechanics of building this kind of credibility in formal settings.
The Peer Dimension
Managing up isn’t just about your relationship with the CEO. It’s about managing across – your relationships with the CFO, the COO, the CMO, and every other member of the executive team.
Technology touches everything. Which means you have stakeholders in every function. And if those stakeholders hear about something from someone other than you first, you’ve already lost the framing.
The CFO who discovers your cloud bill increased by 40% before you’ve explained the ROI is going to be hostile. The CMO who learns from a vendor that you’re evaluating a new martech platform is going to feel bypassed. The COO who finds out your team is building an automation tool that affects operations workflows is going to feel blindsided.
Proactive communication with your C-suite peers prevents most of these conflicts. A ten-minute coffee with the CFO before the budget review. A heads-up to the CMO before you start evaluating their vendors. A conversation with the COO before your automation initiative touches their team.
This feels like overhead. It’s not. It’s the difference between being seen as a collaborative executive and being seen as someone who operates in a silo. And that perception directly affects how much support you get for your initiatives when budget decisions are made.
Understanding the dynamics between CTO and VP Engineering roles is also important here, because how your leadership structure maps to the rest of the C-suite affects every one of these relationships.
Building Executive Presence
There’s a softer dimension to managing up that technology leaders sometimes resist: executive presence. The way you carry yourself in the room, the confidence with which you make recommendations, your ability to disagree constructively with other executives – these things matter.
I’ve seen technically brilliant CTOs get sidelined in executive discussions because they couldn’t hold the room. They’d present data, get challenged by the CFO, and retreat into technical detail instead of standing their ground with business arguments. The CEO watches these interactions. They’re forming judgments about whether you can operate at the leadership level, not just the technical one.
Executive presence isn’t about charisma or being the loudest voice. It’s about clarity, confidence, and the ability to make complex things simple without making them simplistic. We’ve written a detailed executive presence guide that covers this in depth.
CTO-specific programmes at schools like Berkeley, MIT, and Kellogg often dedicate significant time to this exact skill. It’s one of the reasons experienced technology leaders say executive education was worthwhile even when they already knew the technical and strategic content – the peer dynamics and presentation coaching filled a gap that purely technical experience doesn’t address.
The Classic Framework Still Applies
HBR’s foundational work on managing up identified something that remains true decades later: the relationship with your boss is a mutual dependency. They need you to deliver results. You need them to provide resources, remove obstacles, and advocate for your team. When that relationship works well, both sides benefit. When it doesn’t, the subordinate almost always suffers more.
For technology leaders specifically, the dependency is even more pronounced. Your CEO probably can’t evaluate your technical decisions independently. They’re relying on your judgment, your honesty about what’s working and what isn’t, and your ability to translate between the technical and business worlds. That’s an enormous amount of trust. Treat it accordingly.
Practical Steps to Start This Week
If you’ve read this far and recognised some of your own patterns, here’s what to do about it.
First, start the weekly update. Pick a format – email, Slack message, five-minute standup, whatever works for your CEO. Start this Friday. Don’t overthink it. Three bullet points. Business language. Ship it.
Second, audit your next presentation. Take whatever deck or update you’re planning to share with the executive team and ruthlessly strip out anything that doesn’t connect to a business outcome. If a slide requires technical knowledge to understand, rewrite it or cut it.
Third, schedule a coffee with your most important peer. Whichever C-suite executive you interact with most – probably the CFO or COO – have an informal conversation about what they need from your team and what concerns they have. Just listen. The information you get will change how you prioritise.
Fourth, read Will Larson’s writing on the first ninety days for a CTO or VP Engineering. Even if you’re past your first ninety days, the frameworks for building executive relationships are directly applicable.
Managing up is a skill. Like any skill, it gets better with practice and worse with neglect. The technology leaders who get the biggest budgets, the most autonomy, and the strongest CEO relationships aren’t necessarily the best technologists. They’re the ones who figured out how to make their work visible, relevant, and understood by the people making resource allocation decisions.
That’s not selling out. That’s being effective.
Ben is a full-time data leadership professional and a part-time blogger.
When he’s not writing articles for Data Driven Daily, Ben is a Head of Data Strategy at a large financial institution.
He has over 14 years’ experience in Banking and Financial Services, during which he has led large data engineering and business intelligence teams, managed cloud migration programs, and spearheaded regulatory change initiatives.