Priorice los resultados DevOps y ágiles, no la transformación

LAS VEGAS - La transformación digital, invariablemente, conlleva cierto nivel de equipaje. Puede implementar diferentes herramientas, pero las personas que siguen los procesos son más difíciles de cambiar. No puede comprar el convencimiento.

En la Cumbre de DevOps Enterprise, gran parte de la discusión se relaciona con la cultura y la organización de TI, desde cómo ganarse los corazones y las mentes de los ejecutivos, hasta convencer a los gerentes de proyecto y desarrolladores para que cambien sus tareas diarias. Los miembros del equipo técnico pueden tener dificultades para ver el bosque por los árboles; se centran en su desarrollo individual, prueba y otras responsabilidades en lugar del concepto de valor comercial.

Jon Smart es socio y líder de agilidad empresarial en Deloitte, una firma internacional de consultoría de gestión. Tiene un consejo contraintuitivo para las empresas que desean escalar lo ágil o implementar una transformación ágil: No lo haga.

«Es un poco como si una organización quisiera colgar una pintura, [y] ágil es el taladro [que crea] un agujero en la pared, para colgar la pintura», dijo Smart. «Entonces, si hace una transformación ágil, es como hacer una transformación de perforación; termina con una pared llena de agujeros, pero sin una pintura colgada».

Smart tiene experiencia práctica. Lideró el camino en iniciativas ágiles, DevOps y de mejora continua en toda la empresa en su rol anterior, como jefe de formas de trabajo en Barclays Group.

Él recomienda que los equipos de desarrollo y los gerentes de proyecto se centren en los resultados de DevOps y ágil, no en los cambios de proceso. Con las barreras de protección adecuadas para proteger el negocio y un enfoque en resultados DevOps y ágiles clave, dijo, los equipos de desarrollo están motivados en la dirección correcta. Smart se centra en cinco resultados en particular:

• mejor
• valor
• cuanto antes
• más seguro
• más feliz.

Una Transformación Digital, ágil o DevOps a medio cocer puede impulsar una o dos categorías, pero a expensas de otras. Un enfoque en los resultados ágiles y la libertad para expresar la creatividad, dentro de límites, puede generar la tarea técnica necesaria y procesar los cambios de forma natural.

«Usted está incentivado para aumentar la calidad, el flujo, la felicidad y la seguridad; y se equilibran entre sí, porque no puede apostar artificialmente el sistema», dijo Smart. «Si apuesta el sistema, uno de [esos criterios] sube y los otros bajan. Entonces, se equilibran entre sí».

En el podcast, Smart caracteriza los resultados ágiles como una motivación intrínseca para los equipos tecnológicos y el empoderamiento. También comparte cómo los líderes rígidos y sin apoyo pueden deshacer rápidamente todo el progreso que hace una organización de alto funcionamiento hacia la mejora de procesos en una transformación digital.

«Puede haber alguien que tenga una mente bastante abierta y empoderadora, y [entonces] entra alguien más tradicional, que tiene más comando y control», dijo Smart. «Esas organizaciones, las veo ir hacia atrás. Van hacia atrás muy, muy rápido».

En esencia, argumenta, el desarrollo de software debe ser fluido y adaptable para satisfacer las necesidades del cliente. Es una descripción que encaja bien con la mentalidad ágil.

«Ahora estamos en la era del software y lo digital, donde la naturaleza misma de lo que producimos es diferente cada vez», dijo. «Este es el gran cambio, porque el esfuerzo humano organizado debe ser bueno en la emergencia, donde no se sabe lo que se va a construir; no se sabe cómo se va a construir; no se sabe lo que la gente quiere».

Escuche el podcast para escuchar también a Smart sumergirse en cómo DevOps se combina con la seguridad y el cumplimiento, una preocupación creciente en la era de los crecientes ataques cibernéticos.

Nota del editor: Smart habló con el editor del sitio SearchSoftwareQuality, David Carty. La transcripción ha sido ligeramente editada para mayor claridad y por brevedad.

En primer lugar, ¿qué espera ganar de conferencias como esta? Usted se presenta en espectáculos como DevOps Enterprise Summit, e imagino que tiene un par de objetivos diferentes cuando viene a un espectáculo como este. ¿Cómo le son útiles estos tipos de conferencias y qué saca de ellas?

