Management manifesto v3.0
Technical View.
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 how I think about technology, capital, and organizations. They stay constant while evidence refines them.
Engineering is part of the business
Engineering is not a brainless feature factory: it must speak the business language to be effective. Every technological decision has a direct impact on the ROI.
It means
DORA and DX metrics are telling you the status of your team. Looking at the business KPI makes you a manager: let your team work to improve them.
Technical Deep Dive: no metrics is better than vanity metrics
Engineering is capital allocation
Engineering decisions carry both a direct cost and an opportunity cost; technical debt is like financial debt: there is good debt and bad debt. I act as a steward of technical capital; Engineering must speak the language of the CFO.
Sounds cool, but…
Solution cost ≠ time × employees_salary
Just add the missed revenue in the time you develop the solution. And it’s here where you really understand how much debt to add to buy time.
Technical Deep Dive: Engineering is capital allocation: the build-it-ourselves ego
Antifragility through risk exposure
Obsessive stability breeds fragility. Organizations need technical antibodies developed through controlled experimentation and exposure to disorder at the edges. Eliminating all risk leads to stagnation and systemic collapse when a "Black Swan" event occurs.
TL;DR
Stop standardizing everything!
Allow systems to fail in production! (just make sure your system is able to survive a failure)
Embrace innovation coming from your team.
Technical Deep Dive: The standardization trap: why your ‘perfect order’ is making the team fragile
Hierarchy is latency
Every management layer or coordination role adds exponential latency to decisions. It also degrades decision quality because information value decreases at every step of the chain. I build for speed by pushing decisions to the edge.
It’s a long story, you can read it here
Technical Deep Dive: Hierarchy is a latency bug: why adding managers destroys velocity
Software as a disposable commodity
Cloud, AI… it’s easy to ship now. The code is a liability, not an asset. Every line written is a debt to be maintained. I architect for malleability: the goal is to build systems simple enough to be deleted and rewritten. Time to market and agility take precedence over code permanence.
In practice
Avoid premature optimizations, no cathedrals.
Spend time to make your system components very simple and easy to be replaced instead of making them “ready to everything”.
Technical Deep Dive: The collapse of code cost: why AI is a structural accelerator, not magic
Stay light
I prefer guardrails and principles over rigid standards and fixed rules. I promote fewer processes and less bureaucracy. No cages, no micromanagement. Use a barbell approach.
What does it mean?
Put your energy (standard, processes…) on the 20% of the things; the most critical ones.
On the remaining 80% it creates more damage a strict standard than an eventual failure. (Costs are the only guarantee in every investment)
Principled Autonomy
I lead through shared principles and high-level guardrails. This approach provides the necessary alignment for large organizations while preserving the cognitive freedom of the individual. I favor lightweight governance that enables the team to navigate complexity with high autonomy.
Nice words, but… how?
It’s simple: everyone must follow same objectives (the business KPI), sharing the same value-set (the principles), protected by the guard rails (a very permissive grid of rules), with agency on its choices. It pushes to the sky the skin in the game, the quality, the results.
Technical Deep Dive: People as the foundation: why demotivation kills projects and how to avoid it
Minimal Effective Complexity
Simplicity is an active engineering achievement, not a lack of ambition. I view complexity as the natural state of a growing system (entropy) and I commit to the constant effort required to reduce it. I prioritize elegant, straightforward solutions that preserve long-term optionality.
It sounds familiar
Yes, it’s the other face of the point #6.
Removing it makes your system components under control and disposable.
Layer 02 Operating model
The rules of engagement for my teams. These protocols turn strategy into execution with speed and accountability.
Ownership through Skin in the Game
We do not believe in external quality assurance or ivory-tower architects. The team that designs a solution owns it in production. We maintain high talent density by giving Builders total responsibility for their outcomes. We know that the best decisions come from those with the highest ownership.
Managed Autonomy (The Paved Road)
We standardize the output but liberalize the "how." We build "Golden Paths" (highways) that are so efficient and frictionless that teams choose to follow them for convenience rather than being forced to by mandate.
Deterministic Communication
Alignments are a cost to be minimized. We prioritize asynchronous protocols (written documentation, decision records) over synchronous meetings. No agenda means no meeting. If we feel the need for a new process, we assume the underlying organizational or architectural problem remains unsolved.
Business-Centric Topology
Engineering success is measured by Business KPIs, not technical metrics. Teams are structured around product domains with clear, non-overlapping mandates. If a team does not understand the economic impact of their work, they are working on the wrong thing. This alignment is what enables bottom-up decision making.
Radical Pragmatism
We reject architectural cathedrals. We prioritize the 80% solution today over the "perfect" system next year. Every technical decision is weighed against its "Cost of Change." If a process or tool does not directly enable delivery, we delete it.
Absolute Technical Integrity
We prioritize technical reality over social or political comfort. We exchange unfiltered feedback based on facts. We maintain the health of the system by being radically honest about its limitations and its debt, ensuring our architecture remains a reliable asset for the business.