Me aburrió Sketch

No pretendo escribir un manifiesto en contra de Sketch, ni de las otras herramientas que hoy encabezan la lista como favoritas entre los diseñadores de interfaces. Sólo quiero plantear mi visión personal acerca del uso innecesario de estas herramientas sobre todo para quienes tenemos experiencia escribiendo HTML/CSS, y optar por ellas a la hora de diseñar nuevas interfaces, y de paso hacer una invitación a perder el miedo.

Soy un diseñador dedicado a la experiencia de usuario hace varios años y desde hace muchos más, he dedicado tiempo a aprender e investigar permanentemente sobre los procesos de diseño y herramientas disponibles que nos ayudan a hacer mejor nuestro trabajo. Entre esas, hay un par que conocí en los últimos años y que he usado bastante, porque me parecen excelentes y porque hacen una dupla genial: Sketch +Invision.

Pero como decía al principio de este post, no lo escribo para hablar mal de estas herramientas, sino que para explicar porqué (enhorabuena, como dicen los españoles) me aburrí de ellas.

La maravilla de Sketch

Primero que todo, me gustaría decir que considero a Sketch una maravilla. Aunque lamentablemente sea sólo para usuarios de Mac. Sé que muchos consideran caros los Mac (con mucha razón) y otros tantos los detestan, así que mucha pena por los Windows/Linux users, que se la pierden.

En su última versión desarrollaron interesantes mejoras y complementos dentro del software para manejar mejor los objetos y hacerlos más inteligentes a la hora de repetirlos (los overrides) y un sin fin de otras cosas muy geniales. Además de tener una interfaz simple y amigable, ideal para diseñadores que se formaron usando Illustrator de Adobe (o el prehistórico Freehand) e incluso los que se aventuraron con Phostoshop para hacer interfaces en el pasado y sobre todo para los viudos del difunto Fireworks. Y que además de todo eso, tiene full integración con Invision, una plataforma web para crear prototipos, igualmente genial. Pero que sin embargo insisto, me aburrí de usarlas.

¿Por qué me aburrí?

Todos sabemos o creemos que escribir código supone una dificultad extra que puede verse reflejada en el tiempo. No obstante es un pro excepcional para el proceso de la implemementación en desarrollo. Y ahí hay un punto insuperable.

Por lo tanto, si yo sé HTML, ¿para qué gastar el doble de tiempo dibujando interfaces en Sketch (o el software que sea) y luego armando un prototipo en Invision (o el software que sea), si lo puedo hacer directamente en código?

Algunos podrán alegarme que HTML no es muy flexible o mejor dicho, tan rápido de manejar a la hora de probar si esto queda mejor de una manera u otra, que es lo que hacemos todos los diseñadores cuando estamos “creando”. Sin embargo, si estamos en un proceso de diseño de experiencia de usuario, habremos pasado por fases previas donde las interfaces estarán precedidas por wireframes que al menos fueron “microvalidados”. Entonces al momento de ponernos a trabajar en un prototipo, generalmente ya tenemos una base y un layout predefinido.

Así que, meterse directo al código es algo bastante lógico. Y para lo único que se justificaría gastarse un poco de tiempo usando Sketch, sería para trabajar un look and feel más prolijo. Para decidir cuál será el estilo visual que tendrán las interfaces de lo que estamos diseñando. Basta con probar algunos botones, algunos campos de formulario, y uno que otro detalle más y ya. Sólo bastará con diseñar una pantalla y tenedremos todo lo que necesitamos. No es necesario seguir gastando tiempo ahí, diseñando cada una de las interfaces porque será tiempo perdido. Y si a eso le sumas que las interfaces tienen que ser responsive, más tiempo perdido.

Hoy día, en web existe una amplia variedad de frameworks que nos facilitan la vida al hacer código, incluyendo sus microinteracciones, y lo mejor de todo, es que tienen abordado el responsive web design. Bootstrap, es el mejor ejemplo.

Perder el miedo a cerrar Sketch y abrir Sublime

Algunos también podrán insistir aquí que escribir código es mucho más lento. Pero creo que eso es una aseveración planteada desde el miedo. Un miedo que también tuve por mucho tiempo, debo reconocerlo. Pero ya por fin, es parte del pasado.

Así que, me decidí a cerrar Sketch definitivamente y lanzarme a prototipar directamente sobre HTML/CSS, lo que me ha dado muy buenos resultados, incluso en rápidos sprints, donde sólo hay un día para hacerlo.

