Más Allá De Las Tareas: Cultura De Equipo
Siempre digo que es mucho más importante ser buen/a compañero/a, que los conocimientos técnicos. Y esto es indispensable para tener una buena cultura de equipo.
Pero ¿qué significa ser buen/a compañero/a y tener una buena cultura de equipo?
No creo que sea que tengas que ser una persona súper divertida, que siempre te estés riendo, sonriendo, que luego vayan a tomarse algo, que se forme una amistad, que puedas contar si has tenido algún problema personal… No necesariamente. Yo creo que puedes ser buen/a compañero/a y no cumplir nada de esto.
“Los equipos son tareas y relaciones” dijo Jesús Carreras en un taller del manejo de la incertidumbre en el Product Fest y me gustó mucho. Si fuésemos solo tareas, seríamos como una máquina que trabaja, trabaja y trabaja hasta que se quema. Para las relaciones necesitamos pautar cómo vamos a trabajar, cómo nos organizamos, cómo nos comunicamos, cómo nos escuchamos. Nos tenemos que poner reglas y llegar a acuerdos, de los que hablaré más adelante.
Como en todo lo que escribo, aquí viene mi querido disclaimer: esto está escrito bajo mi experiencia, sobre lo que me gustaría continuar haciendo, mejorar y nunca más vivir en cualquier equipo donde esté trabajando. Si tú no estás de acuerdo, está bien <3
Escucha.
Toma en cuenta la voz de todas las personas. Independientemente de la experiencia y su seniority, toda persona que forma parte del equipo tiene derecho de formar parte del proceso de discutir, opinar y proponer ideas/soluciones sobre el producto. Si se proponen nuevas dinámicas/ejercicios/prácticas o un cambio en ellas, evalúa y no te cierres a ello porque “llevamos toda la vida haciéndolo así”. Está bien poner en duda lo que se lleva haciendo “toda la vida”.
Discusión de temas técnicos y no técnicos.
Aunque siempre hay diferentes roles dentro de los equipos, todos tienen el mismo derecho de tener la misma calidad de información.
Si en una reunión se va a dar una información importante que impacte en el desarrollo del producto y no pueden ir todas las personas, entonces luego la información relevante le tiene que llegar al resto. Se puede, por ejemplo, en modo de síntesis nombrar las opciones que se trataron y las razones y argumentos usados para decidir la opción final.
Toma de decisiones.
Hablar en privado y tomar decisiones técnicas dejando a una o más personas fuera de la discusión, no está bien. Les estás quitando la oportunidad de expresarse y ustedes se están quedando sin la posibilidad de conocer un muy buen punto de vista. Si no pueden estar presentes todas en ese proceso, se habla y se llega a un acuerdo. El acuerdo puede ser, efectivamente, que lo hablen los demás y luego te cuenten la conclusión, pero es algo que se tiene que hablar.
Silos de información.
Comparte conocimiento. No acapares información. Que tú seas el que sabe más algo o que seas el único que sabe hacer una cosa, eso no te hace el mejor. De hecho, eso es de mal desarrollador. El conocimiento hay que compartirlo y hacer que el resto del equipo sea igual de capaz de hacer lo mismo. Como bien dice Nico Patarino: “el conocimiento compartido no se divide, se multiplica”.
Tranquilos, de verdad que no pasa nada si los demás saben hacer lo mismo que tú, no temas porque los demás sepan más que tú.
Feedback.
No quiero ahondar mucho en esto porque es un tema complejo y existen formaciones, artículos, charlas, workshops sobre cómo dar ¡y recibir! feedback.
Pero me gustaría decir dos cosas:
-
Den feedback constantemente, tanto positivo como constructivo, que no se haga raro si un día te dan feedback y ya te asustas, porque como nunca te lo dan, piensas cualquier cosa.
-
No invaliden las emociones de los demás. Si alguien te dice que se ha sentido <EMOCIÓN> por algo que has dicho/hecho, acéptalo e intenta ser mejor. No le refutes, no invalides el cómo te está diciendo que se ha sentido. Esto puede llegar a perjudicar mucho las relaciones y la salud del equipo.
Nueva incorporación, nuevo equipo. Una baja, nuevo equipo.
Al entrar/irse una persona, el equipo cambia y debe haber una adaptación por ambos lados, no solo la nueva persona es la que se tiene que adaptar. Las dinámicas van a cambiar, hay nuevas ideas y nuevas maneras de trabajar y hay que estar abiertos a escucharlas y asumirlas si supone una mejora.
Y, como dije anteriormente, pongan en duda lo que se lleva haciendo mucho tiempo de una misma manera.
No le pongas un techo a los demás.
Si piensas que una persona del equipo no va a poder con una tarea y le dices “no se si vas a poder”, “es muy difícil para ti”, le estás poniendo un techo y transmitiendo inseguridad. Así no se aprende, somos personas adultas y debemos tener la libertad de hacer sin que nadie cuestione nuestra capacidad y, a la vez, tener la responsabilidad de pedir ayuda cuando lo necesiten.
Pero claro, tienes que ser una persona de fácil acceso a la que pedir ayuda no suponga una experiencia desagradable.
Solventar dudas/bloqueos.
Estar receptiva y transmitir que tu ayuda ante una duda o bloqueo es una vía de aprendizaje más, que no es una “tontería” preguntar y hacer sentir que no hay nada de malo en no saber algo y preguntarte.
Evita dar respuestas a cuenta gotas por slack. Normalmente cuando se pide ayuda es por un bloqueo y estar parada sin poder seguir porque vas respondiendo de manera escueta cada 2 horas, no se siente bien.
Yo pienso que, a menos que tengas la solución directa y sea algo simple que le puedes decir por escrito, lo mejor es hacer una llamada, permitir que te pongan en contexto mostrándote lo que está haciendo, el problema/bloqueo, todo lo que ha intentado y luego guiarle hacia donde tiene que ir.
Muchas veces tampoco sabes qué está pasando, eso está bueno expresarlo y así disminuir la sensación de “soy la única que no sabe esto” y ponerse mano a mano a debuggear.
Si estás ofreciendo ayuda/guiando y no te están entendiendo, igual no te estás sabiendo explicar y debes cambiar de estrategia para hacerte entender.
Nadie es tonto que no entiende, solo tenemos que adaptar nuestra manera de enseñar hacia los demás, porque todas aprendemos distinto, no puede funcionar una misma estrategia para todas.
Sobre cómo pedir ayuda ante bloqueos/dudas y cómo darla, tengo también algo escrito que, si les interesa, lo puedo publicar pronto ( y no es tan largo 🙂)
Algo muy muy importante para los perfiles más seniors y de mucha experiencia: ustedes también deben pedir ayuda al resto del equipo. Si al leer esto te pones a pensar cuándo fue la última vez que pediste ayuda y te cuesta recordarlo… eso no es nada bueno.
Onboarding.
Tener bien preparado un onboarding para cuando entra alguien nuevo dice mucho de tu equipo y es un buen punto de entrada.
Acompañar al inicio en todos los procesos de pedir accesos, permisos, repos, dar una explicación del proyecto, de la empresa, explicar agreements y plantear nuevos.
Hablen del lenguaje ubicuo pero a la vez también tenerlo documentado para que, luego con la base que le has contado, lo pueda seguir teniendo a la mano y volver a consultarlo (porque no se va a recordar de nada que le cuentes esos primeros días). Me parece mucho más personal que se sienten a explicarte a que te den un link con una documentación a que te lo leas por tu cuenta.
Dar oportunidad de bajarse el repo y revisarlo por su cuenta con calma y, a la vez, pautar X tiempo al día para comenzar trabajando en pair programming aprovechando de enseñar el código y parte del producto.
Asumir que no sabe nada.
Cuando estás en una situación donde tienes que explicar y vas muy al detalle, hasta cosas muy básicas o a cada rato preguntas “¿sabes lo que es X?”; puede sentirse como “este piensa que no se nada”. No creo que lo hagas intencionalmente, solo que no sabes hasta dónde tienes que llegar explicando y prefieres dar exceso de información que quedarte corto. Pero esto se soluciona fácil:
Propicia un ambiente de confianza donde la otra persona te pueda preguntar libremente cuando algo no entiende/no conoce. Se puede pautar previamente: “tú ve explicándome y si hay algo que no se, yo te voy a interrumpir para preguntarte”.
Evita el paternalismo y la condescendencia.
Esto normalmente se ve hacia mujeres y personas juniors. Por favor, no lo hagas más. Trata a todas las personas por igual, no des tratos especiales.
Agradece, reconoce.
No esperes a solo dar kudos a alguien de manera muy general en las retros. Si alguien te ayuda en algo, te enseña algo, hizo una buena sesión de pair programming contigo, tomó una buena decisión: reconoce y agradécele el buen trabajo.
Piensa la última vez que lo has hecho a cada compañero/a. Mira si hay una persona a la que nunca se lo has dicho, o si solo lo haces a la misma persona… o si nunca lo has hecho.
Pair programming.
Sobre esto también tengo algo escrito desde hace meses pero es demasiado largo y está escrito de manera visceral, por lo que aún no está para publicar, pero lo estará.
Un resumen para no dejar este punto vacío es que sepas que la idea del pair programming es que las dos personas se sientan empoderadas en contribuir de igual manera en la conversación, pero claro, el tema está en si te sientes empoderada para contribuir de la misma manera jaja. Y es que en el pair programming siempre hay alguna dinámica de poder y el primer paso es aceptarlo. Aceptar que existen y luego identificar de qué tipo (de jerarquía, de género, de raza, de background, etc) y en qué posición estás dentro de esa dinámica. Una vez que sepas esto, seas consciente y sepas que hay cosas de las que estar pendiente y trabajar, todo debería mejorar. Pero si ni lo aceptas, va a ser difícil y seguirás perpetuando esta dinámica.
Si mientras publico esto les interesa leer sobre este tema, lean a Sarah Mei y miren la charla de Vanessa Medina.
Code reviews.
No personalices. Los comentarios son hacia y sobre el código, no a la persona que ha escrito ese código. Ejemplo: en vez de “¿Por qué usaste esto aquí?” mejor “el usar esto está añadiendo complejidad…”.
El otro día tuvimos un training en el trabajo sobre CR y Álvaro Pernas dijo algo muy bonito que estaría bien tenerlo presente siempre, no solo mientras revisamos código: “las personas aprenden por el reforzamiento de lo que están haciendo bien y no solo de lo que podrían hacer mejor”. Claro que hay que corregir y evitar, de nuevo, la condescendencia, el paternalismo o el colegueo, no hay que ser “permisivo”; no pasa nada si nos llevamos 30 comentarios por MR, son 30 oportunidades de aprender. Pero tómense el tiempo también de reconocer lo bueno, de reconocer cuando has aprendido algo que no sabías gracias al código de la otra persona, de hacerle saber que te gustó mucho cómo ha hecho algo, etc.
Agreements.
Definir acuerdos es imprescindible y es necesario revisarlos y modificarlos de vez en cuando y, como dije anteriormente, cuando hay una nueva incorporación y/o baja.
Pueden ser acuerdos sobre horarios, maneras de trabajar, comunicación, merge requests, code reviews, convenciones, procedimientos… ¡lo que quieran! Y dejarlo documentado.
Team building.
Aunque el trabajo no va de hacer amistades, considero que está bien tomarse ciertos momentos para hacer otras cosas juntas que refuercen el trabajo en equipo fuera del ambiente laboral.
Estas actividades funcionan para dejar en evidencia los roles y las dinámicas de poder que están establecidas dentro del equipo y que se perpetúan incluso en actividades ajenas al trabajo.
Y, por el contrario, también pueden servir para descubrir una faceta desconocida de alguna persona del equipo que no se ha podido dejar ver en el trabajo por alguna razón.
También creo que es recomendable que de vez en cuando se hable de cosas que no sean el software. Y no necesariamente contar tu vida, tus intimidades. Es poder intentar tener una comunicación cómoda sobre otro tema y así poder ver, por ejemplo, si la persona que es muy callada en reuniones de trabajo, lo es siempre o, por el contrario, en otro tipo de conversaciones es bastante habladora. Esto te da indicativos de que algo pasa y habría que revisar qué dinámicas están establecidas que no permiten que esta persona se exprese.
O también puedes ver si se replican las mismas dinámicas, el típico que no deja hablar a los demás, el que no escucha a los demás, por ejemplo.
Yo soy la primera que ha estado en equipos donde no quiero tener que hacer nada con ellos que no sea solo trabajo, que no me quedan ganas de hablar de, yo que sé, películas, que no me quedan ganas de hacer ninguna actividad de team building. Lo entiendo perfectamente, trabajo es trabajo y va separado de tu vida. Pero creo que podrían ser actividades sanas que mejoren la comunicación y las relaciones en el equipo para poder tener un entorno mejor a la hora de trabajar. Eso sí, SIEMPRE en horario laboral.
Los retreats y estas cosas que se van un finde entero a hacer X actividad o que la actividad es una cena; para unas personas está muy guay pero para otras no y eso hay que respetarlo. Si se quiere hacer una actividad fuera de horario laboral, que sea porque todas las personas pueden y han tenido en cuenta su conciliación.
Donde hay relación, hay conflicto.
Esto hay que aceptarlo. Somos personas y es natural. El conflicto hay que atajarlo de raíz, intervenir, intentar eliminar las conductas que lo desatan y que, por tanto, perjudican a la salud del equipo. Luego, si trabajas con alguien con quien no congenias, intentar ser profesional y saber trabajar juntos en pro del producto e intentando ser cada vez mejor persona y compañera.
Y para terminar, así en general, evitar cualquier comentario machista, misógino, racista, gordófobo, capacitista, sobre el cuerpo de los demás y las típicas bromitas que piensas que “ay, qué chistoso soy” y son completamente inadecuadas para el contexto.
Me encantaría trabajar en un equipo así 🙂
¿A ustedes qué les parece? ¿Qué añadirían? Seguro me faltaron mil cosas más. Me lo pueden comentar compartiendo el artículo en Linkedin o Bluesky.
¡Gracias por leerme! <3