Últimamente, seguí reflexionando sobre dos temas que comparten un tema similar. El primer tema tiene que ver con la infraestructura pública del estado de California y cuán ineficiente se ha vuelto a lo largo de los años. El segundo es el fracaso de las grandes empresas de tecnología para innovar y ejecutar más rápidamente que los titulares de inicio. Permítanme brindarles algunas perspectivas sobre por qué estos temas están relacionados, primero brindándoles dos ejemplos para pensar:

• Infraestructura : El puente Golden Gate tardó unos cuatro años en construirse (1933–1937) y nos costó ~$500 millones en dólares actuales. Por el contrario, el SDS ( Suicide Deterrent System ), que básicamente agrega una red alrededor del puente, nos llevará cinco años completarlo (2017-2023) y se prevé que nos cueste ~ $ 217 millones. Si hace una revisión de los principales proyectos de infraestructura en California, encontrará que para los proyectos completados antes de la década de 1950, el trabajo se hizo más rápido, más barato y con mayor calidad que en la actualidad en al menos una magnitud 5 veces mayor, aunque hoy tenemos más capital, mejor tecnología, mejores materias primas y un mayor número absoluto de ingenieros civiles y arquitectos.
• Empresas tecnológicas : Adobe, a pesar de todos sus recursos financieros y humanos, se ve en la necesidad de adquirir un competidor por 20.000 millones de dólares. Queda por ver si Adobe pagó de más por Figma, pero la pregunta más interesante es ¿por qué una empresa con 100 veces el personal, 100 veces la experiencia en herramientas de diseño y 100 veces el capital financiero no pudo ganar?

Del mismo modo, si observa dentro de las empresas, es posible que descubra que, a medida que crecen, procesan y se hinchan, se infiltran en cualquier cosa y reprimen el trabajo real y la innovación. En ese entorno, los empleados que están más ansiosos por crear cosas, los creadores, encuentran que es más atractivo irse a un lugar más pequeño donde su trabajo tiene una salida para materializarse. Tanto las fallas en la infraestructura como las fallas en la innovación de la empresa se deben, al menos en parte, a la expansión y la lentitud de los procesos.

¿Por qué ocurre la fluencia del proceso?

Todo proceso comienza con buenas intenciones.

• “Queremos asegurarnos de que todas las partes interesadas participen en el trabajo final, por lo que todas las propuestas de proyectos enviadas deben ser revisadas por equipos legales, de diseño, de productos e ingeniería”.
• “Queremos asegurarnos de que los grandes proyectos de infraestructura no causen daños, por lo que debemos realizar estudios ambientales exhaustivos antes de comenzar cualquier trabajo”.
• “Queremos minimizar las violaciones de datos, por lo que cualquier solicitud de datos debe realizarse a través de los equipos de TI y Seguridad”.

El camino al perfeccionismo

Recuerdo haber escuchado a un gerente bien intencionado decirle a sus subordinados directos que escribieran software como si fuera a durar 100 años. Aunque el comentario fue hiperbólico, el consejo hace eco de algo que he escuchado a menudo en la industria de la tecnología a través de adagios como "mide dos veces y escribe una vez" o "si no tienes tiempo para hacerlo bien, ¿tienes tiempo para hacerlo?" dos veces? Este no es un mal consejo. En algunas situaciones, debe escribir código como si fuera a durar 100 años ., e ir de cabeza a la ejecución sin planificación es un desperdicio. No obstante, el énfasis extremo en la planificación puede conducir a la parálisis y a la falta de reconocimiento de los beneficios del aprendizaje a través de la iteración. Preferiría vivir en un mundo donde el software se reescribe cada año porque existe un fuerte reconocimiento de que la perfección no existe y que el requisito previo para la evolución es el cambio, en lugar de un mundo donde las cosas se ejecutan en " bases de código de 50 años ".

demasiado pegamento

Hace muchos años leí la publicación de blog de Tanya Reilly sobre ser Glue (lectura muy recomendada, por cierto). En ese momento de mi carrera, el contenido realmente resonó porque estaba tratando con algunos colegas que, aunque eran técnicamente competentes, simplemente no estaban trabajando en las cosas correctas. La gente de Glue se involucra en un proceso de liderazgo técnico y tutoría que lleva a hacer que otras personas en el equipo sean más productivas. Se necesita cierta cantidad de pegamento, sin embargo, descubrí que demasiado pegamento crea una serie de otros problemas:

• Las personas que trabajan con pegamento evitan que otras personas mejoren sus habilidades no técnicas. Por ejemplo, un Tech Lead que no permite que su equipo hable sobre su trabajo o que, a menudo, actúa como un "amortiguador" esencialmente le está quitando oportunidades a los IC para luchar y eventualmente mejorar sus habilidades de comunicación.
• Las versiones extremas y tóxicas del comportamiento del pegamento a veces se manifiestan al atribuirse el mérito del trabajo de otras personas o al generar una atribución muy exagerada (“por ejemplo, sin que yo actúe como intermediario, el proyecto no tendría éxito”). Si bien Tanya habla sobre las situaciones en las que la gente de Glue a menudo no es reconocida, mi experiencia es completamente opuesta. Debido a que la gente de Glue es buena comunicadora, sabe cómo publicitar su trabajo y jugar bien a la política. A cambio, terminan con una mayor visibilidad y más oportunidades de promoción, mientras que el ingeniero que trabaja en los detalles de implementación a menudo obtiene un reconocimiento simbólico o ningún crédito.
• Por último, agregar demasiadas personas a cargo reduce la propiedad y la responsabilidad de los ingenieros individuales. En lugar de agregar personas de apoyo para administrar un equipo técnicamente competente, simplemente dejaría de lado a los ingenieros que parecen no tener intuición comercial, carecen de habilidades de comunicación o no pueden armar un párrafo que describa por qué el trabajo que realizan es impactante. Sugerir que se necesita más pegamento para administrar ingenieros termina descartando el patrón general de que las personas que son técnicamente brillantes también tienen un alto nivel de inteligencia general, leen mucho, aprenden de por vida y son muy buenos en los negocios y no solo en el código.

