Why the leap from Director to CTO is really three distinct shifts, and how to start making them before you have the title

If you want to move from Director to CTO, the real secret is this: you don’t make one giant leap. You make three distinct shifts: to your focus, your horizon, and your sense of what leadership means. This article will break down the three shifts so that you can see the real path ahead.

Before I get into this, I want to be clear. My path to CTO will not be your path. Every CTO I know got there in a different way. Most of us started as developers, then moved into engineering management and worked our way up. But the companies we worked for, the time we spent at each level, the opportunities we had, and the choices we made along the way vary wildly. There is no one true path.

My CTO experience is mainly with mid-sized startups (Series C-D, 150–a few hundred employees, engineering teams of 50–200). I’ve also worked at early-stage (places you’ve never heard of) and large companies (IBM, Microsoft, Adobe, Spotify), and I mentor leaders across company sizes, so I’ll bring those varied perspectives. But if you want to be CTO at a 10,000-person enterprise, someone who’s done that will be a better guide.

That said, the three key shifts I describe: broadening your focus, extending your strategic horizon, and evolving your definition of leadership, are still relevant in larger enterprise environments. The specifics may differ: for example, decision-making is slower, your “company-wide” focus as a technology leader can mean navigating far more complex org structures, and building cross-functional relationships requires even more intention because of the sheer number of stakeholders. You may be more specialized or work through more layers of management, but the same underlying transitions in how you think and lead still apply. Directors at large organizations may need an even greater emphasis on influence, coalition-building, and navigating ambiguity across business units, so as you read, consider how these shifts might scale in your context.

I’ll outline the key transitions on this path and what changes at each level. You need to broaden your focus from team to company and industry, extend your horizon from near-term delivery to long-term strategy, and adjust your definition of leadership as your scope grows. I’ll detail each shift so you’re ready for each step up.

What the roles actually look like

One important note before I describe these levels: I’m talking about a director of engineering, not a director of security, IT, data, or another domain. You can hold a director title in technology and manage a small team if you own a domain important to the company. In engineering at mid-sized or larger companies, a director usually manages managers and possibly a couple of very senior engineers.

A director of engineering is fundamentally execution-oriented. Your focus is your organization: are your teams delivering, what’s getting in the way, and how are your engineering managers doing? You were likely a line manager not long ago, and before that, perhaps a developer. Thus, your technical background remains focused, as your teams cover adjacent disciplines (e.g., Backend and Frontend). You’re thinking strategically, but mainly in the near term. Typically, your time horizon is six months to a year, since you are building on your manager’s strategy.

That’s not a criticism. The execution layer is essential. As a Director, you’re closer to the work than your manager. Organizations fall apart without people who are genuinely focused on delivery. But it does describe the ceiling of the role.

At the VP of engineering level, the shift is from looking down to looking around the company. You join the extended senior leadership team and work with cross-functional peers across the business. You now have visibility into the company’s longer-term direction. You’re expected to think at the system level, not just the team level. Your directors handle execution. Your job is to see how the pieces fit together and where they don’t. You have a wider technical scope because you are responsible for more disciplines. You’re thinking operationally, one to three years out.

Ask yourself: When was the last time you mapped dependencies across functions or business units? How often do you step back and assess how different teams’ plans might intersect or compete? Bringing this kind of diagnostic reflection into your routine helps you build the habits and perspective needed at the VP level.

The VP role also varies significantly depending on the company’s structure. In some organizations, a VPE reports to the CEO and effectively runs engineering day-to-day alongside a CTO co-founder who isn’t a management leader. In others, multiple VPs report to a CTO. The title means different things in different places, which is worth keeping in mind.

At the CTO level, your focus widens again, this time beyond the company. You think about how the company is executing and what technology can enable. You also watch the industry and your competitors, and track emerging trends that may matter in three to five years. You’re now a senior leadership team member. You contribute to the company strategy, not just align with it.