Jon Smart: En resumen, aprendizaje compartido. Es una comunidad fantástica para compartir el aprendizaje, y es a la vez dar y recibir. Creo que es genial tener personas que se salgan de los límites de las organizaciones en las que trabajan. Vienen y comparten las cosas que han funcionado, las que no han funcionado y las lecciones aprendidas. Entonces, eres una especie de asistente [incluso como orador]. Me encanta, es mucho que aprender en muy poco tiempo.

Se puede ver los patrones que se repiten y los antipatrones que se repiten. Las cosas que generalmente tienden a funcionar están más basadas en principios que en prácticas, los tipos de enfoques que funcionan. De lo que se trata también es de compartir sus propias experiencias, porque de lo contrario tiene estas burbujas de aprendizaje en las empresas: las personas no comparten [conocimiento]. Puede haber una burbuja de genialidad en una organización, pero si la gente no habla de su burbuja de genialidad, se quedará en la burbuja, es un efecto de burbuja. Entonces, se trata de compartir.

También usted es miembro del comité de programación de DevOps Enterprise Summit, ¿verdad? ¿Cómo intenta evaluar las tendencias de DevOps y cultivar un plan de estudios en torno a eso? ¿Y cómo básicamente lo clasifica todo en algo comprensible para los asistentes y útil para ellos?

Jon Smart

Smart: Entonces, Gene [Kim, fundador de IT Revolution], presenta algunos temas y, como comité de programación, discutimos y acordamos los temas cada año. Tratamos de tener alguna variedad en los temas, los tipos de charlas. Cuando Gene habló en la apertura del primer día, compartió el porcentaje de charlas por tema. Intentamos asegurarnos de que haya un buen equilibrio entre operaciones, la división entre tecnología y negocios, liderazgo, etc., y repetir conversaciones también. Creo que repetir las conversaciones es importante porque puedes seguir organizaciones en el viaje de varios años. En mi experiencia personal, muchos de los aprendizajes se dan en el tercer y cuarto y quinto año, no en el primero y segundo. Intentamos asegurarnos de que haya un equilibrio, nos esforzamos mucho por tener la mayor diversidad posible en los oradores, lo buscamos. Cada vez más, [estamos] tratando de subir a gente nueva al escenario principal que no ha hablado allí antes. Entonces, ahora, algunos de los oradores que repiten están hablando en sesiones, tratando de lograr que se cuenten historias nuevas en la conferencia. Es un trabajo súper difícil porque la calidad de todas las presentaciones es muy alta, y había muchas de ellas. Es un muy buen problema que tener. Es genial ver que la Cumbre DevOps Enterprise se hace cada vez más grande cada año. Es una comunidad realmente excelente.

Eso habla de la ubicuidad de DevOps ahora, y cómo algunas de estas historias de éxito están emergiendo del programa y se están volviendo un círculo completo y regresan para informar otras historias de éxito, ¿verdad? ¿Cuáles fueron algunos temas emergentes que surgieron en sus conversaciones con Gene sobre el desarrollo del plan de estudios para este show? ¿Hubo algún tema o tendencias que le sorprendieron o le interesaron particularmente?

Smart: Un par me viene a la mente. Ampliar la división entre negocios y tecnología es, en realidad, [un tema] del que me siento bastante convencido, porque esto no es algo que uno debería hacer de forma aislada en tecnología de la información. Es nuestro negocio. No es el negocio; es nuestro negocio. Es trabajar juntos en equipos multidisciplinarios donde su identidad tribal es el valor que está produciendo. Su identidad tribal no es su rol de trabajo: esa es la antigua forma de trabajar donde su identidad tribal es ‹Yo soy TI›. La forma moderna de trabajar es: ‹Mi identidad tribal es hipotecas, ahorros, motores de helicópteros, hoteles, lo que sea que haga la empresa›. Entonces, esa es una.

La otra cosa en la que estoy bastante interesado en este momento, y de la que hablé en la Cumbre Empresarial DevOps, es sobre el riesgo, el control y el cumplimiento: GRC, [que significa] gobernanza, riesgo y control. Cada vez más, veo conversaciones y una conciencia de que el cumplimiento también debe cambiar. Recientemente ha habido muchos ejemplos bien publicitados: British Airways, Marriott, Experian, Capital One. [También hubo] el virus NotPetya en 2017 que hizo caer a Maersk, Merck, cuatro hospitales, seis centrales eléctricas, 300 empresas, 22 bancos: los cajeros automáticos no funcionaban; su tarjeta de crédito no funcionaba.

