Desarrollo Impulsado por la Empatía

Entonces, hola a todos. Hoy voy a hablar sobre el desarrollo impulsado por la empatía. Quizás este es el tema del que no se habla mucho y por eso estoy aquí hoy, construyendo un software con un toque humano y cómo puedes aplicarlo. ¿Cómo puedes aplicar la empatía como desarrollador o tal vez en tu proceso de desarrollo? Entonces, tal vez vamos a ver eso.

Pero antes de eso, permíteme presentarme. Soy Anjula Dubey y soy Líder de Entrega Técnica en Vanguard Europe. Vanguard es una firma de inversión. Solo para tu conocimiento, es una empresa de EE.UU. También soy organizadora en React India y JSConf India. En Twitter, puedes encontrarme como Manjula underscore Dubey. Entonces, si quieres hacerme algunas preguntas después de mi charla, también puedes contactarme en Twitter.

Genial. Antes de continuar, rápidamente, puedes levantar la mano. ¿Por qué estás aquí? ¿Quizás para aprender empatía? Supongo que todos nosotros sabemos de eso. Sí. Puedes buscarlo en Google y lo sabrías. ¿Estás aquí para aplicar la empatía a tus equipos de desarrollo? ¿Sí? Vale. ¿Algún líder técnico aquí? ¿Líderes técnicos? ¿Líderes de equipo? Quizás hoy haya muchas ideas útiles que puedes recoger y aplicar a tu equipo.

Entonces, solo una definición simple, por supuesto. Todos nosotros sabemos lo que es la empatía. Es la conciencia de los sentimientos de los demás. Quiero decir, todos nosotros lo sabemos, muy simple. Pero, ¿cómo lo aplicamos? Entonces, la definición dice que te pones en el lugar de otra persona, ¿verdad? Y para comprender sus emociones, perspectivas, experiencias, ¿y cómo respondes con sensibilidad y compasión? Pero, ¿realmente significa literalmente ponerse los zapatos de otra persona? No, por supuesto que no, ¿verdad? ¿Qué significa? Bryn Brown dijo que deberías poder ver el mundo como lo ven los demás, o tal vez no ser demasiado crítico con tu desarrollador junior o un desarrollador senior, o tal vez entender los sentimientos de los demás. Veremos eso en nuestras próximas diapositivas.

Entonces, la definición de desarrollo impulsado por la empatía significa que te enfocas en el comportamiento humano en el proceso de desarrollo de software. Y eso te ayudará a fomentar la confianza, la transparencia y también a construir software robusto, ¿verdad? Y cómo lo aplicas en tu proceso de desarrollo, lo veremos más adelante.

Entonces, como se dijo, la empatía también es para los ingenieros, ¿verdad? ¿Estás de acuerdo conmigo? ¿Sí? ¿Cuántos de ustedes han lidiado con código heredado aquí? Vamos. ¿Sí? Quiero decir, yo también. Sí, comencé mi career como desarrollador, y todos nosotros pasamos por el código heredado.

Ahora, de nuevo, una pregunta. ¿Cuántos de ustedes vieron el código, se unieron a la empresa y pensaron, Dios mío, ¿quién es este idiota que ha escrito este código? Vamos, seamos honestos. ¿Sí? Quiero decir, eso literalmente es un comportamiento incorrecto. ¿Cómo estás aplicando la empatía aquí? Deberíamos dejar de hacer eso. Deberíamos dejar de culpar y avergonzar porque eso va en contra del principio de la empatía. ¿Verdad?

¿Qué deberías hacer en su lugar? Cambia la culpa a ella. Vamos, vamos. No sabes cómo y cuándo se escribió ese código en qué escenario. ¿Había un plazo estricto? Sabes, ese desarrollador escribió el código, pero ahora se ha ido. Y ahora estás aquí para mejorarlo, ¿verdad? Entonces, ¿por qué incluso, sabes, estás culpando a ese desarrollador? Comienza a pensar en cómo puedes mejorarlo. Eso te enfatiza como desarrollador para centrarte en la empatía. ¿Verdad?