Cuando estaba en Novell, me enteré de que había personas a las que llamo "personas adhesivas". La gente del pegamento es una gente increíblemente agradable que se sienta en los límites intersticiales entre los grupos y ayuda en la actividad. Y son muy, muy leales, y la gente los ama, y ​​no los necesitas en absoluto.

En Novell, seguí tratando de deshacerme de estas personas pegajosas, porque estorbaban, porque ralentizaban todo. Y cada vez que me deshago de ellos en un grupo, aparecían en otro grupo, y se transferían, los volvían a contratar y todo eso.

entropía

A medida que crecen las organizaciones, aumentan el conocimiento institucional, el número de partes interesadas, las bases de código y la entropía. El aumento de la entropía conduce a un alto desperdicio, una alta carga cognitiva, desorganización y caos.

Como ingenieros de software, creo que hemos hecho un trabajo de mierda en la gestión de la complejidad. Por ejemplo, durante años hemos escuchado que los monolitos son malos porque generan bases de código infladas, dificultan las implementaciones o crean problemas de escalabilidad. Sin embargo, en el otro extremo, donde tenemos que operar en un mundo de microservicios, encuentro que para enviar cosas básicas necesito operar en múltiples bases de código escritas en diferentes idiomas, cada una con sus peculiaridades de implementación y patrones de arquitectura, con todo el paradigma convirtiéndose en espagueti lambda . Detenerse y volver a concentrarse en lo que es importante tiene un gran impacto en la reducción de la entropía. En un nivel bajo, orientado a la acción, puede manifestarse de la siguiente manera:

• Eliminación de código muerto que no se ejecuta en producción. He interactuado con tantas bases de código en las que >50 % del código era código inactivo y creaba una carga cognitiva para los colegas. Desearía que hubiera algo en el espacio de productividad de desarrollo que generara cobertura de código basada en líneas ejecutadas en producción. Cada trimestre, se detiene y revisa esos informes y simplemente elimina los archivos que no tuvieron ejecución.
• Como gerentes de producto, no reflexionamos lo suficiente sobre qué características debemos eliminar o revertir. Sin embargo, detenerse y reflexionar sobre lo que debe eliminarse puede ser muy significativo para simplificar y mejorar la experiencia del usuario. Me considero un experto en tecnología, pero encuentro que muchos de los productos creados hoy se han hiperoptimizado en un conjunto de usuarios existentes, lo que lleva a una experiencia UX desordenada y confusa para los nuevos usuarios. Preguntar al final del trimestre "¿Qué función podemos cancelar?" puede ser útil para reducir el desorden.

El ego es el enemigo

Ryan Holiday sugiere en su libro Ego is the Enemy, existe una fuerte "tentación que existe para todos, de hablar y exagerar para reemplazar la acción". El ego es una gran razón por la cual el progreso y la innovación pueden ser mediocres en muchas instituciones. Así es como se manifiesta el ego:

• Ver a las mismas personas ansiosas por expresar sus pensamientos en una conversación grupal, a pesar de que sus ideas agregan poco o ningún valor marginal.
• Tener gente que nunca se dedica a patrocinar activamente a sus compañeros o que intenta acaparar visibilidad. Si es gerente o gerente de gerentes, puede notar esto al ver con qué frecuencia su informe directo habla sobre los éxitos o las contribuciones de otras personas en sus 1:1. La falta de reconocimiento o patrocinio desinteresado de otras personas puede ser un signo de un ego enfermizo.
• Optimización para el equipo en lugar de la empresa u organización en general. Tomé prestado el diagrama de Staff Engineer's Path de Tanya Reilly y ejemplifica perfectamente este problema donde los equipos optimizan para el máximo local. Por ejemplo, ¿estaría de acuerdo con disolver su equipo y redistribuir empleados a otros equipos si dentro de su dominio está ingresando al modo de mantenimiento? La mayoría de los gerentes nunca harían eso porque significaría perder capital social y político dentro de la empresa.

• Dependiendo de su rol, existe una dicotomía muy fuerte en términos de cómo ve el valor de las reuniones. “ La mayoría de las personas poderosas están en el horario del gerente ”. Desafortunadamente, su percepción del valor de las reuniones crea una anulación cultural que afecta a las personas que prefieren tener tiempo ininterrumpido para pensar en un problema y una solución. Incluso con fines de lluvia de ideas, la evidencia sugiere que la lluvia de ideas en grupo es una pérdida de tiempo . Sin embargo, ¿por qué tantas organizaciones infladas terminan dedicando la mitad del tiempo de los CI a las reuniones?

Conclusión

El motor de la innovación se basa en el cambio evolutivo. En última instancia, si una institución se vuelve rígida y no se adapta al cambio, tendrá una muerte lenta. En mi experiencia, la introducción de un proceso a menudo tiene costos no deseados que conducen a una velocidad reducida. En su lugar, me centraría en lo siguiente:

• Favorecer la iteración y aprender de los errores en lugar de intentar alcanzar el perfeccionismo.
• La gente de cola es necesaria, pero tiene que haber un límite en su número, para que puedan actuar con gran influencia. La simple contratación de personas que sean técnicamente competentes y tengan una buena intuición comercial puede resolver la necesidad de sobrecontratación para roles de pegamento.
• Por último, me centraría en reducir la entropía preguntando constantemente qué se puede descartar y recompensando a las personas por un comportamiento que aumente la simplicidad.