Entonces, las implicaciones de los ataques cibernéticos son cada vez más altas cada día, a medida que las empresas se convierten cada vez más en empresas de tecnología de la información. La necesidad de un cambio de mentalidad en el cumplimiento es muy importante, porque no se trata solo de tratar de mantener a las personas fuera del perímetro. Debe asumir que los atacantes entrarán, más allá del perímetro, y luego podrá identificar eso, bloquearlo [y] minimizar el daño cuando alguien entre.

Ha trabajado en el espacio fintech, entiende las necesidades de algunos de estos clientes, trabaja con ellos. Ahora, son clientes para usted. ¿Puede explicar lo que necesitan de una implementación o metodología de DevOps? ¿Cuáles son algunas de sus necesidades en este espacio en particular que podrían diferir de, por ejemplo, una startup o alguien que no tiene ese tipo de regulación en torno a su negocio?

Smart: Mi opinión personal es que cada compañía es una compañía regulada, a menos que no tenga ningún dato del cliente y no tenga detalles de tarjetas de crédito. Si no tiene clientes, entonces probablemente no esté regulado, pero probablemente no esté haciendo negocios. Entonces, cada empresa está regulada. Mi opinión personal es la misma. No importa si usted es una organización de 10 personas o 300.000 personas, todavía tiene la responsabilidad de los datos personales que tiene y las multas son cada vez más grandes. La legislación GDPR en Europa afecta a todas las empresas a nivel mundial, si tiene datos de clientes europeos. British Airways fue multado recientemente con 183 millones de libras por una violación de los datos de los clientes.

Obviamente, cuanto más grande es la empresa, más personas están involucradas. En mi experiencia, hay más burocracia. Hay más años en los que los controles se han acumulado con el tiempo, donde tienes 100 años o 300 años de puntos de auditoría, y cada vez que alguien satisface un punto de auditoría, introduce un nuevo control. El paisaje se vuelve bastante complejo y complicado, y tiende a ser una cultura de cumplimiento sobre el riesgo, el apetito por el riesgo. Entonces, lo que quiero decir con eso es siga las listas de verificación: básicamente siguiendo la lista, el enfoque de las casillas de verificación, sin tener una conversación de apetito de riesgo. Especialmente para las empresas más grandes, es importante no adoptar un enfoque único para todos.

Es una tarea difícil escalar lo ágil en una empresa, y usted justo estaba hablando de eso un poco. Existen todos estos diferentes marcos de escalamiento ágiles. Hay todos estos diferentes libros y podcasts y técnicas. Sin embargo, es algo que pudo manejar bastante bien en Barclays Group, una gran organización global. El viaje de todos, las necesidades de todos serán diferentes. No hay un enfoque único para todos, como usted mencionó. Pero, ¿qué trataría de impartir en una empresa que lucha por escalar lo ágil a ese nivel?

Smart: Dos cosas. Si quieres escalar lo ágil, no lo haga. Primero disminuya el trabajo. Hágalo bien antes de escalarlo: haga que funcione en lo pequeño y luego repita. Es una adopción de curva S durante un período de varios años; no es lineal. Para empezar, debe mantener el gradiente bajo para cambiar, porque tiene la mayoría de los impedimentos: la mayor inercia, la menor cantidad de personas que lo entienden. Se vuelve exponencialmente más fácil con el tiempo, porque ha creado pruebas sociales; ha creado puntos de prueba en su organización.

El segundo pensamiento es: Si quiere hacer una transformación ágil, no lo haga. Concéntrese en: mejor, valor, antes, más seguro y más feliz, porque ese es el trabajo que está contratando: lo ágil, la agilidad, DevOps, pensamiento de sistemas, teoría de restricciones, pensamiento de diseño, etc., etc. Ese es el trabajo para el que los está contratando. Es un poco como si una organización quisiera colgar una pintura, [y] lo ágil es el taladro [que crea] un agujero en la pared para colgar la pintura. Entonces, si hace una transformación ágil, es como hacer una transformación de perforación; termina con una pared llena de agujeros, pero no cuelga la pintura. Un ejemplo de esto es Nokia Mobile: estaban obteniendo un 99 % en su prueba de ‹¿cuán ágiles somos?›, y no ayudó a Symbian [su sistema operativo móvil]. No ayudó a Nokia Mobile. También cometí este error en el pasado, donde una parte particular del negocio era ágil, pero no estaba teniendo un impacto material en la experiencia del cliente de extremo a extremo y el tiempo hacia el valor, debido a bloqueos en otra parte.

