Forem: Alvaro

Most Software Engineering -ilities Are Becoming Irrelevant in the Age of AI

Alvaro — Sat, 25 Apr 2026 12:58:16 +0000

For decades, engineering has been shaped around a set of principles that we rarely question. Maintainability, testability, modularity, and reusability have been treated as foundational qualities of good systems. They are deeply embedded in how we design architectures, review code, and evaluate technical decisions.

The assumption behind them is simple: if we optimize for these qualities, we will build systems that last longer, scale better, and are easier to evolve.

But that assumption was built for a different world.

A world where writing software was expensive. A world where change was slow. A world where mistakes were costly to recover from.

That world is disappearing, but our mental models have not caught up.

In previous articles, I explored how AI is not removing complexity, but shifting where it lives. Execution is no longer the bottleneck. The constraints have moved toward coordination, decision-making, and validation. The system did not get simpler. It just changed shape.

If you haven’t read them, this builds directly on:

Because once execution stops being the limiting factor, many of the qualities we have historically optimized for don’t just lose importance. They become the wrong optimization target.

Most “-ilities” were never ideals

We tend to talk about “-ilities” as if they were timeless engineering virtues. In reality, they were responses to constraints.

Maintainability exists because rewriting systems was historically expensive. If making changes was difficult, then the rational strategy was to design systems that could be safely extended over time. The goal was not elegance, but survival.

Reusability exists because duplication was costly. If writing the same logic twice meant additional effort, additional bugs, and additional maintenance overhead, then abstracting and centralizing logic became the obvious optimization.

Testability exists because confidence was hard to achieve. When systems were opaque and debugging was slow, the only scalable way to reduce risk was to introduce layers of validation.

These were not universal truths about good engineering. They were adaptations to a specific cost structure.

That cost structure has changed

With AI-assisted development, the cost of producing code has dropped significantly. Generating, modifying, and even rewriting large portions of a system is no longer a prohibitive activity. What used to require careful design upfront can now be explored iteratively at a much lower cost.

This changes the trade-offs in a fundamental way.

If rewriting is cheap, the value of maintainability decreases. If duplication is cheap, the value of reusability decreases. If tests can be generated automatically, the role of testability shifts.

This does not mean these qualities disappear. But it does mean they are no longer the dominant factors in system design.

One of the most overlooked consequences of this shift is that we are still optimizing for the constraints of the past. We are investing time and complexity into preserving systems that, in many cases, would be cheaper to regenerate than to maintain.

When rebuilding becomes cheaper than maintaining, maintainability stops being the primary concern.

The first cracks appear in practice

This is not just a theoretical shift. It is already visible in how systems behave in real organizations.

In one case, a company I spoke with was focused on evolving their core platform to support a new business model. The effort was estimated in months of refactoring, carefully preserving existing structures and abstractions. Instead, a full rewrite using AI was completed in two weeks and reached feature parity.

The implication was not just speed. It was that the original investment in maintainability did not pay off under the new cost structure.

The pattern tends to repeat. Systems were designed with long-term maintainability in mind, often introducing layers of abstraction and structure intended to make future changes easier. Engineers avoid touching certain parts of the system because they are too complex or too constrained.

However, as requirements evolve faster and timelines compress in the age of AI, those same structures become friction. What was designed to enable change starts to resist it.

The assumption that systems will be incrementally evolved over long periods of time is becoming less reliable, and in some cases, a fallacy.

The “-ilities” that AI is killing

If we take the shift in constraints seriously, some “-ilities” are not just losing importance. They are becoming actively misleading as primary goals.

Maintainability is the clearest example. It assumes that systems should be preserved and evolved over long periods of time. But when rebuilding is cheaper than understanding, preserving structure becomes a liability rather than an advantage.

Reusability follows the same pattern. It was designed to reduce duplication in a world where writing code was expensive. Today, duplication is often cheaper than coordination. Shared abstractions introduce dependencies, and dependencies slow teams down. What was once efficiency becomes friction.

Readability is another concept that starts to break under this new model. We have long optimized code for human consumption, assuming that engineers would spend significant time reading and understanding existing systems. But increasingly, machines are the ones generating, modifying, and even explaining code. Human readability is no longer the only, or even the primary, interface.

This does not mean readability disappears entirely, but its role changes. We are no longer optimizing code to be read line by line by humans. We are optimizing systems to be interpreted, transformed, and regenerated by machines.

Testability, while still relevant, is also shifting. The ability to generate tests is improving rapidly, but the ability to define what correctness means has not kept pace. We are automating validation without necessarily improving understanding. This creates a risk of false confidence at scale.

What all of these have in common is that they optimize for a world where execution was expensive. As that constraint weakens, so does their centrality.

The -ilities that remain

If we shift the focus from code to systems, a different set of concerns emerges. These are not tied to how code is written, but to how systems behave under continuous change.

Observability becomes critical because systems evolve faster than individuals can track. Understanding behavior in production becomes more valuable than understanding implementation details. When change accelerates, visibility becomes the only stable reference point.
Reliability remains essential because increased change frequency introduces more opportunities for failure. Faster delivery does not reduce risk; it amplifies it. Systems need to withstand continuous modification without degrading.
Security expands in scope as AI-generated systems introduce new forms of risk, including supply chain vulnerabilities, generated flaws, and unintended behaviors. The surface area increases even if the effort per change decreases.
Scalability also becomes more, not less, important. As the cost of building decreases, the number of systems, features, and interactions increases. Load is no longer just a function of users, but of system complexity and internal interactions. Systems must scale not only in traffic, but in the rate of change they can handle.
Evolvability becomes a more accurate framing than maintainability. The question is no longer whether a system can be maintained efficiently, but whether it can adapt continuously without collapsing under its own complexity.

The uncomfortable conclusion

Engineering has always been about managing constraints.

What has changed is which constraints matter.

If we continue to optimize for maintainability, reusability, and other code-level qualities as primary goals, we risk improving the wrong part of the system. We become more efficient at preserving systems that should be replaced.

The dominant challenges are no longer in writing software, but in deciding what to build, aligning on why it matters, and adapting systems as reality changes.

The most important “-ilities” are no longer properties of code.

They are properties of how organizations operate under increasing speed and complexity.

🗞️ Other articles you may like

✌️ That’s all folks

I love hearing from readers, and I’m looking for feedback. How am I doing with The Engineering Tax? Is there anything you’d like to see more or less? Which aspects of the newsletter do you enjoy the most?

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

