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:

1. Build things outside: greenfield (Replit, Lovable, v0… or Claude Code + OSS). This gives you a picture of what’s possible without major constraints.

2. 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

Shortly after publishing it, I read another article that addressed the same issue from a different angle. Where my piece leaned more on careers and value concentration, this one stepped back and looked at industrial revolutions, disposable software, and what happens when production scales faster than stewardship.

Both texts start from the same observation. We can now generate far more software, far faster. That part is already visible. The more interesting effects appear later, once that abundance collides with markets, organizations, and incentives that were designed for scarcity.

Why did we have big teams?

For most of software’s history, large teams existed for structural reasons. Translating business complexity into working systems was expensive in terms of cognitive effort. Operating those systems reliably over time incurred additional costs. Dividing the work across people and teams was the only way to manage that load, even if it introduced coordination overhead and organizational drag.

But technical necessity is only half the story. The last decade has introduced a powerful economic incentive to rapidly expand teams. The zero-interest-rate period (ZIRP), combined with abundant venture capital (VC), rewarded speed and scale over efficiency. Hiring became a way to buy time, maintain feature parity with competitors, and signal momentum. Ultimately, hiring also became a way to preempt rivals rather than out-execute them.

Speaking with Sergi, I also agree with his take. In many companies, headcount growth was just as much about dividing cognitive load as about keeping up. If your competitor had three teams on a problem, you staffed four. That’s how roadmaps expanded, and scope creep was everywhere. Sometimes, it is because users demanded it and are driven by the fear of missing out (FOMO).

Hiring also occurred in bulk, and we observed entire teams added at once. And what happens when you do that? Exactly, talent density drops, and you end up with a myriad of processes to cope with scale. Team organization followed familiar patterns: let’s do microservices everywhere, layers of managers, and so on. What worked for a few successful companies was widely copied, often without the underlying constraints remaining the same. The result was more bureaucracy, more politics, and steadily decreasing marginal output per new hire.

None of this was irrational at the time. Capital was cheap, growth was rewarded, and efficiency could wait. The issue is that when software production becomes cheaper and faster, the justification for large teams weakens. Not all at once, and not everywhere, but enough to matter. The economic environment no longer rewards carrying excess coordination costs just to keep pace. Feature parity becomes easier to reach with fewer people, and the old incentives start to flip.

Efficiency, margins, and labor economics

Efficiency spreads faster than culture. As more teams adopt similar AI tooling and practices, any initial advantage disappears and becomes the baseline. New competitors form faster. Existing ones reorganize. The supply of “good enough” software is growing rapidly, particularly in horizontal products and undifferentiated SaaS offerings.

This is where the shift stops being technical and starts being economic. Once feature parity becomes cheap, pricing power weakens. Margins begin to erode. Not everywhere and not uniformly, but enough to matter. Companies with strong data moats, network effects, or regulatory constraints still have defenses. Many Web 2.0 incumbents sit here. They have users, data, and distribution that newcomers cannot easily replicate.

But those advantages mainly buy time. If these companies continue to operate with cost structures, team sizes, and incentive models designed for a world in which software was expensive to produce, they become vulnerable from within. Disruption rarely comes from rebuilding the same product slightly better. It stems from a different operating model: fewer people, tighter feedback loops, less coordination, and greater tolerance for disposable output.

As margins compress, the effects cascade: we’ll see smaller teams become the norm, training pipelines shorten, and fewer hiring risks. If roles become easier to substitute, then compensation follows. Deep expertise still matters, especially where failure is costly, but the long tail becomes less differentiated. This is not a sudden collapse. It is a gradual pressure that accumulates quarter after quarter.

At the same time, owning larger domains introduces a different cost that is easy to underestimate. With fewer teams covering broader systems, the blast radius of mistakes increases. Operational risk, security concerns, and regulatory requirements drive organizations toward stronger internal platforms, guardrails, and governance frameworks. Coordination does not disappear, but gets transformed into a more centralized and formalized form.

The system ends up leaner in headcount, but heavier in constraints. This is the second-order pattern that keeps repeating: cheaper software enables nimbler teams → nimbler teams increase competition → competition compresses margins → compressed margins reshape labor economics and organizational design. None of these steps is dramatic in itself. Together, they change the industry’s equilibrium.

