Lidiando con la deuda de los sistemas

Preámbulo/tl;dr: Recientemente publiqué El principio de agilidad de Lloyd Braun principalmente como una observación tonta pero cierta sobre cómo la línea clásica de Seinfeld "Serenidad ahora, locura después" se relaciona con Ágil. Terminé esa publicación con una declaración sobre cómo debemos prepararnos mejor para la "Locura" que viene después. Con eso en mente, presento mi enfoque para construir equipos productivos. Se trata de pagar su deuda de sistemas.

El equipo de tecnología moderna está roto. Confiamos demasiado en las personas mayores y no aprovechamos a las personas menores.

He estado pensando mucho en este problema durante el último año, ya que he adaptado varios equipos a nuestra "nueva normalidad". Hace meses, comencé un artículo para respaldar el caso de que los gerentes de contratación deberían contratar a juniors. Para hacer un argumento efectivo, sabía que tenía que abordar una preocupación común: "Primero necesito que los seniors entrenen a los juniors..." Rápidamente el artículo creció y creció.

Si eres nuevo en la administración, este es mi "tratado" sobre administración. Se trata de cómo construir equipos altamente efectivos y productivos y se basa en más de una década de gestión exitosa de múltiples equipos grandes.

Lo que sigue es una lectura larga, por lo que el tl; dr es:

Hablamos mucho de #TechnicalDebt, pero Technical Debt es un síntoma de un problema mayor que estoy denominando Systems Debt.

La receta es sencilla:

1) Encargue a sus Seniors que paguen su deuda de sistemas y faciliten el trabajo.

2) ALQUILER. JÓVENES.

3) Deja de luchar contra el desgaste. Los jóvenes se quedarán por un promedio de 18 a 24 meses. Quieren experiencias variadas. Buscarán otros trabajos. Como comunidad tecnológica, QUEREMOS que los jóvenes adquieran más experiencia en su camino hacia la antigüedad. Los hace mejores, y nos hace mejores. Entonces, aceptemos el desgaste. Empecemos a concentrarnos en permitirles aprovechar al máximo esos 18 meses y luego apoyarlos en sus próximos pasos.

Cualquier buen equipo de entrega enfatiza la usabilidad. Los principios que impulsan la usabilidad aparecen en muchas formas diferentes: el Principio de Pareto , la Prueba de la abuela , el Principio de lo suficientemente bueno y más. Y todos llegan a algo muy humano: ¿es esto más difícil de lo que debe ser?

Lo vemos todo el tiempo : Diseños minimalistas que priorizan la facilidad de uso y están hiper-enfocados en una visión clara. Todo lo demás es una distracción, es una hinchazón.

Hay mucha gente hablando de liderazgo, gestión, equilibrio entre el trabajo y la vida personal y el trabajo remoto/en persona. Todo está siendo reevaluado, y la pregunta que ronda en mi mente desde hace meses ha sido simplemente esa: ¿Es el trabajo más difícil de lo que debe ser? De ninguna manera es una pregunta nueva, pero es un hilo que se ha tejido a lo largo de la mayor parte de mi carrera. Me encanta escribir código y crear productos, pero una visión holística puede revelar que más código no siempre es la respuesta. Más código significa más costos de capacitación y mantenimiento.

Si es un gerente nuevo, tener en cuenta esta pregunta puede ser muy valioso. Los gerentes son responsables de mucho: están ayudando a cada individuo a lograr sus entregas y sus objetivos personales. Eres responsable de la cohesión y dirección del equipo. A menudo es responsable de establecer procesos y políticas. Luego está la asignación y planificación de recursos, así como trabajar en torno a los horarios de PTO. Pero la luz que guía todo esto es la misma pregunta: ¿Es esto más difícil de lo que debería ser?

¿Cuándo fue la última vez que evaluó su mecánica interna? Pensando en su equipo de entrega como un producto, ¿qué tan fácil es para sus consumidores (el equipo de negocios/operaciones) lograr su objetivo? Y pensando en todo su negocio como un producto, ¿qué tan fácil es para los clientes lograr el suyo?

Centrándose en las personas, se aplican las mismas preguntas: ¿Qué tan difícil es para su equipo hacer su trabajo? ¿Qué estructuras, marcos, procesos artificiales y jerarquías existen que harían que tu abuela negara con la cabeza lo mucho que has complicado las cosas?

Una cartilla sobre la deuda

Todo este tren de pensamiento de evaluar críticamente sus procesos internos es, de hecho, una parte de la filosofía Agile que a menudo se pasa por alto. Los equipos afirman que son completamente ágiles, o un "híbrido ágil", pero al mirar más de cerca, se da cuenta de lo que quieren decir es que simplemente están tomando atajos inconvenientes para entregar productos descuidados más rápido. Cuando se trata de software, cualquier desarrollador experimentado sabrá exactamente en qué se convierte esto en una receta para una deuda técnica cada vez mayor. La broma constante de los codificadores es que la última persona lo hizo mal, y si quieres hacerlo bien , tendrás que reconstruirlo. Esto no se debe a la pereza o falta de habilidad. El trabajo nuevo es más fácil porque elimina toda la deuda técnica, pero, si se deja a los mismos malos procesos, solo crecerá una vez más.

La deuda técnica es un síntoma, e incluso cuando eres bueno en pagarla activamente, solo estás tratando el síntoma . Este síntoma proviene del error de pensar que Agile se trata solo de la entrega de software.

Una definición adecuada de Deuda Técnica es la 'acumulación de trabajo que necesita refactorización'. Como se mencionó, surge de tomar atajos cuando se enfoca en la entrega. A menos que lo esté pagando activamente, crece rápidamente. El resultado de demasiada deuda técnica es la fragilidad y la inestabilidad.

