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

Resumen.

Cuando las personas trabajan desde casa, a menudo se espera que estén presentes virtualmente durante la jornada laboral habitual. Esto puede plantear problemas a medida que las personas hacen malabarismos 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, combinando el trabajo asíncrono y sincrónico según corresponda según la importancia de la comunicación tácita a nivel de tarea. El proceso de GitLab se habilita respetando: (1) límites claros a nivel de tarea entre realizar tareas y declararlas realizadas; (2) el principio de cambio mínimo viable; y (3) la necesidad de una comunicación abierta. Además, GitLab ofrece oportunidades para socializar en línea, lo que resultó útil durante la pandemia.

La crisis del Covid-19 ha distanciado a las personas del lugar de trabajo y los empleadores han aceptado generalmente, aunque a veces a regañadientes, 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 animado a las personas a seguir de cerca la jornada laboral convencional. El mensaje es que trabajar desde casa está bien e incluso puede ser muy eficiente, siempre y cuando las personas se unan a las videollamadas junto con todos los demás durante todo el día.

Pero los empleados a menudo tienen dificultades con el «día de trabajo» cuando trabajan desde casa, porque muchos tienen que lidiar con las solicitudes contrapuestas que vienen de su familia, también en casa. Entonces, ¿qué tan efectivo es trabajar desde casa si todos siguen trabajando al día? ¿Es posible deshacerse del reloj?

La respuesta parece ser que sí. Desde antes de la pandemia hemos estado estudiando las prácticas de trabajo remoto de la empresa tecnológica GitLab para explorar cómo podría ser que las empresas rompan las cadenas cronológicas de sus empleados, así como sus vínculos con el lugar de trabajo físico.

El desafío de GitLab

Desde su fundación en 2014, GitLab ha mantenido un personal totalmente remoto que ahora cuenta con más de 1.300 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, como siempre hay «9 a 5» en algún lugar del planeta, el trabajo puede continuar las 24 horas del día, aumentando 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 implicaciones organizativas de amplio alcance.

La forma más natural de distribuir el trabajo entre ubicaciones es hacerlo modular e independientes, por lo que hay poca necesidad de coordinación directa: los trabajadores pueden ser eficaces sin saber cómo progresan sus colegas. Es por eso que el trabajo distribuido puede ser tan eficaz para centros de llamadas y evaluación de patentes. Pero 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 de antemano.

Para este tipo de trabajo complejo, la coubicación con comunicación continua suele ser un enfoque mejor porque ofrece dos virtudes: la sincronicidad y la riqueza de los medios. El desfase temporal en la interacción entre dos o más personas es casi nulo cuando están ubicadas conjuntamente 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 suaves: cómo fácil ¿es percibir las reacciones de otras personas en una reunión grupal de zoom?

Todo esto implica que es poco probable que intentar replicar en línea (a través de video o chat de voz) lo que sucedió 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 no recurrir cuando se ve obligada a trabajar de forma remota, ya que nuestra encuesta sobre prácticas de trabajo a distancia inmediatamente después de los confinamientos en todo el mundo ha revelado.

Coordinación tácita

Hay una forma de superar este dilema. Nuestro anterior investigación sobre la tercerización en el extranjero del desarrollo de software demostró que basarse en coordinación tácita mecanismos, como la comprensión compartida de las normas de trabajo y el contexto, permiten la coordinación sin comunicación directa.

La coordinación en este caso se produce a través de la observación de la acción de otros empleados y de ser capaz de predecir lo que harán y necesitarán basándose en normas compartidas. Puede ocurrir bien 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 hace una entrega clara del documento y no trabaja en él cuando el otro lo está).

Las organizaciones de desarrollo de software suelen optar por esta solución y suelen depender ampliamente de repositorios compartidos y 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 bastante singular en el sector de las organizaciones con fines de lucro en la medida en que depende de esta tercera vía no solo para su codificación, sino también para el funcionamiento de la propia organización. Se apoya especialmente en el trabajo asíncrono porque 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 se encuentra el proceso de flujo de trabajo «git» inventado por Fundador de Linux Linus Torvalds. En este proceso, un programador que hace una contribución a un código» horquillas» (copia) el código, para que no quede bloqueado a otros usuarios, trabaja en él y, a continuación, realiza 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 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 totalmente 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 dado un paso más allá, aplicándolo también al trabajo directivo que implica ambigüedad e incertidumbre. Por ejemplo, recientemente el director de marketing de GitLab esbozó una visión para integrar el vídeo en la estrategia anual de la empresa. Solicitó comentarios asíncronos de toda la empresa dentro de un período de tiempo fijo y, a continuación, programó una única reunión sincrónica para acordar una versión final de la visión. Esta visión desencadenó cambios de entrada asincrónicos 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 en el trabajo asíncrono es posible respetando las tres reglas siguientes hasta el nivel de tarea:

1. Separe la responsabilidad de realizar la tarea de la responsabilidad de declararla realizada.

En entornos compartidos, donde los empleados están en la misma oficina, la comunicación sencilla y las señales sociales les permiten resolver ambigüedades de manera eficiente y gestionar los conflictos en torno a las responsabilidades y las remesas laborales. Sin embargo, en la configuración remota, esto puede ser difícil. En GitLab, por lo tanto, se espera que cada tarea tenga un individuo directamente responsable (DRI), que es responsable de completar la tarea y tiene libertad en cómo debe realizarse.

Sin embargo, el DRI no decide si la tarea se ha completado. Esa función es responsabilidad de un «responsable», que tiene autoridad para 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 funcionen en paralelo de la forma que deseen en diferentes partes de un código mediante la realización de copias locales («bifurcación»). El responsable del mantenimiento consiste en evitar cambios innecesarios y mantener la coherencia en la versión de trabajo del documento o código.

En un contexto ajeno al 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 persona de la empresa, redactarían políticas específicas de la forma que quisieran, y sus contribuciones serían aceptadas o rechazadas por el CFO que actúa en calidad de responsable, que podría también ofrecen comentarios (pero no instrucciones) a los DRI. Una vez activa, la página fusionada sirve como la única fuente de información sobre las políticas de gastos a menos o hasta que otra persona haga una nueva propuesta. Una vez más, el responsable 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 actuaran como mantenedores.

2. Respeta el principio de «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 otro. Para minimizar este riesgo, se insta a los empleados a que presenten el cambio mínimo viable: una versión imperfecta y en fase inicial 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 está duplicado. Obviamente, una política de cambios mínimos viables debería venir acompañada de una política de «sin vergüenza» para obtener un resultado temporalmente imperfecto. En entornos remotos, el valor de saber lo que hace el otro lo antes posible es mayor que conseguir el producto perfecto.

3. Comunícate siempre públicamente

Como suelen decir los miembros del equipo de GitLab, «aquí no enviamos correos electrónicos internos». En su lugar, los empleados publican todas las preguntas y comparten toda la información en los canales de Slack de sus equipos y, posteriormente, los jefes de equipo deciden qué información debe estar visible de forma permanente para los demás. Si es así, se almacena en un lugar al alcance de todos los miembros de la empresa, en un documento de «emisión» o en una página del manual en línea, accesible para cualquier persona, dentro o fuera de la empresa. Esta regla significa que las personas no corren el riesgo de duplicar o incluso destruir inadvertidamente el trabajo de sus colegas. Los gerentes dedican mucho tiempo a curar la información generada a través del trabajo de los empleados que supervisan y se espera que sepan mejor que otros qué información puede ser necesaria para un futuro equipo o que sería útil para personas ajenas a la empresa.

Reconocer los límites del enfoque de GitLab

Por muy bien implementado, el teletrabajo asíncrono de este tipo no puede proporcionar mucho en el camino de la interacción social. Eso es un gran fracaso, 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 de 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 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 discutir libremente lo que quieran (GitLab ofrece una pregunta inicial diaria para romper el hielo en caso necesario, como: «¿Qué hiciste el fin de semana?» o «¿Dónde está el mejor lugar al que has viajado y por qué?»).

Además, GitLab tiene grupos sociales de holgura: 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 extraños que tienen un interés mutuo conversar con un café juntarnos.

Por supuesto, los gerentes de GitLab no se hacen ilusiones de que estos grupos sustituyen perfectamente a los tipos de interacciones sociales enriquecidas fuera del trabajo que la gente encuentra gratificante. Pero sí ayudan a mantener a los empleados conectados y, en un momento en que muchos empleados han estado trabajando bajo las reglas de confinamiento, esto ha resultado 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. Abarca prácticas destinadas a compensar o evitar las limitaciones fundamentales del trabajo a distancia, así como aprovechar al máximo la flexibilidad que puede ofrecer el trabajo remoto: trabajar no solo desde cualquier lugar sino en cualquier momento deseado. Nos hemos centrado en GitLab porque no solo tiene una amplia experiencia en el trabajo remoto, sino también porque persigue un modo inusual de resolver los desafíos intrínsecos del trabajo remoto. Si bien algunos de los procesos principales de GitLab (como su largo proceso de incorporación remota para nuevas contrataciones) y sus ventajas (como la posibilidad de contratar en todo el mundo) no se pueden reproducir completamente a corto plazo en empresas que estarán temporalmente remotas, hay otros que cualquier empresa puede implementar fácilmente.

— Escrito por Marco Minervini, Phanish Puranam