Subscribe now

On disposable software

Disposable software is not merely a technical choice but also a financial one. There are growing classes of software where low expectations of longevity make sense. Internal tools, experiments, one-off agents, and workflow automations often exist to be replaced. In those cases, lower production costs change the calculus in a positive way.

Other systems do not benefit from that treatment. Software that touches money, identity, safety, or compliance accumulates risk over time. Maintenance, ownership, and long-term understanding remain critical, regardless of how cheap the initial code was to produce.

As output increases, responsibility becomes more diffuse. Dependency chains grow. Maintenance costs remain hidden until they manifest as incidents. Technical debt behaves less like a backlog item and more like an environmental problem, building quietly and affecting everything downstream.

Where the next disruption comes from

I think the next disruption won’t come from software engineers working in isolation or from incumbents slowly layering AI onto existing processes. It will arise from close partnerships between software engineers and subject-matter experts. People who understand the incentives, constraints, and pathologies of an industry and can redesign workflows from first principles.

Law is a good example. Many law firms still operate on a billable-hours model that rewards inefficiency. Partner structures, risk aversion, and legacy processes make meaningful change from within difficult. A strong engineer, paired with a lawyer who deeply understands how legal work actually occurs, can reimagine the system end-to-end. Not just automate documents, but change how value is delivered, priced, and operated.

The same pattern applies elsewhere, including accounting, insurance, and healthcare administration. Compliance-heavy industries where software was never the primary bottleneck, but where it also couldn’t realistically attack the core of the work.

That constraint is changing. It is not just large language models. It is AI-first systems more broadly: agents, retrieval pipelines, long-running workflows, and systems that can observe, reason, act, and iterate. Together, they enable work across millions of documents, contracts, emails, and records in ways that were previously impractical. They are good at mapping unstructured human input into structured systems, coordinating multi-step processes, and encoding domain logic directly into operational flows.

In Law, this means navigating case histories, contracts, and precedents at a scale no junior team could. In accounting and insurance, it means translating messy reality into systems of record with far less manual glue and back-and-forth.

The incentives were broken before. Now the tooling is finally strong enough to expose how broken they are. Cheap code lowers the cost of attacking those incentives. AI-first systems reduce the cost of understanding the domain sufficiently to redesign it.

Share

Capital flows leverage

As margins compress in pure software, capital reallocates. VCs thrive on asymmetry. When software production becomes cheap and competition intense, volume alone no longer creates outsized returns. What matters is leverage: control over scarce resources, real-world constraints, or deeply embedded workflows.

This is why investment increasingly concentrates in contexts in which AI reshapes physical or institutional systems rather than merely improving digital ones, across healthcare, manufacturing, logistics, and defense. In these domains, software does not just optimize processes. It changes cost structures, labor models, and regulatory dynamics.

In parallel, more capital is flowing into robotics, biotechnology, and other hard-tech domains, where software amplifies physical capabilities rather than replacing them. These areas absorb complexity rather than abstracting it away, which makes them harder to copy and slower to commoditize.

Pure software remains important. But its role in producing venture-scale asymmetry narrows. The winners are less likely to be the teams that generate the most code and more likely to be those that combine software, domain expertise, and operating leverage in ways that are difficult to replicate.

This capital shift reinforces everything upstream. Lower margins in software push salaries down. Lower salaries and cheaper tooling enable more entrants. More entrants increase competition. And the cycle tightens.

Final thoughts

What’s changing is not just how software is built, but what kind of behavior the system rewards.

For a long time, the industry optimized for growth under conditions of scarcity: scarce engineers, expensive production, and abundant capital. That combination justified large teams, extensive coordination, and substantial inefficiency. It worked because the environment enabled it.

That environment is fading. When software becomes cheap to produce and easier to replace, some assumptions quietly cease to hold. Team size is no longer a proxy for progress. Headcount stops being a moat. Speed alone stops being enough. Many structures that made sense under ZIRP-era economics start to feel heavy.

The pressure doesn’t show up as a single breaking point. It appears as a series of small adjustments: teams become leaner, roles become more dynamic, and hiring gets more cautious. Disposable output becomes normal in some areas, while expectations rise sharply in others. The gap between “good enough” and “critical” software widens.

