Management manifesto v3.0
Technical Truth.
Business Economics.
Leading engineering as a value engine. A map of the beliefs that remain constant when the stack changes, and the operating model I use to make them real.
Layer 01 Core philosophy
Foundational principles that underpin my approach to technology, capital, and organizational physics. These are constant, yet evolve with new evidence.
Engineering is a capital allocation
An engineering department is a portfolio of high-risk investments, not a feature factory.
The true cost of software is never just the developers’ salaries. The real cost is the
opportunity cost of diverting top talent away from the core business. Rebuilding non-core
products internally is capital destruction. The ultimate seniority of a technical leader lies
in knowing exactly what not to build.
Read more
Software is a disposable commodity
Software is not an asset. Every line of code written is a liability and a maintenance debt
until it delivers measurable business value. Architecture must be designed for malleability
rather than eternity. If a component cannot be deleted and rewritten in 48 hours without
breaking the company, you do not own the software. The software owns you.
Read more
Technical debt is financial leverage
Technical debt is exactly like financial debt. Bad debt is over-engineering a system for
hypothetical future problems, acting like a consumer buying luxuries on credit. Good debt is
shipping a “roughly correct” solution today to validate a market and generate revenue,
leveraging time to beat competitors. A Value Engineer knows how to calculate the interest rate
of every technical compromise.
Read more
Technical truth over corporate alignment
Systems do not lie. Hierarchies do. Engineering is the search for the most objective and
efficient solution to a reality-based problem. Supporting a flawed architectural decision
simply to appease the ego of a senior executive or to maintain corporate alignment is
organizational debt. My role is to protect the business from political decisions disguised as
technical strategies.
Read more
Hierarchy is decision latency
Every layer of management added to an organization is a millisecond of delay injected into the
system. Information distorts and velocity collapses when operational choices are forced up a
chain of command to executives who lack context. Management should remove friction, not add
control. Decisions must be isolated and executed at the lowest possible edge of the hierarchy.
Read more
Continuous collaboration is an architectural bug
If two teams must constantly schedule alignment meetings to release a feature, the organizational
design has failed. True scalability is achieved through complete decoupling, which I call
Organizational Mitosis. Teams should not be forced to “collaborate” continuously. They must
communicate asynchronously through clear API contracts, maintaining absolute autonomy over their
perimeters.
Read more
Standards are insurance policies, not cages
Obsessive standardization shuts down the brains of senior engineers and creates single points of
failure. Standards are insurance policies. We pay the premium of slower velocity only for
catastrophic risks like Security and Compliance. For everything else, we use the “Paved Road”
approach. We strictly standardize the output (contracts, observability, logs) and liberalize the
input (how the team implements the solution).
Read more
Anti-fragility requires risk exposure
The obsession with absolute stability creates systems made of glass. If you protect a team from
every possible error through rigid rules, endless reviews, and committees, you strip them of
their organizational antibodies. At the first unexpected event, the structure collapses.
Controlled chaos at the edges of the system is the only way to find innovative solutions and
build true anti-fragility.
Read more
Business KPIs are the only engineering metrics
Measuring the “means” instead of the “goal” destroys value. Using proxy metrics like lines of
code, hours logged on Jira, or mandated AI usage quotas creates a measurement theater where
engineers game the system to satisfy management. Engineering is an arm of the business. Teams
must be structured around clear, measurable business outcomes. You tell the team where to go, not
how to get there.
Read more
Incompetence masquerades as process
Whenever a company introduces a heavy, new bureaucratic process, it is a signal of a
fundamental lack of trust or competence. Processes are often added to constrain mediocre
performers, but they end up chaining the top performers. A lean organization solves problems by
increasing talent density and accountability, not by adding paperwork.
Read more
M&A assimilation destroys the asset
When a corporation buys a scale-up, it buys speed and innovation. Forcing the acquired company to
adopt the legacy processes, rigid standards, and heavy infrastructure of the holding company
intentionally destroys the very engine that was just purchased. Integration must happen at the
edges (data, finance), never in the core delivery process, or the true builders will leave.
Read more
The agentic shift and syntax collapse
Artificial Intelligence is driving the marginal cost of syntax to zero. The competitive advantage
is no longer writing the perfect function. The value has shifted entirely to system architecture,
context curation, and the orchestration of autonomous agents. The engineering leader of the
future does not manage typists; they orchestrate systems.
Read more
Layer 02 The operating model
These are not suggestions. They are the non-negotiable rules of engagement for my teams.
Autonomous teams & skin in the game
We do not treat engineers as assembly-line workers waiting for task assignments. We drive teams
with business objectives, KPIs, clear context, and hard guardrails. We never dictate the technical
solution from the top down. We foster bottom-up implementation because true ownership—“you
build it, you run it”—is the only scalable form of quality assurance. We do not micromanage; if
micromanagement feels necessary, either the hiring process or the architecture has already failed.
Read more
Guardrails and principles over processes and standards
Rigid standards create a false sense of predictability, but their true cost is that they switch
off brains. When you dictate exactly how every problem must be solved, you demotivate your most
competent people. We prefer principles and guardrails: they reduce cognitive load and prevent
catastrophic failures (security, compliance) while keeping teams actively thinking, accountable,
and responsible for their own technical debt.
Read more
Pragmatic solutions over academic perfection
We operate in reality, not in a textbook. We aggressively avoid premature optimization and the
construction of “architectural cathedrals” designed for a 10-year horizon that will never arrive.
We must maximize the technical ROI, not the complexity of the solution. Solution malleability—the
ability to delete and rewrite a module in 48 hours—always beats theoretical or academic perfection.
Read more
Boundaries over dependencies, contracts over collaboration
Continuous cross-team collaboration is a symptom of a broken organizational design. While
communication is fundamental, we design our systems and our teams for strict boundaries. We
prefer API contracts over alignment meetings. If two teams must constantly talk to release a
feature, we haven’t built an agile organization; we’ve built a distributed monolith with human
latency.
Read more
Ruthless efficiency (no agenda, no meeting)
Alignments and sync meetings are an operational cost, and we treat them as such: we minimize them.
Asynchronous communication (RFCs, ADRs, documentation) is the default state. If a meeting is
required, it must have a predefined agenda, a clear decision to be made, and the absolute minimum
number of participants. If we are spending more time talking about the work than doing the work, we
are failing.
Read more
Business KPIs are our KPIs
We are not an isolated IT silo operating in a vacuum. We are a core business unit. Engineering
success is not measured by story points, lines of code, or the number of microservices deployed. It
is measured entirely by business impact: conversion rates, latency reduction, operational cost
savings, and revenue generation. If a technical initiative does not move a business metric, it is
expensive hobbyism.
Read more
If we need a process, the problem to solve is another
Processes are usually invented to constrain mediocre performers or to patch over a lack of trust,
but they end up chaining the top performers. Whenever the organization feels the sudden urge to
invent a new process, a new interaction protocol, or a new reporting matrix, we stop. We assume the
underlying problem is organizational (wrong team topology) or architectural (coupled systems). We fix
the root cause; we do not add bureaucracy.
Read more
We love changes and differentiation (anti-fragility)
We embrace uncertainty and diverse approaches across different teams. The obsession with absolute
stability produces fragile, crystal-clear systems and lowers the bar for engineering talent. We want
teams to experiment, to make controlled mistakes, and to build organizational “antibodies.” It is
through the multitude of experimentation at the edges of the organization that we find the winning
solutions. We do not fear the chaos of innovation; we fear the stagnation of uniform mediocrity.
Read more
Technical truth is more important than politics
Systems do not lie; hierarchies do. Engineering is the pursuit of the most objective and efficient
solution to a reality-based problem. We do not support flawed architectural decisions simply to
appease the ego of a senior executive or to maintain comfortable corporate alignment. We prioritize
the physical reality of the software over social comfort. Politics is technical debt, and we refuse
to pay interest on it.
Read more