En el mejor de los casos, la Deuda Técnica es una decisión intencional: es poner algo a crédito con la intención de pagarlo más tarde. En tales casos, la deuda técnica no es mala, siempre que sea diligente en el pago de la deuda. La encarnación más nefasta de la deuda técnica es cuando sin querer aumenta la deuda, o peor aún, no se da cuenta de que la ha aumentado.

La Deuda técnica se ocupa de la tecnología, pero existe un concepto similar de Deuda de proceso : procesos heredados que se han vuelto obsoletos, funcionan mal, crean fricción, afectan la dinámica entre equipos o pueden ya no aplicarse a medida que cambian los roles. La Deuda de Procesos cubre nuestras deficiencias operativas no técnicas.

Todavía hay otras formas de deuda que impactan en la entrega: Deuda de diseño, Deuda de arquitectura.

Por supuesto, la deuda no es inherentemente mala. Al igual que puede llevar estratégicamente una buena cantidad de deuda financiera, asumir cualquiera de estas formas de deuda es una decisión estratégica. En lugar de pagar $ 20,000 por un automóvil de una vez, obtiene un préstamo para automóvil y distribuye los pagos en 10 años. Del mismo modo, la pila de tecnología que utiliza, la forma en que ha estructurado el conjunto de habilidades de su equipo, la antigüedad de esos roles y los procesos que impulsan su negocio adquieren una forma de deuda que se paga durante un período.

Solo que, a veces, no lo pagamos. O, peor aún: creemos que estamos pagando deuda pero en realidad estamos acumulando más.

Introducción: Deuda de sistemas

Me gustaría presentar un concepto que llamaré Deuda de Sistemas (Sistemas como en Teoría de Sistemas; para más información sobre Teoría de Sistemas, lea el fantástico Thinking in Systems de Donnella Meadow ).

Systems Debt es la causa principal y principal de las formas de deuda posteriores que impiden o afectan negativamente la entrega, ya sea a través de decisiones comerciales, técnicas, arquitectónicas o de procesos. Es el producto de tomar atajos calculados en el negocio, poniendo el trabajo a crédito. La deuda del sistema impide que un sistema funcione a través de su diseño estructural.

En Thinking in Systems, Meadows proporciona un ejemplo simple de un sistema: una bañera. La entrada al sistema es el grifo, siendo la salida el desagüe. Meadows explica cómo diferentes factores pueden hacer que la tina nunca se llene, permanezca nivelada o se desborde. Un sistema óptimo es el nivel restante del agua, con la entrada (grifo) y la salida (drenaje) fluyendo al mismo ritmo. La Deuda de Sistemas sería la consecuencia de tomar atajos a la hora de componer el sistema. Para estirar la analogía de la bañera, tal vez el grifo esté mal instalado y el agua eventualmente se escape. Tal vez la ubicación del desagüe hace que se acumule agua en ciertas áreas, por lo que la bañera nunca se puede vaciar por completo. Tal vez nuestra agua necesita ablandarse y hace que se acumule cal.

En estos casos, no hay un impacto inmediato y aún es posible crear un sistema óptimo, pero lo que está oculto es la acumulación de deuda que está sobrecargando el sistema: el grifo tiene que fluir más rápido para compensar las fugas, o el grifo fluye más lento y la bañera tarda más en llenarse.

Si está familiarizado con el libro de Meadows, muchos de sus ejemplos tienen sus raíces en la realidad con modelos que generalmente brindan una visión estática; el sistema no cambia con el tiempo. Es perfecto para sus propósitos, pero cuando se trata de personas, equipos, operaciones y negocios, lo que somos hoy no es lo que seremos mañana.

Para definir Systems Debt de una manera ligeramente diferente:

Deuda de Sistemas = Teoría de Sistemas + Modelo de Madurez

Con los equipos de software, verá que la deuda de los sistemas se manifiesta de varias maneras:

• Con el tiempo, si no se administran, los equipos desarrollan cada vez más "conocimientos tribales". Estos aparecen como hábitos bien intencionados, atajos y soluciones alternativas. Debido a que producen eficiencias a corto plazo, dan como resultado que se pasen por alto las deficiencias a largo plazo. Si no se paga, existe un riesgo evidente de pérdida de conocimiento debido a la deserción regular. Esto conduce a pérdidas de productividad ya que los equipos tienen que girar y acelerar. ("Joe sabía esto, pero ahora que se fue, tendremos que dedicar tiempo a resolverlo") o una acumulación de deuda técnica debido a la falta de familiaridad. ("No podemos actualizar ese componente. Sally lo construyó, y cada vez que lo tocamos, se rompe...")
• Los equipos se basarán en patrones de diseño personalizados, reglas de desarrollo no oficiales o acuerdos que maximicen el flujo local, pero esos patrones son frágiles para cambiar. Esto impide la entrega cuando algo no se alinea con un patrón establecido, lo que mantiene al equipo comercial como rehén de las decisiones técnicas. ("No podemos activar una instancia personalizada, nunca la hemos diseñado de esa manera").
• Los equipos que se vuelven complacientes dan prioridad al mantenimiento del statu quo sobre las retrospectivas disruptivas. Es posible que aún realicen retrospectivas, pero si han perdido la fe en la capacidad de abordar los problemas reales, solo se centrarán en solucionar cosas triviales. ("Estamos sobrecargados con solicitudes de incidentes, pero lo que sea, solo tenemos que seguir resolviéndolos, supongo...")
• El malestar o la indiferencia que surge al alcanzar una velocidad sostenible a pesar de la fricción abordable. La velocidad sostenible crea una falsa sensación de eficiencia. ("¿Realmente necesitamos cambiar el proceso? Hemos alcanzado nuestro ritmo, ¿por qué interrumpirlo?")

