Aquí en x.ai , hemos desarrollado un asistente personal con Inteligencia Artificial que programa reuniones para usted. Suena simple, pero no se deje engañar. La inteligencia artificial es un problema técnico extremadamente desafiante.

Hace seis meses, enfrentamos un dilema: nuestro equipo de tecnología creció de unas 15 personas a más de 30 muy rápidamente. Queríamos asegurarnos de que, a pesar del enorme crecimiento, pudiéramos identificar fácilmente lo que teníamos que hacer y cómo hacerlo bien y sin demora.

Por lo general, existe un equilibrio muy básico cuando se desea hacer crecer un equipo exitoso sin perder agilidad: a medida que su equipo crece, cada individuo gana un mayor grado de libertad y su impacto en la organización es menor. Pero no queríamos eso.

Queríamos un entorno donde, a medida que crecíamos, los miembros del equipo todavía tuvieran el potencial de tener un gran impacto operativo y hacer el mejor trabajo de sus carreras, dentro de un equipo exitoso.

En ese momento (a finales del verano de 2016) estábamos muy tranquilos, con diferentes funciones siendo responsables de diferentes tareas.

Un efecto secundario de este arreglo fue una gran variación en la forma en que administramos los equipos. Básicamente, no pudimos priorizar nuestro trabajo correctamente.

Por lo tanto, probamos muchas cosas nuevas en un intento de escalar nuestro equipo sin sobrecargar nuestra estructura con áreas y departamentos cerrados.

Primero: ¿cuáles son los objetivos?

Implementamos OKR individuales y de equipo tan pronto como nuestro equipo creció más allá de un grupo unido de ingenieros de datos y científicos.

Con el tiempo, aprendimos que los OKR, que se siguen durante tres meses, eran muy estrictos, teniendo en cuenta la velocidad con la que estaban cambiando las cosas en nuestra empresa.

En cambio, decidimos que deberíamos alinear al equipo en torno a un pequeño conjunto de objetivos trimestrales de la empresa , y si algún proyecto individual no contribuía significativamente a un objetivo específico (y no había más de cinco ), entonces ese proyecto no debería ponerse en funcionamiento.

Estos objetivos abarcaron todo el trabajo que queríamos hacer.

Ahora, necesitábamos decidir en qué proyectos específicos enfocarnos, cómo asignar miembros del equipo a proyectos específicos sin replicar una estructura de grupo cerrado y qué otros procesos podrían ayudarnos a escalar nuestros equipos exitosos.

Discusiones transparentes utilizando solicitudes de comentarios

Las solicitudes de comentarios (RFC, o Solicitudes de comentarios, en inglés) se han convertido en la base de nuestro proceso. Estos documentos compartidos y altamente estructurados permiten que cualquier persona con una idea para un nuevo proceso o un nuevo enfoque de nuestro trabajo la comparta con el equipo, reciba comentarios y luego, si es aceptada, implemente esa idea.

Estas ideas pueden venir de cualquier parte. Un ejemplo ahora clásico en la empresa fue nuestro » turno de noche «, propuesto por uno de nuestros científicos de datos. Básicamente, señaló que no estábamos haciendo un trabajo adecuado para resolver errores críticos y, peor aún, estábamos sacando ingenieros de proyectos importantes de manera inmediata para apagar incendios.

Necesitábamos encontrar una manera de apagar estos incendios de manera oportuna sin comprometer el tiempo de los técnicos y mantener a nuestro exitoso equipo trabajando de manera productiva.

Este RFC en particular tenía todos los elementos necesarios:

• Una declaración del problema a resolver.
• Una solución: un turno con rotación semanal de tres técnicos.
• Cualquier requisito relevante. En este caso, hubo un tema con la famosa “Guardia de la noche” de la serie Juego de Tronos, incluyendo un texto con los votos de compromiso de los participantes.