Please don’t hesitate to connect with me on LinkedIn and send a message. I always respond to everyone!

Clean Architecture Is Dying How AI Is Killing Essential Software Patterns

Alvaro — Sat, 25 Apr 2026 12:58:06 +0000

For decades, we repeated a simple idea: code is read more than it is written.

So we optimized for readability. For naming. For clarity. For structure that could be navigated by someone who didn’t write the code.

That assumption is breaking.

Code is now generated more than it is written. It is traversed by machines before it is ever read by humans. It is modified, expanded, and reorganized by systems that do not need meaningful names or carefully crafted layers to understand what is happening.

Humans are no longer the primary readers of code. We are reviewers at best. We serve as auditors for a system that is becoming increasingly self-reliant.

Despite this, we persist in optimizing as if a future developer will manually navigate the system and comprehend every line.

We are optimizing codes for the wrong audience.

The industry still treats the code as literature.

It is increasingly closer to bytecode.

And because of that, a large part of what we call “good engineering” has quietly become unnecessary. Meaning, patterns, and languages are becoming less important.

The Cost Model Has Inverted

This transformation is the shift most people haven’t fully internalized.

In the old model, writing code was expensive. Changing it was risky. Running it was relatively cheap. So we optimized everything around reducing change. We introduced patterns to isolate impact. We introduced abstractions to avoid rewriting. We introduced processes to minimize risk.

In the new model, writing code is cheap. Changing it is cheap. Running it—at scale, continuously, globally—is where cost accumulates. So the optimization target changes.

We should no longer be asking, “How do we make the code easier to maintain?” . We should be asking, “How do we make the software cheaper to run, easier to validate, and faster to evolve—even if that means rewriting it?”

We spent decades optimizing the cost of writing code. We are entering a phase where the dominant cost is running it.

DDD, Hexagonal Architecture… Were Always About Fear

SOLID principles, Domain-Driven Design, ports and adapters, hexagonal architectures…we were taught these as markers of maturity. These were taught as indicators of engineering rigor. These were taught to distinguish amateurs from professionals.

But underneath, they all share the same assumption: we don’t know what will change, and when it does, it will be expensive.

So we prepare. We abstract. We decouple. We introduce interfaces that may never have more than one implementation. We create layers of indirection to absorb hypothetical futures.

We built systems that are easy to change because changing them was hard.

AI changes that equation. We are now operating in a world where regeneration is getting cheaper faster than abstraction.

Abstractions exist to preserve structure over time. They reduce the need to change codes by anticipating variations.

Regeneration does the opposite. It embraces change. It assumes that structure is temporary and can be recreated as needed.

We Now Care More About Product Quality, Not Code Quality

We haven’t stopped caring about quality. But it’s moving from structure to behavior. The focus has shifted from code elegance to system outcomes.

Validation shifts toward runtime instead of relying entirely on compile-time guarantees. Observability becomes more important than internal structure, because what matters is not how the system is built, but how it behaves under real conditions.

We move from designing systems that are easy to understand to systems that are easy to evolve.

The source of truth shifts.

It is no longer the code.

It is the behavior of the system in production.

TypeScript, C#, and “Developer-Friendly” Languages Were a Local Optimum

We chose our languages based on developer experience.

TypeScript, C#, Python, Java… All of them share a common goal: make it easier for humans to write and maintain code.

That was the right optimization—when humans were the ones writing most of it.

Now the cost of writing code is collapsing. The marginal effort of producing another implementation, variation, or approach is close to zero when AI is in the loop.

So the axis shifts.

If developer time is no longer the dominant cost, then optimizing for developer ergonomics is no longer the dominant strategy.

What starts to matter is not how easy code is to write but how it behaves when it runs.

We spent the last two decades optimizing the authoring experience, but we are entering a phase where the dominant cost is execution.

The Return of Low-Level Thinking

This phase is where things get uncomfortable.

If code is cheap to generate and cheap to change, then performance, memory efficiency, and runtime predictability become more important.

Not because systems got bigger. But because the cost structure shifted.

The trade-off flips. We no longer optimize for developer time. We optimize for machine time.

And that naturally pulls us toward languages and paradigms we spent years abstracting away from.

We might return to low-level languages not because developers improved, but because developers matter less in the loop.

The Part Nobody Wants to Admit

A large part of modern software engineering exists to compensate for human limitations.

We built patterns to help us think. Languages to help us express intent. Architectures to help us avoid mistakes.

Those constraints were real. They shaped an entire discipline. But they are not as dominant as they used to be. If the constraints change, the practices built around them do not automatically remain optimal.

Clean Architecture didn’t become wrong.

SOLID didn’t become useless.

TypeScript didn’t become a bad language.

They became expensive.

And most of the industry hasn’t noticed yet.

🗞️ Other articles you may like

✌️ That’s all folks

Use the links below, or even better, hit reply and say hello. I’d love to hear from you!

Please don’t hesitate to connect with me on LinkedIn and send a message. I always respond to everyone!

Engineering After AI 3 Ways to Fix the Real Bottlenecks in Modern Teams

Alvaro — Sat, 25 Apr 2026 12:58:04 +0000

Execution is no longer scarce. It has been compressed by years of tooling improvements and, more recently, by AI. The cost of producing software continues to fall.

What has not changed is everything around it.

Decisions are still slow.
Validation is still uncertain.
Alignment is still expensive.

This creates a structural imbalance: the system can now produce more than it can meaningfully process.

At that point, improving speed stops being useful and just hinders the system.

What matters is how the system decides what deserves to be scaled.

1. Optimize for Learning Velocity, not Delivery Speed

Speed only creates value if it is connected to learning. Shipping faster does not matter if the system cannot determine whether what was shipped was correct. The real loop is not:

build → ship → repeat

It is:

decide → build → learn → adjust

And in many organizations, the “learn” step is the weakest.

Feedback is delayed, indirect, or disconnected from the original decision. By the time signals arrive, multiple layers of work have already been built on top of unvalidated assumptions. The system moves quickly, but without a tight connection to reality.

Improving this does not require more data, but better alignment between decisions and feedback.

Every initiative should define, upfront, what change it expects to create—whether in user behavior, system performance, or business outcomes. Feedback mechanisms should be designed to observe that change as directly as possible. When that is not feasible, uncertainty should be made explicit rather than ignored.

Research on software delivery performance consistently shows that high-performing teams are defined not just by speed, but by how quickly they can detect and recover from mistakes.