Contaba con una ventaja que no estaba aprovechando sólo por miedo. O me había encantado tanto usar Sketch que me estaba olvidando lo genial que es mirar tu prototipo funcionando casi de verdad, adaptado en diferentes dispositivos y que cambiando un par de líneas de código o reglas de CSS podía hacer mucho más (y mucho más rápido) que duplicando artboards en Sketch o peor aún, simulando las interacciones después en Invision.

Lo mejor de todo esto, es que un prototipo HTML, es algo que agradecerán mucho los desarrolladores, que no necesitaran tener que tomar el Invision, y mirarlo para tratar de replicar las interacciones o mirar las interfaces del manual de diseño que tuviste que hacer en Zeplin o en PDF, para imitar las interfaces, con todos sus detalles. Así entonces, cuando el software esté terminado, no existirá ese maldito GAP entre lo que diseñaste en Sketch y lo que terminó resultando. Incluso harás un diseño responsable, probado de que lo que propones efectivamente se puede hacer.

¿Entonces estoy sugiriendo no usar más Sketch?

No, en absoluto. Pienso que Sketch es genial para modelar, para el momento de la “creación” y perfeccionamiento del look and feel. Es mucho más amigable que HTML para ello, porque nos permite con soltura, probar, mover, cortar, pegar, repetir, duplicar, achicar y agrandar rápidamente. Pero en la mayoría de los casos, basta con hacerlo para una sola pantalla, y de ella obtener las medidas y posición del layout o el estilo visual de los elementos de interfaz. Los colores, sombras, bordes, tamaño de la tipografía, etc. Es lo mejor que existe para manejar y exportar assets, tipo SVG.

¿Y qué pasa con el diseño mobile?

Por supuesto que no podemos ignorar que Sketch es insuperable cuando hablamos de diseño de aplicaciones móviles. Porque aún no hay nada tan simple para nosotros, los diseñadores, con respecto a meternos en el código de apps nativas, como si lo es en web.

Sin embargo la gran nueva de era de Javascript mueve la aguja de vuelta hacia la web. Hoy por hoy, las aplicaciones híbridas, están tomando fuerza por sobre las nativas, sobre todo por lo práctico y económico que es desarrollar un sólo código. Otra razón para acercarse a HTML.

Mi consejo

Si eres un diseñador con experiencia en HTML, te sugiero que hagas como yo y cierres el Sketch, abras sublime (o el editor que prefieras) y te sumerjas en el código. O si quieres puedes compartir tu desacuerdo en los comentarios, con los fundamentos que quizás me hagan entender lo equivocado que estoy.

Si eres uno de los que no sabe mucho de HTML/CSS, y por eso no te atreves a aventurarte, te recomiendo retomar el aprendizaje y mejorar, para hacer un trabajo mucho más eficiente. Recuerda que la práctica hace al maestro.

Y si eres de los diseñadores que no se manejan nada con el código, te invito a que aprendas ya. A la larga te darás cuenta lo bueno que es trabajar de este modo.

Tu mercado laboral es el mundo. Pero tu currículum no es un papel

Hace unos meses fui invitado a la 9punto5, una conferencia sobre trabajo remoto realizada en Valdivia, Chile (que por cierto estuvo muy buena, les recomiendo registrarse para saber más sobre la edición 2017). Mi charla fue sobre cómo construir un “currículum” para aprovechar las enormes oportunidades que se abren cuando puedes trabajar más allá que en las empresas que tienen oficina cerca de donde vives.  Y por qué ese currículum no es un papel, ni un PDF, ni menos — horror de horrores — un Word.

Pueden ver el video acá:, o pueden leer una versión escrita más abajo.

El software se sigue comiendo el mundo: ¡No te quedes abajo!

¿Conocen el clásico del 2011 “Software is eating the world”? Léanlo (está detrás de un paywall, pero lo clickean desde los resultados de Google pueden verlo sin problemas). Van como 6 años desde su publicación y cada vez es más y más cierto. En todas las áreas económicas el software es pieza clave. Publicidad, retail, películas, viajes, hotelería, taxis, lujo, lo que quieran. Y empresas que saben de software (Amazon, Apple, Spotify, Uber, AirBnb, Google, Facebook, etc, etc, etc) se comen a las empresas que todavía no se dan cuenta que o se toman en serio el software o mueren.