Ahora, ¿con qué frecuencia, cuando haces una revisión de código, comienzas con una pregunta. ¿Por qué no lo hiciste? ¿Por qué lo hiciste? Seamos honestos. ¿No? Todos, está bien. Tenemos algunas manos levantadas. Creo que eso, de nuevo, es un comportamiento incorrecto. Podría herir a alguien porque alguien que es un desarrollador junior que acaba de unirse a la empresa, y tú estás como, ¿por qué nombraste esta variable? ¿O qué está haciendo este código aquí? La forma correcta de hacerlo sería, ¿podrías explicarme qué estás haciendo aquí? Eso es más no acusativo, pero es más objetivo. Así que deja de ser acusativo, deja de ser acusatorio en tus conversaciones, deja de hacer preguntas directas, que podrían herir a otros. Y estos son los pequeños detalles que puedes empezar a aplicar, ¿verdad? Como desarrollador. Quiero decir, no nos cuesta mucho esfuerzo. Es solo el tono. ¿Verdad?

Entonces, déjame darte algunas cosas que podríamos aplicar. Quiero decir, detén la crítica, enfócate más en lo que ese desarrollador podría hacer. Como comenzar con, podrías, sabes, eso enfatiza mucho. Tal vez también primero entender quién es el desarrollador. Tal vez estás escribiendo los comentarios en tus revisiones de código, porque eres más senior.

Pero sabes, el código está escrito por un junior. Así que también entiende la perspectiva de dónde viene antes de escribir tus comentarios. Así que sé más claro, como, ya sabes, articula tus comentarios muy claramente en las revisiones de código también.

Anima y reconoce, como, digamos que ves algo bueno, ¿verdad? Solo pon un comentario. Esa fue realmente una buena parte. Porque eso asegura que estás animando a ese desarrollador. ¿Verdad? Quiero decir, he visto en mis empresas anteriores, toda la solicitud de extracción se convirtió en un chat. ¿Verdad? Eran como 40 mensajes en la parte superior. Y sabes, luego el desarrollador se defiende. No hagas eso. Quiero decir, esto podría haber sido como si yo fuera un desarrollador, podría haber ido a esa persona, me hubiera sentado con esa persona. Y sabes, podría hacer eso. No hay necesidad de hacer como 50 mensajes en esa solicitud de extracción. No estás siendo empático allí.

Así que estas son algunas de las directrices. Quiero decir, por supuesto, no voy a ir y leer todas ellas. Compartiré la diapositiva más tarde y puedes leerla. Pero te da una idea de cómo puedes ser empático y aplicar estos, ya sabes, mientras te comunicas en las solicitudes de extracción. Estas son cosas muy pequeñas. Y tú como humano no sabes cómo puedes herir a otros. Así que tal vez, ya sabes, antes de que incluso escribas, asegúrate de ser más empático. Así que la empatía no es solo para los revisores de código aquí. Tú como desarrollador, porque estás escribiendo el código, también necesitas ser empático. ¿Verdad? Porque alguien más, como Armin dijo correctamente en su charla anterior, code quality, ¿verdad? Si escribes con una actitud de no importarte quién va a ser el próximo desarrollador en la empresa, simplemente vas a escribir, ¿verdad? Pero si te importa, vale, esto es algo difícil. Déjame tal vez poner algunos comentarios. Déjame tal vez nombrar la variable, ya sabes, de una manera que el otro desarrollador, cuando venga y vea el código, pueda leer o entender qué está pasando. Así que también es parte de nosotros los que estamos escribiendo el código. Lo que significa que si ves alguna parte en tu código, que es más desafiante, tal vez pon un comentario, ¿verdad? Algunos comentarios extra también para los futuros líderes para que entiendan qué está pasando en esa parte. Muy, muy importante. Como desarrolladores, asegúrate de que esté completamente probado antes de enviar tus PRs.