In a world of cheap execution, the advantage is not who builds faster.

It is who learns faster.

2. Design for Flow Efficiency, not Resource Efficiency

Most organizations are still optimized for keeping people busy. Maximizing utilization. Filling roadmaps. Ensuring constant activity.

This made sense when execution was expensive—when writing, testing, and shipping software required significant effort and time. But that constraint is fading. AI has reduced the cost of execution dramatically.

What hasn’t changed is how organizations are designed. Activity is no longer scarce. Attention is.

And yet, many teams continue to optimize for utilization, as if idle time were the primary risk. It isn’t. The real problem is not idle engineers—it is work that doesn’t move.

Work that sits in queues. Waiting for decisions. Waiting for alignment. Waiting for context. Waiting to be understood. This is where most time is lost.

Flow efficiency shifts the lens. Instead of asking whether people are busy, it asks whether work is progressing smoothly through the system. Whether ideas become outcomes without unnecessary friction.

This leads to very different design choices.

Smaller batches, so uncertainty and decisions surface earlier instead of accumulating. Fewer parallel initiatives, so attention is not fragmented across competing priorities. Reduced handoffs, so context is preserved and rework minimized. Clear ownership, so work does not stall in ambiguity or shared responsibility.

These are not optimizations of effort—they are optimizations of movement.

Research in lean systems and software delivery consistently shows that reducing work-in-progress and shortening queues improves system performance disproportionately. Not by increasing output, but by eliminating waiting time and coordination overhead.

Because when execution becomes fast, queues become the dominant constraint.

And most organizations are full of invisible ones.

3. Institutionalize the Ability to Say No

When execution becomes cheap, the default response is to build more. More features, more initiatives, more surface area. Work enters the system easily, almost automatically, because the cost of saying “yes” has collapsed.

But the cost of carrying what you build has not.

Every addition introduces complexity. Dependencies increase, constraints accumulate, and the system becomes harder to evolve. These costs are not immediate, which is why they are often ignored. Over time, the system doesn’t fail because it lacks capability—it fails because it has too much of it.

At that point, speed stops helping. You can still ship, but each change requires more coordination, more context, more effort. The system moves, but with increasing friction.

This is rarely framed as a consequence of saying “yes” too often, but that is exactly what it is.

In most organizations, saying no is informal. It depends on individuals, moments, and negotiation. That makes it inconsistent. Some things are rejected, many are not, and very little is ever removed.

Without removal, complexity only grows.

Research on cognitive load consistently shows that beyond a certain point, more options and features degrade both usability and decision quality. More is not neutral. It actively makes the system worse.

In a world where building is cheap, the constraint is no longer creation.

It is how much you allow into the system—and how much you are willing to remove.

Conclusion

Execution now scales easily. That is no longer where advantage comes from.

What defines the system is how quickly it learns, how smoothly work flows, and how much unnecessary complexity it avoids. These are not improvements on top of the system—they are what the system is now built around.

Organizations that continue to optimize for output will produce more.

Organizations that adapt will produce less—but with far greater clarity and impact.

Because once building becomes cheap, the real discipline is not in what you create. It is in what you choose not to carry forward.

The Real Bottleneck in Engineering Why AI Didnt Fix What Slows Teams Down

Alvaro — Sat, 25 Apr 2026 12:57:53 +0000

For years, we optimized engineering speed.

We invested in better tooling, faster CI/CD pipelines, cleaner architectures, and platform engineering capabilities that reduced friction across the delivery lifecycle. Entire organizations reorganized around improving developer productivity, shortening lead times, and increasing deployment frequency. The assumption was simple: if we could make engineering faster, everything else would follow.

And for a long time, it did.

But something subtle has changed.

Today, teams can build faster than ever before. AI has further reduced the cost of execution, compressing hours of work into minutes and making exploration almost free. Yet despite this acceleration, most organizations are not seeing a proportional improvement in outcomes. Delivery performance is not dramatically better. Quality is not consistently higher. In some cases, stability is even degrading.

That mismatch is not accidental.

It’s a signal that we are still optimizing for a constraint that does not exist.

Engineering is no longer the bottleneck

For most of modern software development, execution was expensive.

Writing production-grade code required time, coordination, and deep expertise. Testing, integrating, and deploying safely introduced additional layers of friction. Improving these areas had a direct and measurable impact on performance, which is why so much focus was placed on optimizing them.

Frameworks like DORA reinforced this approach by showing how capabilities such as deployment frequency, lead time, and change failure rate correlated with high-performing teams. The industry responded accordingly—investing heavily in automation, DevOps practices, and platform engineering to remove bottlenecks in delivery.

Recent observations across teams show that even as execution becomes significantly faster—especially with AI assistance—system-level performance does not improve at the same rate. In fact, some studies suggest a more complex picture: while developers report feeling up to 55% faster when using AI tools, controlled experiments on complex tasks show that experienced engineers can actually become slower, as they spend additional time validating, correcting, and integrating AI-generated outputs. At the same time, broader delivery metrics show little to no improvement in throughput and, in some cases, a decline in stability.

This contradiction points to a deeper reality:

When improving one part of a system no longer improves the whole, it usually means the constraint has moved elsewhere.

The real bottleneck: coordination and decisions

Modern engineering is not a pipeline—it is a network.

Value is not created in isolation by writing code but through a continuous flow of decisions across multiple domains: product defining priorities, design shaping user experience, security enforcing constraints, compliance defining boundaries, and business stakeholders driving commercial direction. Every meaningful change in the system crosses these boundaries.

And at each boundary, coordination is required.

Research into organizational dynamics has consistently shown that as companies scale, collaboration overhead increases non-linearly. Studies on “collaborative overload” highlight how a small percentage of individuals, often in central roles like engineering leads and senior developers, become bottlenecks because they sit at the intersection of too many dependencies. At the same time, research on attention residue demonstrates that frequent context switching significantly degrades cognitive performance, reducing the quality of decision-making and increasing error rates of those individuals.

In practice, this means that a growing portion of engineering time is not spent building but navigating communication: meetings, alignment discussions, clarifications, and trade-offs.

This is where the real work happens.

Deciding what to build. Aligning on why it matters. Understanding how it fits into an evolving system. And validating it affects the correct metrics in the expected way.

These activities are inherently slower, more ambiguous, and harder to optimize than execution. And unlike code generation, they cannot be easily automated.

This has always been and will continue to be a bottleneck, as it’s a system absorption problem and not a procedural optimization.