This outward focus is not just about scanning the horizon for interesting trends, but critically assessing risk and opportunity. For example, the emergence of generative AI has quickly expanded what is possible in product differentiation and introduced new security and ethical risks. Suddenly, companies face both the chance to leap ahead with innovative features and the risk of being disrupted by startups that build faster on these new technologies. Similarly, cybersecurity threats are evolving so rapidly today that your company’s market reputation and even core operations can be at stake if you are not looking ahead and shaping proactive responses. The CTO sees these shifts early and helps the company decide where to lean in, when to move cautiously, or when to double down.

When I moved into this level, I became responsible for areas I had never worked in directly: security, infrastructure, IT, data science, analytics, and internal finance and marketing systems. I had to learn enough about each area to lead well and make sure they had what they needed, even if I couldn’t do the work myself.

Across all three levels, your focus grows wider. You move from execution to operations, then strategy. Your technical scope grows broader, and your time horizon shifts from months to years.

How do you actually make the transition?

Here’s the thing about all of these transitions: you generally don’t get promoted to demonstrate them. You get promoted because you’ve already been demonstrating them. The title follows the behavior.

So, how do you start doing the next job before you have it?

Broadening your focus

If you’re an engineering manager or a director, your focus is naturally on your team. That’s appropriate. But if you want to move up, you need to start showing that you think beyond it.

Start by understanding how the people you work with daily actually do their jobs. How does product management decide what to include in the roadmap? How does UX approach a design problem? What does the QA team care about that your developers downplay? These are not just networking conversations. They give you real context for your decisions.

To put curiosity into action, turn this into a regular exercise. Set yourself a simple goal: once every week or two, schedule a lunch or coffee with someone outside of engineering: product, UX, QA, finance, or marketing; and ask them about their work and how it connects to the company’s goals. Treat it like an intentional challenge. Committing to scheduled conversations will build your understanding over time and help you develop a real cross-functional perspective, not just theoretical knowledge.

Then expand further. Take someone from finance to lunch and ask what accounts payable does and why it matters to the business. Ask a marketing person how they think about the customer. These conversations may seem unnecessary when you’re deep in delivery. But they help you build a picture of how the company works. That picture is what you need to help shape how it should work.

If there are cross-functional working groups or improvement efforts, volunteer for them. These tasks might feel like distractions, but they do two useful things. First, they give you exposure to people and processes you wouldn’t normally see. Second, they signal to your manager that you’re thinking beyond your own team. That signal matters.

The same goes for industry knowledge. Follow the trade press, podcasts, and industry blogs. It does not take long. If you want to join conversations about where the company fits in its market, you have to know what’s going on there. You need opinions you can back up.

Widening your orientation

Understanding your organization’s strategy is different from simply being aware of it. Most people hear the company’s goals at a town hall and think, “Okay, I understand the strategy.” That’s a start. But it’s not enough. Pause for a moment and ask yourself: how does my team’s work connect to that strategy? Does it connect cleanly? If not, how could it?

At Adobe, I led a team focused on heterogeneous computing, writing software to schedule signal-processing work across GPUs and CPUs. Our goal was to run as fast as possible on whatever hardware was available. This was deep, specialized work, very close to the metal. Then Adobe started moving to the cloud. Suddenly, that work was heading in a different direction from the company.

The easy move would have been to dig in. Cloud latency was terrible for our use case. Local hardware was better. I could have made that case. But instead, I asked: Could we treat the cloud as just another compute target? The latency was longer than the GPU bandwidth, but we controlled the cloud hardware. Maybe our scheduling system could be extended to handle it.

We started building a strategy around that alignment. People noticed. And I think one reason people started thinking of me as director-level was that I was actively considering the company’s direction, not just my team’s work.

You don’t need a perfectly polished strategy proposal every time. If you have an idea, bring it to your manager. If it’s not quite right, the conversation still helps. You learn why it doesn’t fit, which helps you develop better ideas. Having ideas and sharing them shows you’re thinking at that level.

Another part of broadening your orientation is understanding the system around you, not just the teams you manage. How does your team depend on other teams? What are the dependencies the other way? If you see two teams making heavy demands on a shared service team at the same time you need something, you can plan ahead. That kind of awareness: knowing constraints and relations between teams and using it to plan, is operational thinking. It’s VP-level thinking, even if you do it as a director.

Thinking longer term

