El marco de decisión para CTO que arranca desde la posibilidad de no sobrevivir

El CTO está en un board. El CFO va por la slide 14, partida de infra. 22% del burn. El presidente del board pregunta, en ese tono educado con el que preguntan los board, por qué. El CTO tiene seis buenas respuestas técnicas y cero que traduzcan. La conversación sigue, pero algo se movió. El próximo trimestre le van a pedir que defienda cada línea.

Si sos founder-CTO en Seed o Series A, ya estuviste en alguna versión de esa sala. Las decisiones que tomás sobre arquitectura, vendors, refactors, hires y rewrites ya no son decisiones técnicas — son decisiones de runway vestidas de técnicas. Todo marco de decisión para CTOs que leí asume que la empresa sigue existiendo. En tu etapa, eso no es una asunción segura.

D4S es el marco que uso cuando estoy en esas salas como el DevOps / Solutions Architect que ayuda al CTO a defender una decisión. Cuatro filtros: Differentiation, Dollars, Delight, Defense. Una decisión tiene que pegar significativamente en al menos uno. Si no pega en ninguno, la respuesta correcta es Skip — y Skip es el feature, no un fracaso.

TL;DR

• D4S filtra decisiones técnicas a través de cuatro dimensiones. Una decisión tiene que pegar significativamente en al menos una para ganarse pasar Skip.
• El default es Skip. La mayoría de las decisiones "¿hacemos X?" en Seed–Series A no pasan ninguno de los cuatro Ds y no merecen el trimestre de ingeniería que las costaría.
• El marco está armado para la realidad de las primeras etapas: runway finito. Todo otro marco que leí asume que sobrevivís hasta el año tres.
• Cada D ancla en un resultado distinto: diferenciación defendible, dinero modelable, UX que retiene, riesgo identificado. Si no podés nombrar cuál D estás golpeando, estás racionalizando.
• D4S es más útil cuando tenés que defender la decisión ante un CEO no-técnico o el board. "Hacemos X porque es la única forma de cubrir Defense contra [amenaza compliance específica]" se sostiene. "Es best practice" no.

La pregunta real, y por qué Skip es el default

Los founder-CTOs con los que trabajo no están tratando de decidir si REST o gRPC es técnicamente superior. Están tratando de decidir si el trimestre que su equipo va a gastar en la migración es el mejor uso del trimestre, dado 14 meses de runway y otras cuatro cosas compitiendo por las mismas horas de ingeniería.

La mayoría de los marcos esquivan esto. Evalúan una decisión aislada, por sus méritos técnicos, contra un futuro hipotético en el que la empresa tiene tiempo ilimitado para recuperarse de una decisión errada. Es razonable para Series C. Es el marco equivocado para vos.

La matemática es brutal. Un equipo Seed US de seis personas quema ~USD 450K por trimestre. Un equipo LatAm es USD 60-90K. Sea cual sea, eso es lo que cuesta una decisión trimestral. Si lo gastás en algo que no pega en ningún D, quemaste un trimestre para terminar en aproximadamente la misma posición competitiva.

La respuesta correcta a la mayoría de las decisiones técnicas en tu etapa es no tomar la decisión. Mantené el monolito. Mantené el Postgres. Mantené los deploys manuales. La respuesta aburrida es la correcta mucho más seguido de lo que el ecosistema de blogs de ingeniería implica. D4S existe para que Skip sea el default y las otras respuestas tengan que ganárselo.

Los cuatro Ds, anclados en engagements reales

Una decisión se gana pasar Skip si pega significativamente en al menos uno. No vagamente relacionado. Significativamente.

Differentiation: ¿un cliente la mencionaría en un review?

Diferenciación defendible que los clientes efectivamente sienten. El test: ¿un cliente o prospecto alguna vez mencionaría esto en un review, en una sales call, o como razón para haber switcheado desde un competidor?

Si ningún cliente alguna vez mencionaría tu wire protocol, tu pipeline de CI/CD, la estructura de tu monorepo, o tu elección de ORM — esos no puntúan en Differentiation. Pueden puntuar en Dollars o Defense, pero no diferencian.

La trampa: los ingenieros aman reclamar Differentiation para decisiones internas que los clientes no pueden ver. "Microservicios nos dan mejor autonomía de equipo, que nos deja shippear más rápido, que nos diferencia." Es una cadena de cuatro inferencias optimistas. Si no podés apuntar al resultado visible al cliente al final, no es Differentiation.

Dollars: ¿podés modelar el impacto en plata?

El D más concreto y el que más decisiones fallan honestamente. El test: ¿podés modelar el impacto financiero en dólares o en semanas de runway, con assumptions que alguien del equipo va a defender por escrito?

