AI won't break your company, but pretending nothing changed will
How CTOs should rethink teams, delivery, and leadership in an AI-native world
You are the Chief Technology Officer (CTO) of a company with more than 100 engineers. You have rolled out ChatGPT, Gemini, GitHub Copilot, Claude Code, and whatever else looked reasonable at the time. If you are honest, you do not really know what value this is creating beyond some anecdotal productivity wins.
What do you do next? This is the question many CTOs will be forced to answer in 2026. The pressure is only increasing, driven by both real technological change and hype. Even if you ignore what you read on X, which is a distorted signal at best, there is one consistent pattern: people who actually use AI agents to build software, not those who just talk about them, tend to be genuinely impressed. Work that used to take quarters can now be compressed into days.
That shift has second-order effects that most organizations are not prepared for.
What changed?
Writing code was never the bottleneck
We have known for years that, in large companies, the main bottleneck is not writing code. It is coordination, handovers, and organizational complexity. However, AI changes the shape of that problem.
If you can compress creation so dramatically, and if maintenance also becomes cheaper, a difficult question follows naturally: Do you really need the same number of people to achieve the same outcomes?
A significant part of delivery friction stems from the organization’s scale, not from the technical challenge. Over the past decade, many companies have optimized for vertical ownership. Teams were structured to take problems end-to-end into production. This worked well until the problems became large enough to require splitting across teams. At that point, gray areas emerged — am I owning this or is team B? —, along with coordination overhead.
Why org design matters more than tools
If a smaller team can cover a larger domain, you reduce handovers and coordination costs. In greenfield environments, this is already obvious. That is why many new companies are born lean. The harder question is what to do with ten existing teams and a large legacy surface area.
The first thing to internalize is that adding people does not linearly speed up delivery. The “Mythical man-month” — nine women do not give birth to nine babies in one month — still applies. This observation leads directly to the next step.
What can I do as a CTO?
#1 Shift capacity towards Developer Experience
If teams can handle increased scope and LLMs introduce new constraints in Continuous Integration (CI), Continuous Deployment (CD), observability, and operations, there is a clear opportunity to reallocate talent. Product engineers can be moved toward platform and developer experience work, with the explicit goal of increasing business throughput rather than building “nice” infrastructure.
This only works if it is measured properly. Deployment frequency, release confidence, and incident rates matter. DORA metrics are a solid reference point, even if you cannot implement them perfectly on day one.
These teams must be AI-native. Today, it is possible to build internal platforms far more cheaply than a few years ago, and standardization is easier when AI reduces the marginal cost of abstraction and automation.
#2 Get out of your ivory tower
Less abstract management. Fewer spreadsheets and OKR decks. More direct exposure: use AI agents yourself and build something real. Start from scratch with standard tooling and deploy it. Then, try to build something inside your company’s existing environment. The contrast is usually instructive.
Look at the gaps. Count how many steps are manual. Identify how many processes exist simply because “that is how things work here.” With AI in the loop, none of this should take very long. If you are technically out of practice, that is a problem you should address directly.
For example, I’ve built a few products with AI myself — end to end — so I grasp the change we’re living:
“Support Hero” — moving tickets from Slack to Jira. I wrote about it here.
🇪🇸 “Menú del Cole” — to get the menus of my kids on my phone, daily.
“Rotahog” — to solve a problem I had as a manager
🇪🇸 “Herramient.as” — to avoid using free tools full of ads for generating QRs and a few chores.
#3 Establish a baseline
You don’t need perfection. Track delivered versus delayed initiatives per quarter. Track production deployments and incidents. If you have DORA metrics, use them. If you do not, do not turn this into a six-month transformation project. A lean approach is sufficient to start. Light gamification — LLM token usage, etc. — can help early on, but it should not become structural.
#4 Identify your champions
They already exist inside your organization. They are the people aggressively using AI agents and pushing boundaries. Bring them with you. Use them to help other teams adopt new ways of working. The first team will be the hardest. The next ones will move faster. Always tie the effort to business outcomes. The goal is not to build the most efficient factory possible, but to deliver things users actually value.
#5 Be visible in the work
People need to see you learning and building. This requires time and deliberate communication. It is acceptable to temporarily reduce the number of one-on-ones and people management. It is acceptable to ask managers to spend less time on people management and more on execution. This is a strategic choice aimed at shifting culture. Show what you have built, explain what improved, and clearly state what you expect from teams. Use data to validate whether the change is working.
#6 Not everyone will adapt
Some people will struggle in this new environment. That is normal. Have an honest plan for them. Set expectations. Avoid defaulting to low-impact training programs that exist mostly to make leadership feel better. Some people will leave. In other cases, hard decisions will be required. This is part of leadership’s responsibility.
#7 Comfort is not a strategy
If this entire approach feels too uncomfortable, and your instinct is to optimize change management so everyone feels safe and unchanged, that is a signal. The leadership playbook that worked between 2010 and 2022 no longer fits the current pace of change.
This does not mean acting recklessly. It means accepting that making stability a primary goal is no longer viable. If you do not raise the bar and change yourself first, the environment will force the change anyway. Companies that fail to adapt do not provide long-term safety for anyone.
#8 Transparency
Report back to teams on what is working, what is not, and which practices are evolving. Encourage sharing and reuse.
At the executive level, speak in terms of ROI and outcomes. What do you gain per €10k invested in AI tooling? How does that translate into business impact? Where are the constraints that leadership can help remove?
#9 Systems over heroes
If success depends on you, a handful of champions, or a specific moment in time, you are building a trend, not an advantage.
Decide what becomes standard. Which tools are approved? What changes in senior roles? What does “doing a good job” mean in 2026 with AI in the loop? Encode these decisions in hiring, promotions, performance reviews, and organizational design. If incentives and rules do not change, the organization will drift back to its previous equilibrium, even if that equilibrium is worse.
AI will not break your company. Continuing to operate as if nothing fundamental has changed will.
No more excuses
None of this is primarily a tooling problem. It is a leadership and organizational design problem. AI simply removes many of the excuses that previously justified slow feedback loops, oversized teams, and fragile delivery pipelines.
The companies that benefit will not be the ones with the most tools, but the ones willing to rethink how work gets done, how teams are shaped, and what is expected from senior roles.
— João