AI didn’t remove complexity—it accelerated exposure to it

AI has not simplified this system. It has intensified it. By dramatically reducing the cost of execution.

AI increases the rate at which teams can generate output. More ideas are explored, more features are started, and more changes are introduced into the system. On the surface, this looks like progress. But each of those outputs carries a hidden cost: it requires decisions, alignment, and validation.

And those layers have not accelerated because:

Customer feedback still takes time.
Understanding real impact still takes time.
Aligning multiple stakeholders still takes time.

So what emerges is a structural mismatch:

Execution operates at one speed.
Decision-making and validation operate at another.

The result is predictable.

Teams hit the coordination bottleneck more frequently. More work enters the system than the organization can properly process. Context switching increases. Alignment becomes fragmented. And decision quality begins to degrade under pressure.

We did not remove complexity. We increased the rate at which we collide with it.

Conclusion: The constraint is now cognitive, not technical

For years, we thought the limiting factor in engineering was only technical.

How fast we could build. How safely we could deploy. How efficiently we could execute.

Today, that has been shown not to be the truth. The constraint is something less visible but far more fundamental: our ability to make good decisions, align across boundaries, and validate before scaling.

And most organizations are not designed for this.

They are still optimized for a world where execution was expensive and slow. A world where the primary challenge was building the thing.

That is no longer the challenge.

Now, the challenge is knowing whether the thing we are building should exist at all—and proving it before we scale it.

The Illusion of Speed Why AI Is Making Teams Fasterbut Not Better

Alvaro — Sat, 25 Apr 2026 12:57:43 +0000

Two weeks ago, I built an MVP for StrengthsOS in under 12 days. At the same time, I started rewriting Octolaunch from scratch. That’s not the interesting part.

The interesting part is that this is becoming normal.

What used to feel like exceptional productivity is quickly turning into baseline. Features that once required days of focused work now emerge in hours. Entire systems can be scaffolded in a single sitting. The barrier between idea and implementation has almost disappeared.

And if you look at most engineering teams right now, the signals all point in the same direction: more output, faster cycles, and shorter time to code.

So why does it feel like nothing is actually improving?

Output is exploding; outcomes are not

Across teams, the pattern is hard to ignore.

Developers are shipping more code than ever before. Pull requests are increasing, backlogs are moving faster, and the visible indicators of productivity are trending up. On dashboards and status reports, it looks like acceleration.

But when you step back and look at the system as a whole, the picture becomes less convincing.

Quality is not improving in a meaningful way. Delivery performance remains largely unchanged. In many cases, rework is quietly increasing. The system absorbs more activity, but it does not translate into better outcomes.

This is not just anecdotal. Early data is starting to surface a contradiction. Some studies show developers feel significantly more productive—reporting perceived speed increases of over 50% when using AI tooling. At the same time, controlled experiments on complex tasks show performance can actually degrade, particularly for experienced engineers. And broader delivery metrics show little to no improvement in throughput, with stability in some cases declining.

At the individual level, everything feels faster. At the system level, nothing really moves.

That is the paradox.

AI optimized execution, not decisions

The reason becomes clearer when you separate two layers that are often conflated: execution and decision-making.

AI has dramatically improved execution. Writing code, generating tests, exploring implementations—these activities are now cheaper, faster, and easier than ever before. The friction that once slowed down development has largely been removed.

But the hardest part of engineering was never execution.

It was deciding what to build, why it matters, and how it fits into a broader system of constraints. It was aligning multiple stakeholders with different incentives. It was designing systems that could evolve without collapsing under their own complexity.

None of that has changed.

Modern engineering is not a linear pipeline; it is a network of interdependent decisions spanning product, design, security, compliance, and operations. Value is created—or destroyed—at the boundaries between these domains. And those boundaries are still governed by coordination, judgment, and trade-offs.

Research consistently shows that as organizations scale, these coordination costs grow faster than the teams themselves. More stakeholders, more dependencies, more alignment overhead. In many environments, the majority of time is already consumed by communication, meetings, and context switching rather than actual building.

AI does not remove this complexity.

It simply makes it easier to execute whatever decision has already been made.

You can now scale bad decisions

This is where the dynamic becomes dangerous.

When execution was expensive, it didn’t just slow teams down—it created space for validation. Building something took time, and that time allowed reality to catch up. Teams could observe how features behaved in the wild, understand trade-offs, and adjust direction before moving forward.

That constraint is now gone. Execution is nearly instantaneous, but validation is not. Customer feedback still takes time. Business impact still takes time. Understanding whether something actually works still takes time.

So we’ve created a mismatch. Decisions are made quickly. They are implemented even faster. But they are validated at the same speed as before.

That means teams are now chaining decisions that haven’t proven themselves yet. A feature is extended before its value is clear. A direction is reinforced before it’s tested. An assumption becomes a roadmap before it becomes evidence.

What used to be a sequence of build → learn → adjust is quietly turning into build → build → build. We are not just scaling bad decisions. We are scaling unvalidated ones. And the more we accelerate execution without closing that validation loop, the weaker the connection becomes between what we build and the value it creates.

More output doesn’t mean more impact. It just means we are moving faster on assumptions we haven’t yet earned the right to trust.

Conclusion: The bottleneck has moved

For years, engineering was constrained by execution. Now it isn’t. We can build faster than ever before. But we cannot validate, align, or decide any faster than the systems around us allow.

And that creates a new kind of bottleneck.

Not in code. Not in tooling. But in understanding.

The ability to decide what matters. The ability to align around it. The ability to validate it before scaling it.

That is now the limiting factor.

And most teams are still optimizing for the layer that stopped being the constraint.

In the next issue, I’ll break down where the real bottleneck is hiding—and why most organizations are not designed to handle it.

The Moment Process Starts Eating Your Day

Alvaro — Sat, 25 Apr 2026 12:57:43 +0000

Introduction

As organizations scale, governance expands. Reporting structures multiply, compliance requirements mature, alignment rituals increase, and cross-functional touchpoints become more frequent. None of this is inherently problematic. In fact, process often emerges to reduce chaos and increase predictability.

However, there is a tipping point.

At a certain stage of organizational growth, engineering leaders begin to notice a structural shift: the majority of their time is no longer invested in enabling value creation or shaping long-term direction. Instead, it is absorbed by coordination, documentation, reporting, and operational synchronization.

This is the moment the process starts eating the day. The risk is not that the process exists. The risk is when the process begins to systematically displace strategic and value-generating work.

