Hacer las cosas bien contra hacer las cosas correctas

Descripción

Hay una distinción, vieja en el mundo del management, que rara vez se enseña con precisión en un equipo de ingeniería: hacer las cosas bien (eficiencia: ejecutar con calidad lo que decidiste hacer) no es lo mismo que hacer las cosas correctas (efectividad: haber decidido bien qué hacer, para empezar). Puedes tener una de las dos sin la otra. Un equipo puede escribir código impecable, con cobertura de tests altísima, cero deuda técnica y despliegues sin fricción — y estar, con toda esa excelencia, construyendo algo que no debería estar construyendo. Esa combinación —excelencia táctica sobre una elección estratégica equivocada— no es un caso raro ni hipotético: es, de lejos, la forma más común y más cara de fracasar en un equipo de producto, precisamente porque se siente como éxito desde adentro.

Conexión con el módulo. Esta lección abre la distinción que le da nombre al módulo entero: táctica contra estrategia. Todo lo que viene después —qué ES una estrategia (lección 3), su costo cuando se elige mal (lección 4), las cuatro capas que la ordenan (lección 5)— depende de que esta distinción quede clara primero. Vas a conocerla con una analogía que vas a reconocer el resto del módulo: la montaña y la pared.

Una analogía: la montaña y la pared

Imagina a dos escaladores, en dos montañas distintas, el mismo día. Ana elige "Cerro Torre" —una de las paredes técnicamente más exigentes del mundo, hielo vertical, viento constante— y la escala con una técnica extraordinaria: cada anclaje perfecto, cada movimiento calculado, cero errores en ocho horas de ascenso. Luis elige "Aconcagua" y sube con una técnica mediocre: pasos torpes, un par de paradas innecesarias, nada elegante. Al final del día, ¿quién "escaló mejor"? Si la pregunta es solo sobre técnica de escalada —sobre cómo subieron la pared que tenían enfrente—, Ana gana sin discusión.

Pero cambia la pregunta. Supón que la meta real, la que importaba antes de que empezaran a subir, era llegar a la cima del Aconcagua — esa era la montaña que alguien necesitaba conquistar, por la razón que sea. Con esa pregunta en mente, Ana no llegó a ningún lado que le sirviera: escaló, con una técnica soberbia, la montaña equivocada. Luis, con una técnica mediocre, llegó exactamente a donde tenía que llegar. La técnica de escalada —cómo subes la pared que tienes enfrente— es la táctica. Elegir qué montaña subir —cuál es la pared correcta— es la estrategia. Y la lección incómoda de este ejemplo es que la técnica de escalada, por perfecta que sea, no tiene ningún poder para corregir una montaña mal elegida. Ana no está "un poco menos exitosa" que Luis: está, en términos de la meta real, exactamente igual de lejos de la cima que le importaba que si no hubiera escalado nada en absoluto.

Traducido a un equipo de producto: táctica es cómo priorizas el backlog, cómo dimensionas una oportunidad, cómo recortas al MVP correcto, cómo escribes el código de la feature — todo lo que product-thinking-for-engineers-guide te enseña a hacer bien. Estrategia es, antes que nada de eso, elegir cuál es la montaña: qué segmento sirves, contra quién compites de verdad, qué apuestas siquiera pertenecen al juego que decidiste jugar. Un equipo que prioriza con RICE de forma impecable, mide con rigor cada experimento, y despliega sin fricción — pero nunca se preguntó si el backlog completo apuntaba a la montaña correcta— es Ana en la pared de hielo: técnica perfecta, cima equivocada.

Ejemplo trabajado: Ana, Luis, y la cima que importaba

Vamos a modelar exactamente esta comparación con una función mínima, climbReport, que recibe la montaña que alguien escaló, la montaña que en realidad importaba, y un puntaje de técnica — y devuelve un veredicto de una sola cosa: ¿llegaste a donde te importaba llegar?

// climbReport(): compara dos escaladores. La tecnica de escalada (como subes la
// pared) es la tactica; que montana elegiste escalar es la estrategia. El reporte
// solo pregunta una cosa: ¿llegaste a LA cima que te importaba?
function climbReport(name, mountain, targetSummit, techniqueScore) {
  const rightMountain = mountain === targetSummit;
  return name + ': escalo "' + mountain + '" con tecnica ' + techniqueScore + '/10 -- ' +
    (rightMountain
      ? 'llego a la cima que le importaba.'
      : 'llego a la cima de OTRA montana; su cima real sigue intacta.');
}