At the same time, leverage shifts. Greater value is placed on who can integrate software with domain knowledge, real-world constraints, and durable operating models, rather than on who can produce the most code. That is where capital, talent, and influence start to cluster.

None of this means software becomes less important. If anything, it becomes more embedded everywhere. But it does mean the industry looks less like a gold rush and more like an economy.

The question going forward is not whether AI will accelerate software. That is already happening. The question is which parts of the system adapt their incentives quickly enough, and which ones continue to optimize for a world that no longer exists.

— João

I already raised my concerns. If they chose to ignore them, that’s on them.

Cristian probably said this in a meeting, wrote it down in a document, and explained it on Slack, with context and arguments. And still, the team, or other Staff Engineers, architects, etc., went in a different direction or did nothing.

This article is a translation of the “Antipatrones de un Tech Lead” 🇪🇸 published last week.

From the inside, this feels like frustration. From the outside, it often looks like noise. Most TLs do not end up in this situation due to neglect or poor judgment. They get there because they care, they see risks, and they feel responsible for both the system and the team. That is precisely why this situation hurts so much.

Here is a distinction that is hard to accept: saying what you think is not exercising technical leadership.

Being right, warning about risks, or having sound judgment is not enough. And when a TL feels the needle isn’t moving, they start compensating. That is where antipatterns appear. Not as obvious failures or bad intentions, but as reasonable responses to real frustration that builds up when good judgment does not move anything.

Note: at this point, the plan was to talk about five antipatterns. Then Fabián, a Tech Lead and reviewer of the tech lead series, pointed out one more. He was right. So this starts at #0. I want to thank him for reviewing the article.

#0 The one who does not exercise the role

Before the visible antipatterns, there is often another, less obvious one. Sometimes there is no friction or visible conflict. The team delivers, meetings happen, and decisions are made. That is precisely why the situation goes unnoticed for far too long.

The problem is not what happens today, but what does not happen. Nobody is looking at the system as a whole, pushing a clear technical direction, nor turning local decisions into global coherence.

This often happens when the previous TL leaves, and no one truly fills that space. Or when the most senior engineer inherited the title without redefining the role. Or during rapid growth phases, when the highest producer is promoted because “they already know the system.”

In the daily work, the TL is present but does not provide direction. They do not push principles, do not anticipate risks, and do not articulate technical decisions beyond the immediate. They neither block nor unblock. It is not that they make poor decisions. They simply do not decide.

The effect is not immediate. Each engineer starts optimizing their own area. Decisions are made locally, and judgment fragments. Then, when a structural problem appears, nobody feels responsible for owning it.

This is often confused with autonomy, but it is actually a void. The team does not depend on the TL, but it also does not grow around a shared direction. It moves forward, but without accumulating judgment or long-term speed.

#1 Opinions with no ownership

There is a very recognizable moment when this antipattern starts. Cristian keeps participating in conversations, pointing out risks and offering judgment.

Cristian starts to take refuge in a comforting idea: “I already did my part.” He shared his opinion, left a record, and warned about the risks. If the decision goes wrong, it will not be due to a lack of warning. That reasoning is understandable, but dangerous.

From that point on, Cristian stops making decisions and limits himself to issuing diagnoses. His judgment is still good, but it no longer creates movement. He is present in the conversation, but not in the outcome.

That gap between how Cristian sees himself and how he starts to be perceived often surfaces in uncomfortable conversations. Sometimes in a 1:1:

João: Hey, how do you think the team is doing lately?

Cristian: Fine. More or less the same as always. I already said what I thought about the latency issue and the new design. If they end up deciding something else…

J: Right. The issue is that, from the outside, it can feel like you have a lot of opinions, but you are not really pushing for anything specific.

C: What do you mean I’m not pushing? I’ve been warning about the risks for weeks.

J: Sure, but warning about risks isn’t the same as leading a decision. The team leaves those meetings knowing what you don’t agree with, but not knowing what you would do differently or what you are actually willing to prioritize to change it.

C: … [he looks upset]

J: I’m not saying this as a criticism. Your judgment is solid. But right now your opinion isn’t helping the team make decisions faster. If anything, it leaves them in limbo.