The paradox is clear: process is introduced to support value creation, yet beyond a certain threshold, it competes with it.

Governance in Growing Environment Normally Becomes Self-Reinforcing

As organizations grow, process layers are often added in response to past incidents or perceived risk. Rarely are they removed. Over time, leaders inherit overlapping rituals, redundant reporting, and duplicated reviews.

Research on digital transformation from McKinsey indicates that complexity is a primary cause of execution failure in scaling organizations. High-performing digital companies actively simplify decision-making and reduce unnecessary procedural friction.

When process expansion is not accompanied by intentional simplification, it gradually dominates leadership bandwidth as governance complexity compounds over time.

Engineering leaders become coordinators of governance rather than designers of systems.

Value Work vs. Process Work

To understand the tipping point, it is useful to distinguish between two categories of leadership effort:

Value-oriented work includes:

Architectural & strategic direction setting
Technical & non-technical prioritization
Developer experience improvement
Talent development and mentoring
Long-term system design

Process-oriented work includes:

Status reporting
Governance documentation
Compliance questionnaires
Budget control & updates
Recurrent alignment meetings
Escalation handling

Both categories are necessary. However, only one category compounds long-term engineering capability.

Beyond the time allocation, there is also a cognitive dimension to this problem. As value-oriented tasks require uninterrupted cognitive bandwidth. When leadership calendars are saturated with 30-minute blocks dedicated to reporting, coordination, and alignment, deep thinking becomes fragmented.

The result is not immediate failure, but a slow erosion of strategic clarity:

Architectural decisions become reactive.
Technical debt accumulates incrementally.
Innovation slows.
Platform investments are deferred.

The organization continues operating, but its engineering foundation weakens. In engineering leadership, process overload does not merely consume time; it reduces strategic depth.

The Strategic Opportunity Cost

The most significant cost of process saturation is opportunity cost.

Time invested in incremental reporting is time not invested in:

Platform modernization
Reliability engineering
Developer productivity tooling
Technical innovation
Architectural resilience

These investments may not generate immediate visibility, but they determine long-term competitiveness.

DORA research demonstrates that elite-performing engineering organizations achieve both higher velocity and stronger stability. This dual capability is not accidental; it results from consistent investment in foundational engineering practices.

If leadership capacity is absorbed entirely by governance management, the organization risks optimizing for short-term coordination while sacrificing long-term capability.

Restoring Balance: Designing for Strategic Capacity

The solution is not eliminating the process. Governance is necessary in complex systems. The objective is balance.

Periodic process audits are important. Every recurring meeting and reporting requirement should be evaluated against a simple question: does this materially improve decision quality or reduce meaningful risk?

If not, it should be simplified or removed.

Protecting strategic bandwidth is not optional. It is a prerequisite for sustainable engineering performance.

Conclusion

The moment the process work starts eating the day is rarely dramatic. It is incremental. A few more meetings. Additional reporting cycles. Expanded review layers. Increased cross-functional synchronization.

Over time, the cumulative effect is substantial.

Engineering leadership requires governance, but it also requires protected space for value creation and strategic direction.

When process displaces strategy, long-term engineering capability erodes.

The responsibility of engineering leadership is not to resist governance but to prevent it from overwhelming the system it was designed to support.

Sustainable organizations do not eliminate process. They design it intentionally and defend the time required to build the future.

When You Realize Engineering Is Everyones Dependency

Alvaro — Sat, 25 Apr 2026 12:57:32 +0000

Introduction

In technology-driven organizations, engineering is not merely a delivery function — it is the execution engine of the business. Strategic ambition, product vision, commercial commitments, regulatory obligations, and operational reliability ultimately depend on engineering capacity.

As organizations scale, this structural dependency becomes increasingly visible. Engineering leaders often experience a shift in role: from managing teams and technical systems to managing organizational interdependence. The realization that “engineering is everyone’s dependency” reflects how modern companies are architected.

Research supports this structural centrality. The DORA (DevOps Research and Assessment) “Accelerate State of DevOps” reports, now published by Google Cloud, consistently show that high-performing engineering organizations outperform peers in profitability, productivity, customer satisfaction, and resilience.

Similarly, McKinsey research on technology performance indicates that companies with strong engineering and digital capabilities significantly outperform competitors in revenue growth and operating margin.

When engineering performance correlates directly with business outcomes, dependency intensifies. That dependency introduces both leverage and complexity.

Engineering as the Organizational Convergence Layer

In digital-first companies, every major initiative requires engineering participation:

Product strategy must be validated against technical feasibility.
Sales commitments require implementation capacity.
Security and compliance frameworks require system-level integration.
Financial efficiency initiatives often depend on architectural optimization and automation.

Cross-functional coordination has grown accordingly. A Harvard Business Review analysis on collaboration overload by Rob Cross and colleagues found that time spent on collaborative work has increased dramatically over the past two decades, often consuming more than 50% of managers’ time. In environments where engineering sits at the center of execution, this coordination burden is amplified.

The dependency of multiple functions on engineering does not inherently create dysfunction. However, it does create a system in which engineering leaders must continuously reconcile competing priorities within finite capacity constraints.

The Leadership Role as Translation and Integration

As cross-functional dependency increases, the engineering leader’s role evolves toward translation and integration.

This translation includes:

Commercial urgency into technical feasibility
Regulatory requirements into implementation scope
Architectural constraints into business timelines
Operational risk into product decisions

Each department operates under distinct incentives. Sales may optimize for quarterly revenue. Product may optimize for feature velocity. Security may optimize for risk minimization. Finance may optimize for cost predictability.

Research on organizational misalignment suggests that cross-functional friction increases when incentive systems are not synchronized, for example Harvard Business Review has documented how siloed performance metrics create coordination inefficiencies.

Meaning engineering leaders must therefore create shared decision principles that align incentives around system-wide outcomes rather than local optimization. Without a structured translation, engineering becomes reactive.

Finite Capacity in a System of Expanding Demand and its Cognitive Fallout

One of the defining characteristics of engineering dependency is simultaneous urgency. Growth initiatives, enterprise deals, compliance obligations, reliability improvements, and platform modernization all present as high priority.

However, engineering throughput is bounded. The Theory of Constraints, introduced by Eliyahu Goldratt, provides a useful systems lens: in any production system, throughput is limited by its bottleneck. In software organizations, engineering frequently becomes that constraint.

Empirical research reinforces this. The DORA research program highlights that elite-performing teams focus on improving flow efficiency and limiting work in progress rather than maximizing parallel initiatives. Organizations that attempt to advance too many simultaneous priorities experience degraded delivery performance.