En resumen: La globalización y el desarrollo acelerado de la tecnología tienen como conclusión natural que el software se come al mundo.

Y si eres desarrollador, diseñador, líder de producto o emprendedor, estás participando de la industria que se come el mundo. Sin necesidad de irte a otro país: En nuestra industria el trabajo remoto funciona, desde el impresionante movimiento open source hasta múltiples empresas líderes que permiten (e incentivan) esta modalidad.

La oportunidad es gigante, pero el desafío también. Tú también compites con ingenieros, diseñadores, desarrolladores, product managers y emprendedores de otros 195 países.

Un ejemplo de lo que significa eso: Ya no te sirve decir “Vengo de la prestigiosa Universidad tanto o tanto” para ganarte un lugar privilegiado: ¡Capaz que la empresa a la que estás postulando ni conozca a tu prestigiosa universidad! Ni tampoco a las “grandes empresas” en que has hecho carrera. Así que te tienes que armar otro tipo de currículum. Para no predicarles en el vacío, voy a contarles cual es el mío.

Mi Currículum.

Ups.

Lo confieso — ¡que diablos! — tengo un “currículum”. De esos tradicionales, en PDF.

¿Pero saben qué? En realidad no sirve de currículum. Si no me creen, miren la definición de la palabra currículum según la mismísima RAE:

Relación de los títulos, honores, cargos, trabajos realizados, datos biográficos, etc., que califican a una persona.

El PDF que les mostré es una lista de honores, cargos o trabajos. Pero para ser sincero nunca ha convencido a nadie de que califico para algo. No es mi currículum. Así que les voy a contar las distintas cosas que sí han convencido a gente de que vale la pena trabajar conmigo.

Dudo que en mi primer trabajo hayan leído el papel que presenté como currículum. Me llamaron porque mi nombre les saltó en una página web que se llamaba “La Web Del Programador” y acordamos trabajar durante ese verano del 2005. Casi como una práctica.

Pero algo de lo que hice durante esos 3 meses los convenció a contratarme. Trabajé más de 4 años allí. Entre medio tuve la chance de trabajar “part-time” en el Google Summer of Code a mediados de 2008. Para ser aceptado en esa oportunidad tuve que escribir una propuesta en Marzo de 2008 que me calificara para que Google (y la Python Software Foundation) se gastara plata (¡más de 5 mil dólares, que es harto más de lo que uno consigue por una “práctica de estudiante”!)  y tiempo en mí. No los voy a aburrir con toda la propuesta. Esta es la parte clave:

I am relatively familiar with both codebases, after my first attempts of Django/Jython integration around past September[3][4]. All patches sent by me at that time were well received by both groups of core developers.

Todo el truco era que unos meses antes ya había hecho un avance, lo había enviado a los desarrolladores y ellos habían leído e integrado mi código.

O sea, ya estaba pre-calificado por algo concreto que había hecho y que otras personas podían ver, revisar y evaluar . Me dí cuenta que la propuesta escrita era una formalidad. Importante y necesaria, pero una formalidad. Con tu currículum es lo mismo.

Y la gracia es que esto es una bola de nieve. Unos 4 meses después estaba en el escenario de una sala de conferencias en Google

Mi trabajo durante los 3 meses del Google Summer of Code convenció a otra gente de que hiciera una charla en la DjangoCon 2008 (obviamente también hubo que hacer una propuesta de charla). Luego hicimos la misma charla en la PyCon 2009 y en alguno de los “after conference” de ese evento un editor de Apress se interesó en nuesto tema (pro tip: si van a conferencias siempre aprovechen también de socializar o tomarse unas cervezas con otra gente; yo soy introvertido y me cuesta, pero vale la pena).

A los meses después terminé como co-autor de un libro. Y en realidad mi inglés era limitado. Y no hubo un currículum en papel que me calificara como escritor técnico diciendo que había estudiado inglés en tal o cual parte y que había sacado un puntaje en un test . Las charlas y el trabajo open source que hicimos nos calificó. 

¿Saben como llegué a Continuum?

Este fue el correo con el que yo diría que califiqué para que Jorge (fundador y hoy mi socio en Continuum) se gastara algo de tiempo en cachar quien diablos era yo:

El tema se concretó como un año después. Parte del “pololeo” incluyó que uno de mis ensayos de mis charlas en EEUU lo hice en la oficina de Continuum. Califiqué haciendo cosas, no por lo bonito que se viera o sonara el papel ese al que llamamos currículum.