Over time, two things happen:

• On one hand, decisions are made despite Cristian, not with Cristian. His opinion is heard, but it loses weight. On the other hand, frustration grows because he feels his judgment changes nothing

• At this point, the role begins to degrade without anyone explicitly deciding to do so. By assuming his responsibility ends at giving an opinion, Cristian reduces his impact without realizing it. His judgment stops being a lever and becomes just another comment.

This is usually the first step. When having opinions stops working, the temptation is to compensate in other ways. That is where the rest of the problems start to appear.

👋 Hi, I am João. This is the fourth post of a series designed for Tech Leads and Engineering Managers who want to lead with greater clarity and intention.

• “Traits of a good Tech Lead”

• “I’m a Tech Lead, and nobody listens to me. What should I do?”

• “Operational Excellence, the Tech Lead lever”

• “Antipatterns of a Tech Lead” ← This article

• To be continued…

I’m currently writing “The Tech Lead Handbook”, scheduled for release in H1 2026. The ideas in this series will form its core.

If you join the waitlist, you will receive a 25% launch discount. More than 100 tech leads and engineering managers already joined!

Join the waitlist

#2 The TL as a bottleneck

If opinions stop working, the next step seems logical: doing. Cristian no longer limits himself to pointing out problems; he is now getting more involved, reviewing more things, and being part of more decisions. Not because he wants control, but because he wants things to go well.

At first, it works. Decisions improve, and risks decrease. Incidents go down. The team breathes. It can even look like effective leadership.

But there is a trap. More and more decisions go through Cristian. More and more context lives in his head. More and more conversations wait for his validation to move forward. Without realizing it, Cristian becomes the point through which everything must pass.

The team adapts quickly. It learns which decisions can be made independently and which cannot. It learns when it is worth waiting and when it is not. And little by little, it stops deciding at the edges.

From Cristian’s perspective, day-to-day work becomes exhausting. He is always busy. There is always something urgent or someone waiting. And still, the underlying feeling is that the system is not speeding up.

Here is the paradox: the more Cristian tries to unblock the team, the more he slows it down. The signals usually appear late:

• Pull requests waiting for review “when Cristian has time”

• Technical decisions were postponed because “we need to check with him”

• Incidents nobody dares to close without his sign-off

When the TL becomes a bottleneck, the problem stops being technical. It becomes systemic. The team has externalized decision-making, and the organization has concentrated risk in a single person.

And the worst: Cristian is becoming indispensable. And that, far from being a strength, is a fragility. The more the team depends on him to decide and move forward, the less time Cristian has for N+1 work. Improving the system, reducing uncertainty, or creating the conditions for others to make better decisions. His calendar fills with urgencies, and the role stops scaling.

#3 Judgement lives in the TL’s head

One day, someone asks, “Are we doing things the right way?” and nobody knows how to answer without looking at Cristian. Review becomes his center of gravity. Pull requests, designs, and implementation details go through him. Not because the team is insecure, but because there is no clear reference for what “done right” means without his approval.

Cristian reviews with good intentions. He wants to maintain quality and avoid mistakes. But feedback starts to vary depending on context, timing, or how tired he is that day. Something acceptable yesterday is questioned today. What is tolerated in one service is debated in another.

The team learns quickly. There are no explicit rules. You have to wait and see what Cristian says. And here something subtle but very damaging happens: people stop thinking about the best solution and start thinking about what will pass review. They take fewer risks, propose fewer alternatives, and ask more than necessary.

The problem is not that there are standards. It is that they are not written or shared. They live in his head and only surface during review. While Cristian is around, the system works. When he is not, the team hesitates.

🎁 Does this sound familiar? It is not a coincidence

Many of these antipatterns appear when judgment is not explicit, and the team does not share a definition of “what good looks like.”

To help move out of this, I have prepared a free alignment toolkit with practical tools already used by other teams:

• For Tech Leads: a self-assessment traffic light to identify where you are adding value and where you are becoming, unintentionally, a bottleneck.

• For Engineering Managers: an evaluation traffic light to give feedback based on observable behaviors, not gut feelings.

• For the team: an operational principles template to take judgment out of the TL’s head and stop debating the same decisions every week.