Entonces, en mi experiencia, el eje aquí es cuando uno se enfoca en los resultados que está tratando de lograr: ‹mejor› es la calidad; ‹valor› es valor; ‹antes› es el rendimiento, el tiempo de entrega y la eficiencia del flujo; el tiempo de aprendizaje es ‹antes›; ‹más seguro› es el control, el cumplimiento –ágil, no frágil–; y ‹más feliz› es colegas, clientes, ciudadanos y clima más felices, porque no tiene ningún costo para la sociedad, el planeta o los colegas. Las organizaciones que [no hacen esto] bien, como lo muestra el reporte del State of DevOps, reducen su tiempo de entrega; sin embargo, la calidad disminuye y la felicidad disminuye.

Eso cuenta la historia allí mismo. Me imagino que enfocarse en los resultados [ágiles], como lo estás contando, también envía un mensaje claro a los trabajadores, ¿verdad? No es: ‹Hey, estamos adoptando esta metodología ágil o esta metodología DevOps que tiene todas estas ideas y conceptos diferentes a su alrededor›, sino [en lugar de eso], ‹Aquí, nos vamos a centrar en estas áreas específicas que ofrecen valor para el negocio y ayudar a aclarar un poco su trabajo›.

Smart: Sí, y está capacitando a las personas para que usen sus propios cerebros para descubrir cómo mejorar en mejor, valor, antes, más seguro, más feliz. Entonces, en realidad... aquí es donde aumenta la felicidad. A medida que aumentan los niveles de compromiso y obtiene una experiencia más gratificante, tiene una existencia más humana, porque no todo es el dador, todo el tomador y seguir el proceso. Lo que es, está dentro de las barandas para que no se caiga por el borde y no filtre los datos del cliente y, lo que sea; usted está empoderado. De hecho, tiene incentivos para aumentar la calidad, el flujo, la felicidad y la seguridad; y se equilibran entre sí, porque no puede apostar artificialmente el sistema, porque, si apuesta el sistema, uno de [esos criterios] sube y los otros bajan. Así, se equilibran entre sí. Entonces, lo que he encontrado es que eso es muy poderoso. Se tiene una motivación intrínseca, porque se está intrínsecamente motivado para elegir por si mismo, cómo uno aprende a mejorar en esas cosas.

Un ejemplo particular, no se trataba de ágil en absoluto. Lo que funcionó para la cultura y la historia de esta área comercial en particular fueron las cascadas más pequeñas, porque había equipaje alrededor de la palabra con A: ágil. Hubo tres intentos fallidos previos de tratar de infligir la A mayúscula, Ágil: muy prescriptivo, dueño del producto Scrum master, stand-ups, retrospectivas. Por lo general, lo que sucede es que se usan las nuevas etiquetas, pero debajo es el mismo comportamiento anterior. La gente todavía está haciendo cinco iteraciones de análisis, y cinco iteraciones de desarrollo, y cinco iteraciones de prueba, y llamándose unos a otros maestros de Scrum y propietarios de productos. Así que, en cambio, enfóquese en los resultados. En ese caso en particular, se trataba de cascadas más pequeñas. Finalmente, se llegó a lo que podríamos llamar ágil, pero sin llegar a ello desde una falta de motivación intrínseca, de infligir lo ágil.

Y sin darles a los trabajadores esas pesadillas de recordar cómo no funcionó la primera vez. Una palabra que he escuchado en varias conversaciones en la conferencia es  ‹confianza›. Es un concepto central de DevOps, confianza entre el lado comercial y el lado tecnológico, entre trabajadores en diferentes espectros. Es un concepto central de DevOps que surge en los puntajes Net Promoter Scores de los empleados, el modelo de tipología Westrum e incluso en el nuevo libro de Gene Kim; aparece en The Unicorn Project. Hemos hablado de las ideas de DevOps y ágil a gran escala, pero ¿cómo aborda específicamente el problema de mejorar la confianza con el personal de TI?

Smart: ¿Debe ser solo personal de TI?

Bueno, supongo que es en todo el negocio.

Smart: En términos de organizaciones que ofrecen valor, mejor, más pronto, más seguro, más feliz, diría que son solo personas. Entonces, sobre la confianza, creo que esto vuelve a las barandas. Por lo tanto, debe tener este tipo de cumplimiento mínimo viable: #MVC. Cuanto mejores sean esas barandas, y sean del tamaño correcto, no son de talla única, son sensibles al contexto. Se trata de personas sobre procesos sobre herramientas. Se trata de conversación. Cuando tiene esas barandas en su lugar, eso les da a los equipos más libertad, y puede haber más confianza, porque es difícil caerse del borde.

