Me importa el trabajo, no el rol
A las personas nos gustan las etiquetas. Nos dan un sentido de pertenencia y, a la vez, delimitan el alcance de nuestras responsabilidades.
Bienvenido, bienvenida a Rodobo, un boletín quincenal que explora la relación entre el diseño de producto, la experimentación, analítica y las empresas.
Son muchas las ocasiones en las que nos encontramos atrapados en la forma en la que definimos nuestro rol profesional. Product Manager, Diseñador de Producto, Analista Digital, etc. Esta obsesión por los títulos no solamente limita nuestro crecimiento profesional, sino que también dificulta la colaboración entre equipos.
En esta ocasión, me gustaría escribir sobre cómo la fijación de un título puede afectar a las dinámicas de equipo y qué podemos hacer para, dentro de nuestro alcance, preocuparnos por el trabajo, no por el rol. Y con esto, no quiero decir que un diseñador tenga ahora que desarrollar y viceversa, sino que tenga la responsabilidad de querer ayudar a los demás.
Pero antes, como este es el último artículo que publicaré este año, quiero aprovechar para desearte feliz final de año, feliz entrada del próximo y comentar que Rodobo volverá la segunda o tercera semana de enero.
Roles por sentido de pertenencia
A las personas nos gustan las etiquetas. Nos dan un sentido de pertenencia y, a la vez, delimitan el alcance de nuestras responsabilidades. Y eso está bien, porque son capaces de dar sentido a lo que hacemos de forma ordenada.
Pero en ocasiones nos limitan, nos hacen pensar que si hemos visto una ineficiencia en un proceso o un error, al no ser nuestro trabajo, no podamos levantar la mano y generar un debate en torno a ello.
En el mundo profesional, como también en el personal, las etiquetas están por todas partes. Cada una de lo que dices cuando te preguntan “¿a qué te dedicas?” no solamente define lo que eres sino también aquello que no eres. Esta distinción, aunque es útil en términos de claridad, también puede actuar como una barrera para la colaboración.
De hecho, esta tendencia a proteger los límites del rol que mencionaba antes, puede derivar en conversaciones como:
“No debería tocar Figma porque no soy diseñador”
“Esta pregunta deberías hacérsela al Product Manager, yo soy desarrollador”
“Esta decisión debería tomarla el manager”
No digo que no sean malas porque todo depende de la situación, pero estas actitudes son las que pueden llegar a crear silos dentro de los equipos. En vez de enfocarse en el objetivo común, cada persona se refugia en su “caja de responsabilidad”, lo que en mi experiencia, es capaz de ralentizar los proyectos y reducir la capa de innovación.
Porque si solamente innovas cuando una situación no va como esperabas, no estás innovando, estás solucionando el problema sobre la marcha. Innovar es levantar la cabeza, ver cuales son los siguientes pasos y anticiparte a ellos. Pero eso es otro tema. Sigamos con los roles.
Una forma de entender habilidad y experiencia
El problema de definir el rol es que rara vez se centra en cómo hacer mejor el trabajo. Se pone demasiado énfasis en el título pero muy poco en el impacto que ese rol debe generar en el equipo y en el producto final.
Y cuando la conversación se estanca en el título, las personas tienden a proteger su terreno, a evitar involucrarse en las tareas que “no les corresponden”. Y esa actitud, por lógica, entorpece la colaboración.
No estoy diciendo que los roles sean inútiles, al contrario, tienen un propósito claro, ayudarnos a entender las habilidades, la experiencia y la motivación de las personas. Por ejemplo, cuando hablamos de “desarrollador fullstack” entiendes que esa persona tiene conocimientos tanto en frontend como en backend. Los roles son atajos mentales que nos permiten, a primera vista, entender lo que una persona puede hacer.
Los roles también cumplen la función de facilitar la organización del trabajo y la previsión del mismo. En equipos grandes o en proyectos complejos, contar con definiciones de trabajo claras permite dividir el trabajo de forma más eficiente, evitando esfuerzos duplicados.
Es decir, que si cada persona sabe en qué se especializa la otra, es más fácil asignar tareas y gestionar las expectativas. Es una claridad que operativamente es muy necesaria en entornos donde el tiempo y los recursos son limitados.
Pero cuando la definición del rol se vuelve demasiado rígida es cuando se pierde la capacidad de adaptación ante los cambios. Es por eso por lo que la pregunta que siempre me surge en este debate es la de, ¿cómo podemos aprovechar la claridad que nos dan los roles sin limitar la colaboración entre equipos?
Separar el trabajo del rol
Para conseguir que un equipo trabaje de forma más ordenada, en mi experiencia tenemos que aprender a separar el trabajo del rol.
Seguro que has escuchado “es responsabilidad del equipo tomar la decisión conjunta para que el proyecto salga bien en tiempos”. Eso significa que aunque una persona tenga un rol asignado, eso no la excluye de participar en tareas o discusiones fuera de su área de “competencia establecida”.
Y esto pasa porque el trabajo no le pertenece al rol, le pertenece al equipo.
Pensar de esta manera genera una cultura de responsabilidad compartida. Porque es cuando el equipo entiende que el objetivo es común cuando se reducen las excusas basadas en los límites del rol. Por ejemplo, si estamos retrasados en un roadmap, nadie dice “no es mi problema” sino que, como equipo, se buscan formas de colaborar para desbloquear el avance.
Responsabilidad compartida que no solamente mejora las operaciones sino que también genera más confianza. Todos sabemos que podemos contar con los demás cuando las cosas se complican.
Y es esta versatilidad la que no solamente ayuda a cumplir plazos y expectativas sino que también genera que aprendamos nuevas habilidades. Por ejemplo, cuando das servicio a cliente, se requiere por su propia naturaleza, de una constante adaptación a sus problemas, haciendo que aunque los límites de los roles sean mucho más difusos, se pueda anticipar mejor el riesgo.
Por ejemplo, un desarrollador que participa en la definición de la experiencia de producto podrá, más adelante, anticiparse a problemas mientras lo desarrolla. De la misma forma, un diseñador que se involucra en la definición de la estrategia entenderá de forma más profunda el impacto de sus decisiones de diseño.
Entornos de colaboración
Sé que es necesario definir lo que haces pero también encuentro útil adoptar una mentalidad más flexible, centrada en lo que se tiene que hacer, en el objetivo compartido. Y con esto no quiero decir que tengamos que eliminar los roles sino usarlos como guía, no como una barrera.
Algunos de los principios que siempre me gusta llevar por delante en este tipo de situaciones:
Enfócate en los objetivos. Empezar cada proyecto respondiendo a “¿qué se necesita hacer, cuál es el problema a resolver?” sin importar el tipo de habilidades que requiere. Lo importante es que lo que se haga esté alineado con ese trabajo y los objetivos.
Pedir opinión, generar debate, crear en equipo. No se trata de obligar a un diseñador a diseñar ni a un desarrollador a desarrollar sino de crear un entorno, unas dinámicas en las que todos puedan exponer necesidades, problemas y se trabaje en solucionarlas.
Aprender de los demás. La especialización es muy útil, especialmente en etapas iniciales en las que tienes que vender y dar un servicio, pero la polivalencia hace que los equipos sean más resilientes. Haz que los diseñadores puedan aprender de código, como también los desarolladores entender los principios del diseño. Empatía entre roles.
Eliminar de tu vocabulario “esto no me toca”. No quiero decir que todos debamos hacer de todo, pero si que estemos dispuestos a ayudar cuando sea necesario. Si tenemos un roadmap retrasado, por ejemplo, cada persona debería preguntarse “¿cómo puedo ayudar para que esto avance?.
Define roles, pero no los uses como barrera. Son necesarios, pero deben usarse de forma flexible. Piensa en ellos como zonas de especialización, no como muros de contención.
La frase que personalmente me estoy grabando a fuego es “aunque mi rol dice X, puedo ayudar en Y si el equipo lo necesita”.
Una conclusión, esta vez corta
Un rol es útil para entender el contexto, pero no debería definir nuestros límites ni afectar a nuestra capacidad para aprender y crecer.
Porque lo que importa no es el rol que tienes sino el trabajo que puedes hacer. No obstante, lo que importa al final en el éxito de un equipo no es cómo o cuánto cumplió cada persona con su trabajo sino por la forma en la que se consiguieron los objetivos de proyecto.
Si te gusta mi contenido, lo mejor que puedes hacer es compartirlo. También he habilitado una página en Ko-fi para que puedas invitarme a un café.
Nada más, por ahora, nos leemos cuando pasen las fiestas de navidad, durante la segunda o tercera semana de enero, y nos escuchamos ahora, en el nuevo episodio del podcast que tienes aquí abajo.
Gracias.
Nuevo episodio en el podcast
La invitada de este episodio es Begoña Antón Plaza.
Service & Strategist Designer, Begoña es una persona con mucha sensibilidad para entender de manera profunda al usuario y la organización, y eliminar así las barreras que se forman en la relación entre ambos.
Entre otros temas hablamos de:
La relación del diseño estratégico con otras áreas del diseño
Gestión del cambio: cuál es el rol de los usuarios y cómo influye su feedback en un proceso de diseño estratégico
Cómo de importante es mapear el sistema cuando estás empezando a diseñar
La influencia de las tendencias sociales en las decisiones que tomamos
Trabajar con incertidumbre y ambigüedad
Gestión de expectativas con todas las partes que participan
El papel de diseñar para futuros posibles en una estrategia de diseño
Cómo evitamos crear soluciones que solo resuelven síntomas y no las causas profundas de los problemas
Te dejo el episodio aquí abajo y en este enlace.
El contenido de estas semanas
Tener ideas y demostrar que son buenas son 2 habilidades diferentes
Los pre-mortem: cuando pensar como un gafe te ayuda a mitigar riesgos
Una frase
The best people possess a feeling for beauty, the courage to take risks, the discipline to tell the truth, the capacity for sacrifice. Ironically, their virtues make them vulnerable; they are often wounded, sometimes destroyed. Ernest Hemingway