
Rethinking the Advice: When CTOs Should Stay “On the Tools” in the Age of AI-Assisted Development
What if the smartest move for today’s CTO isn’t stepping away from the code—but stepping back into it, strategically?
Hi everyone,
Thank you for reading Great CTO. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to the CTO and the issues they face, distilled from my career experience.
I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine posts, ensuring you always receive the best and most up-to-date information with the most clarity.
If you’d like to support the growth of this resource, consider upgrading to paid and take advantage of the other ways I can help you.
This is an AI-assisted post based on brainstorming I did with one of my chatbots. It is intended as a thought starter on key issues CTOs are experiencing.
Introduction - CTOs Should ‘Get Off The Tools’, Right?!
One of the most repeated pieces of advice CTO coaches give is, “Get off the tools.” Focus on vision, people, and scale. Let the team code—your job is to lead.
Like any context-free advice, it’s good advice until it isn’t.
In a world where AI-assisted development redefines the relationship between humans and code, it’s time to revisit that assumption. What if staying close to the tools isn’t a sign of poor delegation, but a competitive advantage, when done with strategic intent?
* I can hear a gasp from 1000 CTO Coaches as they read this line *
The Classic Rationale for Stepping Back
CTOs are told to step back from hands-on coding for good reason. As teams grow, the demands on leadership shift. Your leverage comes not from the lines of code you write, but from the systems you architect—technical, operational, and cultural.
Writing code when you should be scaling culture is often a sign of avoidance or over-comfort. And when you're the bottleneck for decisions or pull requests, that’s a problem.
But the game has changed.
AI Tools Have Shifted the Leverage Point
The emergence of tools like Cline, Cursor, RooCode, and Windsurf is not just about productivity. It’s about cognition. These platforms act less like IDEs and more like thinking companions—collaborators that reason, suggest, and refactor alongside you. The working practices for individuals and teams shift, and all of a sudden, there are a lot of new concepts to learn, and they continue to evolve quickly.
Understanding how to ask and guide AI becomes as crucial as writing code in this new paradigm. That shift creates a new strategic surface for the CTO.
Three Strategic Reasons to Stay (Selectively) “On the Tools”
Pattern Recognition at the Frontier
When you're building in a fast-moving domain (e.g., LLM integration, agent workflows, multi-modal AI apps), your team is likely learning on the job. Being hands-on—even briefly—gives you context to spot emerging abstractions, brittle edge cases, or systemic inefficiencies early.
This isn't micromanagement. It's proximity to the edge of innovation. With some large shifts, such as the changes involved with AI-assisted development, it’s common to find some of your team's experienced members behind the curve. That makes it hard to delegate leading such a shift to them.
Empathy and Enablement
Many AI development workflows still have rough edges. Prompt strategies, tool ergonomics, integration quirks—these are lived experiences your team wrestles with daily. When you occasionally pair-program with AI or explore a new tool firsthand, you gain insight into where your developers are getting stuck, bored, or confused.
That knowledge enables better process design, onboarding, and toolchain selection. Most importantly, it helps you better understand what is involved in the change so you can lead it more effectively and know the team’s concerns firsthand.
Credibility and Thought Leadership
If you’re a product-led CTO in an AI-driven business, your credibility doesn’t just come from title—it comes from demonstrated understanding. Investors, customers, and candidates want to know: Does this leader understand the terrain they’re navigating?
You don’t need to be the best engineer in the room. But if you’ve explored the tools, you’ll speak with authority, grounded in experience, not hearsay. You won’t be driving your team into unsafe situations where the hype doesn’t match the reality.
📢 Join the inaugural ‘Humans In The Loop’ livestream - a weekly discussion of new practices emerging from the AI and software development frontier. ⤵️
All Technical Leadership is Situational
This doesn’t mean reverting to being the lead engineer. It means selectively engaging in hands-on work when it supports broader strategic goals:
To validate a new AI-assisted development workflow before rolling it out team-wide
To prototype and test ideas at the edge of what’s possible
To evaluate tools with a practitioner’s mindset, not just a buyer’s
CTOs who embrace this model aren't doing it to control. They’re doing it to sense, learn, and guide.
More on why doing real work with these tools is required to assess and understand them here properly:
Closing Thought
Being “on the tools” isn’t a binary choice—it’s a dial you adjust based on context. AI-assisted development gives CTOs a new kind of leverage: faster learning cycles, deeper insight into team pain points, and a sharper lens for strategic opportunities.
The larger the organisation, the more likely it is that you have people more than capable of delegating this to and other priorities that might outrank this one. But that isn’t all companies. Navigating this shift might be your top priority if you compete based on speed or technical capability.
So next time someone tells you to “get off the tools,” pause and ask: Is there a strategic reason for me doing this, and have I adequately communicated my intent?
Over to you💬
Q1: In your context, where might a short burst of hands-on exploration unlock insight or unblock your team?
Q2: How might you evaluate new AI dev tools without becoming a bottleneck or reverting to individual contributor mode?
Q3: What rituals or rhythms could you introduce to stay technically literate without undermining your team’s autonomy?
Was this article's hero image created by AI? Maybe it didn't know how to spell Cursor because it was released after the model was pre-trained :D
Great post!