console.log(climbReport('Ana', 'Cerro Torre', 'Aconcagua', 9));
console.log(climbReport('Luis', 'Aconcagua', 'Aconcagua', 5));

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

Ana: escalo "Cerro Torre" con tecnica 9/10 -- llego a la cima de OTRA montana; su cima real sigue intacta.
Luis: escalo "Aconcagua" con tecnica 5/10 -- llego a la cima que le importaba.

Nota, con cuidado, lo que el reporte no hace: en ningún momento pondera el techniqueScore para "compensar" la montaña equivocada. Un 9/10 de Ana no vale más, para el veredicto final, que un 5/10 de Luis en la montaña correcta — porque, literalmente, no hay ninguna cantidad de técnica que convierta "Cerro Torre" en "Aconcagua". Esa es la propiedad central de la relación entre estrategia y táctica que este módulo entero va a desarrollar: la estrategia decide si la técnica cuenta para algo. No es que la técnica de Ana no importe nunca — en la montaña correcta, esa misma técnica de 9/10 la habría llevado más rápido, más segura, con más margen de error. Lo que este ejemplo aísla es que, aplicada a la montaña equivocada, ni la mejor técnica del mundo compra ni un metro de distancia hacia la cima real.

De la montaña a Mercado: el mismo patrón, otro disfraz

El error de Ana rara vez se ve tan obvio en un equipo de producto real, porque nadie anuncia "vamos a escalar la montaña equivocada" en voz alta. Se ve, en cambio, así: el equipo de Mercado decide, sin una discusión estratégica explícita de por medio, invertir el trimestre en construir un motor de búsqueda con ranking propio — un problema técnico fascinante, con mucho para aprender, que cualquier ingeniero fuerte disfrutaría resolver. Lo ejecutan con una técnica excelente: arquitectura limpia, benchmarks sólidos, resultados de búsqueda medibles y mejores que antes. Al cierre del trimestre, el equipo se siente orgulloso, con razón, del trabajo técnico. Y sin embargo, si la elección correcta para Mercado era competir por descubrimiento curado en vez de por precisión de búsqueda —una elección que vas a ver formalizarse en la lección 3, y que el módulo 5 va a mostrar por qué, contra el gigante genérico, es casi imposible ganar de frente en búsqueda pura—, entonces ese trimestre entero fue Ana escalando Cerro Torre con una técnica de nueve: extraordinario, admirable, y estratégicamente irrelevante para la cima que Mercado necesitaba alcanzar.

Esto no es un argumento contra la excelencia técnica — todo lo contrario. Es un argumento sobre dónde apuntas esa excelencia. La misma habilidad de ingeniería que construyó el motor de búsqueda propio, aplicada al problema correcto —por ejemplo, un sistema de reputación y confianza que haga que descubrir un vendedor local se sienta seguro—, habría sido tan fascinante de construir y, además, habría movido a Mercado hacia la cima que sí importaba. La pregunta de este módulo no es "¿qué tan bien construyes?" —esa la contesta product-thinking y, más aún, la ingeniería misma—. La pregunta es, siempre, la que viene antes: ¿esta es la montaña correcta?

Errores comunes

Medir el éxito de un trimestre solo por la calidad técnica de lo entregado. Qué pasa: un equipo revisa su trimestre y reporta "cero incidentes, cobertura de tests al 95%, cero deuda técnica agregada" como evidencia de un buen trimestre, sin mencionar nunca si lo construido apuntaba a la dirección correcta. Por qué pasa: la calidad técnica es fácil de medir y agradable de reportar; la pregunta "¿era la montaña correcta?" es incómoda, porque a veces la respuesta es que no. Cómo detectarlo: en la retro del trimestre, todas las métricas mencionadas son de cómo se construyó, ninguna de qué se construyó y por qué. Cómo corregirlo: agrega, siempre, la pregunta anterior — antes de calificar la ejecución, pregunta si la elección de fondo era la correcta. La lección 4 te da un modelo que combina ambas preguntas en un solo número, para que dejen de evaluarse por separado.

Creer que "trabajar más rápido" arregla una montaña mal elegida. Qué pasa: al notar que un trimestre no dio los resultados esperados, la reacción es apretar el ritmo del siguiente — más sprints, menos reuniones, entregar más rápido lo mismo que antes. Por qué pasa: la velocidad se siente como la palanca que sí controlas, mientras que cuestionar la elección de fondo se siente fuera de tu carril. Cómo detectarlo: el trimestre siguiente entrega más rápido, con la misma calidad técnica, y el resultado de negocio sigue sin moverse. Cómo corregirlo: la velocidad es una propiedad de la táctica —de cómo subes la pared—. Si la montaña sigue siendo la equivocada, escalarla más rápido solo te hace llegar antes a un lugar que no querías. La pregunta que hay que hacer no es "¿cómo vamos más rápido?", es "¿es esta la montaña?".