Luego Continuum me mandó a Hashrocket. En Hashrocket tuve 3 semanas para programar con ellos. Sin duda el libro, mis charlas, y mis colaboraciones en el OpenSource ayudaron a calificarme para que invirtieran esas 3 semanas. Y lo que hice esas 3 semanas me calificó para que me tocara liderar Hashrocket Chile.

El 2012 trabajé varios meses para una empresa en Australia (part-time mientras hacía mi MBA allá). Nunca vieron ese papel que le llamamos currículum. Lo que me lleva a algunas historias de otros miembros de Continuum:


Ella es Macarena. Cuando dije que los Australianos nunca vieron mi currículum me acordé de ella. Ya varias veces me ha dicho, con un dejo de indignación: “Oye pero eso que me estás preguntando estaba en mi currículum, ¿no lo leiste?”. Y tiene razón, no lo leí. Pero para mí Pichanga — la app-y-emprendimiento de Macarena — es más currículum que el papel que seguro mandó y no leí.


Él es Ernesto. También dió una charla en la 9punto5, contando sobre su actual trabajo remoto con un cliente que tenemos en el extranjero y compañeros de equipo en múltiples países. Nos escribió en Marzo de 2013 en remoto y llegó a Chile a fines de ese año para su primer día de trabajo. Para mí, su currículum fue su GitHub.

Ellos son Alfredo, Alba y Carlos. Los ví por primera vez el 2008 y el 2009 en eventos de Linux y OpenSource, y los seguimos conociendo en eventos el 2010 y fueron parte de la organización del Encuentro Linux 2011. No recuerdo nada que haya leído del papel-currículum de ellos (si es que lo enviaron), y todos trabajan hoy en Continuum. Para mí, la pasión y el trabajo en equipo que pusieron en su comunidad, los eventos (y sus míticos asados) fue su currículum.

Ni ellos ni yo somos la excepción. Tu currículum no es un papel.

Conclusiones y Tips

Volvamos un momento a la definición de currículum:

Relación de los títulos, honores, cargos, trabajos realizados, datos biográficos, etc., que califican a una persona.

El currículum existe porque en muchas industrias, en muchos casos, esa lista de cosas sobre un papel es lo que hay. No hay una mejor forma de ver si alguien califica para algo. No queda otra.

Nuestra fortuna es inmensa, no solo porque el software se esté comiendo el mundo. Además nuestra industria nos permite una mejor forma de destacarnos y calificar. Acá van tres tips para que te hagas un currículum que sirva:

  1. Muestra tu habilidad técnica.  Tu código, subiendo tus proyectos de hobby a GitHub. O tus diseños a behance. O tus investigaciones o reflexiones personales a tu web o blog.
  2. Muestra tu capacidad de trabajo en equipo: Aplica tus habilidades para alguna causa como voluntario, o participa de un proyecto opensource colaborando con otros desarrolladores. Por cierto, ¡demostrarás que tienes las habilidades trabajar en remoto y comunicarte en inglés escrito también! No porque lo dices en un papel, sino porque se puede ver que lo has hecho.
  3. Muestra que puedes enseñarle a otros, explicar cosas complejas, transmitir un mensaje. Enseña en tu blog, escribe un e-book, da charlas en meetups y conferencias. A las empresas nos encanta contratar gente que sabe enseñar: Suelen dominar los temas sobre los que enseñan, y además saben como compartir el conocimiento. Eso vale oro.

¿Y sabes qué? La verdad aún quedan muchas empresas que te tratarán de calificar por un papel, o PDF o con una porquería de Word que te hacen llenar.  Así que mis tips no sirve para todos los casos. No importa: tu objetivo no es gustarle a todas las empresas. Tu objetivo es hacer match con empresas que te interesan.

Si construyes un currículum de verdad (y no ese sucedáneo de papel) harás match con esas empresas interesantes que saben leer tu verdadero currículum. Que significa que allí ya hay gente que puede “leer” y evaluar ese verdadero currículum. Más importante aún: significa que esas personas que pueden evaluar tu verdadero currículum también influyen en la decisión de quien contratan.

El mejor consejo que les puedo dar es trabajar en esas empresas. Sean empresas con sede en tu país, o en cualquier otro de los 195 países de este mundo.