Con los equipos de Producto y Operaciones, verá Systems Debt de manera similar:

• El método abreviado "cada llamada de un cliente es una alarma contra incendios" involucraba al equipo de desarrollo para solucionar rápidamente problemas menores, retrasos en los lanzamientos, reducción de la velocidad, etc. ("Necesito que el equipo analice un problema planteado por un cliente furioso, solo toma 20 minutos...")
• El caos de la última persona con la que hablé es mi máxima prioridad obliga al equipo a cambiar constantemente de contexto y no puede concentrarse en un problema hasta su finalización.
• Cuando priorizar es un atajo mediante el uso de métricas engañosas. Por ejemplo, el cliente caro que ya no está alineado con los objetivos comerciales. Tenían sentido en sus primeros días de puesta en marcha, pero a medida que el negocio ha madurado, ese mismo cliente se ha vuelto más problemático. ("No sabemos si querremos retener a este cliente, pero nos pagan mucho, así que tenemos que hacerlo...")

Para reiterar: todas las formas de deuda son cuando elegimos tomar un atajo ahora con la intención de arreglarlo más tarde. Deuda técnica es cuando hacemos esto con código. Proceso de la deuda es cuando hacemos esto con nuestros procesos formales. La deuda de sistemas es cuando hacemos esto a nivel organizacional. Prefiero verlo como 'Deuda de sistemas' en lugar de 'Deuda organizacional' porque pensar en la organización como un sistema significa que la Deuda técnica, de proceso y de diseño son todas causadas directamente por la Deuda de sistemas. Los factores que nos llevan a asumir Deuda Técnica están relacionados en última instancia con la Deuda de Sistemas. ("Solo puedes evitar que tantas personas se ahoguen en un río antes de comenzar a mirar río arriba para determinar por qué siguen cayendo").

Como ejemplo: el equipo de desarrollo está lanzando una nueva función que se planificó y presupuestó correctamente. El equipo ha ido por buen camino, pero en las etapas finales se encuentra con un problema que obliga a una temida pregunta: ¿Retrasar el lanzamiento al abordar el problema correctamente o hacer la solución mínima y luego resolverlo correctamente en la próxima iteración? Eligen asumir la deuda técnica: "Lo conseguiremos en la próxima iteración".

Aquí es ahora donde Systems Debt comienza a entrar en la ecuación. ¿Será realmente capaz el equipo de abordarlo? ¿Está el equipo adecuadamente capacitado para refactorizar? ¿Responderá el negocio con "es lo suficientemente bueno, tenemos que seguir adelante"? ¿Revelará el costeo futuro que ahora se ha vuelto demasiado caro para hacerlo de la manera correcta? ¿Un cambio en las prioridades o un aumento en los problemas urgentes retrasarán repentinamente la solución en otra iteración? Luego otra iteración, luego otra...

Además, mirando aguas arriba: ¿por qué tomó tanto tiempo encontrar el problema? ¿Qué malas suposiciones se hicieron? ¿Eran malas suposiciones? Siempre está el problema que no puedes determinar hasta el final del juego, pero entonces, ¿por qué se convirtió en una cuestión de retrasar el lanzamiento? ¿Se hicieron las promesas demasiado pronto? ¿Debería haber habido un amortiguador más grande? ¿Se habría resuelto esto si la Persona A (vendedor comercial ascendente) hablara más con la Persona F (desarrollador descendente) siguiendo la cadena más corta ?

Otro ejemplo demasiado familiar viene con la infraestructura, la arquitectura y los modelos de alojamiento en los que nos encerramos desde el principio, en función de las suposiciones sobre cómo escalará el negocio en 3 a 5 años. Un equipo pequeño puede optar por asumir una deuda de infraestructura y arquitectura desde el principio a favor de una entrega más rápida que adherirse a los mejores principios de DevOps.

Por supuesto, es fácil pintar escenarios como este sin los detalles, pero independientemente de los detalles y las excusas para esos detalles: se acumulará deuda de sistemas. Es inevitable. Eso está bien, solo requiere atención constante y se enfoca en pagarlo a niveles sostenibles.

Atajos de compensación

Asumimos la deuda, del sistema o de otro tipo, como un atajo. Antes de profundizar en Systems Debt y cómo pagarla, primero demos un paso atrás y preguntémonos por qué estamos tomando los atajos. Los atajos, al igual que la deuda, no son intrínsecamente malos, pero deben analizarse detenidamente.

Pensar en atajos físicos es una excelente manera de comenzar. Si alguna vez ha sido peatón o ciclista, seguramente habrá notado cómo las cosas están diseñadas primero para los vehículos y luego para los peatones. Cuando camina, termina tomando muchos "atajos" y no sigue las carreteras, pero por supuesto, estos no son atajos. Estos atajos son los caminos óptimos como las moscas del cuervo para un peatón que puede ir donde los autos no pueden. De hecho, construir nuestras rutas principalmente para autos en áreas muy transitadas por peatones es [otra forma] (otra forma) de Deuda de Sistemas.

