Por Qué Construí Mi Práctica Autoral (Y Hacia Dónde Vamos)

"La consultoría debería ser transferencia de capacidad, no creación de dependencia."

Después de más de 15 años trabajando en la trinchera de la tecnología, pasando por infraestructura tradicional, DevOps, arquitectura en nube, ingeniería de datos, FinOps y ahora sistemas de inteligencia artificial, identifiqué un patrón estructural que me incomodaba profundamente en el mercado tradicional de servicios técnicos.

La mayoría de las operaciones crea dependencia deliberada.

En la economía clásica, este fenómeno se conoce como el problema de agencia (principal-agent problem): cuando quien presta el servicio gana por hora asignada y por contrato prolongado, el incentivo financiero oculto pasa a ser complicar la arquitectura, esconder el conocimiento en cajas negras y dejar a la empresa cliente siempre necesitando un aditivo más para mantener el sistema en pie. Puede ser lucrativo a corto plazo para quien vende horas, pero es destructivo y antiético a largo plazo para quienes necesitan construir un negocio saludable.

Este artículo no es un panfleto comercial. Es una carta abierta y un manifiesto de ingeniería aplicada sobre por qué estructuré mi práctica ejecutiva y editorial en Cesar Zanis (incluyendo este cuaderno abierto de ensayos, análisis y estudios) y cuáles principios innegociables guían mi trabajo.

La Paradoja de Solow y por qué "entregar código" no basta

En 1987, el economista ganador del Premio Nobel Robert Solow acuñó una frase que persigue a los directores de tecnología hasta hoy: "Vemos las computadoras en todas partes, excepto en las estadísticas de productividad". Décadas después, el profesor Erik Brynjolfsson (del MIT y de la Universidad de Stanford) explicó el motivo de este fenómeno en el estudio The Productivity J-Curve (2021).

Brynjolfsson demostró que comprar tecnología de punta (ya sea nube, bases de datos modernas o modelos de IA) genera casi cero ganancia de productividad si no viene acompañada de capital intangible: rediseño de procesos, documentación viva, gobernanza clara y capacitación real de las personas que operan el negocio todos los días.

Cuando una consultoría externa entra en una empresa, construye un sistema hermético que nadie de la casa entiende y se va llevando el contexto en la cabeza, entrega el software, pero retiene el capital intangible. Al día siguiente, el equipo interno no puede evolucionar una línea sin pedir socorro.

La filosofía de actuación: transferir capacidad real

Mi actuación ejecutiva nació a partir de una premisa opuesta: entregar capacidad instalada y autonomía, no solo ejecución tercerizada.

En la práctica de la ingeniería, asumir este compromiso significa cuatro disciplinas diarias:

• Documentar obsesivamente: las decisiones de arquitectura, los motivos de elección, los límites de costo y los manuales de operación quedan registrados de forma cristalina para quienes se quedan;
• Entrenar a los equipos internos lado a lado: usar el proyecto real como escuela abierta para que los ingenieros y analistas de la propia empresa dominen la solución;
• Construir para disminuir la dependencia: el verdadero indicador de éxito de una intervención técnica es que el equipo interno necesite cada vez menos apoyo externo para mantener y evolucionar lo que fue construido;
• Orientar el trabajo por resultado, no por reloj fichador: medir el valor por el impacto entregado en el margen, en la estabilidad y en la velocidad del negocio, y no por la cantidad de reuniones acumuladas en el mes.

Para quien mira solo la planilla del trimestre, enseñar al cliente a caminar con sus propias piernas parece contraintuitivo. En la vida real, sin embargo, la confianza funciona a interés compuesto: las organizaciones que ganan autonomía real se convierten en aliadas a largo plazo. Vuelven cuando deciden enfrentar un desafío aún mayor, recomiendan con los ojos cerrados y construyen relaciones basadas en el respeto técnico.

Los tres pilares que guían cada decisión

Toda arquitectura que diseño y todo texto que publico aquí pasan por tres filtros simples:

1. ROI por encima de la vanidad técnica

Alineado con los principios de economía unitaria de la FinOps Foundation, todo proyecto necesita comenzar con una pregunta honesta: "¿Cuál es el retorno esperado de esta iniciativa y cómo vamos a medir si se pagó a sí misma?". Si no podemos responder a esto con claridad antes de escribir la primera línea de código, el mejor consejo técnico es no comenzar.

2. Pragmatismo antes que purismo

No existe premio en el balance financiero para la arquitectura más compleja o para la herramienta que acaba de volverse tendencia en una conferencia. Como comprueban años de investigaciones del programa DORA, los sistemas esbeltos, comprensibles y fáciles de mantener vencen a las catedrales tecnológicas rígidas. A veces, un script bien probado y una base de datos relacional bien indexada resuelven en tres días, por una fracción del costo, lo que un conglomerado de microservicios tardaría seis meses en entregar.

3. Las personas están siempre en el centro

La tecnología nunca es un fin en sí misma; es una palanca. El objetivo final de cualquier buena ingeniería es siempre mejorar la vida concreta de alguien: sacar al analista del trabajo manual repetitivo, permitir que el desarrollador duerma en paz el fin de semana sin falsas alertas y entregar una experiencia rápida y confiable al usuario final.

Hacia dónde vamos: IA pragmática y conocimiento abierto

En los próximos años, mi foco técnico e intelectual está concentrado en la intersección entre agentes autónomos de IA, ingeniería de datos y eficiencia operacional (FinOps). No por el ruido del mercado, sino porque es donde veo la mayor oportunidad de nuestra generación para destrabar la productividad real de las empresas, siempre que sea aplicada con rigor matemático y control de costos.

Al mismo tiempo, decidí transformar este espacio en un cuaderno público de ingeniería, economía y liderazgo. La idea detrás de los artículos, estudios de caso y análisis que publico aquí es directa: incluso un profesional, estudiante o gestor que nunca tenga ninguna relación comercial conmigo debe poder leer un texto, encontrar datos verificables y aplicar algo útil en su propia trinchera el lunes por la mañana.

Una nota personal

Podría haber seguido el camino más cómodo: permanecer en una gran corporación, con salario previsible, alcance protegido y problemas ya conocidos. Elegí construir un camino autoral porque creo que quince años tropezando y aprendiendo en la práctica solo tienen sentido si sirven para destrabar a otras personas y organizaciones.

Cada sistema diseñado y cada artículo publicado aquí tienen el mismo propósito: dejar el mercado un poco más lúcido, más técnico y más honesto de lo que lo encontré. Ese es el legado que vale la pena construir.

Continúa profundizando: lee también Ambiente Leve, Equipo Fuerte y El CTO del Futuro: ¿Técnico o Estratégico?. Conoce también la actuación en Liderazgo Ejecutivo y Fractional CTO y nuestros Estudios de Caso.

---

Referencias y lecturas verificables

• Brynjolfsson, E., Rock, D., & Syverson, C. (2021). The Productivity J-Curve: How Intangibles Complement General Purpose Technologies. American Economic Journal: Macroeconomics, 13(1), 333-372.
• FinOps Foundation. FinOps Framework: Principles and Cloud Unit Economics. Linux Foundation.
• DORA (DevOps Research and Assessment). Accelerate State of DevOps Reports. Google Cloud / DORA.