Cuando era DevOps Manager en GoJiraf, tratamos infra como una decisión de Dollars desde muy temprano. La métrica que hizo funcionar a GoJiraf fue el costo por usuario activo. Pasamos de USD 1,5K/mes de infra con ~1.000 usuarios a USD 2,5K/mes con 50.000 usuarios — 50× de escala a 1,7× el costo. No por un descuento mágico de AWS. Porque cada decisión de infraestructura tuvo que responder: "¿qué nos cuesta esto por usuario, y qué nos ahorra por usuario, a 10× la carga actual?". Las decisiones que no se podían responder así no se tomaban.

Muchas veces no vas a tener números precisos. Está bien. Una aproximación útil, defendida en voz alta, le gana a un número preciso que nadie cree. "Pensamos que esto nos ahorra unos USD 40K/año a escala actual, doblando a 2× escala, acá están las tres asunciones que lo manejan" es un argumento de Dollars. "Nos va a ahorrar plata con el tiempo" no.

Si querés una forma rápida de pressure-testear una decisión que estás considerando ahora, pasala por el diagnóstico D4S — tres minutos, sin registro, te devuelve un veredicto en lenguaje de board.

Delight: ¿el usuario siente la diferencia?

El D más complicado porque es el que los ingenieros más seguido confunden con developer experience. Delight se trata del usuario. Si tu refactor hace que el codebase sea un placer para trabajar pero el usuario no lo nota, no es Delight — puede ser Dollars (mayor velocidad de dev tiene impacto en costo por feature) pero no es Delight.

Delight real se ve así: un checkout que baja de un umbral perceptible de latencia, una búsqueda que devuelve resultados por debajo del umbral de atención humana, un feature que elimina un paso que los usuarios estaban refunfuñando. Los usuarios tienen que notarlo. Si tenés que explicarles qué cambiaste, probablemente no sea Delight.

Defense: ¿estás protegiéndote contra un riesgo identificado y plausible?

Amenazas reales y nombradas — no "best practices" abstractos. El test: ¿podés enunciar el riesgo específico contra el que te estás defendiendo, quién o qué es el actor de la amenaza, y cuál sería el impacto si la amenaza se materializara?

"Necesitamos mejores backups" no es un argumento de Defense. "Nuestra estrategia actual de backup implica que perderíamos unas 4 horas de data transaccional en una falla de región primaria, y nuestro contrato enterprise con [cliente] especifica RPO de 30 minutos" — eso sí.

La trampa: Defense "best practice". "Deberíamos encriptar at-rest porque es best practice" no pasa. "Deberíamos encriptar at-rest porque estamos a punto de arrancar un proceso SOC 2, el auditor lo va a flaggear, y remediarlo durante auditoría cuesta 3× más que hacerlo ahora" — pasa.

Cómo usar D4S sobre una decisión real

Tomá la decisión que estás sopesando ahora mismo. Escribila arriba de un doc. Debajo, escribí cuatro headers — Differentiation, Dollars, Delight, Defense — y debajo de cada uno, escribí la afirmación específica. No la abstracta, la específica.

Si podés escribir una afirmación específica defendible bajo uno o más headers, la decisión se ganó pasar Skip. Si tres de los cuatro dicen "n/a" o "no" y el cuarto dice algo de manos al aire, la decisión es Skip.

El marco no es un score. No es "sumá los Ds y agarrá el número más alto". Cada D es un filtro independiente. Una decisión puede pegar fuerte en Defense y cero en todo lo demás — sigue siendo un pursue válido. Una decisión puede puntuar débil en los cuatro — es Skip.

La vara para "significativo" es: lo podés defender en voz alta ante un CFO escéptico que no habla ingeniería, y no se ríe.

Ejemplo trabajado: la migración a Kubernetes que esperó dos años

En un cliente de Hubbing LATAM, el lead de ingeniería quería Kubernetes desde el día uno. Tenían un cliente, un equipo chico, y una arquitectura que corría bien en un puñado de instancias EC2. El argumento era el canónico: "lo vamos a necesitar eventualmente, hacerlo después es más difícil".

Correlo por D4S como estaba entonces:

• Differentiation: Ningún cliente lo sabría ni le importaría. Nada.
• Dollars: Costo operativo aproximadamente igual en cualquiera de las dos arquitecturas. Costo de tiempo de dev dramáticamente más alto en los primeros seis meses de Kubernetes. Negativo.
• Delight: Cero impacto user-facing. Nada.
• Defense: Ninguna nueva amenaza contrarrestada. Nada.