Note: If you are already subscribed and previously requested the toolkit, you will find it in the same document.

Download the EM/TL toolkit

The more time Cristian spends reviewing, the less time he has to do the work that would truly help the team grow. Clarifying principles, reducing ambiguity, and building a system that works without his constant presence. Review replaces clarity.

#4 The hero

Let’s be clear: Cristian does not wake up one day wanting to be a hero. He simply starts to notice that there are situations where his presence makes a difference.

He realizes that, in the most complex problems, people usually rely on him. Those delicate decisions wait until he is around. And that is when something goes well, it often passes through his hands.

That feels good. It is confirmation that his work matters. In a role where impact is not always visible, that feeling carries more weight than it seems.

Little by little, Cristian starts leaning on it. His professional identity becomes tied to being present, to being the one who unblocks, to being the one who “saves” the situation when things get complicated. Delegating becomes uncomfortable. Not because he distrusts the team, but because it means disappearing a bit from the center of the action.

Documenting decisions gets postponed. Giving others space to lead an initiative creates a discomfort that is hard to explain. There is no clear intention to hoard anything. He is simply always there, just in case.

The system keeps working, but it starts to work around him. Meanwhile, Cristian’s role stops evolving. The next level requires the opposite. Accepting that many things work without his direct involvement, giving up the spotlight, and measuring impact differently.

This is the point where growth stalls, because all important work depends on being present. Cristian stays busy, useful, and visible, but with less and less room to redefine his role.

The problem starts with confusing impact with presence. And when that happens, the TL stops growing.

#5 Winning all the arguments while losing the team

This antipattern does not start with conflict or a heated discussion. It starts with a sense of calm. Meetings get shorter, decisions seem to flow, and conversations close quickly. Cristian presents his point of view and, most of the time, nobody challenges it. Everything can even look aligned and efficient.

Inside the team, however, something has changed. Alternatives are becoming increasingly rare, and uncomfortable questions are rarely raised. Not because they do not exist, but because the conversation’s outcome feels predictable. The team implicitly learns what is worth debating and what is not. Cristian is not aware of this change. To him, things simply work better than before. The first time he hears it framed this way is in a conversation he did not expect:

J: There’s something I’ve been thinking about for a few weeks and wanted to run by you. The team barely talks anymore, right? Meetings are very quiet.

C: And is that a bad thing? Moving fast can be a good sign too.

J: Sometimes, yes. The problem is when that calm doesn’t come from clarity, but from assuming the discussion is already over before it even starts.

[Cristian looks confused]

C: I don’t think anyone is holding back.

J: It’s not that they’re holding back. They know how the conversation is going to end. And when that happens, people stop bringing alternatives.

C: …

J: You have strong judgment, and the team respects it. But right now it feels like your point of view carries so much weight that it takes up almost all the space.

[Cristian nods slowly]

J: When a team stops thinking out loud, something gets lost. And it usually happens without anyone noticing.

The team keeps delivering, and everything appears to work. But it no longer thinks out loud. Responsibility for decisions gets diluted, and engagement becomes more superficial. Execution is good, but questioning is rare.

Winning all the arguments has a cost. When the TL becomes, even unintentionally, the only voice that matters, the role ceases to fulfill its purpose. Because technical leadership is not about always being right, but about creating the space for others to develop judgment too.

Subscribe now

When the TL takes too much space

When rereading these antipatterns, there is a temptation to think of them as “mistakes.” They are not. Most of them, au contraire, appear because of involvement, judgment, and a real sense of responsibility when the system and the team seem to be heading toward danger.

The problem is that when a TL feels their voice does not move anything, they start compensating with behavior. They push opinions harder, get involved in everything, and review more. In short, they become indispensable and, unintentionally, take up so much space that the team stops thinking out loud.

If there is one thing that connects all these scenarios, it is this: technical leadership is not measured by how many times you were right, but by how much judgment and autonomy the team around you gains.

And here is the uncomfortable question worth asking from time to time, especially when you catch yourself saying “I already said it”: Am I helping the team depend less on me, or am I building a system that only works when I am there?

— João

I like your article, but you do not talk about KPIs, SLOs…

