Should managers become hands-on again?
Why engineering leaders can’t afford to stay away from the terminal
Technology is undergoing a structural shift, and leadership blind spots at this moment are extremely costly. The role of a CTO or VP of Engineering is to detect inflection points early, understand their real impact beyond the hype, and decide where to place informed bets.
X: João, the CTO and senior leaders have a huge cost of opportunity. Is this the best use of their time?
João: Everything has an opportunity cost. What I expect from a CTO or VP of Engineering is the ability to analyze the environment, make informed bets, and evaluate their returns. In the end, no one has the absolute truth.
AI-assisted development is changing the economics of building software. The relevant question is whether enough of what we’re seeing is true to materially impact productivity, speed, cost structure, and competitive advantage. If even part of it holds, delegating the exploration entirely becomes a strategic risk. So… what am I seeing in the environment?
People are going back to hands-on
Even the ones that, for years, didn’t ship a product or line of code. Those who try it report “fantastic” results. As a senior engineering leader, I’d ask myself:
Damn! how much of this is actually true? If even half of it is real, what impact would it have on my teams? How could it help the business?
That alone should trigger an investigation. And when I say investigate, I mean two things:
Build things outside: greenfield (Replit, Lovable, v0… or Claude Code + OSS). This gives you a picture of what’s possible without major constraints.
Build things inside: with constraints (environment, data living in cloud accounts, access, security, legacy, etc.). This gives you a picture of what’s possible in my enterprise.
Both perspectives provide a delta between what is possible and how far you can go. That diff should become a vector for action. Even if the productivity gain were just 5%, at scale it would be massive.
To inspire change like this, you have to share
What better than sharing that you fixed a bug, noticed DevEx could be improved, and opened a PR? It doesn’t have to be something ultra-critical in production. It could be an unmet business need that, as CTO, you know is burning. Or a tool for customer support.
The act of sharing makes people think:
Wow… this must be important. This must be a game changer. If even my CTO/VP of Engineering — with a thousand meetings — is doing this, I’d better step up
Leadership at terminal speed
Many of the “AI wow” reports — including mine — are based on people opening terminals and running prompts between meetings.
It’s not that you stop doing your job. It’s that during the time you might have spent reading an article, you’re feeding prompts and watching things move at a speed you’ve never seen before. And on top of that, you’re supposed to know how to parallelize, delegate, and evaluate decisions. The shift is so massive that you can’t delegate it to a consultancy company.
It’s not enough to just have champions inside the company. You have to lead it. It’s like people working at newspapers in 1997 who didn't use the Internet. But with one aggravating factor: the speed — precisely because of the Internet — is 20x faster. The adaptation window is much smaller, and each day you don’t get inside it, the gap widens.
Think about a 200-person org: 1 CTO, 4–6 directors, 40 teams. For change to reach critical mass, it must pass through at least four layers of indirection. At least. By the time it trickles down organically, the window may already be closing.
Now, thinking about all of the above: what priority do you give this vs 1:1s / coaching vs budget? vs strategy?
So the real question isn’t whether managers should become hands-on again, but rather whether they can afford not to.
— João