Serie de 3 partes｜ Tiempo de lectura estimado: 10 minutos
En la entrega anterior, seguimos el proceso de transformar un libro de referencia de 685 páginas en un framework de tres capas mediante sesiones de brainstorming con IA. Base común, perfiles, entorno de desarrollo de talento. Incluso diseñamos la arquitectura de privacidad.
Siendo honesto, en ese punto estaba bastante satisfecho.
Entonces ejecuté lo que el propio framework recomienda: «someter este mismo diseño a una sesión de brainstorming con IA». ¿Cuál es el mayor punto débil de mi diseño? Esa pregunta reveló dos puntos ciegos estructurales adicionales.
Punto ciego ①：El desarrollo sin objetivos no es más que un «juego de superar debilidades»
Usé la evaluación de 5 dimensiones presentada en la primera entrega —profundidad de estructuración, exhaustividad de perspectivas, pensamiento crítico, metacognición, adecuación al perfil— para elaborar un informe de análisis de una organización hipotética de 18 personas.
El informe quedó impecable. Agregué las puntuaciones de cada equipo, emití alertas de homogeneización, propuse emparejamientos complementarios y prioricé las medidas de desarrollo. «La exhaustividad está en 3,2, subámosla a 3,6.» «La metacognición está en 3,1, apuntemos a 3,4.»
Entonces llegó la pregunta definitiva.
«Este informe no tiene en cuenta los objetivos. ¿No debería considerar el plan a medio y largo plazo de la empresa, así como los objetivos personales a 1, 5 y 10 años, y planificar y evaluar mediante Working Backwards, es decir, partiendo del objetivo hacia atrás?»
Tenía toda la razón.
Todas las medidas estaban diseñadas bajo un pensamiento de mejora basado en «cubrir las debilidades del puntaje actual». Exhaustividad baja → subámosla. Metacognición débil → entrenémosla.
Pero el «para qué» estaba completamente ausente.
Si la empresa va a entrar en el negocio de pagos el año que viene, reforzar el pensamiento en seguridad es la máxima prioridad. Si la estrategia es lanzar masivamente nuevos productos impulsados por IA, la capacidad de brainstorming rápido con el perfil A es lo más importante. Si un ingeniero aspira a ser CTO en cinco años, quizás sea mejor invertir de forma concentrada en metacognición y exhaustividad de perspectivas, en lugar de subir todas las dimensiones por igual.
Sin objetivos, el desarrollo no es más que un «juego de superar debilidades».
Working Backwards: superar debilidades vs. retroceder desde el objetivo
Al incorporar la perspectiva de Working Backwards, las prioridades cambian aunque las puntuaciones sean las mismas.
Basado en superar debilidades (antes de la mejora):
- Introducción de plantillas de brainstorming (elevar la exhaustividad base)
- Medidas contra la homogeneización de la metacognición
- Taller de mapas de conocimiento
Basado en retroceder desde el objetivo (después de la mejora):
- Acelerar la promoción al perfil B (retrocediendo desde la incorporación de un gran cliente en Q3 → plazo Q2)
- Construir el sistema de seguridad (retrocediendo desde el lanzamiento de la función de pagos → plazo Q3)
- Introducción de plantillas de brainstorming (personalizadas para tener impacto inmediato en los dos puntos anteriores)
Incluso para «elevar la base de metacognición», al retroceder desde el objetivo puede bajar en prioridad. Si el plazo para la apertura de la API externa es Q1 de 2027 y hay margen, reforzar esa dimensión puede dejarse para después.
El plan de desarrollo individual también cambia
Consideremos el ejemplo del miembro J, con 6 meses en la empresa. Sus puntuaciones en todas las dimensiones están entre 2,0 y 2,8, es decir, bajas.
Plan basado en superar debilidades: Elevar la base en todas las dimensiones. Entrenar los fundamentos en el equipo del perfil A.
Plan Working Backwards: Sabemos que el objetivo de J a 5 años es «ingeniero de seguridad». Entonces, durante el primer año se entrenan los fundamentos con el perfil A, pero en las sesiones de brainstorming se incorpora conscientemente la perspectiva de seguridad desde ya. Se planifica el traslado al equipo del perfil C en el segundo año.
Aunque se trate del mismo «entrenar los fundamentos», el simple hecho de tener un objetivo desde el que retroceder cambia el enfoque del brainstorming diario.
Estructura jerárquica de objetivos
Para que Working Backwards funcione, los objetivos se conectan jerárquicamente en 4 niveles.
Plan a medio y largo plazo de la empresa (visión a 3-5 años)
└→ OKRs anuales u objetivos de negocio
└→ Objetivos trimestrales de cada proyecto
└→ Objetivos de carrera individuales: corto plazo (1 año), medio (5 años), largo (10 años)
Retrocediendo desde el nivel superior al inferior se determina «qué debe priorizar este equipo en el próximo trimestre». El momento de promoción de perfil también se planifica de forma activa: no «ya va siendo necesario», sino «lo dicta el plan de negocio».
Las debilidades de Working Backwards
Dicho esto, Working Backwards no es infalible. Tiene tres puntos débiles.
Dependencia de la calidad de los objetivos. El plan cambia según si «quiero ser CTO en 5 años» es una fachada o una convicción real. Se vuelve necesario hacer brainstorming sobre el propio proceso de definición de objetivos.
Los objetivos cambian. Descubrir la fascinación por los sistemas a gran escala y cambiar el objetivo de seguridad a arquitecto de software es algo que pasa con frecuencia. Se necesita flexibilidad para acoger esos cambios.
Los objetivos de la empresa y los personales pueden entrar en conflicto. Si la empresa necesita perfiles de seguridad pero la persona quiere orientarse al frontend, la IA no puede resolver eso. Solo queda que el manager y la persona lleguen a un acuerdo mediante el diálogo.
Aun así, es claramente superior a «solo superar debilidades sin tener objetivos».
Punto ciego ②：La racionalidad absoluta mata lo que no puede nacer de la racionalidad
Justo cuando creía que había terminado el framework v2 integrando Working Backwards, llegó otra pregunta fundamental.
«La creatividad de los desarrolladores, la motivación, la cohesión del equipo y el espíritu lúdico son fuentes de innovación. Así como la "regla del 20%" de Google dio origen a Gmail y AdSense, ¿no contribuye también a la sostenibilidad a largo plazo de la organización dejar un margen para experimentos "no racionales"?»
Al revisar toda la discusión hasta ese punto, todo estaba impregnado del pensamiento de «diseñar racionalmente, medir racionalmente, mejorar racionalmente».
La base común es racional. Los perfiles son racionales. La evaluación es racional. La arquitectura de privacidad también es racional. Incluso incorporamos la retroproyección de objetivos con Working Backwards.
Todo era racional. Y esa racionalidad perfecta era precisamente el punto ciego.
Gmail nació de la regla del 20% de Google. AdSense y Google News también. Ninguno de estos habría surgido jamás de «inversiones en desarrollo calculadas a partir del plan a medio y largo plazo de la empresa». Porque lo que no existe en el plan no puede ser objeto de retroproyección.
Este framework, partiendo de Software Engineering at Google, había pasado por alto una de las características culturales más importantes de Google.
La 6.ª dimensión: apertura
Las 5 dimensiones de evaluación —estructuración, exhaustividad, pensamiento crítico, metacognición, adecuación al perfil— miden todas «qué tan bien se manejan los problemas ya conocidos».
Sin embargo, la fuente del innovación reside en «la capacidad de percibir lo que todavía nadie reconoce como un problema». Esto está profundamente vinculado a la «apertura a la experiencia» (Openness to Experience) del modelo de los Cinco Grandes.
Por eso añadí «apertura» como 6.ª dimensión. Sin embargo, su tratamiento es fundamentalmente distinto al de las otras cinco.
| Pregunta de diseño | Respuesta |
|---|---|
| ¿Se incluye en la puntuación de evaluación? | No se incluye. La apertura es un rasgo de personalidad, no una habilidad. Catalogar una apertura baja como «debilidad» no es apropiado. |
| ¿Para qué se mide entonces? | Observación y fomento. Para la autoconciencia de la persona y para ver la diversidad del equipo en su conjunto. |
| ¿Cómo se aplica a la composición del equipo? | Un equipo donde todos tienen apertura 5 es estimulante pero nunca termina de implementar nada. Un equipo donde todos tienen 1 es sólido pero no genera innovación. Se observa el equilibrio de la diversidad. |
El margen de exploración: diseño institucional
No basta con «medir» la apertura. Es necesario crear institucionalmente un estado en el que la exploración sea bienvenida en la organización.
Regla del 20% de brainstorming exploratorio (recomendada). Se recomienda que al menos el 20% del total de sesiones de brainstorming se realice sobre temas no directamente relacionados con el proyecto asignado. Sin embargo, es fundamental que sea «recomendado, no obligatorio». En el momento en que se vuelve obligatorio, se convierte en «exploración obligatoria del 20%» y pierde su sentido como fuente de creatividad.
Showcase de brainstorming exploratorio (mensual). Un espacio donde quienes lo deseen comparten «esto tan interesante que estuve discutiendo con la IA». No importa la calidad de la presentación ni la contribución al negocio. Con «fue interesante» es suficiente. Tanto la asistencia como la presentación son voluntarias. Se declara explícitamente que no se refleja en ninguna evaluación.
Día de hackathon de brainstorming (trimestral). Un día en que todos se alejan del trabajo habitual y crean algo libremente con IA sobre el tema que quieran. Se desconecta intencionalmente de la retroproyección de objetivos de Working Backwards, y solo ese día se permite oficialmente lo «no racional».
La decisión de diseño de «no gestionar»
Aquí está el punto de diseño más delicado.
El espíritu lúdico deja de ser juego en el momento en que se institucionaliza.
En el momento en que se institucionaliza el «Día de hackathon de brainstorming», se convierte en «juego autorizado por la organización», algo distinto al espíritu lúdico espontáneo original. Pero sin una institución, queda la barrera psicológica de «no sé si está bien que juegue».
La respuesta a esta contradicción es que la institución se limite a dar «permiso» y no gestione en absoluto el contenido. Qué hacer, qué crear, si se producen resultados o no: todo es completamente libre. La propia decisión de diseño de «no gestionar» es el mecanismo más importante para preservar el espíritu lúdico.
Grado de exploración recomendado por perfil
El margen de exploración también se gradúa según el perfil.
| Perfil | Exploración recomendada | Motivo |
|---|---|---|
| A: Pequeña escala / alta velocidad | ★★★ Máximamente recomendada | Fase en que los experimentos y descubrimientos determinan la dirección del producto |
| B: Sistemas a gran escala | ★★ Recomendada | Como fuente de ideas de mejora que superan los marcos existentes |
| C: Seguridad estricta | ★ Permitida | El pensamiento creativo de ataque es necesario, pero el trabajo principal es prioritario |
| D: Mission-critical | ☆ Permitida con moderación | La estabilidad es la máxima prioridad |
Arquitectura final: 3 capas + 2 ejes
Integrando los dos puntos ciegos, la forma definitiva del framework quedó completa.
┌─────────────────────────────────────────┐
│ Eje horizontal ①: Working Backwards │
│ Empresa → Área → Proyecto → Objetivos individuales (retroproyección) │
├─────────────────────────────────────────┤
│ │
│ Capa 1: Base común │
│ Monorepo / Trunk-based / CI/CD impulsado por IA │
│ Principios culturales / Jerarquía de objetivos / Margen de exploración │
│ │
│ Capa 2: Perfiles (A / B / C / D) │
│ Nivel de dependencia de IA / Estándares de pruebas / Sistema de revisión │
│ Grado de exploración recomendado por perfil │
│ │
│ Capa 3: Entorno de desarrollo de talento │
│ Evaluación de 6 dimensiones (5 dimensiones + apertura) │
│ Feedback en 3 etapas │
│ Arquitectura de privacidad (3 capas de datos) │
│ │
├─────────────────────────────────────────┤
│ Eje horizontal ②: Margen de exploración │
│ Exploración del 20% / Showcase / Hackathon │
└─────────────────────────────────────────┘
Dos principios de diseño
Dos principios atraviesan todo este framework.
Principio ①: Proteger mediante mecanismos, no mediante políticas. No «el CEO tampoco verá los registros», sino «no existe ningún permiso de acceso para que el CEO pueda verlos aunque quiera». No «no se usará en evaluaciones», sino «los datos no existen en una forma que pueda usarse en evaluaciones».
Principio ②: Proteger racionalmente los valores que están fuera de la racionalidad. La retroproyección de objetivos de Working Backwards es completamente racional. Sin embargo, la innovación que no está en el plan no nace de la racionalidad. Por eso, el margen de exploración se «diseña racionalmente», se «institucionaliza racionalmente» y se «protege racionalmente».
Coexistencia de racionalidad e irracionalidad. Puede parecer una contradicción, pero esa era la última pieza del framework.
Avance de la próxima entrega
En la segunda entrega explicamos el descubrimiento de los dos puntos ciegos estructurales (Working Backwards y el margen de exploración) y la visión global del framework definitivo (v2).
En la tercera entrega, trasladamos este framework a una forma utilizable desde mañana mismo. Veremos las reglas de operación concretas de los perfiles A a D implementados como archivo CLAUDE.md de Claude Code, el diseño de los prompts para generar informes de análisis con IA, y una reflexión sobre el hecho de que este propio artículo es en sí mismo «un ejemplo real de brainstorming».
Continúa en la 3.ª entrega: «Listo para usar mañana: implementación de CLAUDE.md y prompts de análisis con IA» →