Obviamente, esto es algo en que los servicios financieros, como muchas industrias, se basan exclusivamente en la confianza. Estamos confiando en una organización con nuestro dinero, que ya no es físico, son unos y ceros en algún lugar del disco. Confiamos, usted sabe, al igual que el papel moneda todavía es confianza –‹en Dios confiamos›–, y poder acudir a un banco central y canjearlo por oro, excepto que no puede hacerlo. Por lo tanto, debe tener esas barandas.

En mi experiencia personal, cuanto más confianza se da, más personas se comportan con confianza. La gente eleva el listón... ‹Si este es un estado de niñera y, ya sabes, no puedo hacer esto, esto y esto sin pedir permiso, o no me van a tener confianza›. Las personas no aumentan su juego tanto como cuando se confía en ellos. Obviamente, ocasionalmente habrá alguien malicioso. Así que, una vez más, se trata, como dije antes, de esperar un fracaso o un ataque criminal o actividad maliciosa, y luego poder identificarlo rápidamente y tratarlo con gracia.

Para los usuarios maduros de DevOps o los usuarios de alto rendimiento de DevOps, según las tendencias que ve: ¿Cómo asesoraría a esos clientes? ¿Cómo continúan optimizando y acelerando de una manera que mantenga estos valores de los que hemos hablado?

Smart: Nuevamente, enfóquese en los resultados que está tratando de lograr. En mi experiencia, en varias compañías, las palabras ‹mejor, valor, antes, más seguro, más feliz›, se aplican claramente en cada contexto. Así que, para una organización, siéntase libre de usar cualquier palabra que funcione. Sin embargo, la calidad, el valor, el flujo, la seguridad y la felicidad que aún tengo que encontrar, no dejaría caer una de esas. Todavía no he encontrado una que haya faltado. Tal vez, dentro de un año, habrá otra palabra allí, no estoy seguro. Ese es un viaje interminable. Cuando uno se enfoca en esas cosas alrededor de la calidad, el flujo, la seguridad, la felicidad, cuando se enfoca en esas cosas, es un viaje interminable. Nunca ha terminado; es una mejora continua, como en lo que Toyota es extremadamente bueno. Es una mejora continua.

Los sistemas humanos, la entropía, tan pronto como quitas el pie del acelerador, los controles vuelven a entrar, la burocracia vuelve a entrar, es solo la naturaleza humana. Es un poco como la jardinería. Si deja de desmalezar su jardín, las malezas crecerán. En el pasado, lo que hemos hecho es que hemos dejado crecer las malezas, y hemos tenido que hacer un enfoque de tipo tala y quema, donde luego talamos y quemamos el jardín. Gasté una gran cantidad de dinero en un programa realmente grande para hacer un realmente grande ‹Programa de transformación› –con T mayúscula–, y luego lo dejamos nuevamente. Me sorprende cómo pocas organizaciones tienen personas cuyo trabajo es ser continuamente un líder de servicio, apoyar la mejora del sistema de trabajo, que es lo que hago, y ayudar a las organizaciones con esto. Tener un número relativamente pequeño de personas que son los sirvientes [líderes] es apoyar a los equipos, personas que están tratando de que las cosas se hagan.

Algunos de los impedimentos son más grandes de lo que los equipos pueden manejar. Puede haber impedimentos organizativos, como el cambio en el ciclo de vida, por ejemplo, como el cumplimiento, que surgió, y hay algunas personas que, de cierta manera, se encargarán de eso, trabajarán con las personas adecuadas, obtendrán el patrocinio del comité ejecutivo y eliminará esos impedimentos. La causa de esto es apoyarse en mejor, valor, antes, más seguro, más feliz. Es apoyarse en las últimas ideas y en el aprendizaje de otras compañías sobre formas de trabajo. Entonces, creo que es muy importante tener un número relativamente pequeño de personas cuyo trabajo es hacer eso.

¿Y es esto lo que está viendo que los adoptadores de DevOps de alto rendimiento están haciendo en general?