This was part of Fabián’s feedback on the first article in the Tech Lead (TL) series. And he was right. The uncomfortable question was missing: how do we know if we are doing well?

If you are a Tech Lead, you will eventually be asked for “more speed”. More features. More projects. More impact. And in parallel, you will see more incidents. More alert noise. More uncertainty. More time wasted investigating things that “should not happen”.

You can have good judgment and push for quality standards. But if you cannot measure the state of the system or its real operating cost, you are flying blind. And when you’re blind, everything turns into endless discussions: “I think it is fine”, “this has always been this way”, etc. For me, that is exactly what operational excellence prevents.

Operational excellence is the team’s ability to deliver value sustainably, without degrading user trust, without burning out the team, and without every incident resetting the counter. It is a discipline, not a project.

Different metrics, different intentions

The first step is to separate by intention. If you mix intentions, you end up with pretty dashboards and zero decisions.

KPIs

Let us start by separating concepts. Key Performance Indicators (KPIs) are not only business metrics. There are business KPIs — conversion, retention, revenue, adoption — and internal team KPIs (lead time, deployment frequency, incident volume, cost per request, on-call noise). Both matter. But they answer different questions.

• Business KPIs show whether the organization is getting value.

• Internal KPIs show the operational and human costs associated with that value.

A Tech Lead primarily operates at this second layer. Not because they ignore the business, but because their lever is making the technical system sustainable as the business grows.

SLIs or “how is the system behaving”?

A Service Level Indicator (SLI) is an observable measure of how your service behaves. Typical examples:

• Availability (successful requests vs. total).

• Latency (p50, p95, p99).

• Error rate (by type, endpoint, or cause).

• Data freshness (queues, batch jobs, replication)

• Saturation (CPU, memory, connection pools, queues, rate limits).

SLIs describe reality. They do not tell you whether that reality is acceptable.

SLOs or “what does ‘good enough’ look like to users?”

A Service Level Objective (SLO) is an explicit target on an SLI over a time window. For example:

Over 30 days, 99.9% of checkout flow requests must complete successfully in under 300 milliseconds.

SLOs are a form of contract. Not legal. Operational. A statement of “this is what we guarantee as a team”. One important point: SLOs are not binary. It is not about “pass or fail”. This is where the key concept comes in: error budgets.

If your SLO is 99.9%, you are explicitly accepting that 0.1% of requests may fail or be slow in that window. That failure is allowed by design, not an accident. As long as consumption of that budget is under control, the system is “within SLO”, even if incidents occur. An incident does not automatically mean you are out of budget.

A good negotiation tool

In my experience, most friction among Tech Leads (TL), Engineering Managers (EM), and Product Managers (PM) stems from the same place: a lack of a shared definition of “good”.

All three are valid. The problem is that without a mechanism, the discussion becomes political. SLOs and error budgets are part of that mechanism. If consumption is low, the team has room to take risks, ship changes, and push new features. If the error budget burns quickly, it is a clear signal to stop, stabilize, and pay down debt.

From a Tech Lead’s perspective, SLOs and error budgets are among the most powerful levers for negotiating speed, scope, and quality without relying on opinions or hierarchy.

They do not remove hard conversations, but give them structure instead.

It’s all about reducing uncertainty

Here is the key part for a Tech Lead: operational excellence is not “being an SRE” or “living in Grafana”. It is about designing an operating system for the team that minimizes uncertainty.

A TL leads operational excellence when they make it possible to:

• Detect problems quickly

• Diagnose with less guesswork

• Mitigate in a repeatable way

• Learn for real, not through incident reviews nobody executes

• Keep the on-call load sustainable

• Make trade-offs using data

Subscribe now

👋 Hi, I am João. This is the third post of a series designed for Tech Leads and Engineering Managers who want to lead with greater clarity and intention.

• “Traits of a good Tech Lead”

• “I’m a Tech Lead, and nobody listens to me. What should I do?”

• “Operational Excellence, the Tech Lead lever” ← This article

• To be continued…

I’m currently writing “The Tech Lead Handbook”, scheduled for release in H1 2026. The ideas in this series will form its core.

If you join the waitlist, you will receive a 25% launch discount.

Join the waitlist

What should they lead? What should they influence?

Clarity matters here. Otherwise, the TL tries to cover everything, becoming a bottleneck.