Y no menciones eso, oh, funciona en mi máquina. No lo sé. Entonces, ya sabes, ten mucho cuidado. ¿Cuántos de ustedes aquí han documentado proactivamente algo que era un poco complejo para ustedes? Sigue haciendo eso. Quiero decir, puede que no se te asigne una tarea por separado, pero hazlo porque, ya sabes, estás siendo empático en ese comportamiento porque, ya sabes, esto es un poco complejo. Déjame documentarlo. Ahora, al documentar, ¿qué estás haciendo? Estás facilitando las cosas para tus futuros líderes, ¿verdad? Estás pensando en los futuros desarrolladores. Así que empieza a hacer eso. Equilibrando los requisitos técnicos con la empatía. A veces puede haber, ya sabes, algunos requisitos que pueden ir en contra de la empatía. Así que inicia un buen debate sobre eso. Tal vez sea con tus gerentes de producto, diseñadores. Deberías hacer eso. Mensajes de commit, solicitudes de extracción, nombrando tus archivos, nombrando tus pruebas. ¿Cuántos de ustedes piensan, quiero decir, simplemente ponen algo que les viene a la mente? ¿No? Quiero decir, un poco pensado, ¿verdad? Y eso realmente ayuda porque estas son las pequeñas cosas que empiezas a aplicar y luego puede que sin querer, ni siquiera estás pensando en ello, pero ya sabes, tal vez estás haciendo algo mal. Pero cuando empiezas a dar demasiada importancia o un poco de importancia, empiezas a crear ese efecto, ¿verdad? Así que todo eso es fundamentalmente sobre la comunicación. Y en todos estos aspectos, básicamente lo que estamos tratando de decir es comunicar el tono, ¿verdad? Así es como ves que los artefactos de comunicación son uno de los artefactos importantes en la fase de desarrollo. Estas son algunas de las cosas, verbales, no verbales, tal vez escribir correos electrónicos, ¿verdad? ¿Verdad? Sé un poco suave, no demasiado duro, incluso en una solicitud de extracción o tal vez un junior. Así que muchas cosas comprenden esto. Esto te da una imagen más grande.

Ahora, ¿cómo te beneficia a ti, como a mí o a ti como desarrollador? Por supuesto, crecimiento personal, comunicación efectiva, reducción del estrés, ambiente positivo en el equipo, buen performance. Por supuesto, cuando estás lidiando con buena code quality, estás teniendo esa colaboración entre revisiones de código. Bueno de una buena manera. Ya sabes, todo eso te beneficia.

¿Cómo ayuda como equipo? Como equipo, por supuesto, hay alta code quality, comunicación efectiva. Hay más satisfacción laboral. Hay creatividad innovadora. Muchas cosas vienen. Así que estos son los pequeños, pequeños detalles, pero aún así suma la forma en que te comunicas dentro de tu equipo. Y por supuesto, para los organizadores, las organizaciones, es más como, ya sabes, construir esa cultura positiva, imagen de marca, mejor tasa de atención. Esto es algo muy importante. Sí. Más líderes inspiradores. Y lo más importante, estás construyendo un producto o un software que a los usuarios les encanta usar. Correcto. Entonces, por supuesto, estás haciendo todo ese trabajo bajo una cáscara de nuez, siendo un buen desarrollador, siendo un desarrollador empático, pero eso está agregando valor. Correcto.

Entonces, ¿por qué es importante? Como, en general, ya sabes, Andrea Gollett, puedes buscarla en Google, pero ella aboga mucho por esto en su propia empresa. Ella da charlas. ¿Por qué es importante? Pasaremos por el desarrollo impulsado por la responsabilidad, DDD. Sabemos acerca de DDD. Ves la última referencia, desarrollo impulsado por la empatía. ¿Por qué es importante? Te importa, estás considerando, estás conectando con tu gente. Y eso es realmente importante para que funcione en una organización o un equipo. Correcto. Esa es la base. Esa es la fundación. Pero todo tiene un lado negativo. Correcto.

¿Cómo puede perjudicarte? Correcto. ¿Cómo puede ser perjudicial la empatía? Demasiada empatía es realmente mala. Como, por ejemplo, tienes un desarrollador, digamos, ¿verdad? Y estás de alguna manera forzando tu experiencia en él. Eso no es correcto. Porque estás forzando a esa persona y poniéndola en una situación donde él o ella no se siente realmente cómodo. Correcto. Lo que significa que no eres responsable de cómo se sienten otras personas. Así que aplica la empatía de una manera efectiva. Correcto. Fomenta la empatía no reactiva, lo que significa que puedes preocuparte por esa persona. Puedes ayudar. En su mayoría, esa persona ni siquiera necesita la ayuda. La mayor parte del tiempo, esa persona ni siquiera necesita que sientas su dolor. Sabes, solo necesitan alguna respuesta compasiva o tu ayuda. Como se dijo correctamente, aplícala de una manera más efectiva. Por lo tanto, la empatía efectiva es una habilidad que va más allá de entender las emociones de los demás. Implica una respuesta considerada y compasiva.

Bueno, supongo que todos pueden leer aquí lo que está escrito. Imagina un escenario donde uno de tus miembros del equipo, llamémosle Chris aquí, está trabajando en una tarea técnica compleja. Y Chris es relativamente nuevo en esta pila de tecnología técnica, de acuerdo. Acaba de llegar, acaba de unirse, tal vez la pila de tecnología es Kotlin. Y tiene algunos problemas desafiantes y está tratando de implementarlo. ¿Qué piensas? Como desarrollador, ¿qué harías para hacer que esta persona se sienta cómoda?