When engineering is everyone’s dependency, the leadership challenge shifts from evaluating importance to sequencing work deliberately.

As dependency increases, so does coordination load. Research on “collaboration overload” shows that high-performing individuals often become central nodes in communication networks, leading to disproportionate demand on their time.

Engineering leaders frequently occupy these central positions. Their involvement is requested in roadmap alignment, incident reviews, enterprise negotiations, hiring decisions, governance discussions, and architectural trade-offs. Yet deep technical and strategic thinking requires sustained focus.

Additionally, studies on multitasking and context switching in cognitive psychology demonstrate measurable declines in efficiency and increased error rates when individuals switch frequently between tasks.

If unmanaged, structural dependency can erode strategic bandwidth. Leaders become responsive rather than directional.

Dependency as Organizational Leverage

Dependency is not inherently a liability. It is a form of leverage. However, leverage does not imply universal ownership.

A common failure in scaling organizations is conflating technical dependency with total accountability. Because engineering enables execution, other functions may gradually transfer policy, risk, or coordination ownership to engineering. Over time, engineering becomes the default owner of decisions that properly belong elsewhere.

Effective governance requires explicit distribution of ownership:

Security owns policy and risk appetite.
Compliance owns regulatory interpretation.
Product owns prioritization intent.
Commercial functions own revenue commitments.
Engineering owns architecture, implementation, and system integrity.

Engineering is frequently consulted, but consultation is not equivalent to full domain ownership.

Collaborative research further demonstrates the risk of concentration. Studies on collaboration overload show that central actors absorb disproportionate coordination demand.

Without structural safeguards, clear intake processes, explicit decision rights, work-in-progress limits, and capacity visibility, leverage degrades into overload.

Conclusion

Engineering centrality is not a theoretical claim; it is an observable structural feature of modern enterprises. As revenue, compliance, and operations become software-mediated, engineering performance directly influences business outcomes.

Research across DevOps performance (DORA), digital transformation (McKinsey), collaboration science (Harvard Business Review), and cognitive psychology converges on a consistent finding: unmanaged demand and ambiguous ownership reduce organizational effectiveness.

Sustainable leverage requires defined interfaces.

Engineering enables execution across domains, but accountability must remain with their respective functions. When ownership boundaries blur, coordination load concentrates, context switching increases, and system performance degrades.

Engineering is a core operating layer of a company, and its effectiveness depends not only on technical excellence but also on governance design that balances central integration with distributed accountability.

I Couldnt Write While I Was Paying the Tax

Alvaro — Sat, 25 Apr 2026 12:57:22 +0000

For almost a year, I didn’t publish anything. Not because I didn’t have opinions. Not because I stopped caring. But because I was struggling.

I was navigating the same things I was trying to write about:

Scaling pressure.
Coordination overload.
Process multiplying faster than value.
The quiet emotional weight of leadership.

And I found it hard to give recommendations while I was still inside the fog. It felt dishonest to write “how to lead clearly” when I was figuring it out myself. So I stopped.

Over this last year, something clicked. The problem wasn’t a lack of ideas. It was that I was trying to write about leadership as if it were clean and structured.

It isn’t.

Engineering leadership at scale is messy. It’s trade-offs. It’s governance creep. It’s explaining why output isn’t outcome. It’s protecting teams from becoming process administrators. It’s absorbing pressure so others can build.

That’s when the name became obvious.

This newsletter is no longer Leadshorizons.

It’s now:

The Engineering Tax

Because that’s what I’ve been living.

The tax of coordination. The tax of growth. The tax of AI hype. The tax of emotional load. The tax nobody budgets for.

This is not a newsletter about perfect frameworks.

It’s about:

The real cost of scaling engineering
Revenue per person over vanity metrics
AI as leverage, not magic
Leadership under cognitive and political pressure
And the uncomfortable truths we don’t post about on LinkedIn

If you’re leading engineering in a growing company, you’re paying the tax already.

The question is, are you aware of it? And are you getting a return?

I’m writing again — not because I figured everything out. But because I’ve lived enough of it to speak honestly.

Welcome to The Engineering Tax.

Are We Providing Feedback or Something Else

Alvaro — Sat, 25 Apr 2026 12:54:11 +0000

Feedback is often called a gift, and indeed it's a powerful tool for improving our behaviors. This article won't cover how to provide feedback or various feedback methods, as these topics have been extensively covered elsewhere. Instead, I want to explore a key question: are we truly providing feedback when we claim to be?

Definition of feedback

Let's take the definition from wikipedia:

Feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause and effect that forms a circuit or loop. The system can then be said to feed back into itself.

This type of feedback requires an event to occur before it can become an input for future iterations. In human interactions, we typically think of Corrective feedback:

A practice that typically involves a learner receiving either formal or informal feedback on their understanding or performance on various tasks by an agent such as teacher, employer or peer(s). To successfully deliver corrective feedback, it needs to be non-evaluative, supportive, timely, and specific

While this sounds great, it’s not always a silver bullet.

The weak point of feedback

While this definition seems straightforward, complexity arises when two or more parties engage in conversation. A feedback system emerges, creating a snowball effect through the conversation's cause-and-effect nature:

Simple causal reasoning about a feedback system is difficult because the first system influences the second and second system influences the first, leading to a circular argument. This makes reasoning based upon cause and effect tricky, and it is necessary to analyze the system as a whole. As provided by Webster, feedback in business is the transmission of evaluative or corrective information about an action, event, or process to the original or controlling source.

— Karl Johan Åström and Richard M.Murray, Feedback Systems: An Introduction for Scientists and Engineers

We can represent this with the next graphic:

This dynamic often leads to a situation where the feedback provider includes their personal views on the receiver's output, introducing bias or prejudice into the system. As a result, what should be feedback becomes merely an opinion or judgment.

The difference between Feedback, Judgment & Opinion

While we've defined feedback, there are related concepts that often get confused with it:

Opinion: An opinion reflects a perspective or feeling about something, often based on personal beliefs, experiences, or interpretations. Unlike feedback or judgment, opinions are subjective and can vary depending on the individual's circumstances or emotions. Opinions are less formal and more likely to be influenced by personal viewpoints rather than objective analysis.
Judgment: Judgment involves evaluating situations, analyzing information, and making decisions based on reasoning or experience. It is often based on facts, logic, and critical thinking, but it's also influenced by personal biases, emotions, or values. Judgment is more structured and reasoned compared to an opinion.

