- Ahora soy engineering manager, pero cuando trabajaba como software engineer, pasé varios días trabajando en una función compleja y subí un PR
- El feedback fue tajante y frío: “Esto es overengineering. Es complejo. Refactorízalo” fue todo lo que dijo
- Me enfurecí por recibir solo críticas sin una sola palabra de reconocimiento, pero esa historia con ese manager apenas era el comienzo
Un estilo de liderazgo que no cuidaba las emociones
- Este manager era distinto a los líderes que había conocido antes
- No te llevaba de la mano ni usaba palabras suaves
- Tenía características como estas
- Rechazaba de inmediato las ideas a medio cocinar
- Odiaba la complejidad por la complejidad misma
- Solo le importaba el código limpio, eficiente y fácil de mantener
- Incluso en las retrospectivas no daba rodeos y señalaba los problemas de forma directa
- Al principio pensé que era una persona despiadada, pero detrás había otra filosofía
El punto de inflexión de un feedback que sacudió mi orgullo
- En una sprint review hice una demo de una funcionalidad en la que confiaba, pero el manager me interrumpió a mitad de camino y preguntó
> “Esto es frágil. ¿Qué pasa bajo carga? ¿Cuál es el plan de rollback?”
- Como no pude responder bien, el manager dijo:
> “Ahora mismo estás pensando como coder. Tienes que pensar como engineer”
- Al principio me molestó, pero al final me di cuenta de que mi estilo de código estaba más enfocado en ser ingenioso que en ser resiliente
La verdadera lección: ese manager no me estaba atacando personalmente
- Hubo un gran cambio en mi forma de pensar
- En vez de código “inteligente”, empecé a escribir código fácil de leer
- Me enfoqué en diseñar pensando en escenarios de falla
- Dejé de escribir código para mí mismo y empecé a escribir código para los desarrolladores que vinieran después
- Después de eso, sus code reviews comenzaron a pasar sin problemas
- No fue que el manager cambiara, sino que yo había crecido
El impacto que dejó en mi estilo de liderazgo
- Cuando me convertí en engineering manager, recordé mucho esa experiencia
- No quería convertirme en un líder que la gente odiara, pero tampoco en uno que solo fuera amable
- Fui definiendo mi estilo de esta manera
- Doy feedback directo con contexto
- Enfatizo el pensamiento sistémico
- Mantengo estándares altos, pero doy feedback humano
- Los engineers quieren sentirse desafiados, pero no ignorados ni menospreciados
Cuándo hace falta un manager tajante
- En el liderazgo se mezclan el ego, los deadlines y la presión, y eso genera confusión
- Un manager tajante despeja esa confusión al hacer que
- pienses en escalabilidad, no solo en la funcionalidad
- escribas código mantenible en vez de código ingenioso
- te prepares de antemano para fallas y casos excepcionales
- Le da más importancia a la capacidad de supervivencia del código que a las emociones
Cómo sobrevivir y crecer bajo un manager tajante
- Si estás bajo un líder agobiante, puedes manejarlo así
- No lo tomes como un ataque personal: el feedback es sobre el código
- Después del feedback, pregunta “¿por qué?”: la mayoría de los líderes tajantes respetan la curiosidad
- Piensa tú primero en los puntos de falla: tienes que empezar a pensar como tu manager
- Si eres líder, deberías poner en práctica lo siguiente
- Establece estándares altos, pero explica por qué importan
- Sé específico en vez de dar feedback ambiguo
- Celebra el crecimiento más que el éxito: si un desarrollador detectó un problema antes que el manager, reconócelo
El mejor regalo que me dio un Pull Request rechazado
- Al principio me hirió el orgullo, pero mirando atrás, ese PR rechazado fue la mejor oportunidad de mi vida
- Fue el punto de partida para dejar de ver la programación como un proyecto personal y empezar a verla como la construcción de sistemas
- Un manager tajante no te hace sentir bien, pero te hace crecer como desarrollador
- El verdadero crecimiento no empieza cuando aprueban tu PR, sino cuando lo rechazan
22 comentarios
Si hay un gerente directo que no considera las emociones y otro amable que mantiene una buena relación, ¿qué tipo de gerente puede impulsar el crecimiento de los integrantes del equipo a través del feedback? Al leer el texto anterior me surgió esa duda.
Yo creo que es un juego de probabilidades. En cualquier lugar hay personas que logran crecer incluso superando probabilidades terribles. Creo que un gerente, dejando de lado a esas personas, debe esforzarse por aumentar la probabilidad general. Pienso que un gerente que actúa convencido de que su actitud, a su manera, eleva esa probabilidad merece respeto. Siempre que no se limite a mantener la forma en que ha venido haciendo las cosas solo porque sí.
Creo que este tipo de retroalimentación, dependiendo de la personalidad, de la cultura y de las diferencias individuales, puede hacerte sentir mal o incluso enojarte al escucharla. Pero, en principio, parece mejor abordarla pensando que "esa persona no me está molestando a propósito", tanto a nivel mental como desde la perspectiva del crecimiento. Si te toca una situación así, creo que podrías recordar este texto y pensar: "¿Y si este manager también...?". Es un buen texto.
Se habla mucho de ser
kind and direct, pero en realidad es mucho más difícil serdirectque serkind.Un líder que no puede transmitirles a sus seguidores el contexto que deben seguir, aunque no les dé el panorama completo, no tiene valor.
Parece un texto escrito por un seguidor excepcional que atribuye a otros sus propias capacidades sobresalientes.
Si un líder no transmite el contexto, entonces ese líder realmente no hace falta.
Hay que reemplazarlo urgentemente
Que algo suene bien no significa que sea algo bueno. Yo también creo que la revisión de código que solo decía dos palabras, "Nasty Code", fue la que más me ayudó en la vida.
No todos los desarrolladores son iguales.
He estado pensando qué significa eso de la "mentalidad sistémica", y en el contexto del texto me da la impresión de que se refiere a una forma de pensar desde la perspectiva del funcionamiento de una aplicación. Aun así, creo que de verdad es una perspectiva muy importante.
Puedo identificarme bastante, porque he visto cómo por querer llevar todo “en buena onda” la base de código termina hecha un desastre. De verdad es enorme la importancia de la capacidad de un manager.
Estoy de acuerdo.
La implicación del texto parece ser menos que ese manager haya sido excelente y más bien que la propia persona lo hizo bien. (¿No será que el autor es del tipo de persona que crece sin importar qué tipo de feedback reciba?)
Recuerdo haber visto un estudio que decía que, cuando se recibe feedback negativo (sin suficiente contexto), es más probable que la conducta cambie en sentido contrario a lo esperado.
Hay que entender que el feedback sobre tu trabajo no es un ataque personal.
Habría sido mejor si el manager hubiera sido una mejor persona, pero la empresa no es la escuela... porque somos profesionales... tenemos que aprender por nuestra cuenta a lidiar con el feedback.
También hace falta el valor de decir que no sabes algo cuando no lo sabes.
Parece que usted tiene una perspectiva bastante distinta a la mía. Quizás porque mi experiencia profesional aún es corta, he visto muchas veces que la retroalimentación poco clara o la retroalimentación con referencias ambiguas termina produciendo más bien el efecto contrario...
La ortografía está incorrecta.
"Debe escribir
비난이 아닌것을 깨닳아야합니다.como비난이 아닌 것을 깨달아야 합니다".Aunque sabrá que no es una crítica personal, creo que en cuanto vio mi observación se habrá enojado. Algunos lo llaman una distinción sin importancia, pero al final las personas sí tendemos a percibir de manera distinta cosas que parecen equivalentes.
pd. Yo tampoco me había dado cuenta de su error ortográfico, pero fue recién cuando lo pasé por el corrector para buscar un ejemplo que encontré lo que estaba mal escrito.
Si alguien te corrige un error de ortografía, basta con decir “gracias, no lo sabía”; no me parece que sea motivo para enojarse. Creo que pensar que los demás sentirán lo mismo que uno sintió es una generalización peligrosa. Y además, no es "aceptarlo separado", sino "aceptarlo como una sola palabra".
Creo que ser profesional también significa poder resolver incluso situaciones estresantes.
No intento justificar que te hagan pasar estrés. Cuando trabajas de manera profesional, también habrá cosas que te enojen, pero creo que resolverlas con inteligencia también es parte de ser profesional.
No soy un experto en ortografía. Y la comunidad tampoco es una empresa.
Realmente estoy de acuerdo con el comentario. Creo que fue por la gran capacidad y la actitud de quien lo recibió. Pienso que ese gerente tenía una filosofía clara, pero no sabía cómo abordar bien la forma de transmitirla al equipo.
Aunque te lo lancen de cualquier manera, lo recibes y lo entiendes perfecto... jaja
Es un texto realmente bueno. Creo que debo seguir viéndolo tanto antes como después de abrir un PR.
Parece que, para que no se convierta en un ataque personal, hay que haber construido bien la relación. (Especialmente en el contexto de la sociedad coreana)
Personalmente, procuro tener cuidado con el uso del sujeto. Lo que está sobreingenierizado es "este código", no que "la otra persona" esté equivocada.
Me recuerda al artículo ¿Qué demonios está pasando dentro de la cabeza de un experto?. Cuando recibes revisiones como “Esto es over-engineering. Es complejo. Refactorízalo”, o “Esto es vulnerable. ¿Qué pasa bajo carga? ¿Cuál es el plan de rollback?”, también puede ser buena idea preguntar por qué lo pensaron así, qué problemas prevén y en qué dirección de mejora están pensando. (Más que decir que el autor no lo hizo, lo digo porque me hace pensar en cómo se podría haber obtenido más valor en una situación así).
Muy buen texto...