The TL should lead

• Definition of SLIs and SLOs that represent user experience, not vanity metrics

• Alerting philosophy: alert on user-visible symptoms, not internal causes

• Minimum instrumentation: logs, traces, metrics, and diagnostic standards

• Incident hygiene: clear runbooks, contextual alerts, and structured incident reviews

• Cadence: regular review of SLOs and resulting actions

The TL should influence

• Error budget policy and its impact on the roadmap, with PM and EM

• Prioritization between reliability and new features, with EM and PM

• Definition of technically measurable KPIs, not “wishful” ones, with PM

• Investment in tooling, with EM and the relevant platform team, if applicable

The TL should not carry alone

• On-call rotations and guardrails, owned by EM

• External communication, roadmap decisions, and product narrative, owned by PM

• Cross-org agreements and political negotiation with other stakeholders, owned by EM or PM, depending on context

The TL participates in everything. But does not own everything.

Different team archetypes, the same role

So far, I have talked about KPIs, SLIs, and SLOs in fairly abstract terms. In practice, their design depends heavily on the type of team you are in. More precisely: where is the team’s center of gravity?

Pure teams are rare. Most operate somewhere in between. Even with the Team Topologies framework, what usually changes is not the team type but its center of gravity. Some teams lean toward building and operating platforms. Others toward delivering direct product value. The framework is the same. The focus changes.

Platform teams

In platform teams — cloud infrastructure, shared components, multi-tenant services — your primary user is usually another team. That changes how you define “good”.

Let’s start with SLIs and SLOs. A globally aggregated SLI often hides real problems. You need visibility at the tenant, cluster, or logical partition level.

Support is also an explicit part of the service. Time to first response or resolution can be a perfectly valid SLO. The same applies to documentation and self-serve capabilities. They reduce tickets, interruptions, and uncertainty. They are part of reliability.

In this context, the KPIs that give a TL the most leverage are usually internal and operational:

• Number of active teams or integrations

• Ticket volume and deflection capacity

• Unit cost per request, tenant, or key operation

• Operational noise: recurring incidents, alerts, and on-call load

These KPIs do not directly measure business success. They measure whether the platform scales sustainably as the organization grows.

Common antipattern

Optimizing stability and cost without a clear signal of adoption or real value for user teams. The system works, but nobody uses it. Operational excellence without impact is also debt.

Product teams

In product teams — teams that ship and maintain user-facing features — the focus shifts to end-user experience.

Here, SLOs such as availability should not be defined at the service or endpoint level, but at the critical flow level: search, checkout, publish, book. Average latency matters little if the key funnel step is slow or failing. Correctness is also defined at the business level. An HTTP 200 is useless if the result is wrong.

This does not mean product teams lack internal KPIs. They exist and matter. From a TL perspective, two layers coexist.

On one side, internal operational KPIs:

• Incident count and severity

• Alert noise and on-call load

• Lead time, deployment frequency, and production failures, for example, DORA metrics

• Operational cost per request or per user

On the other side, product-adjacent technical signals:

• Crash-free sessions.

• Performance by device, version, or segment.

• Functional errors that do not surface as obvious technical failures.

These internal KPIs do not replace business KPIs. But they constrain them. If the system is slow, unstable, or expensive to run, conversion, retention, and experimentation will degrade over time, even if it is not obvious at first.

Here, role boundaries matter. The PM owns the outcome. The TL ensures the system can pursue it without breaking.

Common antipattern

Optimizing conversion and experimentation while internal KPIs degrade. At first, everything looks fine. Then velocity collapses, and every change costs twice as much.

The common point

Regardless of the center of gravity, the Tech Lead’s job is the same: define what “good” means, measure it honestly, and turn those signals into decisions.

What changes is not the TL role, but where operational excellence has the biggest impact.

Subscribe now

A simple system that works

Most teams do not fail due to a lack of metrics, but because those do not change any decisions. Not because metrics are missing, but because they do not influence real work. The key is not the tool or the level of sophistication. It is closing the loop: measure, decide, act.

In practice, teams that do this well share a pattern: few well-chosen indicators, explicit objectives, and a regular cadence to turn signals into decisions. This usually means:

