El dilema de las dos pizzas

Dimos la bienvenida a 2021 con 11 empleados. En septiembre, seremos 23 y, si tenemos suerte, despediremos el año siendo aún más. Demasiados para seguir gestionándonos de forma eficiente como un único equipo. Al menos, según el corpus organizacional de la industria informática. 

Uno de los mantras de la misma es la regla de las dos pizzas, instituida por Jeff Bezos en los albores de Amazon, que dictamina que cualquier equipo debería ser lo suficientemente pequeño como para poder alimentarse con un par de pizzas. 

La norma persigue la eficiencia, la escalabilidad y la colaboración. Eficiencia, porque un equipo pequeño puede autogestionarse y dedicar más tiempo a ejecutar que a coordinar. Colaboración, porque obliga a los equipos a colaborar entre sí para alcanzar los objetivos más ambiciosos de la empresa. Escalabilidad, porque la estructura es replicable ad infinitum, al menos en teoría. 

La regla de las dos pizzas funciona perfectamente en un departamento de desarrollo de software, pero al aplicarlo en otras áreas -por ejemplo, servicios de recruiting, como los que prestamos en Manfred- surgen varios dilemas que tendrá que afrontar cualquier organización en crecimiento: 

1. El criterio mismo para formar equipos. ¿Por el tipo de tareas que asume? ¿por zona geográfica? ¿por el idioma con el que trabaje? En nuestro caso, sería bastante natural especializarlos por tipos de perfiles -un equipo que se encargue de los puestos de back, otro de front, un tercero de Sistemas-, pero aunque la especialización pueda hacerte más eficiente, también te hace menos resiliente. ¿De verdad queremos eso?

2. La permanencia o rotación de los componentes de cada equipo. Una de las consecuencias indeseadas de la división de grupos es la aparición de «reinos de Taifas» que se encierren en sí mismos y empiecen a hacer la guerra por su cuenta. Para evitarlo, una de las posibles soluciones es hacer que los empleados cambien de equipo cada cierto tiempo. Eso puede dotar de mayor «visión de empresa» a tu staff, pero también empujarlo fuera de su zona de confort de forma periódica y hacerlo menos eficiente mientras los nuevos grupos se acoplan entre sí. ¿Estamos dispuestos a asumirlo?

3. Cómo evitar los silos de información. Una de las principales motivaciones para restringir el tamaño de los equipos es limitar las duraciones de las reuniones, pero al dejar de tener un punto de encuentro en común, toda información relevante que surja en las mismas debe ser capturada y compartida con el resto de los equipos o sino todo lo que ganemos en eficiencia lo perderemos en colaboración. ¿Tenemos claro cómo hacerlo?

4. Definir quién reporta a quién. Si se pretende que los equipos sean independientes y autogestionados para mejorar la eficiencia ¿tiene sentido crear una capa de control externa? ¿y un rol de liderazgo dentro de los mismos? Por muy plano que sea un organigrama, es inviable que una única persona gestione con eficiencia los 1:1s, revisiones de desempeño y actualizaciones salariales de más de 10 personas… excepto que ese sea su único trabajo. Así que, ¿quién debería hacerlo?

Lo relevante de esta historia es que no trata una casuística específica. Un proceso de selección no deja de ser una especie de «venta bidireccional» en la que se alinean los intereses del candidato y las necesidades de la empresa. Y todas las compañías  a las que les vaya medianamente bien llegarán a un punto en el que tendrán que escalar su equipo de ventas, atención al cliente, administración o cualquier otro que no trabaje con tareas tan específicas como una funcionalidad o un proyecto de software. 

Los «Sales Pods»

Precisamente de las organizaciones comerciales podemos tomar un préstamo muy interesante para organizar un departamento no técnico: el concepto de pods o equipos autónomos, compuestos por entre tres y seis trabajadores que adoptan diferentes roles -en los que pueden especializarse o ir alternándose- para optimizar la gestión de oportunidades de venta, procesos de selección, tickets de soporte o cualquier tipo de actividad que requiera completar tareas acotadas y similares -que no idénticas- de forma continuada en el tiempo. 

