Problemas comunes en la organización de equipos

Durante más de 20 años trabajando en tecnología, este último año dando cursos en empresas, he visto multitud de topologías en equipos y organizaciones. Es normal y necesario que cada empresa adapte su estructura a sus necesidades. Cada organización tiene su idiosincrasia y hay que estructurarse de la forma más eficaz para tus problemas, así que es lógico acabar con una gran variedad de topologías. No creo que exista una única forma correcta de organizarse, pero sí creo que cada una tiene un contexto y problemática que debemos conocer. En mi experiencia algunas opciones son mejores que otras.

Una de las organizaciones más comunes es estructurar los equipos en base a disciplinas; por ejemplo, tener un equipo de frontend, backend, diseño, etc. Este tipo de estructura en mi opinión tiene varios problemas, el más importante es la velocidad de entrega y la autonomía. Habitualmente estos equipos quedan bloqueados a la espera de otros para progresar. 

Por ejemplo, alguien de la capa de negocio tiene una idea o pone la estrategia, producto le da forma, la define. Diseño prepara la interfaz. Ten en cuenta que todos estos pasos, hay un feedback loop entre dos, gestión y producto, diseño y producto. Backend empieza su parte mientras frontend espera, una vez que se integran se den cuenta de que algo no está como se esperaba y entonces empieza el ciclo de nuevo, la pelota vuelve al equipo de backend y vuelta a empezar…

Con esta topología de  equipo el tiempo necesario para llegar a producción se pierde en reuniones generalmente inútiles que se repiten. Por ejemplo, muchas de las dudas que tendrá diseño, también las tendrá producto y las tendrá desarrollo. Validar una idea sencilla o estudiar la viabilidad técnica de un proyecto podría llevar semanas. Produce silos de conocimiento, este proceso a veces requiere que todo siga un orden así que no puedes hacer cosas en paralelo, o al menos requieren de una coordinación por parte de alguien que tenga una visión más holística y que coordine los equipos. Cuando descubres que algo no encaja suele volver la cadena hacia atrás y se bloquea hasta que responda. De hecho al estar organizados de esta manera también fuerzas a que las comunicaciones sean ineficientes. 

Esto además genera falta de compromiso y sentido de pertenencia por parte de los equipos e individuos ya que no tienen el control sobre el trabajo que realizan, o propósito de producto a nivel de equipo, sino que la misión de los equipos es la de ejecutar los planes de terceros, sacar funcionalidades como si fueran proyectos, generando problemas de mantenibilidad...

Otra forma habitual de organizarse es la de agrupar a gente por componentes, el equipo de web, el de android, iphone, etc

Este tipo de equipos es parecido al orientado a disciplinas, la diferencia aquí es que los componentes están agrupados en torno al usuario Web, Android, iPhone, API. Estos equipos pueden contar con gente de backend también. La ventaja de estos equipos es que se crea un entorno donde la gente tiene un conocimiento enorme de su plataforma, android. Y eso les hace ser super competentes. También te aseguras que todo la forma de trabajar en esa plataforma sigue los mismos estándares. Uno de los problemas es que no escala bien. ¿Qué haces si la aplicación de android necesita más gente?¿Acabas con un equipo de 15 personas? ¿Cómo gestionas a ese equipo?.
Además de otros muchos problemas, por ejemplo si las apps móviles comparten las mismas funcionalidades que la web a veces terminan con interacciones completamente diferentes e incluso con partes backend hechas varias veces de forma diferente, la solución que suelen poner a esto es que un equipo se encargue del backend y entonces volvemos a los problemas que contaba sobre los equipos por skills.

La mayor ventaja de este tipo de equipos es que la gente de una determinada tecnología brilla, sigue los mismos estándares, etc pero hay otras formas de hacer esto. Por ejemplo, teniendo equipos crossfuncionales pero luego grupos de trabajo de frontend, backend, etc que se juntan de vez en cuando. 