• A small set of SLIs that represent real system behavior

• One or two SLOs per critical flow

• Alerts that indicate real user-facing degradation

• A clear rule for what to do when that happens

• Regular reviews that turn into concrete actions

🎁 Do you want to apply this to your team?

Throughout the article, I have discussed KPIs, SLIs, and SLOs, and how to use them to make better decisions. But the difference is not understanding the concepts. It is putting them to work day to day. For that, I prepared two practical templates that I use with teams:

• Define KPIs, SLIs, and SLOs, and make “good” explicit in your context.

• Monthly review to turn metrics into real decisions, not dashboards.

They are not theoretical frameworks or universal recipes. They are simple artifacts to close the loop: measure, decide, act.

Subscribe and fill out the form to receive them. Free.

Download SLI, SLO and monthly review guide

Note: If you already requested access to the EM/TL alignment toolkit, this is not a new download. The KPI, SLI, and SLO templates, along with the monthly review, are part of the same document you already have: the toolkit with the self-assessment semaphore that goes together with the 90-day plan for Tech Leads.

Operational excellence is how you buy velocity

Going back to what I learned at mytaxi, something simple stuck with me: being right is not very useful if you cannot move the team. And moving the team is not about explaining things better. It is about changing the frame in which decisions are made.

When you work with well-defined SLIs, SLOs, and KPIs, you stop asking for faith and arguing over gut feelings. You start operating with a system that makes trade-offs visible and decisions easier.

That is, for me, one of the biggest contributions of a Tech Lead: turning fuzzy conversations into repeatable decisions, and repeatable decisions into sustainable speed.

Because the goal was never fewer incidents for technical pride. The goal is to deliver value consistently, without burning out the team, and without living with the feeling that any Monday at 9 a.m., everything could blow up.

— João

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.

Subscribe now

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

I’ve been writing on HEY World for a while. It’s a refreshingly simple way to blog: send an email to world [at] hey dot com, and it becomes an article with an RSS feed people can subscribe to, like a newsletter.

I enjoyed it enough that I recently imported all my HEY posts into my own domain.

Why changing, then?

There are a few reasons I want to change the platform I use to publish content. I want:

1. A better experience for my writing. I’m a heavy user of (good?) formatting, and not being able to use different headings or not having captions for images was a pain. This comes first because I write for myself first. To share my learnings and condense them in a written form.

2. A better experience for my readers. Substack comes with an app, and it’s pleasing to read posts here. Other big newsletters, like “The Pragmatic Engineer” and “Scarlet Ink,” use it.

3. My own domain. Non-negotiable. The web is increasingly a walled garden, but I still want a way out. Currently, because my posts are imported from “HEY” into my domain, I need to state that the “canonical URL” is the one in “HEY”. Not nice for search engines and discoverability.

4. Features like stats, surveys, and monetization. I need to understand what my audience is — even if, again, I write for myself — where they come from, whether a newsletter mentioned my articles, etc. I also want an easy way to distribute free content to my readers. While Substack does not excel at it, I can do it by creating a survey and letting people subscribe. In “HEY”, I need to put a link to a Google Form and import the email after. Bad UX for users, more work for me.

Still, this move is not just about tooling. It changes how I write, how often I publish, and how you read and interact with the content.

What can I expect?

As you can see from my blog stats, I’m not the most consistent writer. That is, in part, because I tend to prefer sprints over marathons and because my brain is wired that way. I’m trying to change that and force myself to push content out there. You can expect:

• Articles about software engineering, tech leadership, and engineering management. I’m currently writing a series for Tech Leads, paired with a book. So far, I’ve written two pieces in English:

  • Traits of a good Tech Lead

  • I’m a Tech Lead, and nobody listens to me. What should I do?

  • Coming soon: “Operational Excellence, the Tech Leads’ lever”

• Startups and how they operate

• Processes, culture, and productivity in engineering teams

• Important trends in the technology industry

I’m not committing to an exact number of articles yearly. I also write in Spanish, and sometimes the articles will be a translation one way or the other. But I’m trying to keep original content in both.

Subscribe now

The difference is that this is now the place where everything lives. One domain, one archive, one feed you can rely on. If you’ve found value in my writing before, you’ll find it here too.

— João