Corriendo dentro del bus: por qué las “fábricas digitales ágiles” fallan antes de empezar

Nos ha tocado vivir el siguiente episodio varias veces en Continuum:

  1. Project Manager — joven, inteligente y entusiasta — de empresa gigante de servicios se acerca a nosotros porque por fin su compañía está abrazando la Transformación Digital, la Visión Cliente y la Agilidad, y quiere nuestro apoyo en desarrollo ágil, innovación y Lean UX. La Gerencia General ha expresado que esto es prioridad absoluta.
  2. La conversación es maravillosa, estamos alineados en todos los puntos. Sus jefes están también totalmente a bordo y convencidos. Hay ganas y plata para hacer las cosas impecables. Los proyectos a trabajar se ven claros y orientados a sacar mejoras rápidas hacia los clientes.
  3. Elaboramos una propuesta. A nuestr@ amig@ Project Manager le parece perfecta. Los jefes están entusiasmados. El inicio parece inminente. Comenzamos a registrarnos como proveedores.
  4. Comienzan a pasar los días. PM nos explica que sólo falta afinar algunos detalles internos y ya.
  5. Los días se transforman en semanas. Los presupuestos están en aprobación de Comité, suspira PM.
  6. Al mes, PM nos aclara que el proyecto original era demasiado grande y no cabía en el presupuesto de este año; por ende requería postularse al del próximo año y preparar sustentos.
  7. Sin darnos cuenta ya han pasado varios meses sin tener contacto. Y de pronto, un avergonzado mail de pobre Project Manager: durante este tiempo cambiaron las políticas desde la casa matriz, y la nueva gerencia de Compras está cuestionando todos los presupuestos; así que todos los proyectos han tenido que revisarse nuevamente. Pero nuestro proyecto está definitivamente considerado, nos dice sin mucho convencimiento. Y para consolarse: están todos los proyectos del área en la misma situación.
  8. Los puntos (5) a (7) se repiten ad nauseam. PM, mientras tanto, sigue siendo joven e inteligente, pero definitivamente menos entusiasta.

¿Qué ocurrió?

Poner la agilidad en un invernadero no funciona

Dado que el mandato 2017 para las empresas de servicios es Transformarse Digitalmente, Ser Una Empresa Ágil y Poner al Cliente Como Centro, los líderes de dichas empresas están corriendo en círculos, porque la mayoría sencillamente no tiene idea de (a) cómo es que te das cuenta que ya te transformaste digitalmente, (b) qué es exactamente ser una empresa ágil y (c) momento, ¿no que ya teníamos a nuestro cliente como centro?

Y el punto es que este tipo de transformaciones — imprescindibles si quieres que tu empresa no se esté cayendo a pedazos en diez años más — necesitan una cultura abierta y tolerante al riesgo, y sin embargo están siendo ejecutadas por líderes y equipos aversos al riesgo.

Esta contradicción trae como resultado que los experimentos de Transformación Digital se encapsulan, tal como el sistema inmunológico aísla y manda glóbulos blancos al encuentro de un cuerpo extraño (le estoy robando esta metáfora a un gerente con quién, irónicamente, nos sucedió una historia como la de arriba).

Y ahí es donde nace la “Fábrica Digital Ágil”, que no es sino otra forma de decir: OK, OK, OK. Dado que tenemos que incorporar la agilidad, la vamos a poner aquí, en cuarentena, para ver si funciona. O también: Armemos un área que tenga Design Thinking y Scrum, y que sean oficinas de planta abierta, pero la seguimos manejando bajo el esquema jerárquico-burocrático del resto de la empresa.

Entonces, cuando miras al interior de esta Fábrica, ves jóvenes entusiastas e inteligentes (como nuestr@ amig@ Project Manager), muchos recién contratados, con ganas de comerse al mundo y de marcar una nueva era en una gran empresa. Pero luego miras afuera, y te das cuenta que la Fábrica recibe su alimento — recursos y cosas para hacer — tal cual como siempre: en reuniones lateras de planificación semestral, en Comités que centralizan todas las aprobaciones y necesitan que les hagan pitch de cada proyecto, con jerarquías que al cambiar desandan lo avanzado, y bajo presiones de cortar costos y hacerlo todo a la velocidad de la luz — porque eso de “Ágil” viene de avanzar súper rápido, ¿verdad? — .