Strategy is a skill, and like most skills, you get better at it by practicing it, not by reading about it.

Adobe had a training program for people on the cusp of the director level, and I was invited to join it. The whole program was focused on strategy because the leadership team understood that the gap between line managers and managers of managers is fundamentally about strategic thinking. Not technical skills, not management skills. Strategy.

If you want to develop that, start paying attention to what’s happening in your industry beyond your company. Not just as general awareness, but with opinions attached. Right now, everyone is having conversations about AI. What do you actually think about it? What are the constraints? What are the realistic applications for your company in the next six months? In the next two years? You don’t need to have it figured out. But if you can have a substantive, informed conversation with your manager about where you think things are headed and why, that demonstrates extended strategic thinking.

To put this into practice, try this assignment: This week, write a 200-word point of view on how AI might impact your product or your company. Consider the opportunities, risks, and whether you think it’s important for your team to start experimenting or learning now. Treat it as a draft and share your perspective with a peer or your manager to start a real conversation. The point is not to have the perfect answer, but to actively build the habit of strategic thinking by applying it to real, current topics. Over time, these bite-sized exercises will help expand your strategic thinking.

Broadening your technical knowledge

Your technical breadth expands naturally as you become responsible for more disciplines, whether you like it or not. The question is whether you engage with that expansion or manage it from a distance.

I’ve talked in previous articles about why you should lean into learning the technologies you become responsible for. You don’t have to become an expert. The goal is to understand them well enough to have a real conversation with the people who do them every day, to ask questions that aren’t too far off base, and to make them feel heard and understood. That trust matters a lot when you’re leading teams you didn’t come from.

One practical way to accelerate this process is to look for your own knowledge gaps actively. Start by asking yourself some basic self-reflection questions: Which technical areas do I find myself avoiding in meetings? Where do I rely most on others to summarize or interpret? Do I feel less confident discussing certain projects or systems in my team’s portfolio? Listing out these areas can help pinpoint blind spots that deserve attention.

You can also ask trusted peers or team leads for feedback: “Are there technical domains where you think my understanding is weaker?” or “What topics do you wish I engaged with more directly?” This can bring new perspectives to your self-assessment and highlight areas that may not be obvious to you. Knowing exactly where your knowledge is thin lets you focus your learning more efficiently and show your team you are committed to truly understanding their world.

A few other ways to do this: talk to peers who are responsible for disciplines you aren’t. Ask what it’s like to manage a data engineering team. What does that work look like? What are the common failure modes? If it’s possible to sit in on a planning meeting for a team outside your area, ask. Just say you’re interested and want to learn. They might say no, and that’s fine, but if they say yes, you learn something real.

Side projects are another way I’ve learned new things over the years. I’m not trying to become an expert. I’m trying to gain enough hands-on experience so I can follow a conversation with an expert, understand what they’re saying, and ask follow-up questions that make sense. That’s a reasonable bar, and it’s usually achievable with a few weekends of tinkering.

If you’re the mentor

Everything I’ve described above is also a set of things you can actively create for the people who work for you, if you’re a VP or CTO.

Start by identifying potential. The signals are usually pretty visible once you know what to look for. People who are curious about things beyond their immediate responsibilities. The people who are already thinking about how their work connects to the company’s direction. The people who volunteer for things, ask questions in cross-functional meetings, or come to you with ideas that go beyond their job description. Those are the people who are already thinking in the ways that lead to more senior leadership.

One practical way to make this potential-spotting more deliberate is to set aside 30 minutes each month for a quick review of your team. Ask yourself: who has shown these signals recently? Who has stepped up or shown interest in broader company goals? By making this a recurring part of your calendar, you turn talent recognition from an ad hoc practice into an ongoing development discipline. Over time, this habit will help you turn signals into real growth opportunities for the people ready to take the next step.

Once you’ve identified these folks in your team, delegate real work to them. Not just tasks, but ownership of things that require the kind of thinking you want them to develop.