Claro, sí. Entonces, tal vez acercándote a esa persona como líder, tal vez comprobando proactivamente, si está bien, o necesitas alguna ayuda, muy activamente. ¿Está bien, o necesitas alguna ayuda? Escucha muy activa, porque eso realmente importa, es muy nuevo. Necesitas mantener un control constante sobre él y ser un oyente activo, ¿está enfrentando problemas, qué necesita? ¿Necesita algunos recursos para sentirse cómodo? ¿Necesita hacer programación en pareja? Así que esto es algo que no solo depende de los líderes, sino también de los compañeros, ¿verdad? Entonces sí.

Ahora, de nuevo, pongamos un ejemplo de que un equipo está trabajando en un proyecto crítico. Y hay alguien que es técnicamente brillante. Y ahora tiene un plazo para terminar este proyecto. Y también te aparecerías a él. Pero tienes un poco menos de conocimiento con ese proyecto. Pero también estás en su equipo, ¿cómo lo harías? ¿Cómo te asegurarías de que Alex no se sienta abrumado y estresado al mismo tiempo?

Bueno, déjame ver. Entonces, tal vez aquí, lo que podemos hacer es preguntar a Alex con preguntas abiertas, preguntarle, ¿Alex, qué sientes? ¿Deberíamos cambiar un poco el plazo? O tal vez deberíamos acercarnos al gerente de producto. Así que tú, como equipo, estás siendo un poco empático. Tienes esa empatía dentro de ti y le haces estas preguntas, ¿verdad? Aunque sean compañeros, no son directamente responsables de entregar este proyecto. Pero sabes cómo hacer que la otra persona se sienta más cómoda. Así que estas son algunas de las preguntas que, por supuesto, podrías tener en tu equipo también, alguien está luchando, asegúrate de que estás pasando por estas preguntas, o tal vez sabes, haciéndolos sentir más cómodos compartiendo tu propia experiencia de que, estuve en una situación determinada, pero asegurándote de no eclipsar tus sentimientos con tus experiencias. Así que ya hemos pasado por muchas cosas, al final, ¿qué estamos haciendo aquí? Estamos construyendo esos equipos empáticos, ¿verdad? Y esto es realmente, realmente importante. Y este es uno de los temas de los que nadie realmente habla. Pero al final, si esto no es realmente sólido en tu equipo, no puedes trabajar con los miembros de tu equipo, siempre habrá conflictos, siempre habrá estrés en el equipo. Nadie sería responsable. Y a nadie le importaría preguntarte, ¿cómo te sientes hoy? ¿Quieres que me ocupe de algo? Correcto. Así que eso es realmente importante. Así que no codificamos solo para construir nuestros productos. Recuerda esto. También codificamos para nuestros futuros humanos, ¿verdad? Eso es realmente importante. Así que esto es una de las cosas que siempre deberías tener como desarrollador, incluso mientras revisas, incluso mientras incorporas a un nuevo miembro, cualquier práctica o proceso que estés realizando.

Como organización, comienza a enfocarte más en tener masterclass de empatía. Como, si no está sucediendo en tu organización, regresa y diles, vamos a tener algunas masterclass o entrenamientos. Y aprendes una habilidad técnica importante, aunque no fue una charla técnica, pero trata la empatía como una de las habilidades técnicas. Y gracias.

