Kuan Wei (Greg) Soh es un emprendedor tecnológico e inversionista ángel que disfruta construyendo equipos de tecnología de clase mundial. Anteriormente, trabajó en servicios financieros, la industria de fondos de cobertura y en empresas emergentes de alto crecimiento.
El trabajo remoto no es para todos los negocios y puede que no sea del agrado de todos. Cuando mi cofundador y yo decidimos crear un equipo de ingeniería distribuido para nuestra startup, numerosas preguntas pasaron por nuestras mentes: ¿Serán productivos? ¿Cómo se tomarán las decisiones? ¿Cómo mantenemos viva la cultura?
Hoy, administramos un equipo remoto de aproximadamente una docena de ingenieros y hemos aprendido bastante en el camino.
Aquí hay algunos consejos que esperamos que encuentres efectivos. Estos son probablemente aplicables a nuevas empresas en etapas anteriores y menos para organizaciones más grandes.
Programación en pareja
En un entorno de oficina, los empleados tienen amplias oportunidades para interactuar con sus colegas, y estas conversaciones crean orgánicamente una sensación de autenticidad. Pero en un entorno de trabajo remoto, no existe tal privilegio.
Algunos de nuestros amigos fundadores han usado servicios para monitorear o microgestionar a sus empleados durante las horas de trabajo, pero creemos que esto es improductivo y antitético para construir una cultura positiva.
La introducción de la programación en pares, una técnica ágil de desarrollo de software en la que dos ingenieros trabajan simultáneamente en el mismo problema, fomenta la colaboración y crea oportunidades para que los desarrolladores tengan conversaciones como lo harían en la despensa de una oficina. Intentamos emparejar a dos programadores durante un período de tiempo prolongado (alrededor de 10 semanas) antes de considerar una rotación o un cambio.
Algunos pueden argumentar que la programación en parejas es una pérdida de tiempo sobre la base de que si cada individuo puede producir X resultados, entonces tiene sentido producir el doble de resultados haciendo que cada uno de ellos trabaje en problemas separados.
Encontramos esta visión limitante. En primer lugar, la programación en pareja da como resultado una mayor calidad, ya que dos cerebros suelen ser mejores que uno. Cuando los sistemas de ingeniería son increíblemente complejos, casi siempre es una buena idea contar con un “verificador de cordura” reflexivo, ya que esto evita decisiones mediocres y ayuda a frustrar problemas posteriores, que pueden llevar mucho tiempo para resolver en el futuro. En mi experiencia, también conduce a resoluciones de problemas más rápidas. Para dilucidar este punto, si los problemas se pueden resolver en la mitad del tiempo, entonces, en el mismo marco de tiempo, la salida de dos programadores trabajando como pareja seguirá siendo 2x.
Source link