The best example from my own career happened at Spotify. I was a VP reporting to the CTO when we decided the company needed an engineering career ladder. We’d never had one. The CTO delegated that project to me and supported me through it. I had to work across the entire technology organization, design something that would work for hundreds of engineers in very different specializations, get buy-in from leaders I’d never met, and partner heavily with HR, not just my HR business partner, but the CHRO, the compensation team, and the HRIS team. It was genuinely hard. And I learned more from it than from most of the work that was actually in my job description.

Did he delegate it because he wanted to develop me? Maybe. Did he delegate it because he didn’t want to deal with it himself? Also possible. Honestly, either way, it worked. I’ve built engineering career ladders at every company I’ve been at since then, and I delegate it every time.

The point is that there are many things you do as a leader that require exactly the kind of thinking you want to develop in your direct reports. Handing them ownership of those things, with your support, is one of the most effective ways to grow them.

Beyond delegation, explain your thinking. In your staff meetings, don’t just announce decisions; explain them. This matters for a few reasons. First, it helps people understand and support what you’re doing. But more importantly, it gives them the reasoning, not just the conclusion. A decision you announce in five minutes might represent thirty hours of meetings, months of context, and a dozen competing considerations. When you announce it, people get the output. When you explain it, they get the thinking. That’s what lets them make good decisions on their own when a similar problem comes up, instead of just pattern-matching on what you did. To make this easier, try using a straightforward lead-in like, “Here’s the trade-off I wrestled with…” or, “The key constraint I was weighing was…” This kind of sentence opener helps you quickly bring others into your thought process and gives your team a template for sharing their own reasoning when they make decisions.

Beyond explanation, be as transparent as you can. As you move into senior leadership, you accumulate a lot of information you can’t share. That creates a gravitational pull toward sharing less by default, because it’s easier to say nothing than to figure out what to share. I try to resist that. I stay careful about what I actually can’t share, and then I share everything else. The people who work for me make better decisions when they have context, and they understand my actions better when they know what I’m thinking. The alternative is that what I do looks random or arbitrary because I’ve withheld the information that would make it make sense.

Create opportunities for people to expand their thinking, separate from delegation. If someone volunteers for cross-functional work, support it. If that kind of work doesn’t exist yet, create it. Organizational improvement efforts, working groups, task forces, whatever form makes sense in your company. Don’t assume HR or someone else will generate these opportunities. You can create them yourself for your organization.

Give feedback that’s calibrated to the next level, not just the current one. If a director does good work, tell them. Then add what a VP would have done differently in that situation. Not as criticism, but as a way to help them see what growth looks like from where they’re standing. Most people don’t have a clear picture of what the next level actually expects of them. You can give them that picture through the feedback you provide over time.

For example, after a successful project delivery, you might say, “Great job keeping the team focused and delivering on time. At the VP level, I’d expect you also to anticipate cross-team dependencies earlier and proactively align timelines across groups to minimize bottlenecks. How would you approach that next time?” Or when they handle an incident well, you could note, “You communicated clearly with your team and resolved the immediate issue. A VP would also consider which system-wide process or coordination could help other teams avoid similar problems in the future. What broader fixes do you see here?” Specific feedback like this helps people step into the mindset of more senior roles before they get there.

Why this matters

When I look back at my career, the projects I’m proudest of aren’t the ones that lasted. The heterogeneous computing work at Adobe was genuinely interesting and technically hard, and it’s completely obsolete now. Technology moved on. You don’t need software to schedule GPU work the way we used to anymore. I’m proud of what that team built, but the work itself is gone.

What hasn’t faded is watching someone who worked for me post on LinkedIn that they’re starting a new role as a CTO or VPE. That lands differently. The idea that I played some part in helping that person get there, that’s a more direct and lasting impact than anything I’ve shipped.

And the thing about developing people is that it compounds. They’ll go on to support the next generation of leaders behind them. The influence extends well past the moment.

So if you’re on this path, that’s what’s on the other side of it. For the people following the path: keep going. It’s a hard job and a genuinely great one. For the people who are further along and mentoring, the most important work you do might not show up in a product release. It might show up years later in someone else’s announcement.

To hear an extended discussion of this topic, please listen to my recent podcast episode: The Director to CTO Path: How to Follow It, or How to Mentor It.

Originally published in my newsletter.