Sí, creo que tenemos una primera pregunta, que en realidad podemos expandir un poco. Me gustaría ver más empatía de los entrevistadores. Creo que es un problema bastante interesante, porque el entrevistador también quiere algo de empatía del desarrollador que los recursos están limitados por el tiempo. Y en ese caso, ¿cómo podemos ser mejores entrevistadores? Pero, ¿cómo podemos asegurarnos también de que transferimos eso si no va a funcionar de una manera empática, pero no desperdiciamos el tiempo de cada uno. ¿Hay alguna solución? Creo que esta es realmente una buena pregunta. Y creo que todo proviene de la organización, cómo te importa realmente. Quiero decir, incluso como entrevistador, como, ya sabes, también soy entrevistado, todo se reduce a un aspecto que, ya sabes, cómo lo practicas, ¿verdad? Si no lo practicas en absoluto, por supuesto, no serás, ni siquiera te importará. Pero si lo practicas, y es realmente importante en tu organización sobre un equipo de alto rendimiento, como alguna organización, tal vez realmente no les importa. Todo lo que les importa es, ya sabes, construir un equipo de alto rendimiento, sin importar qué. Si estás hablando de practicar este año, ¿te refieres a simplemente practicar entrevistas como entrevistador internamente con los miembros de tu equipo? Sí, tal vez tener a alguien también como observador que estaba viendo cómo lo estás haciendo, tal vez lo estás haciendo mejor porque ya estás en la organización desde hace mucho tiempo, lo estás haciendo. Y también tienes un observador en tu entrevista que está viendo cómo lo estás haciendo. Así que creo que eso realmente ayuda. Bueno, tal vez preguntémosle rápidamente a la audiencia, como quién está haciendo una práctica de entrevista consciente con un enfoque en la empatía? Oh, una persona allí. Tenemos una persona allí. Así que tal vez el resto de ustedes puede llevarlo a sus empresas en el futuro. Porque, sí, esa es otra pregunta complicada, muy filosófica. ¿Cómo reaccionamos a situaciones no empáticas? Creo, quiero decir, va a haber situaciones no empáticas. No es un buen mundo. Por supuesto, hay lados buenos y malos. Hay personas buenas y malas. Algunas personas entienden, algunas personas no. Creo que es muy, como dije correctamente, que es muy importante para ti, incluso si estás en esa situación empática, tal vez solo baja y ve a esa persona más tarde y solo diles que esto es algo que me sentí mal y podrías haber mejorado. Porque dar feedback siempre ayuda y esa persona volvería y tal vez, ya sabes, reflexionaría sobre ello e intentaría aplicarlo. Así que creo que es realmente bueno volver y dar ese feedback más tarde. Bueno, y si hablamos de dar feedback, creo que todos todavía, como muchos de nosotros, estamos trabajando de forma remota, y algunas personas podrían usar la IA para escribir sus mensajes de texto. ¿Eso ayuda con la empatía? ¿Porque la IA se mantendrá neutral en su tono? ¿O es totalmente no empático porque está poniendo todo en una voz diferente? Creo que la empatía es todo acerca de ti, tu sentimiento.

Quiero decir, la IA no puede decidir. Por supuesto, te dará respuestas, pero es tu sentimiento. Y, sabes, alguien no puede decidir cómo te comportarías con alguien o el comportamiento de alguien o, sabes, hacia alguien más. Así que creo que es puramente eso lo que viene de dentro de un individuo. Y no confiaría en la IA, para ser honesto. Sí.

Tal vez podamos expandir un poco esta pregunta, porque también habrá diferencias de idioma donde muchas personas cuyo primer idioma no es el inglés, y luego necesitan empezar a comunicarse en inglés. Y simplemente, es mucho más difícil ser empático en otro idioma. ¿Tienes recomendaciones al respecto?

Claro. Creo que, quiero decir, en mi empresa, practicamos mucho. Quiero decir, tenemos una cultura diversa, personas que vienen de diferentes regiones de Asia, Europa, pero hacemos muchas actividades de construcción de equipos. Hacemos muchas masterclass de empatía juntos con nuestros Scrum Masters. Creo que es realmente importante tener, quiero decir, los idiomas, por supuesto, son una barrera, pero, sabes, todo no depende solo del idioma, ¿verdad? Podrías tener alguna construcción de equipo juntos o tal vez, sabes, algún tipo de masterclass o entrenamientos donde pones tus comentarios y, sabes, lo articulas juntos y ves cómo podrías mejorar. Así que creo que depende. Por supuesto, hay una barrera, pero puedes tener ciertas masterclass y entrenamientos que realmente ayudarían.