En el mundo de los negocios, tomamos atajos para compensar, por falta de tiempo, falta de presupuesto, falta de recursos, falta de responsabilidad o falta de una visión más amplia. El tiempo, el presupuesto y los recursos son el centro de atención, pero la responsabilidad y una perspectiva amplia están exactamente en el centro de mi pregunta inicial: ¿Es esto más difícil de lo que debería ser? Cuando estás salvando a la gente de ahogarse en un río, estás mirando río arriba (perspectiva amplia) y apuntando a la persona (responsabilidad) que sigue empujando a la gente.

En otras palabras: si va a tener una conversación seria sobre Systems Debt, todos deben ser parte de la conversación. Los esfuerzos localizados solo llegan hasta cierto punto.

Entonces, ¿cómo se paga la deuda de los sistemas?

Volvamos a la pregunta anterior: ¿Qué tan fácil es para su equipo de entrega entregar? Si nunca ha considerado esta pregunta, ¡es hora de obtener algunas métricas! Estas métricas no necesariamente le darán las respuestas, pero son un punto de partida importante. Cuando se trata de KPI, el mejor consejo que he recibido es que un KPI individual no es bueno ni malo. Es objetivamente solo un número, un valor. Es su negocio como de costumbre, y usted decide si desea o no ajustar ese número hacia arriba o hacia abajo. Si eres fanático del sistema OKR o de los objetivos SMART, esto es genial porque conocer tus KPI te permite hacer mejores OKR que se cuantifican fácilmente.

Entonces, comencemos con algunos conceptos básicos y profundicemos en la maleza. Lo que sigue no es una lista completa, y puede haber preguntas más adecuadas para su grupo. Piense en esta lista como un punto de partida para hacer mejores preguntas.

Entrega:

• ¿Cuál es su tiempo de entrega y ciclo para artículos urgentes/de alta prioridad?
• ¿Cuál es su tiempo de entrega y ciclo para artículos de baja prioridad?
• ¿Cuánto ha asignado para pagar la deuda?
• ¿Cuánto está aumentando su Deuda?

Estas preguntas pueden parecerle familiares a cualquiera que realice un seguimiento del rendimiento de su equipo, pero recuerde formularlas a nivel de organización. El tiempo de entrega del desarrollador puede haber comenzado desde que se creó el ticket, pero ¿cuánto tiempo existió en la cabeza de alguien?

Recursos:

• ¿Cuál es el desglose actual de su equipo (senior vs juniors)?
• ¿Cuál es su riesgo de deserción entre seniors y juniors?
• ¿Cuál es el costo de perder a alguien mayor?
• ¿Cuál es el costo de perder a un junior?
• ¿Cuál es el costo y la duración de la contratación?
• ¿Cuál es la duración de su entrevista/incorporación?
• ¿Cuál es la duración de su capacitación/aumento (y qué recursos deben involucrarse y, por lo tanto, perder productividad?)

Cartera de negocios:

• Suponiendo que se define el Marco Estratégico del Gerente de Producto, ¿cuántas excepciones se hacen?
• ¿Cuántos Epics/Features no están arraigados en casos comerciales definidos objetivamente vinculados tanto a las finanzas como a los plazos?
• ¿Cómo se integra la canalización de Ventas/Desarrollo comercial en última instancia en su cartera de pedidos de software y cuál es el tiempo de entrega y ciclo para ellos?
• ¿Con qué frecuencia cambian los objetivos comerciales de alto nivel y cuánto afecta ese caos a los esfuerzos posteriores?
• ¿Cuáles son los objetivos de crecimiento a largo plazo de la empresa y cómo se alinean el conjunto de habilidades del equipo y el plan de recursos?

Cartera de operaciones

• ¿Cuántos problemas de los clientes se plantean diariamente?
• ¿Cuántos problemas de clientes deben ir al soporte de Nivel 1, 2, 3?
• ¿Cuál es el tiempo medio de resolución?
• ¿Cuál es el tiempo de espera para un problema del cliente y cuál es el tiempo desde la llamada inicial hasta que se crea el ticket de desarrollo?

Obtener una idea simple de cuánto tiempo lleva algo desde el inicio hasta la disponibilidad puede ser muy esclarecedor, especialmente cuando se trata de un problema del cliente.

Hay una serie de recursos que ayudan a mejorar las métricas anteriores, pero la filosofía clave detrás de todo esto es: 1) Medir, 2) Analizar, 3) Resolver, 4) Iterar. Cuantos más problemas el Nivel 3 pueda transferir al Nivel 2, más del Nivel 2 al Nivel 1, y más el Nivel 1 puede permitir que el Cliente los resuelva de forma independiente, más productivos se vuelven todos.

Desarrolladores:

• ¿Cuánto tiempo les toma agarrar la fuente y construir?
• ¿Con qué rapidez proporciona credenciales a los nuevos desarrolladores?
• ¿Qué tan rápido pueden ponerse de pie e interactuar con un entorno inferior de trabajo?
• ¿Cuánto tiempo le toma a un desarrollador lanzar el código a producción (medido desde su fecha de contratación)?
• ¿Cuánto tiempo lleva acelerar su SDLC y sus procesos?
• Si comienzan a mitad de Sprint, ¿cuánto tiempo se sientan al margen?
• En general, ¿cuál es su curva de aprendizaje actual?

A modo de comparación: Etsy es un gran ejemplo de eficiencia y lo convierte en un gran punto de referencia. Etsy garantiza que los desarrolladores implementen la producción en su primer día .

Visión holística:

• ¿Cuál es el proceso de entrega desde el inicio hasta la disponibilidad? Planifique el flujo de trabajo: ¿se puede optimizar?
• ¿Cuál es el viaje del cliente desde las ventas hasta los ingresos (y más allá)?
• ¿Qué son el RPO y el RTO?
• ¿Cómo se compara el rendimiento empresarial con los de alto rendimiento, como se describe en Accelerate: The Science of Lean Software and DevOps ?
• ¿Cuáles son los 10 mejores escenarios de desastres de pesadilla ? Esto es algo que FedEx hizo para mejorar sus operaciones y crear un "libro de estrategias" interno para convertirlos en la empresa que son hoy.

