El rol de Team Contributor
Porque Individual Contributor suena raro
El concepto de Individual Contributor o IC está ampliamente extendido en la industria. Hace referencia al path de carrera paralelo al de management para los profesionales que quieren seguir creciendo como desarrolladores sin gestionar personas.
Sin embargo, encuentro algo extraña la elección de palabras, ya que desarrollar software (sobre todo en niveles más senior) es más saber trabajar con personas que desarrollar individualmente.
Por ello, una metáfora más adecuada a este path es la de Team Contributor, ya que refleja mejor que desarrollar software es un trabajo de equipo y no es alcanzable con el mero esfuerzo individual.
Nota: después de escribir el artículo he encontrado gente que ya ha hablado sobre ello, seguramente lo haya leído en el pasado y mi subconsciente me lo ha querido recordar. Igualmente considero que el resto del artículo es relevante :)
Habilidades blandas
Suele decirse que hay dos tipos de habilidades que todo profesional ha de tener. Las duras (o hard skills) y las blandas (o soft skills).
Las duras hacen referencia a la habilidad que tienes desarrollando, a tu experiencia aplicada y a lo bueno que eres técnicamente. Estas habilidades se obtienen aprendiendo sobre el oficio, aplicando buenas prácticas y creando una visión crítica de qué es construir buen software.
Por otro lado, están las blandas, que se relacionan con tu habilidad de navegar el entorno de trabajo. De trabajar con personas, de discutir temas delicados, de saber ceder o argumentar cuando es necesario y, sobre todo, de saber trabajar en equipo. Estas habilidades son más complicadas ya que se obtienen con experiencia real y el paso del tiempo. Obviamente son aprendizajes que también puedes extraer de libros y que se pueden enseñar, pero el contacto con el día a día es lo que hace de verdad que aprendas a tratar con personas y gestionar situaciones críticas de la mejor manera posible.
Normalmente, y por motivos importantes, conforme vas subiendo el nivel de seniority las habilidades que se valoran van cambiando. Al principio de tu carrera son importantes tus habilidades duras, vas aprendiendo sobre el oficio y aumentando el valor que aportas con tus desarrollos.
Poco a poco, mientras asciendes el “ladder”, las habilidades que se valoran van migrando hacia las blandas, hacia tu capacidad de trabajar con más gente, hacia tu habilidad de tratar con personas y gestionar conflictos.
Sin embargo, esto no quiere decir que se deje de valorar lo bueno que eres técnicamente, pero es algo que ya se presupone y que se valora de una forma más continuista. En cierta manera, cuanto más seniority tienes, más valor aportas desbloqueando situaciones y gestionando aspectos más estratégicos del desarrollo en vez de centrarte tanto en los tácticos.
Trabajar con personas
No por nada uno de los principios del manifiesto ágil es: Individuos e interacciones sobre procesos y herramientas. Y es que, como hemos comentado, desarrollar software (y cualquier trabajo en general) va más de trabajar con personas que desarrollar.
Y no es algo que se limite a aquellos que navegan el path del manager y que gestionan personas, ni mucho menos. Cualquier desarrollador ha de centrarse en mejorar el trabajar en equipo y tratar con personas.
Hay un término que se popularizó hace unos años que es el de 10x engineer, que viene a ser un desarrollador que hace 10 veces más que los demás. Bueno, eso está bien, pero siempre que lo haga en equipo.
Hay cierta tendencia de desarrolladores “pro” que pueden ser muy buenos técnicamente pero que fallan estrepitosamente trabajando con otras personas. Estos perfiles puede que te saquen trabajo y desbloqueen desarrollos complejos, pero en el medio plazo pueden dar más problemas que beneficios.
Un ejemplo de problema es la generación de silos de conocimiento en los que solo una persona sabe cómo está implementado algo. Si no hay transferencia de conocimiento dentro del equipo hacemos que una sola persona sea crítica para el proyecto, disminuyendo la flexibilidad que tenemos en el desarrollo. Construir un producto de software no es el trabajo de una sola persona, sino de un equipo.
Aunque no os quedéis con la idea de que una persona muy pro no puede trabajar en equipo o que las habilidades blandas lo son todo, todo lo contrario, profesionales verdaderamente senior son los que tienen las habilidades técnicas pulidas (x10) y las blandas desarrolladas con experiencia y trabajo. Son estos perfiles redondos los que impulsarán el negocio de la forma más óptima posible.
Team Contributor
Por lo tanto, es por el tipo de perfiles problemáticos que solo cuentan con habilidades duras y que en ocasiones trabajan por su cuenta por lo que encuentro el concepto de Individual Contributor cuanto menos desacertado.
El objetivo de los que no quieren gestionar gente y quieren seguir creciendo como desarrolladores ha de centrarse también en las habilidades blandas que les permitirán seguir cogiendo seniority y seguir el más acertado path de Team Contributor: donde individuos e interacciones están sobre procesos y herramientas, y dónde el trabajo en equipo es tan importante como ser bueno técnicamente.
Photo by Annie Spratt on Unsplash