Smart: Absolutamente, y creo que hay que combinar eso con una cultura de liderazgo para alentar la experimentación, y no existe un experimento fallido; es solo aprendizaje. Incluso si el experimento no sale como pensabas que iba a ir, has aprendido mucho de eso. Por lo tanto, es tener líderes con esa mentalidad y también experimentos que pueden fallar de forma segura: no desea apostar su empresa en un experimento. Para citar a Frederic Laloux, quien escribió Reinventing Organizations: ‹La conciencia de una organización no puede exceder la conciencia de su líder›. Veo esto mucho, donde hay líderes que fomentan esa cultura correcta de experimentación y mejora, y eso es todo lo que se necesita. Todo lo que se necesita es establecer ese tono de: ‹Te reconoceremos por salir de tu zona de confort y buscar una mejora continua›.

Además, lo que veo mucho son las organizaciones donde hay un cambio en el liderazgo, y puede haber alguien con una mente bastante abierta y empoderadora, y [entonces] entra alguien más tradicional, que tiene más comando y control, menos empoderando, más, ‹Haz lo que te digo›. Y luego esas organizaciones las veo ir hacia atrás. Van hacia atrás muy, muy rápido. Se necesita mucho tiempo para avanzar, y no se tarda mucho en volver atrás de nuevo.

¿Puede entrenar a las personas de comando y control? ¿Es algo que es inherente a ellos si solo reciben una capacitación tan negativa a lo largo de los años que se queda con ellos? ¿O pueden progresar a un lugar donde lo entienden y adaptan su comportamiento?

Smart: Creo que los humanos tienen una velocidad limitada para desaprender. Las personas tienen una velocidad limitada para desaprender. Algunas personas desaprenden más rápido que otras. Creo que no se trata tanto de entrenamiento negativo. Se trata de lo que ha llevado a ciertas personas a tener éxito y a llegar a donde llegaron. Ciertas personas en ciertas organizaciones donde la norma cultural es una determinada norma cultural –por ejemplo, comando y control– que tal vez ha permitido a algunas personas que han sido reconocidas, recompensadas y promovidas con base en ‹hago cosas›. Sin embargo, [ellos] hacen cosas a cualquier costo; típicamente, cualquier costo humano. Y si hay otros líderes más antiguos que tienen la misma mentalidad, entonces tal vez eso no se controle, o sea como: ‹Bien hecho, la madera muerta está abandonando la empresa›, o lo que sea. Así que, es difícil para un leopardo cambiar sus manchas, y hay una velocidad limitada para desaprender y volver a aprender. Mi opinión es que no se trata de ‹resistencia› o ‹convincente›: esas palabras no deberían entrar en el vocabulario. Debería ser ‹invitar› sobre 'infligir›. Debería tratarse de invitar al cambio. Entonces, desde mi perspectiva, si un líder de alto rango no quiere cambiar, o no quiere cambiar la cultura, o ‹mejor, [valor], antes, más seguro, más feliz›, entonces eso está bien. No necesitamos hablar. Si, en algún momento, desea entregar mejor, [valor], antes, más seguro, más feliz, a través de todas esas medidas, no solo una de ellas, entonces tengamos una conversación. Y, querido líder, usted podría ser parte del problema. Pero, supongo, tiene que ser invitado. El coaching tiene que ser invitado. Esa es una condición previa. Eso no se puede infligir.

Sí, no se puede forzar eso sobre nadie. ¿Al menos estamos viendo menos leopardos?

Smart: Creo… ¿estamos viendo menos leopardos? Estamos viendo, en términos de que el leopardo está cambiando sus puntos, estamos viendo más y más organizaciones que están en el camino hacia la mejora continua. Definitivamente estamos en el punto de inflexión o lo hemos superado, donde ahora es solo la norma, nuevas formas de trabajo: ágil, DevOps, transformación digital; porque, a nivel macroeconómico, hemos ido [más allá] de la era de la producción de petróleo y en masa, donde los humanos tenían una competencia en producir en masa la misma cosa 100.000 veces.

Ahora estamos en la era del software y lo digital, donde la naturaleza misma de lo que producimos es diferente cada vez. Este es el gran cambio, porque el esfuerzo humano organizado debe ser bueno en la emergencia, donde no sabes lo que vas a construir; no sabes cómo lo vas a construir; no sabes lo que la gente quiere. Así que no es como construir 100.000 autos Ford modelo T; es emergente. Definitivamente, estamos en o más allá del punto de inflexión. Creo que probablemente estamos más allá de los primeros adoptantes y la mayoría temprana. Creo que estamos en la mayoría tardía, definitivamente estamos en la mayoría tardía ahora. Todavía hay una larga pista de organizaciones que están firmemente en la mayoría tardía y las que están rezagadas en la curva de difusión de la innovación. Ahora se está convirtiendo en una apuesta.