Dados todos los números y métricas detrás de lo anterior, reiteraré que cualquiera de estos números representa su negocio como de costumbre. Si bien no son intrínsecamente malos o buenos, Systems Debt hace que sea más difícil mantener estos números a largo plazo. Algunas cifras pueden resultar sorprendentes y revelar áreas en las que tal deuda ya puede haber tenido un impacto.

El siguiente paso es considerar cómo estas métricas cambian con el tiempo, a medida que ha madurado y continúa madurando. Como ejemplo, los ingenieros que construyeron el producto principal lo encerraron en una arquitectura que se acerca a los límites de su escalabilidad. En estos casos, los equipos buscan cómo pueden pagar la deuda técnica, pero ¿qué pasa con la deuda de sistemas? Dado un conjunto limitado de recursos, un riesgo creciente de desgaste y un negocio en proceso de maduración, ¿cómo mantiene los KPI de entrega mientras paga la deuda técnica?

'Mata a tus queridos', despide a tus 'estrellas de rock', destruye tus 'fábricas ocultas', deja de ser útil

Esas son un montón de declaraciones en negrita en un encabezado. El punto en todo esto es que: Ser "útil" para atajar un proceso puede ser peligroso. Si suscribimos la idea de que “lo que se mide, se hace”, el problema de ser útil es que a menudo no se mide .

Imagine un cliente que llama porque borró accidentalmente un registro en su portal cuando se movió demasiado rápido. Tienen poco tiempo y no pueden pasar por el proceso de restauración de un registro. Llaman y su empleado de Atención al cliente, queriendo ser útil, escala de inmediato al ingeniero de la base de datos quien, queriendo ser útil, restaura el registro de inmediato. El cliente está encantado, la puntuación NPS sube. Todo es genial, ¿verdad?

Ignorando los riesgos obvios de que alguien actualice una base de datos de producción por un momento, hay mucha información valiosa que se pierde al ser útil:

• ¿Por qué es tan fácil hacer una acción tan dramática que el cliente cometió el error en primer lugar?
• ¿Por qué es tan difícil deshacer la acción dramática que tuvieron que llamar?
• ¿Por qué el servicio de atención al cliente no pudo manejarlo?
• ¿Qué impacto en la productividad fue el resultado de ser útil y cambiar de contexto ? (Una tarea aparentemente simple de 20 minutos termina siendo más de 35 minutos debido al tiempo que lleva volver a un flujo productivo).

Seamos claros: mi titular está en negrita. Pero, no estoy abogando en contra de ayudar a un cliente; sin embargo, creo que tales acciones deben seguirse con un análisis de causa raíz. Nada demasiado formal, pero algo para evitar un problema similar en el futuro.

En una organización, mejoré la productividad de nuestro equipo de desarrollo en un 50 % simplemente implementando un Playbook. Un cliente llama y es recibido cortésmente por un representante de Atención al cliente que sigue un flujo de trabajo claro hacia la resolución. Si no pueden resolverlo, tenemos un circuito de retroalimentación para que solo escale el problema una vez. El resultado fue un equipo de atención al cliente más capaz y capacitado, un equipo de desarrollo con menos interrupciones, menos estrés en general y, lo que es más importante, clientes satisfechos.

El punto es que cuando el trabajo útil ocurre en las sombras, no se puede solucionar la causa raíz.

Vemos el mismo problema con el desarrollador Rock Star que asume demasiado trabajo y responsabilidad para compensar a un equipo menos calificado, solo para que se frustren, se agoten y se vayan (un costo que puede ser devastador). El gran libro de Will Larson, un rompecabezas elegante , hace un gran trabajo sobre cómo manejar sus "estrellas de rock".

El poder de los jóvenes...

Las personas mayores son fundamentales para el éxito de una organización y de un producto, pero son igualmente uno de los mayores riesgos.

Por ejemplo, un desarrollador sénior conocerá el código base de principio a fin. Saben lo que está documentado y lo que no. Sabrán dónde escala bien y dónde se deshace. Ellos sabrán dónde están enterrados los esqueletos. Recurrimos a ellos a menudo, confiando en ellos para crear y diseñar características, diseñar soluciones y ayudar a resolver los errores más complicados. Son los gurús del conocimiento que pueden responder cualquier pregunta. Capacitan y asesoran al personal subalterno y son consultados cuando desarrollan soluciones.

Baste decir que se le pide mucho al personal superior. Es una declaración obvia, dada su experiencia y tal vez su interés personal en el éxito de la organización. Sin embargo, diría que aquí es donde asumimos la mayor parte de la deuda de sistemas.

Cualquier miembro senior del personal que progrese en un entregable es un atajo que acumula deuda de sistemas.

Reitero porque es fácil malinterpretarlo. Puede hacer que un miembro sénior del equipo trabaje en una entrega, pero debe planear pagar la deuda que se habrá acumulado al hacerlo.

Confiar en Seniors para los entregables es un modelo roto, particularmente en el mundo actual, donde hay muchos candidatos Juniors y Skilled Entry-Level, y el riesgo de abandono de Intermedio a Senior es alto y costoso .

La fuerza de trabajo virtual remota ha hecho que sea más crítico para cualquier organización elevar al equipo junior/intermedio mientras reduce el impacto del desgaste del personal sénior. Esto no significa disminuir el personal senior, pero sí significa una diferencia estructural en el enfoque.