As humans, we find it challenging to provide pure feedback, since we're not machines. Our own biases and prejudices influence our input. When communicating, we tend to over-explain and insert our views about what the next iteration should be.

Ensure feedback remains untainted by the observer's perspective

Like many complex problems, the solution lies in simplification. Here, we can remove layers of bias and prejudice by leveraging the recipient's capacity for self-reflection.

Why this approach avoids bias:

Neutral perspective: Reflection allows you to observe the situation and the person's reaction without pre-judging or assigning blame.
Person focus: You prioritize their feelings, intentions, and growth over your own insecurities.
Fairness: The feedback is shaped by understanding rather than simply critiquing.

This approach creates a safer environment for growth while ensuring that feedback remains genuine and less influenced by personal biases. This reflective practice also encourages the person receiving 'feedback' to take ownership of their learning.

Final Thoughts

Feedback is often celebrated as a powerful tool for growth, but its true effectiveness depends on how it’s delivered. While some may claim to provide feedback, the focus on feelings, fairness, and authenticity can make all the difference in fostering genuine improvement. By prioritizing understanding over critique, we create safer spaces for learning and ensure that feedback remains meaningful and impactful. Ultimately, the best feedback empowers individuals to take ownership of their development while encouraging continuous progress.

With this said, I am not good at feedback. I also try not to claim that I provide feedback to others. The fact of pushing thoughts to others is itself a selfish thing. If you really care, ask the person to reflect on the situation and explore their own self-awareness.

👋 Let’s connect

You can find me on LinkedIn, Bluesky, or Mastodon.

I share daily tips to level up your skills and become a better manager.

You can also hit the like ❤️ button at the bottom to help support me or share this with a friend. It helps me a lot! 🙏

Transforming Systems Operations Teams into a Unified Platform Team

Alvaro — Sat, 25 Apr 2026 12:53:59 +0000

Over the last months, I've witnessed firsthand the transformation of my team from a basic operation provider to an internal service provider.

In many organizations, systems operations teams are often segmented into specialized units such as DBA, backend operations, networking, etc. While this specialization ensures deep expertise and support to teams in complex situations. It also leads to inefficiencies as it focuses on the reactiveness to the needs of the teams & company and not a proactive approach towards the same long-term needs due to the lack of common vision. It also has the drawback that enforces the dev vs ops culture and not a DevOps culture that has shown over and over again the positive effect on quality and speed of delivery of stream-aligned teams.

’DevOps’ or ‘Dev vs Ops’

Traditionally, Dev and Ops teams have operated in silos, each with their own distinct goals and priorities.

Focus Priorities Dev Culture Development teams are primarily focused on creating new features, writing code, and ensuring the software meets user requirements. Speed and innovation Ops Culture Operations teams are responsible for maintaining the stability, security, and performance of the software in production environments. Reliability and uptime

This separation can lead to several challenges:

Communication Barriers: Lack of communication between Dev and Ops can result in misunderstandings and delays. Developers may not fully understand the operational constraints, while Ops may struggle with the rapid pace of development.
Conflicting Goals: Developers prioritize speed and innovation, while Ops prioritize stability and reliability. These conflicting goals can create friction and hinder collaboration.
Inefficiencies: Siloed teams often duplicate efforts and use different tools, leading to inefficiencies and wasted resources.

The DevOps Solution

The goal of DevOps is to create a culture of ownership to stream aligned teams to do development and operations, breaking down traditional silos and fostering a more integrated approach to software delivery. While the existing operations teams become a provider of abstractions that simplifies that work, reducing the cognitive load of operating the system.

This brings the next benefits:

Enhanced Collaboration: Breaking down silos fosters a culture of collaboration, enabling teams to work together more effectively and share knowledge.
Improved Efficiency: Streamlined workflows and standardized tools reduce redundancy and improve operational efficiency.
Greater Innovation: A unified approach allows teams to quickly adapt to new technologies and methodologies, driving innovation and continuous improvement.
Customer-Centric Approach: By aligning development and operations goals, teams can better understand and meet the needs of end-users, resulting in higher customer satisfaction.

The Birth of the Platform Team

A platform team acts as a service provider for all internal stream-aligned teams, offering essential tools, infrastructure, and support to streamline their work and enhance productivity. We could start enumerating systems and solutions that a platform team can own. But the reality is that would be the same as creating a product without doing any research on your clients.

To truly drive value within an organization, a platform team must deeply understand and address the needs of stream-aligned teams. These teams are directly responsible for delivering products and services to customers, and their success hinges on the support and resources provided by the platform team. Here’s how a platform team can effectively drive value by focusing on the needs of stream-aligned teams:

Active Engagement and Communication: work collaboratively with stream-aligned teams to develop solutions that address their specific pain points, fostering a sense of shared responsibility and mutual support.
Continuous Improvement and Innovation: Implement iterative development practices to continuously refine and improve tools and services.
Metrics and Performance Tracking: Establish key performance indicators (KPIs) to measure the effectiveness of the platform team’s support and use data-driven approaches to make informed decisions about resource allocation and process improvements.
Empowerment and Autonomy: Develop self-service platforms that empower stream-aligned teams to manage their own resources and workflows, and provide comprehensive training and support to ensure proficiency in using the tools and services offered by the platform team.

The key benefits this strategy tries to achieve are:

Efficiency: By centralizing infrastructure management, tooling, and support, the platform team reduces redundancy and improves operational efficiency. Stream-aligned teams can focus on delivering value to customers without worrying about underlying infrastructure.
Consistency: Standardized tools and processes ensure consistency across the organization, making it easier to manage and scale applications.
Reliability: A dedicated platform team ensures that the infrastructure is reliable and secure, minimizing downtime and enhancing the overall stability of applications.

Closing thoughts

By fostering a culture of ownership and collaboration, and by providing abstractions that simplify operations, the platform team can significantly reduce the cognitive load on stream-aligned teams. This transformation brings enhanced collaboration, improved efficiency, greater innovation, and a customer-centric approach, ultimately driving the success of the organization.

As we continue to evolve, the key to driving value lies in deeply understanding and addressing the needs of stream-aligned teams. Through active engagement, continuous improvement, metrics tracking, and empowerment, the platform team can ensure that stream-aligned teams are equipped to deliver exceptional products and services to our customers. This strategy not only centralizes infrastructure management and standardizes tools but also ensures reliability and consistency across the organization, paving the way for sustained growth and success.