La principal diferencia entre los pods y los equipos es que los primeros pueden ser autogestionados, pero no son autoorganizados. A la hora de escalar las actividades de un departamento, estos se replican en vez de expandirse y cualquier cambio de proceso, metodología, formación o política retributiva se aplica en todos por igual, excepto en el caso de contar con un pod destinado precisamente a probar la efectividad de esos cambios antes de replicarlos. 

Los sales pods pueden ser un buen marco de trabajo con el que intentar escalar nuestro equipo, pero tendremos que adaptarlo a nuestra propia actividad e idiosincrasia. Por ejemplo, casi toda la literatura sobre el tema está muy orientada a la consecución de unos objetivos de pod a los que se vinculan unos incentivos, pero si hay una única regla sagrada en Manfred es que los incentivos dependen del desempeño de toda la compañía, no de una persona o grupo en concreto. 

Si vinculáramos los incentivos económicos de una persona a los resultados del pod al que pertenece, quizás consiguiéramos incentivarla más, pero ¿qué estaríamos fomentando? ¿la competición o la colaboración? Para bien o para mal, hemos creado una compañía donde la mejor manera de incrementar tu salario es colaborar con tus compañeros en vez de competir contra ellos. Una decisión que choca frontalmente con el modelo clásico del recruiting. 

Adaptar en vez de adoptar

 Más de un ingeniero, devoto del catecismo agile, estará horrorizado ante la propuesta de extirpar la autorganización de los equipos para convertirlos en pods y repetirá con una seguridad rayana en la fé que cada equipo debería poder elegir los procesos y herramientas con los que crea ser más eficiente en su labor, pero en nuestro caso, ¿cómo conjugaríamos eso con proporcionar una experiencia consistente a candidatos y clientes? Con cada decisión, llegan más dilemas. 

Solo los iluminados jamás dudan de que están siguiendo la dirección correcta, a pesar de que el resto del mundo vaya en el camino contrario, pero nosotros solo somos gente corriente intentando aplicar el sentido común y no podremos evitar pensar que lo más probable es que nos estemos equivocando. 

Es esa falta de fe en sí mismas y la zozobra que provocan los múltiples dilemas es lo que empuja a muchas organizaciones a adoptar «tal cual» el modelo organizativo que esté más de moda o sobre el que exista mayor consenso -«si le ha funcionado a "empresón extranjero molón" malo será que no nos funcione a "empresa pequeña que no tiene nada que ver"»- , pero si algo hemos aprendido de todo este proceso es que la solución infalible para poder escalar los equipos de cualquier organización no existe. Hay que encontrar la que solucione tus problemas específicos y, en muchos casos, construirla. 

Por eso ni se nos pasa por la cabeza transformar todo nuestro equipo de golpe. Arrancaremos con un primer diseño de pod, le asignaremos un objetivo específico -extrapolado de los actuales. Por ejemplo, cerrar ocho procesos de selección al mes- y otorgaremos incentivos no económicos por alcanzarlo, como días extra de vacaciones. Apostamos por la motivación intrínseca, por la obviedad de que a todo el mundo le gusta hacer bien su trabajo, pero no tenemos ni idea de cómo resultará el experimento. Probaremos, revisaremos los resultados y adaptaremos el modelo en consecuencia... o lo cancelaremos por completo, si fuera necesario. 

Porque cada empresa es única. A lo mejor en la nuestra tienen más sentido los equipos de tres mariscadas que los de dos pizzas. Parece una conclusión digna del Capitán Obvio, pero en una industria que en los últimos años se ha dedicado a copipastear a troche y moche el Modelo Spotify con mayor o menor fortuna, parece que nunca está de más recordarlo. Sobre todo, teniendo en cuenta que el Modelo Spotify no funcionó en la propia Spotify. 

Si no tenemos cuidado, corremos el riesgo de quedarnos en la anécdota -en las dos pizzas, los squads o las dailys de cinco minutos estrictos- en vez de en lo verdaderamente importante. Si lo que lo define no es el trabajo que hace, ni sus componentes, ni el liderazgo del mismo, solo nos queda aceptar que un equipo no es más que un grupo de personas que colaboran para alcanzar un objetivo más grande de lo que podrían lograr individualmente. Da igual cómo estructuremos nuestra empresa, mientras no nos olvidemos de por qué lo estamos haciendo.

 Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!

---

---

---