Usando una generalización, los equipos sénior de hoy en día son en gran parte responsables de las complejidades detrás de los sistemas: su experiencia y pericia producen sistemas maduros, y los componentes más pequeños basados en tareas son implementados por los miembros más jóvenes del equipo.

Este es exactamente el modelo que resulta problemático cuando un miembro del equipo Senior se va, y también la estructura que acumula Sistemas de Deuda. En esta situación, el senior es responsable de las complejidades y puede intervenir para ayudar cuando el equipo junior no puede cumplir (el desarrollador "Rock Star", por ejemplo).

Este problema se ve agravado aún más por la tasa actual de deserción del personal: por ejemplo, los desarrolladores junior a nivel nacional permanecerán en un puesto durante 18 a 24 meses (más tiempo en las empresas más grandes). En otras palabras, cuando un Junior llega a un punto en el que puede comenzar a hacer contribuciones más significativas, ya está saliendo.

Las organizaciones lucharán para retener al personal sénior, lucharán (algo) para retener al personal junior, y sufren constantemente una fuga de conocimientos. En última instancia, esta es una batalla perdida: incluso si se retiene al personal o se unen nuevos miembros al equipo, ahora se encuentran en una posición en la que tienen que pagar una gran cantidad de deuda de sistemas.

Haga un buen trabajo más fácil y acepte lo inevitable

Imagina un pequeño restaurante con estrella Michelin. El jefe de cocina está muy involucrado en la elaboración de los platos, con platos demasiado complejos para repartir entre un equipo de cocineros. El chef es el restaurante en este caso.

Compare esto con los restaurantes de franquicia más amplios. Tiene un jefe de cocina en Corporate cuya responsabilidad no es producir platos que consuman los clientes. En cambio, su objetivo es producir platos reproducibles. Platos que se pueden reproducir fácilmente (sin dejar de ser sabrosos). Platos que están optimizados de tal manera que la curva de aprendizaje es mínima: los nuevos cocineros pueden capacitarse fácilmente para producir los platos, y la pérdida de su eventual partida tiene menos impacto. Los jefes de cocina también se asocian con expertos en eficiencia para ver cómo se puede optimizar la cocina de la franquicia para la entrega.

Este es el modelo que debemos usar cuando pensamos en el equipo moderno. La responsabilidad del equipo senior no debe ser la complejidad del producto. Debe centrarse por completo en simplificar la entrega: simplificar la capacitación y la puesta en marcha, los tiempos de configuración, los tiempos de construcción, la racionalización de los tiempos de entrega y de ciclo (en general, desde la solución de ventas/productos hasta la planificación de la iteración y el lanzamiento).

¿Cómo estructurarías las cosas si sabes que solo puedes retener a las personas durante 18 meses? De hecho, ¿cómo estructurarías las cosas si les pusieras un contrato de 18 meses, con una rescisión definitiva al final? Querrás que la aceleración sea lo más rápida y breve posible. Querrá que su equipo de expertos se asegure de que sus nuevas contrataciones puedan aumentar en semanas para que puedan maximizar el impacto. Querrá asegurarse de que su equipo de expertos pueda mantener una puerta giratoria que maximice la eficiencia y nunca intervenga para ayudar (por el riesgo de acumular deuda).

Al crear un sistema que pueda ser más adaptable, que pueda adoptar y aprovechar el empleo a corto plazo, reducirá posteriormente el impacto si pierde a un miembro del equipo sénior porque el conocimiento se inmortaliza en el proceso, no en las personas.

ETIQUETA usted es él

¿Quién te enseñó a jugar a la mancha? No importa en qué parte del mundo te encuentres, es probable que hayas aprendido a jugar este juego de otros niños. Los adultos no necesitan enseñar a los niños a jugar a la mancha.

Pensamos en los memes como imágenes divertidas, pero la definición original de un meme es un elemento de una cultura o sistema de comportamiento que se transmite de un individuo a otro por imitación u otros medios no genéticos.

La etiqueta es un meme. Nadie es dueño de las reglas. Nadie es responsable de mejorar el juego. De hecho, las reglas son simples y aún admiten variantes como Freeze Tag. Además, se puede adaptar a diferentes entornos. Está diseñado para una puerta giratoria de niños que eventualmente se convierten en adolescentes que son demasiado geniales.

Hay muy poca deuda de sistemas en un juego como Tag. Compare Tag con otros juegos de juegos que requieren más jugadores o más equipo... British Bulldog, Dodgeball, Duck Duck Goose, Cops 'n Robbers, Red Rover. Tal vez has jugado estos juegos, tal vez no. Estos juegos conllevan un poco más de deuda de sistemas. Más reglas, más equipo o más jugadores significa que se necesitan más facilitadores.

Entonces, ¿cómo podemos operar como Tag?

