Un equipo de plataformas no tiene un gestor de productos que le entregue un plan de ruta. No hay una línea de ingresos a seguir, ni un mercado a perder. El trabajo no existe a menos que un ingeniero lo invente. Esa es la idea central de «A Staff Engineer’s Guide to Inventing Work», una publicación que argumenta que las señales de lo que construir a continuación ya existen.
La publicación argumenta que esas señales provienen de cuatro direcciones: los sistemas mismos, los usuarios del sistema, la organización y la industria más amplia. El autor, que firma como ingeniero de personal, quiere facilitar esa invención al identificar las fuentes de esas señales.
Señales que emite el Sistema
Los fallos son la señal más inmediata que señala el autor. Las autopsias, cuando se hacen correctamente, señalan qué hay que arreglar o qué hay que reemplazar. A veces señalan algo nuevo que construir también, especialmente si se observa cómo los usuarios se adaptaron durante una interrupción prolongada. El autor advierte contra el sesgo hacia los fallos más fuertes y recientes, calificando el descubrimiento impulsado por fallos como un «indicador máximamente rezagado».
El costo es otra señal obvia. La factura de la nube reemplaza a una estrella del norte de los ingresos. El autor va más allá de la optimización de la base de datos y los recortes de tráfico, pidiendo a los lectores que revisen los contratos de sus proveedores y las partidas de la factura de la nube, o que pregunten a alguien que tenga acceso a los centros de costos. La lección principal: comprar frente a construir no es una decisión única. El alcance, la pertenencia al equipo, la tecnología y los mercados cambian todos, y se permite volver a visitar esa elección.
La tarea es la tercera señal. Cada equipo tiene trabajo que se repite sin fin, y casi nunca se le da prioridad. El autor admite que este es un punto que muchos lectores ya conocen, pero que aún vale la pena señalar. La trampa: arreglar la tarea de tu equipo mejora la economía de la unidad, mientras que arreglar la tarea de tus usuarios mejora su experiencia. Los dos no son el mismo problema.
Señales que emiten los Usuarios
Las entrevistas a usuarios son una trampa, argumenta el autor. Preguntar a las personas qué quieren a menudo te da caballos más rápidos, no una visión del futuro. Pero eso no es excusa para dejar de hablar con los usuarios. El descubrimiento continuo significa tener una conversación en curso:
- Habla con N usuarios por semana/mes/trimestre.
- Muéstrales su tarea más reciente que involucra la plataforma.
- Pídeles sus tres principales problemas.
- Preguntar qué significaría para ellos resolver esos problemas.
- Preguntar quién más tiene el mismo problema.
- Interrogar sus «hacks» — casi todos los problemas reales ya tienen uno.
- Rechazar sus soluciones propuestas y ver si se ajustan a su diseño actual.
- Documentar los problemas, indexados por la frecuencia con la que surgen.
El diseño del espacio de soluciones es un foro aparte, insiste el autor. La entrevista se mantiene comprometida con la comprensión del problema.
Los casos de uso sobrecargados son la heurística favorita del autor. Algunas plataformas son empleadas para tareas para las que nunca fueron diseñadas. El autor pide a los lectores que entiendan por qué los usuarios eligen la plataforma en lugar de alternativas, incluso cuando la plataforma nunca fue pensada para el trabajo. Esos casos de uso actúan como prototipos construidos por los usuarios mismos. La prueba de fuego: ¿quién más entre sus usuarios tiene el mismo problema?
La asociación de colaboradores a prototipo es la versión deliberada de la misma idea. En lugar de descubrir la sobrecarga después del hecho, el equipo y los usuarios trabajan juntos para construir un prototipo en la plataforma. Un prototipo no es una promesa de que la función se convierta en oficial. Es una exploración conjunta. La prueba de fuego sigue siendo la misma: ¿quién más entre sus usuarios tiene el mismo problema?
Señales que emite la Organización
Los OKRs se enumeran aquí por completitud. Si su equipo ha establecido uno, o se le ha entregado uno, ya ha inventado ese elemento de trabajo. El autor continúa.
La heurística de Repetición del Gerente es más sencilla. Si escucha a su gerente, o al gerente de su gerente, o a cualquier persona más arriba en la cadena, hablar de algo dos veces en una semana, es probable que haya una preocupación sin abordar detrás de ello. El autor recomienda tomar notas en las reuniones individuales, o leer las generadas por la IA. Esta es la heurística más débil, en opinión del autor, porque cuanto más arriba en la jerarquía, más lejos del trabajo real.
Una Comparación de las Señales
| Señal (1) | Sesgo (2) | Fortaleza (3) |
|---|---|---|
| Descubrimiento impulsado por el colapso (4) | Fallas recientes/más sonoras (5) | Señales claras de autopsia (6) |
| Costo (7) | Economía unitaria (8) | Patrones esporádicos (9) |
| Labores (10) | Enfoque interno (11) | Invisible a otros (12) |
| Descubrimiento continuo ) | Trampa de caballos más rápidos ) | Conversación en curso ) |
| Casos de uso sobrecargados ) | Valor del prototipo ) | Prueba de contraste: ¿quién más? ) |
| De socio a prototipo ) | Exploración conjunta ) | Misma prueba de contraste ) |
| Objetivos y Resultados Clave (OKRs) ) | Establecidos/transmitidos ) | Objetivo claro ) |
| Repetición de gerentes (1) | Distancia ascendente (2) | Heurística débil (3) |
Lo que esto significa para los equipos de plataforma (4)
El argumento central del artículo es que los equipos de plataforma deben ser proactivos en la búsqueda de trabajo. Sin un jefe de producto que les entregue un plan de ruta, deben buscar señales en los sistemas, los usuarios, la organización y la industria. El autor ofrece métodos concretos para hacerlo, desde autopsias de fallas hasta entrevistas con usuarios hasta OKRs. (5)
Las señales más fuertes provienen de los usuarios, sugiere el autor. Los casos de uso sobrecargados y el prototipo de socios tratan el comportamiento del usuario como un prototipo de lo que la plataforma podría llegar a ser. La prueba de litmus — quién más tiene el mismo problema — transforma las quejas individuales en evidencia colectiva. (6)
La señal más débil es la heurística de repetición de gerentes. El propio juicio del autor es explícito: cuanto más arriba en la jerarquía, más alejado del trabajo real. Es por eso que el autor recomienda tomar notas en las conversaciones individuales y leer las generadas por LLM, incluso si la propia heurística es débil. (7)
Por qué esto es importante ahora (8)
Los equipos de plataforma están en todas partes ahora. Las facturas de la nube han reemplazado los objetivos de ingresos para muchos de ellos, y el trabajo de construir valor para los usuarios no se imponen desde arriba. Las señales que describe el autor son reales, y los métodos para leerlas son prácticos en lugar de vagos. (9)
El autor no ofrece platitudes vagas sobre la innovación. Ofrece pasos concretos — reconocimiento de patrones de autopsias, entrevistas con usuarios, revisiones de contratos y seguimiento de OKR — que cualquiera en un equipo de plataforma puede comenzar a usar mañana. (10)
La debilidad de la heurística de repetición de gerentes vale la pena señalarla. El autor no pretende que sea fuerte. Esa honestidad añade peso a las otras señales, que el autor claramente favorece. (11)
El artículo ofrece consejos reales y prácticos para un problema que enfrentan los equipos de plataforma a diario: cómo encontrar trabajo cuando nadie les entrega un plan de ruta. (12)
«“A Staff Engineer’s Guide to Inventing Work,” sujithjay.com.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.