Decisión: Skip. Mantuvieron la arquitectura EC2 y el trimestre de tiempo de ingeniería se fue a features.

Dos años después, la misma decisión volvió. El producto había evolucionado. Los clientes habían crecido. Requerimientos de compliance obligaban a aislar data de cliente en cuentas AWS separadas, y la elección ahora era: duplicar el stack entero a mano por cada cliente nuevo, o usar Kubernetes para manejar tenant isolation como código. La lectura D4S era distinta:

• Defense: Requerimiento de compliance con deadline específico. Fuerte.
• Dollars: Replicar infra por cliente a mano consumiría semanas de ingeniería por onboarding. El modelado mostró que Kubernetes se pagaba a sí mismo en cuatro clientes a la tasa de crecimiento de entonces. Fuerte.

Dos Ds fuertes, ambas ancladas en problemas presentes y nombrados — no "lo vamos a necesitar eventualmente". El equipo también había crecido lo suficiente para absorber la complejidad operativa que los hubiera aplastado dos años antes. Migraron.

Misma tecnología, mismo equipo, mismo vendor. Dos veredictos D4S opuestos, con dos años de diferencia. Eso es el marco funcionando — no diciéndote si Kubernetes es bueno o malo, sino si esta decisión, ahora mismo, se gana el trimestre que cuesta.

Errores comunes

Reclamar los cuatro Ds en cada decisión. Si cada análisis pega en los cuatro Ds, el marco no está filtrando nada. El punto es que la mayoría de las decisiones fallen. Si te encontrás racionalizando hacia los cuatro Ds, estás usando D4S como decoración.

Confundir developer experience con Delight. Delight es usuarios. Si el refactor delighta a tus ingenieros, eso puede ser Dollars (retención, mayor throughput) pero no es Delight. No disfraces DX como Delight para meter una decisión.

Tratar Defense como anticipatorio en vez de identificado. Defense requiere una amenaza nombrada y plausible. "Best practices de seguridad" genéricas no son Defense. Un requerimiento de compliance específico con deadline específico, sí.

Qué hacer esta semana

Agarrá las tres decisiones técnicas más grandes abiertas en tu roadmap. Las que tienen costos en trimestres de ingeniería, no en tardes. Para cada una, escribí el análisis D4S como cuatro párrafos cortos — uno por D. Solo afirmaciones específicas.

Probablemente vas a encontrar que una de las tres es Skip. Eso solo ya vale el ejercicio: te liberaste un trimestre para gastar en la que sí pega en dos Ds.

Si querés una forma estructurada de hacerlo, el diagnóstico D4S camina una decisión por los cuatro filtros en 3 minutos. Para decisiones con €10K+ en stakes que querés pressure-testear contra 15 años de decisiones parecidas, eso es para lo que está el sparring.

FAQ

¿Qué es el marco D4S?

Un marco de decisión para CTOs y leads de ingeniería en startups de etapa temprana (Seed–Series A). Filtra decisiones técnicas a través de Differentiation, Dollars, Delight, Defense — y trata a Skip como el resultado por default. Una decisión tiene que puntuar significativamente en al menos un D para ganarse pasar Skip. La mayoría no, que es el marco funcionando.

¿En qué se diferencia D4S de otros marcos para CTOs?

La mayoría de los marcos evalúan decisiones por méritos técnicos aislados, asumiendo que la empresa sobrevive lo suficiente para que la decisión importe. D4S está armado para Seed–Series A, donde cada decisión técnica importante mueve el runway en semanas o meses. D4S también hace de Skip un resultado de primera clase — la mayoría de los marcos asume que toda decisión merece análisis.

¿Una decisión puede puntuar en más de un D?

Sí, y las decisiones más fuertes usualmente lo hacen. El punto no es elegir un D — es asegurarte de que al menos uno pegue significativamente. Si podés defender la decisión ante un CFO escéptico usando un solo D, no necesitás los otros. Si podés pegar en dos o tres, probablemente sea un pursue claro.

Conclusión

D4S existe no porque el mundo necesite otro marco. Existe porque todo marco que leí asume que la empresa lo logra. En Seed–Series A, esa es la asunción que no te podés permitir.

Si te llevás una cosa de este artículo: Skip es el feature. La mayoría de las decisiones en tu roadmap ahora mismo no se ganan pasar Skip, y el acto de decirlo en voz alta — a tu equipo, a tu CEO, a tu board — es el movimiento de mayor impacto que podés hacer este trimestre. Las decisiones que sobreviven D4S son las que merecen tus horas de ingeniería. Todo lo demás es teatro.

III