Hacer retrospectivas y stand-ups diarios no sirve de nada si no incorporas los valores de la Agilidad: colaboración, autonomía y confianza. Si el equipo de Transformación Digital está aislado en su agilidad mientras el resto de la compañía sigue funcionando “a la antigua”, ahí no tienes colaboración. Si los Project Managers carecen de poder para tomar riesgos y aprobar proyectos sin pasar por la fiscalización de Compras, eso no es autonomía. Si tienes que ir a comité hasta para pedir la sala de reuniones, es porque no hay confianza.

Y dale con lo de “Fábrica”

Como ya hemos discutido anteriormente, el mero concepto de “Fábrica” obedece a un modelo de organización que no tiene mucho que ver con la agilidad orientada al desarrollo tecnológico.

Una fábrica supone producción predecible y procesos estandarizados y controlados; y de aquí viene lo de correr dentro del bus, porque si el resto de la compañía sigue moviéndose con lentitud, ¿qué es exactamente lo que estás fabricando con tanta agilidad y predictibilidad? ¿De dónde alimentas las decisiones de producto que esta factoría producirá a toda velocidad? Puedes perfectamente estar cavando tu tumba en sprints de dos semanas. Y dado que el aislamiento de una “Fábrica Digital Ágil” surge precisamente de una aversión al riesgo, muy probablemente las decisiones de producto están siendo alimentadas por dicha aversión.

Y como resultado, tenemos a un equipo ágil muy ocupado en:

  • Copiarle features a la competencia
  • Adaptar software enlatado y barato de otra parte
  • Hacerle mantenciones a sistemas obsoletos
  • Preparar presentaciones al comité para ver si te aprueban futuros proyectos
  • Pasarse la tarde en reuniones de sustento para dichos proyectos
  • Pelear con proveedores de TI que siguen trabajando como si estuviésemos en 1998

Por el contrario, cuando una organización toma la agilidad de manera transversal, se orienta naturalmente hacia la experimentación y la toma de riesgos. La gracia de tener un equipo de gente talentosa y autónoma es precisamente que puedes confiar en su criterio y su talento. Y si se equivocan, las dinámicas ágiles hacen que el error sea de bajo costo y que el valor que trae el aprendizaje compense el error con creces.

Libera a tu gente

Un gran costo oculto de mantener la agilidad esterilizada y en cuarentena es la fricción ocasionada por la pérdida de talento. Porque algún día Project Manager se va a aburrir de no avanzar en nada concreto y se irá a una startup, a una agencia más pequeña o arrancará al campo a sembrar choclo, jurando nunca más pisar un entorno corporativo. Y ni las oficinas de planta abierta ni el café gratis l@ detendrán.

Y la cantidad de talento en este rubro es siempre limitada; si quemas tus cartuchos, eventualmente tendrás que reemplazar a una persona talentosa y autónoma por otra menos talentosa y menos autónoma, a la que tendrás que manejar al estilo tradicional.

La gente que hoy está conformando los incipientes equipos ágiles al interior de grandes empresas son personas que llegaron cautivadas por la promesa de impactar a millones de seres con un trabajo de vanguardia, autonomía, libertad y empoderamiento. Pero hay una cierta cantidad de veces en las que puedes hacer esa promesa y no cumplirla, sin que la gente se comience a aburrir y la voz empiece a correr.

Y en el fondo Project Manager, con toda su juventud y entusiasmo, muy probablemente se siente como pez fuera del agua dentro de una organización gigante y monolítica a la que supuestamente tiene que transformar. Si las gerencias que solicitan esta agilidad no se vuelven ágiles en sí mismas, difícilmente van a tener la energía (o la autoridad moral) para infundirlo en el resto de la compañía.

Libera a tu gente. Si tuviste la suerte de sumar a tu equipo a Usain Bolt, no empieces a explicarle cómo se corren los 100 metros planos. Permite que tu equipo experimente, cometa errores y decida sobre sus propios recursos. El líder en un equipo ágil, en todas las escalas jerárquicas, deja de ser un controlador y pasa a ser un facilitador, siempre unos cuantos metros más adelante, despejando las piedritas del camino.

Y usualmente la primera piedra (¡roca!) a despejar es la inercia de tu propia empresa. Acá el “libera a tu gente” incluye también al resto de la compañía, esa otra gente que sigue funcionando bajo esquemas jerárquicos; ellos también necesitan transformación hacia la agilidad, el empoderamiento y la libertad para responder en tiempo real.