Cómo escribir mi "cuaderno WTF" (2021)
(simplermachines.com)- Si, justo después de unirte a un equipo nuevo, en vez de señalar de inmediato las cosas raras las vas juntando en un cuaderno WTF, puedes ganar el contexto necesario para construir confianza como alguien que ayuda al equipo, no como alguien que solo se queja
- Lo que vale la pena registrar son señales de fricción en la operación del equipo y el flujo técnico, como retrospectivas que terminan sin acciones, imposibilidad de hacer pruebas en local, un tablero de builds en rojo o dependencia de una sola persona para cierto trabajo
- Con el tiempo, la lista se va depurando entre cosas que tienen una razón válida, arreglos que ya están en marcha, prioridades bajas para el equipo y elementos fáciles de corregir
- Si después de unas semanas siguen quedando problemas, conviene hablar con integrantes del equipo, el team lead y el manager para confirmar causas e historia, y empezar resolviendo juntos problemas antiguos, molestos pero relativamente simples
- En vez de detonar el problema de inmediato, acumular contexto y prioridades permite que incluso alguien nuevo construya reputación como solucionador de problemas sin perder la confianza del equipo
Cómo usar un cuaderno WTF
- La reputación que quieres ganarte en el equipo es: “la persona que me ayuda a resolver mis problemas”, “la persona que termina lo que yo considero importante”
- Cada vez que me uno a un equipo nuevo, abro una página nueva en mi bullet journal y escribo
WTF - [Team Name], y cada vez que me topo con algo que se siente raro, lo anoto - Si aparece algo que quiero cambiar, también lo dejo registrado como una tarea aparte
- Durante las primeras 2 semanas me enfoco solo en registrar
- No digo de inmediato todo lo que creo que el equipo está haciendo mal
- No descargo en la retro una lista de todo lo que habría que cambiar
- Observo, escucho y anoto lo que me parece profundamente extraño
- Este método sirve para generar cambios en el equipo mientras también te ayuda a regularte y a no parecer alguien que solo se queja
Señales raras que detecto en un equipo nuevo
- En un equipo nuevo siempre hay cosas que te hacen pensar “wtf”
- Algunos ejemplos típicos son estos
- El equipo pasa una hora hablando de problemas serios en la retrospectiva, pero termina sin action items
- Las pruebas no corren en local y a nadie parece importarle
- Una parte grande del tablero de builds está siempre en rojo
- Solo una persona puede encargarse de trabajo importante y sensible al tiempo
- El equipo dedica mucho tiempo a cierta funcionalidad, pero nadie tiene muy claro por qué es importante o cómo ayuda a los clientes
Cosas que se borran de la lista
- Cuando ya se armó una lista lo bastante grande, empiezo a tachar elementos uno por uno
- Normalmente se borran por una de cuatro razones
- En realidad hay una buena razón
- El equipo ya está trabajando en arreglarlo
- El equipo no considera importante ese problema
- Es realmente fácil de corregir
- Incluso que las pruebas no corran en local puede no ser un problema tan grave, dependiendo del contexto
- Puede ser un issue ya conocido y con esfuerzos de solución en marcha
- El equipo puede hacer todo su trabajo en máquinas virtuales y aprovisionarlas fácilmente con comandos de chat
- Si tienen un buen sistema de integración continua y el hábito de desplegar cambios pequeños con frecuencia, no poder probar en local quizá no impida hacer deploy varias veces al día
- En algunos casos se ve una solución simple
- Si sabes dónde va, puedes escribir la documentación
- Si encuentras el script correcto, puede ser un cambio fácil
- Si veo una solución sencilla, la arreglo de inmediato
Tratar los problemas restantes junto con el equipo
- Si después de unas semanas siguen quedando problemas raros y sin resolver, empiezo conversaciones con integrantes del equipo, el team lead y el manager
- Las preguntas se enfocan en por qué esas cosas están así y cómo llegaron a estar así
- El objetivo es ganar confianza como alguien genuinamente curioso y con empatía, con paciencia y respeto por la experiencia de sus colegas
- Las razones por las que un problema sigue existiendo suelen caer en unas cuantas categorías
- El equipo no lo ha notado
- El equipo ya se acostumbró
- El problema es relativamente nuevo y los problemas anteriores eran mucho peores
- No saben cómo arreglarlo
- Antes intentaron arreglarlo y fallaron
- Los primeros tipos de problema a menudo pueden resolverse de inmediato solo con hacer preguntas
- La otra persona lo corrige enseguida o encuentran juntos cómo resolverlo
- Si es un problema técnico, escriben juntos una story o un ticket y trabajan en ello
- Si es un problema de proceso o social, lo hablan con todo el equipo en la retro
- En este punto conviene encontrar uno o dos problemas que hayan molestado a alguien del equipo desde hace tiempo y que tengan una solución relativamente simple
- Cuando lo subes al tablero de retro, eliges algo que no solo te incomoda a ti
- Durante la conversación del equipo, lo convierten en un action item que permita probar de inmediato lo que propuso esa persona
- El equipo empieza a sentir que la persona nueva los está ayudando a resolver sus problemas
Problemas más difíciles y conversación con el manager
- Con el tiempo entras a los problemas pegajosos que el equipo conoce pero le da miedo abordar
- Pueden ser cosas que se consideran “no tan malas”, pero de las que nadie quiere hablar
- Puede faltar la capacidad técnica necesaria
- Puede haber en el centro un problema humano complejo
- En esta etapa, hablas con tu manager llevando la lista que construiste hasta ese momento
- Lo que has visto durante varias semanas
- Que algunas cosas avanzan, pero otras parecen requerir más tiempo
- Si hay algo que se te esté escapando
- En qué áreas quieren que te enfoques
- Puede que al manager también le preocuparan los mismos problemas, pero no pudiera empujar con fuerza porque el equipo no parecía sentirse tan incómodo con ellos
- A partir de ahí pueden ordenar juntos las preocupaciones y los problemas del manager, y hablar de casos del pasado donde algo sí funcionó o no funcionó
- El manager empieza a verte como alguien con buen criterio, capaz de ayudar a resolver problemas más difíciles
Por qué no señalarlo de inmediato
- La reputación que quieres es: “Nat me ayuda a resolver mis problemas”, “Nat termina lo que yo considero importante”
- Esa reputación puede ayudarte a obtener el resultado que buscas en la evaluación de desempeño del año siguiente, y años después convertirse en recomendaciones
- Antes yo decía las cosas apenas detectaba un problema
- El resultado era una reputación de “siempre se queja”, “cree que nunca hacemos nada bien”
- La gente dejó de escuchar, yo me frustré en lo personal y además era ineficiente en lo profesional
- Si alguien nuevo hace un escándalo por cosas que en realidad no son un problema, que el equipo no considera problema, que ya se están resolviendo o que tenían una solución simple que no vio al principio, la confianza se derrumba rápido
- En un equipo siempre hay muchos problemas que podrían mejorarse, pero solo algunos realmente se pueden resolver
- Rara vez el orden en que descubres los problemas coincide con el orden más efectivo para resolverlos
- El cuaderno WTF te permite guardar por un momento el impulso de “quiero arreglar esto ya” y esperar hasta tener el contexto necesario para decidir qué conviene abordar primero
1 comentarios
Opiniones de Hacker News
Creo que este artículo no enfatiza lo suficiente una cosa: la mirada de una persona nueva ocurre una sola vez.
La razón por la que evaluamos mal la usabilidad de un producto es que ya sabemos cómo usarlo y nos volvimos insensibles a los errores y defectos.
Un nuevo integrante del equipo todavía no está en ese estado, así que observar qué pregunta, dónde se traba y dónde necesita ayuda de verdad puede darle al equipo muchas ideas valiosas.
Nos sentamos con una libreta, tomamos notas y conversamos con el usuario mientras usa el producto.
Por muchos terabytes de datos de telemetría que reunas, no puedes entender cómo se usa un producto tanto como hablando con usuarios reales.
La industria tecnológica debería superar un poco su miedo a otros seres humanos.
Es parecido a cuando un profesor experto olvida que lo que está explicando es difícil para un estudiante que recién está aprendiendo.
Pero no todo el mundo es igual de malo en esto; influye mucho si se tiene la empatía y el interés necesarios para ponerse en el lugar de un principiante.
Dos personas que hayan usado la shell Bash incontables veces pueden tener una comprensión totalmente distinta de qué le resulta extraño y poco intuitivo a un principiante.
Mirar con ojos frescos también es una habilidad, y puede mejorar con entrenamiento, igual que aprender a dibujar observando la luz y los objetos reales.
Si lo anotas en vez de expresarlo de inmediato, ganas tiempo para aprender por qué las cosas son así y para entender el terreno de la organización.
Una vez que temas como cuentas, permisos y aprobaciones quedan ordenados, puedes actuar con base en esa lista.
Entonces es más probable que el equipo te perciba como alguien que quiere ayudar, no como “la persona que aparece a cada rato gritando WTF”.
Funcionaba muy bien con un tamaño de 12 a 15 personas, pero no sé si escalaría bien a organizaciones más grandes.
Anotar y esperar es algo inmediato y de baja fricción, y además da la pequeña recompensa de ver que “la lista creció”, así que con práctica sistemática puede reaprenderse fácilmente.
Me gusta que se mantengan separadas la etapa de reconocer y registrar, y la etapa posterior de hacer un mapa, observar, aprender y reunir y guiar a personas con la misma inquietud.
Llevar un diario de trabajo siempre es una buena idea, pero hay algo en el tono de este artículo que me incomoda.
No querría trabajar con alguien que actúa como los Borg o que sigue un guion sacado de How to Win Friends and Influence People.
Si parece que alguien intenta manipularme, me cuesta confiar en esa persona, al menos desde el momento en que me doy cuenta.
Aun así, conviene no dejarse llevar solo por ese rechazo inmediato.
Yo también tengo objetivos sobre cómo quiero que los stakeholders se sientan conmigo, y me resultaron bastante útiles como criterio de conducta.
Aunque hiciera bien el trabajo desde lo técnico, si ignoraba la dimensión de las relaciones humanas surgían problemas, y en la práctica importaban los rumores que circulaban, cómo se me percibía y cómo se presentaba mi trabajo.
Pensar que “basta con hacer bien el trabajo” no elimina el hecho de que importa cómo mi trabajo y yo hacemos sentir a los demás.
Nunca leí How to Win Friends and Influence People, pero sentí que el artículo en sí estaba bastante bien escrito.
Ya seas un colaborador individual con experiencia, un nuevo gerente o un oficial, en los primeros 30 a 90 días lo normal debería ser no cambiar nada e intentar entender cómo funcionan las cosas y, más importante aún, por qué funcionan así.
Tiene muchos beneficios organizacionales y, en pocas palabras, así es como se hace en la práctica.
Los ingenieros han trabajado bajo malos managers, y a menudo intuyen por qué son malos aunque no puedan explicarlo con precisión.
Esa sensación de “mal manager” muchas veces viene de no ejercer un buen liderazgo táctico, y al igual que la ingeniería, el liderazgo también es una habilidad que se puede aprender.
El problema es que no hay muchos lugares que lo enseñen de forma deliberada, salvo ámbitos como el ejército o la formación de altos ejecutivos.
Si quieres trabajar bajo un buen manager, en realidad quieres trabajar bajo un buen líder, y el liderazgo es una habilidad táctica, como escribir código C++ eficiente.
Consiste en coordinar y guiar a las personas para que el equipo alcance objetivos mayores que la suma de lo que cada integrante podría lograr por separado, así que desde cierto ángulo puede sentirse como manipulación.
Aun así, la persona que protege al equipo de estupideces externas, consigue los recursos necesarios, elogia en público y critica en privado, da dirección sin micromanagement excesivo, reconoce y recompensa el desempeño, y no deja pasar el bajo rendimiento, suele ser el tipo de líder que les gusta a los ingenieros.
En cambio, cuando un político carismático con MBA y sin conocimientos técnicos usa estas técnicas por malas razones, se vuelve alguien con quien nadie quiere trabajar.
También suelen ser detestadas las personas que ascendieron de un rol técnico a uno gerencial pero no aceptan que gestionar es una habilidad distinta de la habilidad técnica.
En definitiva, si queremos que haya más líderes competentes en toda la industria, hay que tratar el liderazgo, como hace este artículo, no como una intuición innata y nebulosa, sino como una táctica explicable sobre cómo hacer las cosas.
Ganarse la reputación de que “Nat resuelve mis problemas” puede ser bueno para las recomendaciones, pero riesgoso para la carrera profesional.
Lo hice durante 20 años en varios departamentos, y cada vez querían retenerme como solucionador de problemas, no proponerme como candidato a ascenso.
Un colega que se jubiló después de trabajar 40 años también era de esas personas que resolvía cualquier problema, y era mucho más capaz que los gerentes, pero nunca lo ascendieron.
Era el as bajo la manga de todos, pero casi no recibía reconocimiento; resolver problemas se consideraba “lo normal” y no había recompensa.
A otras personas del mismo nivel se les aplicaban estándares mucho más bajos, y hasta en la última evaluación de desempeño el gerente dijo que “no evalúa contra los compañeros, sino contra los objetivos”.
A mí otro gerente me dijo lo mismo, así que no fue casualidad.
Sobre todo, mi gerente siempre estaba de mi lado cuando bloqueaba pedidos que no venían de él.
Si alguien que no conocía me pedía algo no trivial y yo no tenía tiempo o interés, bastaba con decir: “Ahora no tengo tiempo para verlo. Si necesita que se priorice, hable con mi gerente”, y 99 de cada 100 veces no llegaban hasta mi gerente.
La mayor ventaja de convertirse en la persona a la que todos acuden dentro de un departamento o de toda la empresa es que acumulas conocidos y una red de contactos.
Cuando necesitas información fuera del equipo o atravesar la burocracia para algo importante, funciona como un pequeño superpoder.
También te queda una red a la que contactar cuando buscas nuevas oportunidades; durante 15 años trabajando en el sector privado, todos los empleos que conseguí llegaron por conexiones de este tipo.
Pero se podría decir que uno de los dos enfoques pasa bien por el proceso de ascenso, y el otro no.
No es fácil, pero poner límites es una habilidad importante.
La parte de “lo saqué apenas vi el problema y Nat se ganó la reputación de que siempre se queja y cree que todo lo que hacemos está mal” debería estar cerca del comienzo del texto.
Ese nivel de autoconciencia es una habilidad real que vale la pena desarrollar.
El exastronauta Chris Hadfield también cuenta en su libro que usaba un enfoque similar al sumarse a una nueva misión y a un nuevo equipo.
Primero entraba en modo observación para aprender si los momentos WTF realmente tenían fundamento, y así no convertirse en un nuevo integrante irritante para el equipo.
Vale la pena leerlo.
Después de trabajar mucho tiempo en el mismo puesto, crear un lugar donde filtrar el ruido ayuda a que al menos no se quede tal cual en la cabeza.
No se trata solo de decidir si un problema es válido, sino también de aprender a dejar pasar ciertas cosas.
Sería bueno saber cuál es.
Cuando entro en una situación que ya existe, por lo general he usado un enfoque así.
Durante la primera semana reviso todo y anoto preguntas y observaciones.
No solo los momentos “WTF”, sino también lo que funciona bien y lo que me parece una muy buena idea.
Solo después lo reviso, priorizo y entro en la discusión.
Esto parece un principio que encaja bien con la cerca de Chesterton.
Es la historia de decirle a alguien que quiere quitar una cerca: “Si no conoces su propósito, no puedo dejar que la quites. Ve y piensa; cuando puedas decir que entendiste su propósito, entonces podrás eliminarla”.
Dicho con más claridad, significa que aunque algo parezca torpe, conviene asumir que quienes llegaron antes eran inteligentes y que había una razón para hacerlo así.
Esa razón puede haber quedado obsoleta, pero si no la tomas en cuenta terminarás repitiendo los mismos errores.
No solo mantener una lista de cosas que quieres corregir, sino dejarlas reposar un tiempo para poder entender por qué están así es una buena idea.
Muchas veces habrá sido algo hecho con prisa o un error, pero a veces sí existe una complejidad oculta que no se entiende de inmediato mirando una sola línea de código.
Lo primero es un fracaso evidente; lo segundo suele resolverse cuando te sumerges lo suficiente en ese entorno.
Aun así, anotar ambos es útil.
Justo esta semana les estaba diciendo a dos colegas que tengo un archivo “How the F” en mi computadora.
No es exactamente lo mismo que describe el autor, pero se parece mucho: cuando entro a un equipo nuevo, anoto todo lo que me hace pensar “¿y esto cómo era que se hacía otra vez?” cada vez que surge un problema.
No se lo llevo al gerente como en el texto original, pero me da una perspectiva para identificar cuáles son los puntos de fricción del equipo y de la empresa, y para ir resolviéndolos con el tiempo.
Vivo anotando en una lista todas las ideas que se me ocurren.
No tienen un orden especial; simplemente las voy agregando en papel o en un archivo de texto.
Las ideas no suelen aparecer cuando las necesitas, sino durante todo el día mientras haces otras cosas, y si no las anoto, al menos yo no las recuerdo.
Cuando llega el momento de hacer algo, basta con ir tachándolas una por una, así que no tengo que pensar qué hacer después; como las ideas no se agotan, se vuelve posible una explosión de productividad bastante grande.
Suena más a hablar de cómo organizar una lista personal de tareas, mientras que el texto original trata sobre cómo adaptarse y comunicarse dentro de un equipo.
La vida es demasiado corta para ordenar las notas; prefiero simplemente anotarlo todo y confiar en el orden inverso y la búsqueda.
Irónicamente, sé que tengo un tesoro de ideas increíbles, pero a esta edad ya no me importa ejecutarlas tanto como cuando tenía 20 y tantos.