Absolutamente. ¿Y cómo diseñarías una masterclass para, por ejemplo, mejorar ser más empático en las solicitudes de extracción? Es una buena pregunta, creo. Así que en mi empresa, creo que llevo trabajando aquí casi cuatro años, construimos una completa documentation diseñada, sabes. Y estos fueron construidos por ingenieros iniciales, como cómo actuar cuando alguien está a bordo, tal vez, y, sabes, estás revisando una solicitud de extracción. El lenguaje a usar, por ejemplo, tal como mencioné que, sabes, en lugar de comenzar tus preguntas con por qué, sabes, tener esa práctica de ponerlo, ¿podrías por favor cambiarlo a esto? O tal vez, sabes, en lugar de preguntar eso, ¿por qué hiciste esto? Sabes, sé más cortés, ¿podrías por favor explicarme qué está haciendo esto? Así que creo que teníamos una práctica general documentation que nosotros como ingenieros la usamos. Vale. Y es realmente importante construirlo si eres más... ¿Debería haber documentation sobre cómo leer estos? Sí. Creo que hay algo llamado como comentarios convencionales para revisiones de código, ¿lo estás usando? No realmente. Creo que tenemos muchas experiencias diferentes en el equipo. Tenemos muchos juniors, tenemos demasiados seniors. Así que a veces se vuelve realmente difícil aplicar eso. Pero sí, quiero decir, es bueno aplicarlo. Sí. Y mientras hablamos de solicitudes de extracción, ¿son realmente el lugar más empático para dar feedback? ¿O podemos intentar dar eso antes en el proceso de desarrollo de código? Creo que cuanto antes, mejor.

Como dije, no lo conviertas en un chat, como no hagas una defensa de 40 líneas. Y luego, el desarrollador senior está escribiendo un comentario. Creo que la buena manera aquí que veo es que el desarrollador regrese al desarrollador que ha levantado la solicitud de extracción y se sienten juntos a revisar el código. Quiero decir, no querría que mi PR tuviera 100 comentarios. Eso sería horrible y tomaría mucho tiempo para arreglar.

Exactamente. Mencionaste como desarrolladores senior y desarrolladores junior. ¿Cuánto es como la empatía realmente un poco de crecimiento hacia otro rol? ¿Y cuánto debería ser como un requisito formal? Porque debo decir, realmente no leí la empatía como un punto de bala para, oh el próximo ingeniero de software de nivel, necesitas ese nivel de empatía. ¿Deberíamos introducir algo así? ¿Deberíamos luchar por algo así? Además, ¿cuáles son las diferentes expectativas de empatía en diferentes roles? Porque al final, todos somos humanos como empezaste. Y esperaría que todos mostráramos el mismo nivel de empatía, ojalá, y no necesariamente decir, no, eres un ingeniero de software senior, ahora necesitas ser más empático. Pero como... Sí, ya lo respondiste. Quiero decir, somos humanos diferentes, y tenemos diferentes experiencias. Pero la empatía no significa que sea directamente proporcional a tus años de experiencia o algo así. Creo que es en ambos sentidos, ¿verdad? Si un desarrollador junior es empático también, entonces obtendrás la respuesta positiva. Pero si algo comienza de una manera más negativa, por supuesto, la persona va a React de manera negativa. Pero ahora él tiene el control, porque es un poco senior, sabes, puede calmarse y tal vez volver más tarde y decirle a ese comportamiento que, está bien, sabes, podrías haberlo hecho un poco diferente. Así que, por supuesto, la experiencia ayuda, porque sabes, si tienes experiencia, sabes lo que está pasando, y puedes estar un poco más tranquilo en ese momento y volver y luego evaluar lo que realmente sucedió. Sí, eso es super perspicaz. Creo que podemos conectar las próximas dos preguntas aquí. ¿Cómo trabajas con ingenieros que no son receptivos a los comentarios? ¿Y cómo manejamos la empatía versus la responsabilidad? Entonces, tal vez, ¿qué hacemos si la empatía nos falla? Así que he trabajado con ingenieros así en mi equipo. Sí, donde las personas no son receptivas en absoluto. Se sienten muy superiores a sí mismos. Y creo que la mejor manera de lidiar con ellos es que escuches activamente lo que tienen. Porque si te conviertes en una persona que les está dando órdenes, nunca escucharán. Es más para ellos, sabes, para que escuchemos lo que realmente piensan y por qué están siendo tan negativos acerca de cualquiera de los comportamientos. Y luego reflexionar, como tú como gerente o tú como líder de equipo o líder técnico puedes volver a ellos y decirles, esto es lo que estás mostrando a tus juniors. Y esto no es realmente bueno. Porque si no escuchas activamente a ellos, se vuelven realmente agresivos. Así que tenemos como 10 segundos más. Tal vez una última pregunta. ¿Ser empático también significa que a veces necesitas no ser honesto o hay un conflicto? Creo que se trata de ser honesto. Se trata de ser confiable para que solo haya un espejo y aún puedas hablar. Sí. Muchas gracias por la discusión. Gracias. Si quieres hacer un seguimiento.