In the engineering edition, we focused on what individual engineers can do to help their managers succeed. The underlying idea was simple: by proactively providing context, updates, and clarity, engineers reduce the need for managers to micromanage. When managers don't have to chase information, they can focus on removing obstacles instead of creating them. On a higher level, however, the same dynamic plays out again. CTOs are not immune to falling into the very trap they try to prevent within their teams.
Technology is not the hard part
CTOs often come from an engineering background. For newly promoted CTOs, especially, the natural instinct is to double down on what they know best: technology. They review architectural decisions, dive into codebases, and get deeply involved in technical discussions. That behaviour is understandable. After all, it's what made them successful in their previous role. But while technology remains important, it is rarely the hardest part of the CTO job.
The real challenge lies elsewhere. A CTO's most important responsibility is aligning the technical team with the company's business goals. If the engineering organisation is not clearly contributing to those goals, it slowly starts drifting into irrelevance. Features may be shipped, systems may be refactored, and performance may improve, but if none of that maps to tangible business outcomes, the technical team risks being seen as a cost centre rather than a strategic asset. That is the fastest route to making yourself and your team obsolete.
Playing on both sides: management and engineers
To avoid that outcome, a CTO needs to become fluent in communication across very different audiences. On one side sits the technical team. Engineers need context, not just instructions. They need to understand why something is being built, what problem it solves, and how it fits into the bigger picture. That context cannot be given once and assumed to be absorbed. Repetition is essential. In recurring meetings, the product roadmap should resurface again and again. When a new feature is taking shape, its progress should be shared early, and the team should be invited to give input. The worst scenario is one in which silos form, and product management starts throwing feature passports over the wall for engineers to execute without understanding the rationale behind them.
On the other side sits the management team. Here, the conversation changes. Management needs clarity on what the technical team is building and when it can reasonably be delivered. A roadmap is crucial, and as a CTO, you need to own it. Ideally, this consists of a short-term roadmap covering roughly the next three months that clearly outlines what will be delivered and in what order. Alongside that, a longer-term roadmap helps frame future discussions and allows management to prioritise in advance. Importantly, don't treat the roadmap as set in stone. Priorities should not shift weekly, but when a genuinely promising customer or opportunity appears, adjusting the plan a few weeks out can make sense. The key is that these changes are deliberate and communicated, not reactive and chaotic.
Don't become a project manager
This is where communication becomes critical. If, as a CTO, you keep framing discussions in purely technical terms, explaining that the team really wants to get rid of an old Node.js API, your management peers will quickly disengage. Technical motivations rarely resonate at that level. What matters is the business impact. What does removing that API enable? Does it reduce customer churn, improve stability, or speed up feature delivery? If the answer is "nothing meaningful," then perhaps the team shouldn't be working on it at all.
Speaking in the language of the business
When you fail to speak the language of the business, others will start filling that gap for you. Sales will push urgency. Stakeholders will demand features with statements like, "We really need this next week; I have a customer waiting for it." Slowly, your role shifts. Instead of setting technical direction and helping shape strategy, you become a project manager executing incoming requests. The only question you hear is "When will it be done?"
As a CTO, it's your responsibility to make the trade-offs explicit. Yes, the team can drop everything and start working on a new feature. But that also means the current work goes stale and becomes more expensive to pick up later. If the old Node.js API isn't removed, it will continue to require maintenance and might be responsible for 80% of user issues, slowing the team down in the long run. These consequences must be articulated clearly and repeatedly, so decisions are made with eyes wide open.
Continuous communication
So, how often should a CTO communicate? As frequently as possible, without spamming. In recurring meetings, the roadmap should be brought back into the conversation. Show it, explain it, and invite discussion. With the engineering team, frame it as a direction: this is where we want to go and why. With the management team, use it as a checkpoint: are we still supporting the business in the way it needs right now?
One of madewithlove's fractional CTOs, @Mike Veerman, has the habit of sending a short email every Friday summarising what the team worked on and what's planned for the coming week. It's a simple habit, but a powerful one. It removes guesswork for external stakeholders and prevents assumptions from forming. Every week, people know what's happening and what to expect next. That level of transparency builds trust almost automatically.
People process information differently, so communication should take many forms. Written updates, explanations in meetings, short demo videos, and roadmap timelines. All of them reinforce the same message. It might sound like a lot of work, but the alternative is worse: people filling in the gaps with their own assumptions. A message needs to be heard 7 times in 7 different ways to be "heard". If it feels repetitive to you, it's probably just starting to sink in for others.
Follow our bi-weekly insights on Spotify: where Dimitri and Andreas discuss what they're seeing at SaaS teams and trends they're watching closely.
Keeping the priority
One of the most common pitfalls for CTOs is failing to confront people with the consequences of their requests. Management, sales, and external stakeholders are often very close to customers. They hear that feature X will unlock a deal, so they push for it immediately. This results in a constant stream of new priorities: a bug that needs fixing, a customer request that "can't wait," a report required by the board.
If you don't push back in those moments, people will assume you are working on everything. The current plan, to deliver X to achieve business goal Y, slowly dissolves into noise. It's your responsibility to reflect the situation back to them. If we switch focus now, we leave a half-finished feature behind, and picking it up later will cost extra time. Do we really want to do that? By explicitly stating the trade-offs, you force prioritisation instead of letting it happen implicitly.
Execute with vision
Ultimately, you want to avoid at all costs that the technical team is perceived as a purely executing force: "We tell you what to build, and you build it." In a world where AI increasingly lowers the barrier to execution, that position is fragile. Simply saying, "It'll be done when it's done," or refusing to engage with deadlines, does not strengthen your role.
Instead, you need to shift the conversation. Talk about the customer problem, not just the requested feature. Negotiate on scope. Explain the risks and limitations of half-baked solutions. Position the technical team as a partner in achieving business goals, not as an order-taking department. Move discussions from "you need to build this right now" to "this is the problem we want to solve, and these are the viable ways we can approach it within our constraints."
That shift only happens through relentless, thoughtful communication. And then, when you think you've communicated enough, communicate some more.
Member discussion