Suponer que "elegir la montaña correcta" es obvio y no hace falta discutirlo. Qué pasa: el equipo salta directo a priorizar y construir, asumiendo que "obviamente" todos entienden cuál es la dirección estratégica, sin que nadie la haya puesto en palabras explícitas ni la haya cuestionado nunca. Por qué pasa: cuestionar la dirección de fondo se siente, en muchos equipos, como cuestionar la autoridad de quien la definió — o simplemente nadie se detuvo a hacerlo, porque siempre hay algo más urgente que construir. Cómo detectarlo: si le pides a tres personas del equipo que describan, en una frase, la montaña que están escalando, obtienes tres respuestas distintas — o silencio. Cómo corregirlo: la elección de la montaña necesita quedar escrita, explícita y revisable, no asumida. Ese es, exactamente, el trabajo del módulo 2 en adelante: construir esa elección para Mercado, pieza por pieza, en vez de darla por sentada.

Ejercicios

Ejercicio 1 — Táctica o estrategia. Para cada decisión de Mercado, di si es una decisión táctica (cómo escalar la pared) o estratégica (qué montaña escalar):

• (a) "Vamos a usar una arquitectura de microservicios para el nuevo checkout."
• (b) "Vamos a competir por compradores que exploran, no por los que buscan un SKU exacto."
• (c) "Vamos a escribir los tests del carrito antes de escribir el código (TDD)."
• (d) "Vamos a construir un moat de datos con el historial de compras, en vez de competir en precio."

Ejercicio 2 — Cambia el resultado. Usando climbReport, ¿qué imprimiría si Ana hubiera escalado "Aconcagua" con técnica 9 y Luis hubiera escalado "Cerro Torre" con técnica 5? Antes de correrlo, predice el veredicto de cada uno.

console.log(climbReport('Ana', 'Aconcagua', 'Aconcagua', 9));
console.log(climbReport('Luis', 'Cerro Torre', 'Aconcagua', 5));

Ana: escalo "Aconcagua" con tecnica 9/10 -- llego a la cima que le importaba.
Luis: escalo "Cerro Torre" con tecnica 5/10 -- llego a la cima de OTRA montana; su cima real sigue intacta.

Ejercicio 3 — Encuentra tu propia montaña. Piensa en un proyecto reciente —de trabajo o personal— donde pusiste mucho esfuerzo técnico. Sin juzgarlo todavía con el criterio formal (eso llega en la lección 3), responde: ¿tenías clara, antes de empezar a construir, cuál era "la montaña correcta"? ¿Alguien la había puesto en palabras explícitas, o la diste por sentada?

Resumen y siguiente paso

En esta lección instalaste la distinción que le da nombre al módulo: hacer las cosas bien (táctica, técnica de escalada) contra hacer las cosas correctas (estrategia, elección de montaña). Con Ana y Luis, ejecutados en climbReport, viste algo incómodo y central: ninguna cantidad de técnica compra distancia hacia una cima distinta a la que estás escalando. Y viste cómo ese mismo patrón, disfrazado, aparece en un equipo de producto real cuando la excelencia técnica se mide sin preguntar nunca si apuntaba a la dirección correcta.

Antes de avanzar deberías poder: explicar la diferencia entre táctica y estrategia con tus propias palabras; reconocer, en una decisión cualquiera de un equipo, si es de "cómo" o de "qué juego"; y describir por qué la técnica no puede compensar una montaña mal elegida.

La lección 3 toma el lado de la montaña —la estrategia— y lo define con precisión de ingeniero: ¿qué ES, exactamente, una estrategia? ¿Y qué NO es, aunque suene igual de convincente? Ahí vas a construir isRealStrategy, el primer modelo ejecutado del módulo, y a correrlo sobre las cinco frases del offsite de Mercado que conociste en la lección 1.

Recursos

• Richard Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters — penguinrandomhouse.com/books/208668. La fuente de la distinción que abre este módulo: ejecutar bien no es lo mismo que ejecutar lo correcto. En inglés.
• Michael E. Porter, "What Is Strategy?" (Harvard Business Review, 1996) — hbr.org/1996/11/what-is-strategy. Porter abre el artículo, casi con las mismas palabras que esta lección, distinguiendo "efectividad operacional" (hacer las cosas bien) de "posicionamiento estratégico" (hacer las cosas correctas). En inglés.