Una vez que nuestro científico de datos abrió el RFC (a través de un documento de Google ), cualquier persona de la empresa podía comentar. Como todos los RFC, estuvo abierto a comentarios durante solo dos semanas. Siguió una breve discusión y en unos 10 días, se aceptó la RFC. Luego, implementamos nuestro «Night’s Watch» como se describe.

Las RFC actuaron como un primer paso en la implementación de nuevos procesos. El objetivo no era llegar a un consenso. En cambio, queríamos aumentar el nivel de transparencia en torno a las iniciativas de la empresa y fomentar la conversación, que es esencial para crear equipos exitosos. Y debido a que usamos documentos compartidos para todas las RFC, esta conversación se ha convertido en parte de nuestro registro público.

Autoselección de gerentes

También queríamos asegurarnos de que el equipo de tecnología se sintiera muy autónomo, y con un sentido de responsabilidad percibido, a medida que crecíamos.

Estábamos seguros de que cualquier estilo de gestión de «comando y control» (en el que los gerentes de tecnología asignaran trabajo a los técnicos) no le daría a nuestro equipo el sentido de responsabilidad que creemos necesario para que un equipo exitoso pueda enviar código de alta calidad. semana tras semana.

Por lo tanto, permitimos que todos los empleados seleccionen a sus propios gerentes, proyectos y líderes de proyectos (a esto lo llamamos auto-selección en todos los niveles del proceso).

Si bien puede parecer radical, no creamos este tipo de autoorganización, lo tomamos prestado del Proceso de priorización de Pandora .

Algunos elementos centrales de la autoorganización nos han funcionado muy bien. Seleccionar a su propio gerente, por ejemplo, fue en gran parte algo que sucedió normalmente.

Esto refuerza la libertad real de las personas para elegir a su gerente (porque siempre pueden elegir a otro, si así lo desean).

La selección de sus proyectos también funcionó bien. Las personas generalmente conocen sus fortalezas y cómo pueden ayudar a la empresa a tener éxito.

Transparencia usando días de demostración

Finalmente, configuramos un Demo Day que se celebrará cada dos semanas. El Demo Day tuvo dos partes. La primera mitad fue como una mini reunión general de la empresa. Todos participaron y el equipo de tecnología pudo compartir los proyectos que completaron.

Nuestro equipo de experiencia del cliente también compartió datos importantes sobre la adquisición y el compromiso de los clientes, así como los problemas de los clientes (por ejemplo, errores y puntos débiles que surgieron a través del servicio de atención al cliente).

Después de eso, nos dividimos en grupos más pequeños y el equipo de tecnología seleccionó en qué proyectos querían trabajar.

Durante el Demo Day, dimos «monedas» a todos en la empresa. Usamos notas adhesivas y asignamos un valor a cada nota: cinco días de tiempo para un solo técnico. Cada persona de la empresa recibiría 25 días de tiempo técnico o cinco pegatinas.

Calcule todo esto, y la suma representó la cantidad de tiempo que tendrían que dedicar nuestros técnicos para realizar todos los proyectos en este trimestre.

Es decir, si nuestros proyectos tardaran más en completarse que la cantidad de dinero que teníamos que distribuirles, tendríamos que averiguar cuáles no se ejecutarían.

Fue entonces cuando empezó la diversión. Todos querían “financiar” los proyectos que pensaban que necesitaban más tiempo y esfuerzo este trimestre.

Esto cancelaría inmediatamente algunos proyectos (aquellos que no han sido totalmente financiados). Así, dimos un paso más en la selección, reduciendo nuevamente el conjunto de proyectos financiados, en base a los argumentos de los miembros del equipo (pros y contras) y alineados con los objetivos de la empresa.

¿Eso funciono?

En general, nuestro nuevo enfoque es mucho más colaborativo y multifuncional, lo que significa que producimos un mejor trabajo de manera más eficiente.

También multiplicamos las oportunidades para que las personas lideren. Hoy en día, cualquiera puede liderar cambios técnicos, independientemente de su título o nivel en nuestra jerarquía (todavía bastante horizontal). Esta es una gran victoria para nosotros y para los miembros individuales de equipos exitosos.