Job Probation Period A Two Way Street For Success

Alvaro — Sat, 25 Apr 2026 12:53:37 +0000

Dear readers, I am back. It has been a few “interesting” months in my life that have made me reflect a lot on some topics that before I thought were trivial, and one-sided. I will try to share some thoughts over the next few posts. So let's start with a subject that is really fresh in my mind, as it's what has been affecting me over the last few months.

To the question “During your career, did to pass a Job probation period?” the most common answer will be “Yes”. Traditionally, it is viewed as a tool for employers to evaluate potential hires, nevertheless it's crucial to recognize that these periods serve a dual purpose. They are, in fact, a two-way street that benefits both employers and employees alike.

Leads Horizons is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

What is in for Us?

The probation period is an evaluation period, it can even be seen as an extension of the interview process, as you will never get to know a person you will spend most of your awake workday day with.

With this in mind, the same as in interview, we need to remember is not a one-sided evaluation, Employers should evaluate ROI & employees should evaluate company fitness.

From an employer's standpoint, probation periods offer several advantages:

Skill Assessment: Employers can evaluate a candidate's practical skills and how they apply their knowledge in real-world scenarios.
Cultural Fit: It provides an opportunity to assess how well the new hire integrates with the existing team and company culture.
Performance Evaluation: Employers can gauge the employee's productivity, work ethic, and ability to meet deadlines.
Risk Mitigation: If the employee doesn't meet expectations, the company can part ways with minimal legal and financial implications.

Equally important, but often overlooked, is the employee's perspective on probation periods:

Company Culture Experience: Employees can immerse themselves in the company culture and determine if it aligns with their values and work style.
Job Satisfaction Assessment: It allows individuals to evaluate if the role meets their expectations and career aspirations.
Team Dynamics: Employees can assess how well they work with their colleagues and immediate supervisors.
Work-Life Balance: The probation period offers insight into the company's approach to work-life balance and flexibility

Maximizing the Probation Period

To make the most of a job probation period, both parties should approach it with openness and clear communication:

Set Clear Expectations: Employers should outline specific goals and performance metrics for the probation period.
Regular Feedback: Implement a system for frequent, two-way feedback to address concerns and acknowledge progress.
Encourage Questions: Create an environment where the new hire feels comfortable asking questions and seeking clarification.
Provide Necessary Resources: Ensure the employee has all the tools and information needed to perform their job effectively.

To achieve this, we need to use the correct tools for the job

Onboarding Plan

An effective onboarding plan should contain:

Comprehensive introduction: Include an overview of the company's culture, policies, and procedures.
Role-specific training: Provide training tailored to the new employee's specific job responsibilities.
Introduction to team and colleagues: Facilitate meetings with team members and key personnel.
Resource provision: Ensure the employee has all necessary tools and information to perform their job effectively.
Assign a buddy: pair the employee with a more experienced colleague who can provide informal guidance and support that can help navigate the day-to-day aspects of the job.
Assign a mentor: pair the employee mentor is usually a more senior employee who can provide guidance, share industry insights, and help them grow in their role over a longer period.
Regular feedback sessions: as a manager, schedule frequent check-ins to address concerns and acknowledge progress.

A well-structured onboarding plan helps new employees quickly integrate into their roles and the organization, reducing the learning curve and increasing productivity during the probation period.

30-60-90 Plan

A 30-60-90 plan is a strategic framework used for onboarding new employees or setting goals for the first 90 days in a new role. It breaks down objectives and expectations into three distinct periods:

30 days: Focus on learning and understanding the role, company culture, and immediate responsibilities.
60 days: Begin contributing more actively, implementing initial strategies, and identifying areas for improvement.
90 days: Fully integrate into the role, start driving results, and propose long-term strategies or improvements.

This plan helps structure the transition period, ensuring clear expectations and measurable progress for both the employee and the employer during the probation period, with a framework that can help focus the feedback and

Evaluation of the outcome of a probation period

Pass

When a probation period results in a successful outcome, it's important to celebrate this achievement. Both the employer and employee should acknowledge the positive experience and use it as a foundation for future growth.

This is an opportunity to set new goals, discuss career development plans, and reinforce the mutual commitment to success. A successful probation period can lead to increased motivation, job satisfaction, and a stronger sense of belonging within the organization.

No Pass by Employer

If an employer decides not to continue the employment relationship after the probation period, it's crucial to handle the situation professionally and sensitively.

The employer should provide clear, constructive feedback about why the probation was unsuccessful, focusing on the root cause without personal criticisms. This feedback can be valuable for the employee's future career development.

Additionally, the employer should ensure all legal and contractual obligations are met, including any notice periods or severance pay if applicable. Treating the departing employee with respect and dignity during this process is not only ethical, but also maintains the company's reputation as a fair employer.

No Pass by Employee

When an employee decides not to continue after the probation period, it's equally important to handle the situation professionally.

The employee should provide honest feedback about their experience, highlighting any misalignment or concerns that led to their decision. This feedback can be valuable for the employer to improve their onboarding process or workplace environment.

The employee should also ensure they fulfill any contractual obligations, such as providing proper notice.

Conclusion

Job probation periods are an opportunity for both parties to evaluate the potential for a long-term, mutually beneficial relationship. By approaching these periods with transparency, open communication, and a willingness to learn, both employers and employees can make informed decisions about their future together.

This period should not be demonized, even if it ends in a “No Pass”, it should be taken as a good outcome as it's a relationship that would have most probably failed, or would create friction and other risks down the road when legal obligation from both sides are more complex. If you're the employee, remember this is not a failure. Your worth remains unchanged—it simply wasn't the right fit or timing. If you're the employer, don't be too hard on yourself. Not all relationships work out. The best approach is to move forward and end things on the best terms possible.

I Am Back

Alvaro — Sat, 25 Apr 2026 12:52:55 +0000

Hello Everyone, I want to apologize for this hiatus that I had to take as writer of leads horizons. I have delayed most of the posts and ideas I had to share with all of you. I will resume my writing activities next week, so I am looking forward to any feedback you can/what give me. To give some context, the hiatus was to handle my mental health, and make some changes that will help me move toward my goals and personal happiness. I would like to personally thanks my wife for being a great support all this time 🙏. I want to also say thanks to everyone who is subscribed to the newsletter or reads independently in substack for your support. To show my appreciation, I will add a complimentary subscription to everyone. Thanks again for your support & reading this newsletter, Regards, Alvaro