1. Aproveche las personas mayores para bajar el listón . Las personas mayores no están allí para jugar Tag o entregar la especificación. Su objetivo es bajar el listón: ¿cómo pueden las personas entrenar más rápido y entregar valor más rápido? ¿Cómo pueden los lanzamientos frecuentes, incrementales y regulares con bajo riesgo de impacto? (*tos tos* DevOps, Agile)
2. Mapee los procesos, mapee los flujos e identifique los cuellos de botella: tal vez el problema no sea el equipo de software. Tal vez no sea la falta de un equipo de pruebas dedicado. Tal vez el problema está aguas arriba: ¿el negocio está sobrecargando la canalización de entrega con prioridades en conflicto?
3. ¿Cuál es el motor para que la gente se tome un descanso? No hay absolutamente nada de malo en tomar un descanso, pero a menudo son indicios sorprendentes de un trasfondo de frustración. El seguimiento de cuándo y por qué alguien se retira puede ser muy informativo: tal vez se hayan retirado porque el código tarda un tiempo en compilarse e implementarse. Tal vez se han alejado porque necesitan pensar más profundamente sobre un desafío al que se enfrentan. (Esto no es algo malo, pero ¿podría haberse desglosado el problema para reducir la complejidad?) Tal vez se hayan alejado porque la necesidad de un cliente los está frustrando. Tal vez necesiten salir a tomar aire porque una nueva característica está forzando un rediseño o revelando una mala suposición.
4. Observe la falta de descansos: igualmente revelador es cuando alguien está demasiado cabizbajo. No pueden alejarse, se requiere su atención. Esto significa que existe una dependencia demasiado grande de alguien, o que el trabajo y el alcance se han definido de manera demasiado amplia, o que el sistema subyacente es mucho más complejo de lo que debería ser.
5. Construir una cultura de simplificación. Es decir, sus Gerentes, sus Mayores, sus Intermedios, todos deberían estar facultados para decir: "Esto es más complicado de lo que debería ser, ¿cómo podemos hacer esto más fácil?" Recopile comentarios, especialmente de los jóvenes. Los jóvenes no se valoran lo suficiente. No cometa el error de pensar que su falta de experiencia significa que son ingenuos. Es posible que los jóvenes no siempre sepan que hay mejores formas, pero son muy francos acerca de dónde gastan (y desperdician) su energía.
6. Siempre que un Senior contribuya a una entrega, averigüe por qué. Cada. Tiempo. Un error de P0 en producción requería una corrección urgente. El código de bajo nivel requería un cambio. Un cliente necesitaba una discusión. Los ejecutivos necesitaban una presentación para una actualización.

Una marea creciente levanta todos los barcos. Las personas mayores deberían ser la marea, no los barcos.

La prueba está en el pudín

Un principio rector a lo largo de mi carrera ha sido comprender cómo el problema afecta la productividad. No ha sido hacer equipos más eficientes sino equipos más impactantes. Los Gerentes de Producto tienen el mantra de medir el Resultado, no el Producto. La eficiencia es importante cuando sabes lo que estás haciendo y solo necesitas hacerlo más rápido. El impacto es un objetivo amorfo, mal definido y en movimiento. Requiere adaptarse. Es por eso que los principios Agile, OKR, Lean y Kanban pueden ser tan poderosos cuando se usan correctamente.

Centrarse en los resultados de todo el sistema y pagar la deuda de los sistemas me ha dado la oportunidad de tener un impacto en una variedad de formas.

• Para un negocio de SaaS, mapear el proceso completo desde la etapa inicial de preventa hasta la implementación del código en producción. Medición del Lead y Cycle time desde la perspectiva de cada etapa para identificar cuellos de botella. Al verlo como un sistema, podríamos identificar cómo calificar mejor, descalificar mejor, y cómo y cuándo reestructurar el proceso de ventas e implementación según el tipo de cliente. La aplicación de un enfoque Kanban de tirar del trabajo en lugar de empujarlo, establecer límites WIP estrictos (sin dejar de tener en cuenta la holgura; consulte la analogía Drum-Buffer-Rope de Goldratt ) y formalizar la Definición de Listo nos permitió mejorar continuamente el flujo de trabajo en sí. Por último, un principio adicional, en este caso, era no permitir que el proceso impidiera la productividad . Al crear una ruta acelerada, las cosas podrían moverse más rápido donde fuera posible (es decir, "atajos"), pero siempre vino con un análisis de dónde falló el proceso de referencia (es decir, pagar la deuda del sistema). Esto simplificó las implementaciones de 6+ semanas a 2 y se convirtió en un sistema autogestionado.
• Dotar de personal con una filosofía de Juniors First me permitió cuadruplicar el tamaño de nuestro equipo en 6 meses. Al reducir el tiempo de preparación y centrar el equipo sénior en torno a la productividad de los jóvenes, significaba que podíamos aceptar lo inevitable y predecir el desgaste . Este enfoque dejó a cualquier Junior que alcanzara su marca de 2 años con dos opciones atractivas: graduarse en un rol más intermedio donde su enfoque cambió hacia habilitar a los Juniors a medida que continuaron desarrollando sus habilidades, o trabajar con el equipo en una salida amistosa. Esta transparencia ayudó a combatir la picazón de 2 años que tienen los Juniors cuando se enfrentan a la incertidumbre de su carrera.
• Reuniendo a los equipos de Operaciones y Desarrollo bajo un mismo proceso. Esto alineó a los equipos para que, en lugar de flujos de trabajo paralelos, fuera circular: la salida del equipo de operaciones era la entrada del equipo de desarrollo. La salida del equipo de Desarrollo se convirtió en la entrada del equipo de Operaciones. Al implementar un libro de jugadas "vivo" , con ciclos de retroalimentación estratégica, los equipos se volvieron cada vez más autosuficientes. Esto liberó al equipo senior de estar involucrado en las operaciones y redujo los plazos de entrega de más de 7 meses a 3 semanas.
• Girar la vista del equipo de desarrollo de SaaS desde las etapas de desarrollo de software (definición, implementación, validación, lanzamiento) hasta el enfoque en el cliente con énfasis en el impacto y al mismo tiempo priorizar el trabajo que está más cerca de completarse. Esto permitió que los equipos de entrega tuvieran un mejor sentido del impacto y las prioridades y permitió que la empresa fuera más consciente y crítica con el trabajo/clientes de bajo impacto.
• Inversiones en la racionalización del proceso de desarrollo iterativo mediante la reducción de los tiempos de construcción e implementación. Este fue uno de esos momentos de "Observación de los descansos" en los que el equipo se alejaba con frecuencia debido a la impotencia de un largo proceso de construcción/implementación. Es importante destacar que la solución no fue completamente técnica, sino basada en un proceso. Al establecer un nuevo proceso, los equipos de entrega se volvieron un 200 % más productivos.
• No crear software para las ineficiencias del proceso. Por mucho que me guste escribir código para resolver problemas interesantes, el nuevo código debería ser el último recurso. Incluso si el código no tiene atajos ni deuda técnica propia, es necesario mantener el código. Ha introducido más deuda de sistemas y no ha abordado la raíz del problema. Estos casos están muy extendidos y se pasan por alto fácilmente, pero son el equivalente a resolver una gotera en el techo colocando un balde en el piso. La eliminación de estas soluciones al abordar el problema de raíz crea eficiencias inconmensurables y permite que el equipo trabaje en lo que importa.