Otra forma muy típica es organizar a los equipos por squads creando una matriz, donde los backends, frontends, etc forman equipos que van cambiando en función del proyecto que toque, es decir, su equipo a largo plazo es el de su especialidad pero van formando equipos itinerantes para atacar proyectos concretos o áreas del producto. Estos equipos también tienen sus problemas, igual que los anteriores es muy difícil que tengan un ownership claro ya que cada proyecto o nueva funcionalidad puede que sea un miembro diferente quien la toque, además muchas veces he visto como al final de determinadas áreas siempre se encarga la misma persona porque “hay prisa y es quien más sabe” y eso acaba generando silos y dependencias que acaban bloqueando todo porque al final siempre dependen de las mismas personas para atacar ciertas partes, con lo que la supuesta ventaja de tener equipos “líquidos” desaparece. 

La mayoría de empresas empieza a tener equipos cross funcionales para evitar los problemas mencionados anteriormente, equipos que se forman por todos los perfiles necesarios tanto para hacer producto como proyectos, en el caso de hacer producto, son dueños de una parte del producto como por ejemplo el Onboarding, el checkout, etc.
Pero incluso en estos equipos también veo mucha variabilidad en cómo están formados, esto ya lo cubrí parcialmente en una edición de la newsletter. Voy a resumir en que tenemos dos tipos, aquellos en los que el mánager está dentro del equipo y aquellos en los que no. Estos últimos hay una variedad tremenda, desde empresas donde el mánager lleva 3+ equipos, otras donde el mánager es mánager del Guild, es decir, de todos los frontends, otro de todos los backends, etc y éstos están en diferentes equipos, lugares donde el mánager de todo el equipo es Product Owner o Product mánager.... Desde mi experiencia estos últimos, tienen bastantes problemas, entiendo que muchas veces no queda otra que organizarse así por ejemplo una startup al empezar su CTO seguro que tiene que llevar varios equipos, otras veces no hay dinero suficiente para tener un mánager por equipo, pero es importante que seamos conscientes de sus problemas.
Para estos mánagers es muy complicado ayudar a los miembros del equipo con su día a día, con problemas dentro del equipo, con su rol o carrera dentro del equipo, muy complicado dar feedback, percibir la situación de una persona antes de que sea un problema (piensa en un conflicto que empieza entre dos personas, una persona que se está desmotivando, etc). ¿Por qué? Pues porque sin estar en el día a día de la gente todo lo que te llega es de oídas, todo es de terceros, algo de lo que ya hablé en otra edición de la newsletter. Sin estar en el día a día es muy complicado que entiendas los problemas de cada persona, que veas como funciona el equipo y cómo pueden mejorar, siempre te tocará hablar con unos y con otros para entender los problemas. Esta es una queja común entre los mánagers que están en esta situación cuando hacen mi curso. Además cuando tienes a tu cargo directamente a más 7-9 personas y además tienes otras responsabilidades no vas a tener tiempo para hacer el seguimiento que deberías hacer, tus 1:1s serán con suerte mensuales y claro, entre que no estás en el día a día y que ves a la gente una vez al mes pues normalmente serás reactivo, todo tu trabajo es apagar fuegos porque te enteras de las cosas cuando ya han explotado.

Una nota sobre los “mánagers” por skill (frontend, backend, etc).

Creo que tiene sentido tener guilds de forma que todas las ingenieras de backend o frontend compartan prácticas, conocimiento, etc pero no creo que su mánager deba ser quién sea la líder de frontend o backend. Debemos cambiar esto, para ser un buen mánager no necesitas ser quien más sabe de una tecnología, es más, si eres quien más sabe de una tecnología probablemente tu tiempo no debería estar dedicado a gestionar a gente sino a liderar técnicamente, depende de la empresa tienes muchos roles que aplican aquí desde un principal a un Tech Lead y luego tendrías al mánager que gestiona al equipo. Si el equipo es pequeño y la persona también tiene las habilidades (y quiere) para gestionar al equipo, podría ser la misma persona quien hiciera de Tech Lead y de mánager (TLM).

Por todo lo mencionado anteriormente, creo que la mejor forma de organizarse si podemos, es teniendo a un mánager dentro de cada equipo. Además en el caso de trabajar en producto, me inclino por las ideas compartidas en este post.

Gracias a los que habéis revisado esta edición ❤️