El trabajo remoto no tiene por qué significar videollamadas que duran todo el día

Cuando las personas trabajan desde casa, a menudo se espera que estén prácticamente presentes durante la jornada laboral normal. Esto puede plantear problemas a medida que la gente hace malabares con la realidad de trabajar desde casa. GitLab, que lleva mucho tiempo trabajando de forma remota, ha demostrado que trabajar desde casa puede ser muy flexible, ya que mezcla el trabajo asíncrono y el sincrónico según proceda, según la importancia de la comunicación tácita a nivel de tarea. El proceso de GitLab se posibilita respetando: (1) límites claros a nivel de tarea entre la realización de las tareas y su declaración; (2) el principio de cambios mínimos viables; y (3) la necesidad de una comunicación abierta. Además, GitLab ofrece oportunidades para socializar en Internet, lo que resultó útil durante la pandemia.

••• La crisis de la COVID-19 ha distanciado a las personas del lugar de trabajo y, en general, aunque a veces a regañadientes, los empleadores han aceptado que las personas pueden trabajar eficazmente desde casa. Como para compensar este distanciamiento y mantener vivo el lugar de trabajo en un sentido virtual, los empleadores también han alentado a las personas a seguir estrictamente la jornada laboral convencional. El mensaje es que trabajar desde casa está bien e incluso puede ser muy eficaz, siempre y cuando las personas se unan a las videollamadas junto con todos los demás durante todo el día. Pero los empleados suelen tener problemas con la «jornada laboral» cuando trabajan desde casa, porque muchos tienen que hacer frente a las solicitudes contrapuestas de sus familiares, que también están confinados en casa. Entonces, ¿qué tan efectivo es trabajar desde casa si todo el mundo sigue trabajando según el reloj? ¿Es posible deshacerse del reloj? La respuesta parece ser que sí. Desde antes de la pandemia hemos estado[estudiando](https://publishing.insead.edu/case/gitlab-can-all-remote-scale) las prácticas de trabajo remoto de la empresa de tecnología[GitLab](https://en.wikipedia.org/wiki/GitLab) para explorar cómo sería si las empresas rompieran las cadenas cronológicas de sus empleados, así como sus vínculos con el lugar de trabajo físico. ### El desafío para GitLab Desde su fundación en 2014, GitLab ha mantenido una plantilla totalmente remota que ahora cuenta con más de 1300 empleados repartidos en más de 65 países. La forma de trabajar «git» utiliza herramientas que permiten a los empleados trabajar en proyectos en curso en cualquier parte del mundo y en el momento que prefieran. La idea es que, dado que siempre son «de 9 a 5» en algún lugar del planeta, el trabajo pueda continuar las 24 horas del día, lo que aumentará la productividad agregada. Eso suena bien, pero una fuerza laboral escalonada tanto en el tiempo como en el espacio presenta desafíos de coordinación únicos con amplias implicaciones organizativas. La forma más natural de distribuir el trabajo entre las ubicaciones es hacerlo **modular** e independientes, por lo que hay poca necesidad de coordinación directa; los trabajadores pueden actuar de forma eficaz sin saber cómo progresan sus colegas. Por eso el trabajo distribuido[puede ser tan eficaz](/2014/01/to-raise-productivity-let-more-employees-work-from-home) para centros de llamadas y evaluación de patentes. Sin embargo, este enfoque tiene sus límites en las actividades relacionadas con el desarrollo y la innovación, donde las interdependencias entre los componentes del trabajo no siempre son fáciles de ver con antelación. Para este tipo de trabajos complejos, ubicación conjunta con **comunicación continua** suele ser un enfoque mejor porque ofrece dos virtudes: la sincronicidad y la riqueza multimedia. El desfase temporal en la interacción entre dos o más personas es casi nulo cuando están ubicadas en el mismo lugar y, aunque el contenido de la conversación puede ser el mismo tanto en entornos presenciales como virtuales, es posible que la tecnología no sea totalmente capaz de transmitir señales contextuales sociales y de fondo blandas. ¿Qué tan fácil es percibir las reacciones de otras personas en una reunión grupal con zoom? Todo esto implica que es poco probable que el simple intento de replicar en Internet (a través de un chat de vídeo o de voz) lo que ocurrió de forma natural en entornos compartidos sea una estrategia ganadora o completa. Sin embargo, este enfoque de «ver la cara» es el que la gente parece adoptar por defecto cuando se ve obligada a trabajar de forma remota, ya que[nuestra encuesta sobre las prácticas de trabajo remoto](https://knowledge.insead.edu/blog/insead-blog/what-newly-remote-teams-need-right-now-13706) inmediatamente después de los bloqueos en todo el mundo se ha revelado. ### Coordinación tácita Hay una manera de superar este dilema. Nuestra primera vez[investigación](https://onlinelibrary.wiley.com/doi/abs/10.1002/smj.908) sobre la tercerización en el extranjero del desarrollo de software lo mostró basándose en **coordinación tácita** mecanismos, como la comprensión compartida de las normas y el contexto del trabajo, permiten la coordinación sin una comunicación directa. En este caso, la coordinación se consigue mediante la observación de la acción de otros empleados y la capacidad de predecir lo que van a hacer y lo que van a necesitar en función de normas compartidas. Puede ocurrir cualquiera de las dos **sincrónicamente** (donde, por ejemplo, dos personas podrían trabajar en el mismo documento de Google durante el mismo período de tiempo), **o de forma asíncrona** (cuando la gente entrega claramente el documento y no trabaja en él cuando el otro lo es). Las organizaciones de desarrollo de software suelen optar por esta solución y suelen confiar en gran medida en los repositorios compartidos y las herramientas de creación de documentos, con sistemas para coordinar las contribuciones (por ejemplo, herramientas de integración continua y control de versiones). Pero GitLab es único en el sector con fines de lucro por lo mucho que se basa en este tercer camino, no solo para la programación, sino también para el funcionamiento de la propia organización. Se basa especialmente en el trabajo asincrónico, ya que sus empleados están distribuidos en varias zonas horarias. Como resultado, aunque la empresa utiliza videoconferencias, casi ningún empleado se enfrenta a un día lleno de videoconferencias. ### Cómo funciona en GitLab En el centro del trabajo de ingeniería que impulsa el desarrollo de productos de GitLab está el[proceso de flujo de trabajo «git»](https://www.atlassian.com/git/tutorials/comparing-workflows) inventado por[Linus Torvalds, fundador de Linux](https://en.wikipedia.org/wiki/Linus_Torvalds). En este proceso, un programador que hace una contribución a un código»[horquillas](https://docs.gitlab.com/ee/gitlab-basics/fork-project.html)» (copia) el código para que no lo bloqueen otros usuarios, trabaja en él y, a continuación, hace una «solicitud de fusión» para que la versión editada sustituya a la original, y esta nueva versión estará disponible para otras contribuciones. El proceso combina la posibilidad de un trabajo asíncrono distribuido con una estructura que comprueba los posibles fallos de coordinación y garantiza la claridad de los derechos de decisión. Completamente electrónico (lo que hace posible el trabajo remoto) y completamente documentado, se ha convertido en un marco importante para el desarrollo de software distribuido tanto en contextos con fines de lucro como de código abierto. GitLab ha llevado el tema un paso más allá y lo ha aplicado también al trabajo directivo que implica ambigüedad e incertidumbre. Por ejemplo, el jefe de marketing de GitLab recientemente[describió una visión](https://gitlab.com/groups/gitlab-com/marketing/-/epics/858) por integrar el vídeo en la estrategia de la empresa para el próximo año. Solicitó comentarios asíncronos de toda la empresa en un plazo fijo y, a continuación, programó una única reunión sincrónica para acordar la versión final de la visión. Esta visión provocó cambios de entrada de forma asincrónica por parte de varios colaboradores en las páginas del manual de la empresa en relación con los objetivos de marketing y los resultados clave, que se fusionaron al finalizar. El alto grado de dependencia de GitLab del trabajo asincrónico es posible si se respetan las tres reglas siguientes hasta el nivel de tarea: **1. Separe la responsabilidad de realizar la tarea de la responsabilidad de declararla realizada.** En los entornos de ubicación compartida, en los que los empleados están en la misma oficina, las sencillas señales sociales y de comunicación les permiten resolver de manera eficiente las ambigüedades y gestionar los conflictos en torno a las responsabilidades y competencias laborales. Sin embargo, en entornos remotos, esto puede resultar difícil. En GitLab, por lo tanto, se espera que cada tarea tenga una persona directamente responsable (DRI), que sea responsable de realizarla y tenga libertad de _cómo_ debería interpretarse. Sin embargo, el DRI no puede decidir si la tarea se ha completado. Esa función es responsabilidad de un «mantenedor», que tiene la autoridad de aceptar o rechazar las solicitudes de fusión del DRI. La claridad de estas funciones para cada tarea ayuda a reducir las confusiones y los retrasos y permite que varios DRI trabajen en paralelo de la forma que deseen en diferentes partes de un código mediante la creación de copias locales («bifurcación»). La función del mantenedor es evitar cambios innecesarios y mantener la coherencia en la versión de trabajo del documento o código. En un contexto no relacionado con el software, por ejemplo, al desarrollar la página del manual de GitLab sobre políticas de gastos, los DRI individuales, que podrían ser cualquier miembro de la empresa, redactarían políticas específicas de la forma que quisieran y el CFO aceptaba o rechazaba sus contribuciones en calidad de mantenedor, que también podía ofrecer comentarios (pero no instrucciones) a los DRI. Una vez publicada, la página fusionada servirá como única fuente de información sobre las políticas de gastos, a menos o hasta que alguien más haga una nueva propuesta. Una vez más, el mantenedor aprobaría, rechazaría u ofrecería comentarios sobre la nueva propuesta. En contextos como este, esperaríamos que las personas que ocupan puestos directivos tradicionales se desempeñaran como mantenedores. **2. Respete el principio del «cambio mínimo viable».** Cuando la coordinación es asincrónica, existe el riesgo de que los fallos de coordinación pasen desapercibidos durante demasiado tiempo; por ejemplo, dos personas pueden estar trabajando en paralelo en el mismo problema, haciendo que uno de sus esfuerzos sea redundante o que una persona esté realizando cambios que son incompatibles con los esfuerzos de otra. Para minimizar este riesgo, se ruega a los empleados que presenten el cambio mínimo viable: una versión temprana e imperfecta de los cambios sugeridos en el código o los documentos. Esto hace que sea más probable que la gente se dé cuenta de si el trabajo es incompatible o si está duplicado. Obviamente, una política de cambios mínimos viables debería ir acompañada de una política «sin vergüenza» de ofrecer una producción temporalmente imperfecta. En entornos remotos, el valor de saber lo que hace el otro lo antes posible es mayor que de conseguir el producto perfecto. **3. Comuníquese siempre en público.** Como suelen decir los miembros del equipo de GitLab, «aquí no enviamos correos internos». En cambio, los empleados publican todas las preguntas y comparten toda la información en los canales de Slack de sus equipos y, más tarde, los líderes del equipo deciden qué información debe estar visible permanentemente para los demás. Si es así, se guarda en un lugar disponible para todos los miembros de la empresa, en un documento de «emisión» o en una página de la empresa[manual en línea](https://about.gitlab.com/handbook/), al que puede acceder cualquier persona, dentro o fuera de la empresa. Esta regla significa que las personas no corren el riesgo de duplicar o incluso de destruir inadvertidamente el trabajo de sus colegas. Los directivos dedican mucho tiempo a seleccionar la información que se genera a través del trabajo de los empleados a los que supervisan y se espera que sepan mejor que otros qué información puede necesitar ampliamente un equipo futuro o que podría ser útil para personas ajenas a la empresa. ### Reconocer los límites del enfoque de GitLab Por muy bien implementado, el trabajo remoto asíncrono de este tipo no puede ofrecer mucha interacción social. Eso es un gran defecto, porque la interacción social no solo es una fuente de placer y motivación para la mayoría, sino que también es donde los «encuentros aleatorios», los intercambios fortuitos entre las máquinas de café y los vestíbulos de los ascensores, crean oportunidades para que las ideas y la información fluyan y se recombinen. Para minimizar esta limitación, GitLab ofrece ocasiones para interacciones no relacionadas con las tareas. Cada día, los miembros del equipo pueden asistir a una de las tres llamadas sociales opcionales, escalonadas para incluir las zonas horarias. Las llamadas consisten en grupos de 8 a 10 personas en una sala de videochat, donde pueden hablar libremente de lo que quieran (GitLab ofrece una pregunta inicial diaria como rompehielos por si es necesario, como: «¿Qué hizo durante el fin de semana?» o «¿Cuál es el lugar más guay al que ha viajado y por qué?»). Además, GitLab tiene grupos sociales de Slack: salas de chat temáticas en las que pueden participar empleados con intereses similares (como: #cat, #dogs, #cooking, #mental_health_aware, #daily_gratitude, #gaming) y un canal #donut_be_strangers que permite a desconocidos que tienen intereses comunes charlar un café para reunirse. Por supuesto, los directores de GitLab no se hacen ilusiones de que estos grupos sustituyan perfectamente los tipos de interacciones sociales enriquecedoras fuera del trabajo que la gente encuentra gratificantes. Pero sí ayudan a mantener a los empleados conectados y, en un momento en que muchos empleados han estado trabajando bajo las normas de confinamiento, esto ha demostrado ser muy útil para mantener la moral. ******* Trabajar desde casa de forma eficaz va más allá de dar a los empleados un portátil y una cuenta de Zoom. Incluye prácticas destinadas a compensar o evitar las principales limitaciones del trabajo remoto, así como a aprovechar al máximo la flexibilidad que ofrece el trabajo remoto, ya que no solo se puede trabajar desde cualquier lugar sino a la hora que se desee. Nos hemos centrado en GitLab porque no solo tiene una amplia experiencia en el trabajo remoto, sino también porque busca una forma inusual de resolver los desafíos intrínsecos del trabajo remoto. Si bien algunos de los procesos principales de GitLab (como su largo y remoto proceso de incorporación de nuevos empleados) y sus ventajas (como la posibilidad de contratar en todo el mundo) no se pueden reproducir por completo a corto plazo en las empresas que solo estarán temporalmente remotas, hay otros que cualquier empresa puede implementar fácilmente.