Pero solo soy un gerente de nivel medio, ¿cómo puedo implementar un cambio en toda la organización?

Escribí anteriormente que los esfuerzos localizados solo llegan hasta cierto punto y lo mantengo. Cuando toda la organización toma una mirada crítica sobre cómo ser más eficiente, ahí es donde se ve una mejora real. Los esfuerzos localizados solo llegan hasta cierto punto, pero llegan lejos, y cuando lo hacen, traen consigo el capital de influencia.

la comida para llevar

Concluiré con estos principios finales:

1. La deuda de sistemas se acumula por cualquier atajo comercial (software, diseño, proceso u otro). Eso, por sí solo, está bien.
2. Demasiada deuda es algo malo y requiere un pago continuo e intencional.
3. Este pago debe ser realizado por el equipo Senior. El equipo sénior también debe centrarse en cómo reducir el riesgo de asumir deudas futuras (buscando primero las ineficiencias locales y luego las ineficiencias de todo el sistema). Las personas mayores no deben trabajar en entregas, pero cuando lo hacen debe ser una vez. Establezca ciclos de retroalimentación que pregunten "¿Por qué fue esto necesario y cómo podemos prevenirlo en el futuro?"
4. Una buena medida de la salud de la deuda de sistemas es observar la salud de la incorporación de su equipo junior. Planifica que tu equipo Junior se vaya después de 18 meses. Está bien. Permita que el equipo Senior los haga eficientes lo antes posible.
5. Envalentonar la voz del equipo Junior para identificar problemas. Incluso los problemas ingenuos son indicativos de un problema más serio ("¿Cuándo obtengo mi dirección de correo electrónico?"; "¿Cómo puedo obtener datos de prueba?"; "¿Qué hace nuestro equipo?"; "Acabo de obtener el código fuente y Recibo errores de compilación").
6. Planifique que cualquier persona en cualquier rol se vaya después de 18 meses. Esto también está bien. El equipo sénior debe estar allí para trabajar en la creación de procesos y canales que permitan una entrega continua a pesar de las interrupciones . Deben estar construyendo procesos autosuficientes, equipos autogestionados y autoorganizados. El Equipo Junior eventualmente debería aburrirse del trabajo, porque se ha vuelto repetitivo. Los miembros del equipo deben hacerse constante y activamente redundantes e innecesarios.
7. Plan para aquellos que se quedarán más allá de los 18 meses. A pesar de trabajar para hacerse redundantes, nunca se quedará sin trabajo que impulse la eficiencia. Defina un Marco de Carrera que eleve a los Juniors a Intermedios, Intermedios a Seniors que se alinee con las eficiencias enfocadas en los resultados.
8. Trate el primer día como si fuera el último día: el primer día en el trabajo, los empleados tienen la mejor perspectiva de lo que se necesita para incorporarse. Deberían estar pensando: si alguien más se uniera después de que me haya ido, ¿cómo se podría mejorar esto?
9. Organice reuniones periódicas solo para preguntas estúpidas. Permita que las personas envíen (de forma anónima) sus preguntas más estúpidas. Encontrará las mayores lagunas de conocimiento (y problemas) de esta manera. Estos deben ser abordados.
10. Programe reuniones periódicas de 'pago': reúna al equipo sénior y busque ineficiencias. Cuesta su impacto. Cuesta su resolución. (Esta lista es la razón por la cual su equipo sénior nunca se quedará sin trabajo).
11. La parte más importante de Agile es su adaptabilidad. Ajuste con frecuencia. Tener bucles de retroalimentación. Lo que funcionaba antes no funcionará siempre. Eso no es un problema, esa es la norma. Cualquiera que se resista al cambio continuo y la experimentación es una parte más grande del problema de lo que cree.
12. Por último, y quizás lo más importante: este no es un ejercicio de 'equipo'. Este debe ser un ejercicio de toda la empresa. Si bien puede impulsar las eficiencias locales dentro de su equipo, solo llegarán hasta cierto punto. Dicho esto, si no está en una posición para influir en un enfoque de toda la organización, obtenga la aprobación de su gerente y luego cree estatutos alrededor de sus equipos que aíslen a su equipo de factores externos. Trabaje con su gerente para definir el alcance de su sistema más pequeño, sus entradas y salidas, y obtenga su aprobación sobre cómo planea evaluar, hacer crecer y pagar su deuda de sistemas.

¡Eso es todo! (Escribió, reconociendo toda la ironía de haber escrito su artículo más largo).