Querer tener razón en el lugar de trabajo, y más allá, puede en realidad frenar el progreso, afirma este director de ingeniería.
Discutir un punto con el único propósito de tener razón puede ser un desperdicio de energía.
La corrección está en la mecánica, afirma, mientras que la eficacia está en los resultados.
En los desacuerdos, es importante ponerse de acuerdo sobre el problema, para entender qué se espera que haga la solución.
Mi pareja y yo tuvimos una mudanza infernal hace poco. Tuvimos suerte en que nuestros propietarios son personas amables y razonables, y mala suerte en que eran bastante desorganizados y no habían hecho todo lo necesario, como encargar los muebles y limpiar a fondo después del inquilino anterior.
Así que, mientras esto se desarrollaba, viviendo en un hotel, en un país nuevo (para mí), intentando compaginar su nuevo trabajo, mi trabajo actual y el caos absoluto de todo, nuestras diferencias empezaron a manifestarse.
Mi pareja, ingeniero de software, dijo «deberían hacer estas cosas». Yo, director de ingeniería, empecé a desarrollar una estrategia de mitigación de riesgos.
Por desgracia, como no llegamos a un acuerdo a nivel estratégico, mi estrategia de mitigación de riesgos se aplicó solo en parte y, cuando por fin pudimos instalarnos, pasé una semana sintiendo cómo me asfixiaba lentamente la energía residual de los gatos.
Ahora mi pareja y yo estamos bien. Y probablemente no volveremos a pasar por algo así pronto, ya que es poco probable que hagamos una mudanza internacional más de una vez cada un par de años. Pero veo dinámicas similares en el trabajo todos los días. En concreto, veo a ingenieros de software que disfrutan teniendo razón, y les pregunto: «¿Quiere tener razón? ¿O quiere ser eficaz?».
Y de vez en cuando me enredo en una discusión y me hago la misma pregunta.
Tener razón frente a ser eficaz
Es comprensible querer tener razón, sobre todo en cosas como la ingeniería de software; nuestra «corrección» es la forma en que hacemos el trabajo. Tomamos un problema, lo descomponemos, lo implementamos y lo entregamos. Algunas personas llevan esto demasiado lejos. Dicen «en mi máquina funciona» o «el problema está entre el teclado y la silla», pero incluso los menos molestos encuentran consuelo en la concreción y medibilidad de su trabajo. Pasa la prueba. Mejora las métricas. Es correcto.
Inherentemente, a medida que escalamos, empezamos a trabajar con más personas, y cuando seguimos buscando esa corrección definitiva, podemos perder de vista el objetivo general. Si está dirigiendo un proyecto que requiere que A y B se entreguen para que funcione, y uno de ellos no se entrega, pues su proyecto también ha fracasado. Y puede atribuir razonablemente ese problema al equipo que no entregó (teniendo razón). Pero si puede retroceder, ver el problema que se avecina y mitigar el riesgo, entonces puede ser eficaz.
El riesgo de tener razón es que optimiza las cosas equivocadas. La corrección está en la mecánica, la arquitectura, la cobertura de pruebas y en que todos hagan exactamente lo que se comprometieron a hacer. La eficacia está en los resultados.
Ponerse de acuerdo sobre el problema
A menudo, cuando detecto un desacuerdo entre tener razón y ser eficaz, lo que descubro es que las personas que quieren tener razón proponen una respuesta sin antes ponerse de acuerdo sobre lo que se supone que esa solución debe hacer.
Hace no mucho, uno de mis equipos discutía sobre si debía o no ejecutar el manual de incidentes (nuestros procedimientos estándar de respuesta de emergencia) cuando tenemos que realizar un hotfix (programación no planificada para corregir un error en un sistema en funcionamiento). Parece un punto de proceso esotérico; ¿cómo puede importar tanto? Pero la gente se estaba atrincherando mucho. Sin embargo, una vez que la conversación giró en torno al problema, medido con datos (es decir, cuántos hotfixes habíamos hecho recientemente), el equipo resolvió rápidamente tanto el desacuerdo como el problema.
Cuando considere que una conversación no es constructiva, intente preguntar: «¿Qué problema intentamos resolver aquí? ¿Cómo se manifiesta? ¿Qué impacto tiene?». Si está intentando implantar un cambio de proceso, primero aclare bien qué intenta resolver y convenza al equipo de eso.
Es agradable ser la persona que propone la solución y arregla las cosas, pero adoptar la mentalidad de la eficacia significa dejar de necesitar ser quien arregla las cosas y, en cambio, asumir el papel de facilitador que hace avanzar las cosas. Si consigue que el equipo se ponga de acuerdo sobre el problema y luego alguien más propone la solución que usted tenía en mente, eso es un gran logro. Significa que la solución nunca fue el problema; el problema era la falta de comprensión del problema.
Decidir si invertir su energía en discutir o no
Hay un gran cómic de XKCD sobre no poder levantarse de su escritorio porque «alguien está equivocado en internet», pero tanto en internet como en el trabajo, puede permitir que las personas se equivoquen, especialmente si eso no le afecta realmente.
Si alguien cree que necesita ponerse sus calcetines de la suerte el día del lanzamiento, o que las reuniones 1:1 nunca deben celebrarse en un día cercano a la luna llena, eso puede parecer bastante extraño, pero si esas ideas no afectan realmente a nadie, ¿por qué preocuparse?
En la escala de problemas reales, los desacuerdos sobre estilo (a alguien le gusta el azul, a otro le gusta el verde, dos espacios después de un punto o uno) son simplemente… desacuerdos de estilo. Dar retroalimentación y olvidarlo. Citar una guía de estilo. Exponer sus preferencias y seguir adelante.
Hace mucho tiempo, presencié una discusión de 100 mensajes en un hilo de correo electrónico sobre si las condicionales de código debían ser 'var == const' o 'const == var'. No podía creer el tiempo y la energía que se invirtieron en ese hilo, pero la persona que lo inició había disfrutado de la discusión, hasta el final, cuando alguien intervino para decir lo que yo había estado pensando todo el tiempo: que tanto pensamiento dedicado a algo tan menor les hacía preguntarse qué otras cosas no se estaban pensando como consecuencia.
Algunas personas disfrutan genuinamente discutiendo. Pero está bien si usted no. No hay ninguna obligación de participar en debates insignificantes sobre cosas que el compilador verifica de todos modos. De hecho, si no le gusta discutir, hay todavía más motivos para no hacerlo. Reserve esa energía para las cosas que realmente importan.
Cuando acompaño a alguien (o a mí mismo) para decidir si quiere discutir sobre algo, pregunto:
¿Por qué le importa esto?
¿Cómo afecta a su eficacia?
¿Qué lo convertiría en un problema?
Estas preguntas nos ayudan a descubrir el problema real (o si existe) y nos permiten llegar a la conversación que queremos mantener como resultado.
Si algo afecta significativamente a su eficacia, tiene sentido luchar con firmeza por ello. Si su mayor problema es la contratación, y un cambio concreto va a dificultar significativamente la contratación, entonces su trabajo se va a complicar considerablemente, y eso es algo que debe explicar y frente a lo que debe oponerse. Si su entrega general es bastante buena, pero le preocupa que este cambio ralentice un poco la entrega mientras las personas se acostumbran, probablemente sea manejable.
Cuando preguntamos «¿Qué lo convertiría en un problema?», se articulan los efectos de segundo orden que nos preocupan, porque a menudo el desacuerdo no trata sobre la decisión actual, sino sobre el impacto en decisiones futuras si se toma el mismo camino. Quizá una contratación de alto perfil recibió una compensación fuera de banda. ¿El problema es esa contratación concreta y ese salario concreto? ¿Es ahí donde quiere discutir? ¿O el problema es que, si esto ocurriera repetidamente, anularía por completo el sistema de bandas que tiene y dejaría a sus ingenieros actuales mal pagados? Quizá el verdadero argumento es que debería activarse una revisión salarial completa si esto vuelve a ser necesario, y probablemente será más fácil que las personas acepten eso, frente a convencerlas de sacrificar a alguien que claramente quieren y consideran excepcional de algún modo.
Ya sea que discuta por el largo plazo o por el momento presente, recuerde: hacer que los desacuerdos sean más breves y constructivos puede ser igual de impactante que llegar al resultado que espera crear.
Discrepar y comprometerse
Durante una reorganización en un trabajo anterior, el líder de un grupo afectado se marchó a otro equipo. El arquitecto de la reorganización se molestó por ello y lo planteó como si el líder no estuviera dispuesto a «discrepar y comprometerse». Alguien señaló que «discrepar» y «comprometerse» son, en realidad, dos cosas separadas. Si el líder no podía comprometerse, tenía sentido que pasara a otro equipo.
Cambió por completo la forma en que pienso sobre el concepto de discrepar y comprometerse. El desacuerdo puede ser una conversación continua; podemos hacer hincapié en distintos aspectos según el porqué y el qué de nuestra discrepancia. Si discrepamos vehementemente, debemos pensar deliberadamente en lo que estamos y no estamos dispuestos a respaldar. Al desglosar conscientemente nuestro desacuerdo y ser juiciosos sobre las discusiones en las que participamos, es más probable que sepamos distinguir entre ambas cosas.
En mi último trabajo, un día mis colegas y yo tuvimos una larga discusión sobre si incorporar un sistema de niveles de ingeniería para definir la progresión profesional. Había buenas razones para hacerlo; puede ayudar a dar a las personas una sensación de crecimiento y reconocimiento, por eso es un estándar de la industria. Mi opinión era que no sería una panacea, sobre todo en esa organización (donde no estaría respaldado por la compensación ni vinculado a ella), y dudaba de que fuera un beneficio neto en general, porque poner en marcha un proceso de promoción requiere mucho tiempo, y no solo se trata de promover a personas, también hay que comunicar a otras que no han sido promovidas. En fin, esta discusión se prolongó hasta que dije: «Bueno, yo no seré quien lo haga». Y entonces terminó. No sé si esperaban que yo lo hiciera o si eso dejó claro que tampoco nadie más estaba dispuesto a hacerlo.
«No voy a ser yo quien haga esto» es algo que utilizaría con extrema selectividad, pero esa experiencia sí aclaró hasta cierto punto el poder que tenía. Estar dispuesto a comprometerse a usar algo no es lo mismo que comprometerse a hacer algo.
Tras trabajar en un lugar donde se daba la bienvenida a los nuevos empleados con «bienvenido al caos», para mantener mi equilibrio, pienso en que las cosas deben estar lo bastante bien como para permitirme ser eficaz. No todo tiene que ser perfecto. Solo necesita ser lo suficientemente bueno para que podamos hacer las cosas juntos.
