Lleve la agilidad a toda la organización
El software se ha comido al mundo. Y a medida que continúa consumiendo industrias nuevas y diversas, está transformando la forma de hacer negocios. Todos estamos en el «negocio del software» ahora, independientemente del producto o servicio que proporcionemos, lo que nos obliga a reexaminar cómo estructuramos y administramos nuestras organizaciones.
Cuando pregunto a los gerentes si sus organizaciones practican «ágil» casi siempre dicen que sí. Un análisis más profundo revela que la mayor parte de esta agilidad comienza y termina en los equipos de desarrollo de productos, específicamente en ingeniería de software. Rara vez se menciona «agilidad en el grupo de RRHH» o «mejora continua en las finanzas». Sin embargo, es en estas disciplinas de infraestructura donde la agilidad debe arraigarse para dar soporte a las empresas impulsadas por software.
A medida que la naturaleza del software sigue cambiando hacia la entrega continua, podemos crear un nuevo tipo de conversación con el mercado, una conversación continua. Implementamos productos, observamos, medimos, entrevistamos, aprendemos y optimizamos en horas, no en meses. Las decisiones se toman rápidamente. Las instrucciones cambian durante la noche. Para respaldar esta optimización rápida e iterativa de nuestro negocio, las organizaciones internas que trabajan, financian, gestionan y recompensan a nuestro personal deben mostrar el mismo nivel de agilidad. «De la forma en que siempre lo hemos hecho» empieza a poner al nivel de gestión en conflicto directo con el potencial de los equipos de ejecución.
Echemos un vistazo primero a RRHH. El objeto en torno al que operan la mayoría de las organizaciones de RRHH es la solicitud de trabajo. Una solicitud de trabajo tradicional no suele ser más que una lista de herramientas y capacidades almacenadas por un lenguaje ambiguo sobre «principiantes» y «jugadores de equipo». Estas descripciones de puestos se escriben para llenar un vacío en un silo específico de una disciplina (por ejemplo, el equipo de ingeniería de software o el equipo de diseño). Los reclutadores, incentivados para ocupar puestos rápidamente, revisa los currículums para estas habilidades asegurándose de que todo lo que pase a la siguiente ronda haya «cumplido todas las casillas». ¿Tres años de Rails? Comprobar. ¿GitHub? Comprobar. Los candidatos pasan a los gerentes de contratación, quienes se ven presionados para que tomen una decisión, lo que garantiza que los equipos de RRHH alcancen sus cuotas de tiempo para llenar.
Este estilo de contratación no genera agilidad organizativa. Por el contrario, refuerza las barreras entre disciplinas y minimiza la cooperación. En cambio, los equipos de RRHH deben empezar a contratar por creatividad, colaboración y curiosidad. Necesitan buscar a los inconformistas, los candidatos que no encajan fácilmente en una caja. Son los generalistas con espíritu emprendedor. Son los retocadores polifacéticos que se han especializado en una disciplina como el diseño pero que resultan ser muy buenos programadores. Son los miembros escépticos del equipo. Los que siempre hacen retroceder el statu quo y obligan a la empresa a replantearse la forma en que se presenta a sus clientes. Hay que poner en marcha nuevas prácticas de contratación para atraer a estos candidatos. Las estructuras y los ejercicios de las entrevistas deben repensarse por completo. Es casi imposible evaluar las habilidades de colaboración de un candidato en una sesión de preguntas y respuestas de una hora. ¿Qué debemos cambiar para saber si este nuevo candidato es el innovador que impulsará a nuestra empresa hacia adelante? ¿Cómo nos aseguramos de que nuestras prácticas de contratación sigan mejorando a medida que evoluciona la naturaleza de nuestro negocio?
Si estamos contratando miembros del equipo emprendedores y siempre curiosos, la siguiente pregunta lógica es cómo incentivarlos y retenerlos. En el pasado, solo los asignábamos a un equipo; les dábamos un proyecto para construir y si se enviaban a tiempo y dentro del presupuesto (o al menos lo suficientemente cerca), se les recompensaba de alguna manera. Ya no basta con eso. La compensación financiera no es el principal motivador de estas personas. Construir algo significativo, algo que puedan llamar suyo, tiene mucho más valor. ¿Hay alguna manera de repensar las estructuras de compensación para incluir la equidad (o al menos al alza) para las ideas que crean nuestros equipos de colaboración?
La financiación de proyectos es otro monolito que debe ajustarse a nuestra nueva realidad. Los CFO quieren saber qué se enviará a cambio de financiar una iniciativa. Si bien nunca faltan respuestas (después de todo, estás tratando de obtener financiación), rara vez se da la respuesta verdadera: no lo sabemos. Existe una ambigüedad en el desarrollo de software que hace que el estado final sea incognoscible. Los niveles impredecibles de complejidad, la agitación del mercado y los cambios en el comportamiento de los clientes ponen a cualquier hoja de ruta de productos de más de cuatro a seis semanas en un alto riesgo de convertirse rápidamente en un artefacto obsoleto.
Siguiendo el ejemplo del mundo de las startups, la oficina del Oficial Principal de Finanzas debe empezar a tratar a cada equipo como una startup interna, un grupo de personas encargadas de resolver un problema empresarial. Ese problema empresarial tiene un objetivo objetivo y medible que, en última instancia, determina el éxito del equipo. Al final de cada período de financiación, los equipos deben presentar sus casos a la oficina de finanzas para su reembolso. Esto crea una resiliencia cadenciada en la forma en que la organización toma decisiones, lo que le permite asumir compromisos breves y luego promover esos compromisos o no, basándose en realidades basadas en el mercado en tiempo real, en lugar de elevadas predicciones de un estado futuro que tal vez nunca llegue.
Por último, las jerarquías de toma de decisiones deben cambiar. Tradicionalmente, las decisiones se ejecutan más allá de las capas de gestión, lo que garantiza que todos sean contratados antes de los cambios de dirección Estos procesos son lentos. Proporcionan cobertura en caso de que alguien cometa un error. La agilidad en la organización requiere que la toma de decisiones se realice lo más cerca posible de los comentarios de los clientes. Los equipos que trabajan en los productos deben poder decidir rápidamente cómo avanzar basándose en el flujo continuo de información del mercado. Cometer errores no debería ser un delito capital. En cambio, los errores deben analizarse rápidamente y cualquier nueva información debe incorporarse al siguiente conjunto de tácticas.
Los incentivos deben apoyar la medición de los resultados, la toma de decisiones basadas en la evidencia y el aprendizaje. La cultura del desarrollo de software permite todo esto, pero sin el apoyo organizativo, los equipos no pueden aprovecharlo al máximo. Al final del día, las decisiones tácticas cotidianas que toman los equipos no deben ser de la incumbencia de los directivos. En cambio, los gerentes deben centrarse en el progreso de los equipos hacia los objetivos estratégicos del negocio. Para aliviar la ansiedad de los directivos y garantizar una cohesión estratégica más amplia, recae en los equipos la carga de comunicarse lo más posible con la organización. Deben informar de forma proactiva sobre sus tácticas, aprendizajes, progreso y próximos pasos. Sin embargo, sin la seguridad de informar sobre todo el proceso, las verrugas y todo, la mayoría de los equipos optarán por la seguridad y la previsibilidad, lo que socavará efectivamente su agilidad.
A medida que nuestras empresas se convierten en organizaciones de software altamente centradas, debemos cambiar la forma en que las gestionamos. Un entorno de aprendizaje continuo impulsado por la información y los comentarios de los clientes las 24 horas del día exige equipos, entornos, estructuras de toma de decisiones y modelos de financiación que muestren el verdadero significado de la palabra agilidad: resiliencia, capacidad de respuesta y aprendizaje.
— Escrito por Jeff Gothelf