Hicimos estos cambios hace seis meses y, mientras tanto, hemos creado e implementado:

• Una gran pieza de software nueva (una parte clave del sistema que procesa los datos de programación de entrada);
• Lanzamos dos nuevos productos (las ediciones Professional y Business de nuestro asistente de programación de IA); y,
• Hemos implementado una capa de monitoreo del sistema mucho más sofisticada.

Hicimos esto con un equipo exitoso de aproximadamente 40 ingenieros de datos y científicos. Con solo leer esta lista, puede decir que lo que hicimos fue un éxito abrumador.

Pero la realidad, sin embargo, nunca es tan simple.

También hubo pérdidas. Por ejemplo, al principio fracasamos gravemente en desarrollar un proceso de planificación disciplinado, eficiente y verdaderamente alineado con los objetivos de la empresa.

En cambio, pasamos muchos ciclos (y mucho tiempo) hablando de muchas cosas que sería bueno que hiciéramos, pero que no teníamos tiempo para hacer.

Finalmente logramos «inflar la lista de proyectos», lo que significa que teníamos una cantidad absurda de proyectos en la cartera de pedidos.

En términos de autoselección, también hubo desviaciones. La autonomía funciona solo si estructura el proceso de una manera que aclare las restricciones, prioridades y compromisos.

Desafortunadamente, parte de nuestra planificación ha oscurecido la importancia relativa y la urgencia de diferentes proyectos.

Por ejemplo, algunos técnicos decidieron explorar otro modelo de aprendizaje automático, cuando necesitábamos casi todas las manos disponibles para reconstruir una parte clave de nuestra infraestructura.

Como la producción de software, trabajamos con iteraciones

Afortunadamente, aprendemos rápido. Rápidamente vimos que la autoselección en todos los niveles de la empresa requiere un equipo bien equilibrado y maduro a la hora de negociar los aspectos técnicos de nuestro sistema, las necesidades de los clientes y del negocio, e incluso los deseos individuales de los propios ingenieros.

No tenemos ahora (y quizás nunca) el equilibrio perfecto entre habilidades y madurez, lo que significa que ajustaremos continuamente nuestros sistemas de priorización para mejorar esto.

Por ejemplo, ahora refinamos una lista de proyectos propuestos periódicamente. También creamos foros para que el equipo de Experiencia del cliente pueda brindarnos comentarios en tiempo real y ayudar a priorizar proyectos.

Y una vez que nos dimos cuenta de que los ciclos de dos semanas no coincidían con nuestro ritmo de desarrollo de software real, creamos grupos separados para trabajar en proyectos de ciclos más grandes de cuatro a seis semanas.

Queremos enfatizar que para que ella sea un equipo exitoso, debe entender que algunas de las cosas que necesitamos construir requieren un compromiso más sostenido que insistir en la corrección constante del rumbo.

Nuestro equipo ahora tiene un compromiso más profundo con los objetivos a largo plazo, lo que ayuda a impulsar los proyectos hacia la línea de meta de manera más confiable.

También trabajamos constantemente en formas de ayudar a las personas a ser responsables de la autoselección.

Para poder ocupar roles con este modelo organizacional, estamos probando explícitamente las habilidades de liderazgo y tutoría al entrevistar a los candidatos.

Y capacitamos a los empleados para que seleccionen proyectos que coincidan con sus habilidades e intereses, y que les brinden oportunidades de trabajar con nuestros líderes técnicos.

Una ventaja de la autoselección en todos los niveles de la empresa es que casi no existe una estructura rígida. Y como todo es ligero, la estructura en sí se vuelve bastante adaptable.

Mientras aprendamos continuamente sobre nuestro equipo exitoso y ajustemos nuestro proceso para respaldarlo, cada iteración debe ser mejor que la anterior.

Jeff Smith, Wesley Harris, Alex Poon y Joey Betras también contribuyeron a este artículo.