Generalistas, Especialistas y Cynefin Framework

IMG_20180422_160246218

Barbie™ es especialista-general. Es (entre otras cosas) astronauta, informática, médico y cocinera. Es especialista en todo, pero desafortunadamente no es real: los seres humanos tenemos que conformarnos con ser, o bien especialista en un conjunto muy reducido de áreas, o bien generalistas en varias.

Dando vueltas a las dinámicas de trabajo de personas con diferentes experiencias, esperaba poder escribir un post que me ayudase a identificar cuándo es mejor ser un generalista o un especialista, o cuando conviene contar con más o menos de unos y otros en un equipo.

El tema podría estirarse mucho y existe una gran cantidad de información sobre muchos de los temas relacionados, pero creo que lo que he escrito en este post es suficiente para mi propósito.

Empleo el término “especialista” en lugar de “experto“, como he visto hacer en otros artículos, porque creo que la diferencia fundamental entre “generalista” y “especialista” es cómo distribuyen su experiencia: el generalista tiene mucha experiencia distribuida en muchas áreas; el especialista también tiene experiencia, pero enfocada en un solo área o nicho. Es decir, no se trata de tener mucha experiencia, sino del tipo de experiencia y conocimientos que acumulamos. Es una diferencia cualitativa.

Es importante entender que no existen los generalista o especialistas puros, todos tenemos un poco de ambos. Y también hay que tener en cuenta que nuestros conocimientos varían con el tiempo en base a experiencias pasadas, situación personal, etc. Lo que impide encasillar a alguien en uno u otro perfil de manera indefinida.

Cómo son Especialista y Generalista

El especialista puede actuar sobre algo en particular en su área de conocimiento. Cree saber mucho o todo de su área y extrapola (generalmente mal) al resto. Tiende a no saber que no sabe. Tiende a intentar actuar en solitario. Tiene seguridad en lo que hace y desconfía de lo que no conoce o se sale de sus mecánicas de trabajo. Tiene una visión parcial y busca optimizaciones locales. Evita los grandes cambios.

El generalista puede dirigir y llegado el caso actuar al tener una imagen del contexto y una base de conocimientos, pero ejecuta de forma menos eficiente que un especialista. Sabe que sabe “poco” y tiende a trabajar desde hipótesis que hay que validar. Intenta actuar en equipo. Duda de todo y tiende a anteponer las pruebas a los argumentos. Tiene una visión holística y sistémica.

Cuándo ser o emplear uno u otro

El generalista será más efectivo al ver la foto completa (o al menos una foto amplia) del problema, su contexto y ramificaciones.

El especialista será más eficiente cuando actúe en su campo, resolviendo un problema concreto y definido de forma rápida y limpia aunque tenderá a ignorar el contexto, generando eficiencia local a costa de la del sistema.

Cómo funcionan los grupos de Generalista y Especialistas

1. Equipo de generalistas. Efectivo pero lento. Dales suficiente tiempo y te resolverán los problemas para siempre. Incluso puede que problemas que ni sabías que tenías. En entornos con muchos interrogantes o cambios, o entornos con mucha integración con terceros, posiblemente funcione mejor que otros.
2. Equipo de especialistas. Eficiente pero inefectivo. Dales problemas concretos y acotados a su área y te los resolverán en poco tiempo. Si no les das instrucciones detalladas de lo que quieres, probablemente te generen problemas nuevos. En entornos estables y bien conocidos y planificados (sota, caballo y rey) posiblemente funcione bastante bien.
3. Equipo con más generalistas que especialistas. Frustración de los especialistas ante la falta de velocidad o exceso de “charla”. Efectivo pero lento. Habrá fricción entre unos y otros y puede que sobrecarga de los especialistas en determinados momentos. Parálisis por análisis en según qué casos.
4. Equipo con más especialistas que generalistas. Tendencia a actuar antes de pensar. Frustración de los generalistas al disparar antes de apuntar. Fallos de coordinación e integración. Tendencia a mantener la gente ocupada y a obtener resultados técnicos en lugar de obtener resultados de negocio.

El contexto es importante

Hace tiempo que quería hablar del marco de trabajo Cynefin tras leer sobre él en los blogs de Jerónimo Palacios y Javier Garzás. El post de Garzás me parece el más claro y simple para quien quiera echarle un ojo, pero en la Wikipedia (en inglés) hay toda una entrada el respecto para profundizar.

Este framework nació en 1999 y actualmente se emplea en ejercicios de formación de Scrum para “entender y explicar por qué distintos enfoques de trabajo y de hacer las cosas, funcionan bien en un entorno y en otro no“.

En esencia es un método de toma de decisiones, y creo que puede servir para identificar cuándo es mejor tener (o comportarse) como generalistas o como especialistas.

En mi opinión, cuando estamos en los dominios Obvio o Complicado, los especialistas son necesarios (quizá en solitario, quizá liderando un grupo o quizá siendo mayoría en el grupo). Sin embargo, para los dominios Complejo, Caótico y la zona Desordenada, parece mejor contar con generalistas.

En mi caso, puedo decir que me gusta el dominio Complejo y tiendo a automatizar todo lo que esté en el Obvio para no tener que hacerlo. La zona Desordenada es algo que detesto, por lo que trato de orientar mi trabajo para salir de ella lo más rápidamente posible. Supongo que todo esto me identifica como generalista.

Conclusiones

En el mundo del software (y todo va camino de ser software), los cambios se suceden con velocidad de vértigo, y por lo tanto la mejor opción parece ser el contar con generalistas para poder adaptarse con agilidad a lo inevitable.

Sin embargo, para poder resolver los problemas más típicos de manera eficiente y que una empresa pueda funcionar en el día a día, es necesario tener al menos un especialista en la operativa o problema más común de la empresa. Por ejemplo, merece la pena tener especialistas en gestión de proyectos si tu negocio se basa en proyectos, o en contar con un especialista de bases de datos SQL si muchos de tu trabajos usan bases de datos SQL.

Todos los trabajos que encajan en el dominio de los Obvio van a ser automatizados, así que es mejor evitar esa zona como la peste.

Para terminar

Como decía al principio, no hay perfiles puros, por lo que mi apuesta es tratar de ser especialista en al menos uno de los problemas más comunes de mi empresa y emplear el resto de mi tiempo y esfuerzo en aprender y experimentar cosas diferentes de esa especialidad. O como dicen los libros de autoayuda: salir de mi zona de confort.

Esto me ha permitido realizar una transición ordenada de algo de decadencia a algo en crecimiento y consolidación. En mi caso he realizado me he ido especializando en desarrollo .NET, despues en desarrollo y adminstración de SharePoint. Desde SharePoint a desarrollo y administración en Office 365 y de Office 365 a Azure, donde el perfil de arquitecto te exige ser un generalista.

Pero eso es otra historia. Y aun me quedan más de 40 años de trabajo. Espero.

 

 

 

Anuncios

Libro: Salir del abismo

abismo

Título: Salir del abismo
Autor: Seth Godin
Editorial: Granica

Libro pequeño, de generosos márgenes y apenas 140 páginas que se puede consumir en una tarde o en un par de días de lectura ligera. Era una elección obvia cuando vi el título tan sugerente, y porque llevo tiempo pensando en el tema de la dispersión de esfuerzos como problema y en la necesidad de abandonar cosas sin futuro para poder centrarme en temas más importantes.
El mensaje del libro es bastante concreto y simple: abandona lo que no funciona y concéntrate en lo que sí puede funcionar aplicando más esfuerzo o persistencia.
Dicho así parece una tontería pero es algo importante y es extremadamente fácil olvidarlo y un libro corto puede es suficiente para volver a ponerlo sobre la mesa.

Algunos conceptos interesantes son las curvas de abismo, arrecife y callejón sin salida:

  1. El abismo puede ser demasiado grande para cruzarlo con los recursos disponibles (tiempo, dinero…) pero es el mismo abismo el que nos protege de otros competidores y nos da el éxito, es más cualquier competidor tenderá a ensanchar el abismo una vez que lo haya cruzado.
  2. El callejón sin salida es una curva casi plana, da igual lo que hagamos, ni mejora ni empeora.
  3. El arrecife siempre mejora, de forma constante pero al final se viene debajo de forma rápida. Es importante detectar donde estamos en cada momento para saber cuando abandonar o continuar de forma meditada.

Tres preguntas que el autor sugiere hacer antes de renunciar son:

  1. ¿Estoy sucumbiendo al pánico? Nunca renuncies en estado de pánico, espera a que el momento duro haya pasado y ha haber recuperado la calma antes de tomar la decisión de renunciar. Es más, decide de antemano en qué condiciones vas a renunciar, de modo que tengas una decisión no afectada por las circunstancias de un mal día o mes. Observa la renuncia como una decisión estratégica y tenla planificada desde el inicio. Ten perspectiva.
  2. ¿A quién estoy tratando de influenciar? Es diferente si tratamos con una persona a si lo hacemos con un mercado. La primera tenderá a hacer el abismo más ancho con cada interacción mientras que el segundo tenderá a hacerlo más estrecho. Es decir, renuncia rápido a convencer a una persona pero insiste mucho cuando quieras vender un producto a un mercado (diferentes personas).
  3. ¿Qué tipo de progreso mensurable estoy logrando? Solo puedes estar en tres estados para cualquier objetivo: avanzando, parado o retrocediendo.

Quizá es un libro que interesará a quienes no estén a gusto en su actual empleo, proyecto o hobbie. Es fácil aplicar lo que comenta el autor a casi cualquier ámbito, solo tienes que tener ganas de mejorar en algo.

Como citas para el recuerdo dejo algunas, con mención especial al Transbordador Espacial de la NASA que finalmente fue cancelado y reemplazado por cohetes Falcon de SpaceX, más baratos, rápidos seguros y mucho más chulos:

Numerosas organizaciones se cercioran de cumplir con todos los requisitos -tienen servicio al cliente, una recepcionista, una ubicación conveniente, un folleto, etc.-, pero todo ello es mediocre. Por lo general, los clientes escogen a otro: su competencia. Eligen a los competidores que no tienen un rendimiento óptimo en algunas áreas, pero que son excepcionales en las que interesan.

-o-

El secreto de las organizaciones exitosas es la renuncia estratégica. La renuncia reactiva y la renuncia en serie son la ruina de quienes luchan por conseguir lo que quieren (pero no lo logran). Eso lo hace la mayoría de las personas. Se dan por vencidas cuando el reto se vuelve doloroso y perseveran simplemente por no molestarse en renunciar

-o-

¿Para qué vender una división de miles de millones de dólares que está obteniendo felizmente beneficios y ocupando el puesto número 4 en participación en el mercado? Fácil: porque distrae la atención de la gerencia. Absorbe recursos, capital, enfoque y energía, y, sobre todo, le dice al personal de la organización que está bien no ser el mejor del mundo.

-o-

Las personas esforzadas y motivadas encuentran en la diversificación un desahogo natural para su energía y entusiasmo. La diversificación parece ser el camino correcto. Ingresar en un nuevo mercado, solicitar un empleo en un área nueva, practicar un nuevo deporte. […] Sin embargo, el verdadero éxito lo obtienen quienes se obsesionan.

-o-

Es fácil y divertido empezar a construir algo en el garaje de casa. Es difícil y costoso comprar un molde de inyección, diseñar un circuito integrado o prepararse para producir a gran escala. El tiempo, el esfuerzo y el coste de prepararse para una producción a gran escala crean el abismo. Este mantiene bajo el suministro de productos y aísla y protege a quienes tienen el coraje suficiente para invertir en producción a gran escala.

-o-

El transbordador espacial es un callejón sin salida, no un abismo. Cuando los expertos argumentan a favor del transbordador, no dicen: “Debemos seguir haciendo esto porque con el tiempo va a ser más seguro/barato/productivo”. La única razón por la cual el transbordador existe todavía es que nadie ha tenido el coraje de cancelarlo. No hay razón alguna para seguir invirtiendo en algo que no va a mejorar.
De hecho, si canceláramos el transbordador, crearíamos una necesidad urgente de reemplazarlo. La no existencia de una forma para llegar al espacio nos forzaría a inventar una nueva alternativa, mejor y más barata.
Entonces, ¿por qué no lo cancelamos? ¿Por qué no renunciar a él? Por la misma razón de siempre: porque día tras día es más fácil seguir con algo a lo que estamos habituados, que no altera mucho las cosas, que no hace daño.

-o-

[De la Declaración de Independencia de Estados Unidos] “la experiencia ha demostrado que la humanidad está más dispuesta a sufrir, mientras los males sean tolerables, que a mejorar su situación mediante la abolición de las formas a las cuales está habituada”.

-o-

La respuesta más habitual al abismo es optar por la seguridad. Realizar el trabajo ordinario, hacer una labor sin tacha, una tarea irreprochable. Cuando afrontan el abismo, casi todas las personas aguantan e intentan seguir la vía promedio hacia el éxito.

Nota curiosa: Toda la redacción, edición y publicación de este post se ha hecho en un par de viajes en trenes Avant a 200 km/h con Tablet, móvil para la conexión y teclado Bluetooth.

Libro: El despertar de la PYME

pyme

Título: El despertar de la PYME.
Autor: Carlos Delgado Zarco.
Editorial: Carlos Delgado Zarco.

Explicar porqué cogí este libro es complejo, así que simplemente diré que me interesan las empresas, los procesos y los productos. Y siento un gran respeto por las PYMES y los autónomos. Y este libro trata sobre ellos aunque sea para vender formación de Level UP. Vender no es nada malo de hecho es algo bueno para cualquier PYME, pero pienso que hay que ver el libro como una parte de un proceso de transformación más largo y que requiere de tiempo y dinero.

Las 27 historias (más 1 la del autor) que Carlos Delgado incluye están orientadas a inspirar el crecimiento de las personas en el ámbito profesional. Creo que son buenas y cumplen su objetivo, aunque soy de los que piensan que solo se puede convencer a quien ya está convencido. De todos modos, si te sientes estancado en tu vida profesional, tienes una empresa o quieres conocer historias personales sobre ellas, este libro debería resultarte interesante. Además es extremadamente fácil de leer.

Incluyo aquí mi resumen y notas de cada capítulo para poder recordarlos en el futuro, pero el verdadero valor del libro es el de las historias que cuenta. Son inspiradoras y sirven de ejemplo para demostrar que se puede hacer lo que no creemos posible. Ah y cada historia incluye datos de facturación de la empresa y empleados, lo que ayuda a ver las cosas con perspectiva.

Ahí van las notas:

  1. No esperes actos de fe porque el cliente no es creyente. José Luis Guzman. ReforHabit. Tuvo que hacer algunos cambios para que la gente confíase en sus propuestas. Añadir los rostros de la gente de la empresa, hacer la propuesta atractiva, incluir una “bio” de la empresa…
  2. El tiempo ni se crea ni se destruye, solo se aprovecha o se desperdicia. Sarah-Jane Anthony. Smartenglish Creative Language School. Tener muy claros tus objetivos para poder dedicar todo el tiempo a ellas en lugar de a cosas menos importantes. 4 horas diarias pensando en el negocio. Mantener la cabeza clara con un equilibrio entre la vida personal y la laboral.
  3. O consigues una venta o te venden un motivo por el que no compran. Laureano Pérez-Andujar. Enerluz. Centrar la venta en el comprador, no en el producto. Menos datos técnicos y más estética, garantías y sencillez. Emplear los “fracasos” para obtener feedback y mejorar la siguiente oferta.
  4. Rompe las reglas del mercado antes de que el mercado te rompa a ti. Inma Sánchez. La Pastora. Todos los productos pueden evolucionar de formas muy creativas, como el pimentón de La Pastora hizo (caviar de pimentón, café de pimentón…). Lo extraordinario llama la atención. Cambia lo que ofreces, hazlo de forma creativa. Como mínimo llamarás la atención, aunque vendas más de lo mismo.
  5. Estás diseñado para acumular basura mental. Tira de la cadena. Ángel Díez. SoundAndL. Un grave accidente nos muestra que lo creemos y pensamos nos limita y que la práctica de cualquier cosa nos hace mejores en ello.
  6. Se te conceden 3 deseos: que tu talento genere los ingresos para vivir la vida que deseas. Antonio Hernández. Libera tiempo para hacer lo que te apasiona y vende experiencias, no horas o personas. Y haz un plan de negocio por dios.
  7. Negocia por sistema, por mucho que lo temas. Javier Santías. Farmacia Santías. Todo es negociable. Encuentra a la persona que decide y trata de obtener un buen trato para ambos. Y controla tanto lo que entra en caja como lo que sale (ventas vs gastos).
  8. La primera venta es como el primer beso: si triunfas, vendrán muchos más. Gustavo Amorós. Librería Puzzle / Summum Consulting. “El negocio ha de tener dos estrategias diferenciadas […] Por un lado, la creación de visibilidad y captación de clientes. Por otro, la fidelización y el aumento de la frecuencia de consumo.” Y hay que mover el culo en ambas.
  9. Que un lingote de oro no te impida ver la mina de diamantes. Jorge Juan Ortiz. Beltá Frajumar. Identifica a tu cliente ideal, entiende sus deseos y necesidades y obtén margen de él. Y después trata de ver cómo acceder a más y mejores clientes y mercados. Normalmente tendrás que evolucionar tú y tu negocio para hacerlo posible. No te límites a hablar con el cliente. Conecta con el. Entiéndele.
  10. No vivas lo que te suceda. Haz suceder lo que quieras vivir. Ramón Sánchez Paco. One Telecom. Sal a vender y hazlo de forma metódica, con un plan a largo plazo. Usa los medios a tu alcance, como Internet.
  11. La gente no compra productos o servicios, sino la emoción que les provoca. Antonio García. Santa Cruz Arquitectos. Vende emociones. El producto es una décima parte de importante que las emocione positivas que produzca.
  12. Tus ingresos no dependen ni de lo que dices ni de lo que sabes. Dependen de lo que haces. Andrés García. Relaciones Profesionales Estratégicas SL. Menos hablar y más actuar. Enfrentarse al miedo, definir objetivos y dividirlos en tareas.
  13. Reacción en cadena: antes de la venta física, se produce la química. Maria Ángeles Carnicero. Limpiezas Poniente. Sorprende o asusta para captar la atención. Genera deseo en el cliente, conecta con él de forma positiva, de persona a persona. No se trata de las características del producto sino de los resultados positivos que generará.
  14. Haz de tu negocio una máquina de generar dinero… ¡sin que tú estés en él! Raúl Sanchís. Turcafi2006 SLU y TODO Raúl Sanchís. Trabaja para tu negocio, no en él. Intenta ser prescindible, que funcione solo. Intervén solo cuando quieras que vaya mejor o si es imprescindible (debería ser en pocas ocasiones). Automatiza y delega, solo así puedes crecer (escalar), asegurar la calidad de tu producto o servicio y hacerte prescindible. Puede “automatizar” con procedimientos, videos… pero revisa las cosas de nuevo de vez en cuando para adaptar y mejorar.
  15. Convierte a tu equipo en la locomotora de tu cambio. Carlos Soler. Embasana. El trabajo lo hacen personas y las personas necesitan ciertas cosas como comunicación y reconocimiento. Delegar es clave si quieres crecer y para eso se necesita confianza. Algunas cosas concretas pueden ayudar, como: 1) reunión semanal de hora y media con todo el equipo para hablar de problemas, éxitos, resultados…; 2) cualquier persona del equipo debe poder hablar de lo que necesite (personal o profesional) cada día al menos durante una ventana de tiempo; 3) como líder pregunta a las personas como están, si están contentos, obtén feedback con frecuencia.
  16. Tu problema no es la competencia sino la falta de competitividad. Francisco Javier Martín. DecoElx. Comunicar es esencial para que te compren. Los posibles compradores necesitan conocerte para poder comprarte. Hay diferentes formas y canales y los resultados son modestos pero tienes que hacerlo si quieres vender.
  17. Las personas son como un iceberg: lo que ves es mucho menos de lo que no ves. Rocío Vargas. Vilcabamba Tours. Lastre emocional: en lugar de enfrentarnos a los traumas emocionales, los escondemos. Y nuestra mente retuerce la realidad para evitar conectar con ese dolor. La rabia y el rencor nunca van a ayudarte a salir adelante y mejorar. Rodéate de gente buena, que te aporte algo positivo emocionalmente y acepta a las demás por tu propia salud mental. De una forma u otra cada persona trata de hacer lo mejor siempre, pero los contextos y las experiencias de cada persona son diferentes por lo que no los entendemos.
  18. Sorprende, impacta, molesta… y luego pregunta. Luis Iglesias. Look & Find y otras. Para innovar se necesita mucho conocimiento. No se puede gustar a todo el mundo pero es mejor recibir críticas que ser invisible; y es mejor hacer cosas y equivocarse que quedarse parado.
  19. El éxito no está en la idea, sino en la ejecución de la idea. Rocío Márquez. Casaturis. La persona detrás de un negocio es la que hace a diferencia. Por eso Casatauris, a pesar de ser un Airbnb, funciona. La ejecución de Rocío es diferente, innovadora frente a la startup y por eso funciona.
  20. Hazte íntimo amigo de los números. Es cuestión de confianza. Ana Bardají. Siete Semillas. Mide todo, usa los números para averiguar cómo va tu negocio y como tienes que gestionarlo. Es lo único que te permitirá mantener el control.
  21. El día que entiendas que lo malo, lo bueno y lo regular es 100% tu responsabilidad, tu vida cambiará. Alejandra Payá. Yeclaweb. No achaques a causas externas tus problemas, la responsabilidad de cambiar tu propio entorno es completamente tuya. Auto-engañarse es fácil y cómodo pero te mantendrá en un hoyo.
  22. La llave del crecimiento ilimitado: capta nuevos clientes a mayor ritmo del que los pierdes. Marcos Pareja. Runner Soul. Tienes que captar clientes porque siempre perderás algunos largo plazo. Y para ello tienes que ir a donde esté y conocerle a lo largo del tiempo. Así además podrás adaptarte a su demanda.
  23. Objetivo liquidez: tu negocio no existe para vender ni para facturar, existe para ganar dinero. Pablo Soler. Maza Grupo. En cualquier negocio necesitas liquidez. Para ello: 1) desarrolla un buen equipo, 2) automatiza procesos para ahorrar tiempo y dinero, 3) usa indicadores para gestionar y 3) maximiza la liquidez para poder invertir (tener libertad y crecer).
  24. Los placeres externos no llenaran nunca el vacío interior. Mayte Romero. Mayte. Como interpretamos y reaccionamos a los elementos (de personas o situaciones) depende de nosotros. Como lo tomemos y gestionemos es responsabilidad nuestra, al igual que de con quien y cómo pasamos el tiempo. Ser nosotros mismos y no otra persona, una máscara, es la única forma de ser feliz.
  25. Lleva a tu cliente hasta el orgasmo experiencial. Francisco Bernal. CaféLab. El producto es quizá lo menos importante de un negocio. El cliente consume experiencias y puedes conseguir generar una excepcional a base de pequeñas y constantes buenas experiencias a lo largo del proceso de venta, consumo y hasta pago. Eso sí, tiene que ser algo rentable y requiere tiempo más que dinero el conseguir estas mejoras.
  26. No vendas caviar a quien se alimenta de embutido. Alberto Oliver. Karamel Audiovisuales. Un negocio es un negocio, independientemente de las capacidades técnicas , idea, suerte o dinero que inviertas, necesitas entender cómo funciona un negocio para que este sobreviva y prospere. Un buen técnico y empleado metido a empresario necesita entender eso. Elige a tus clientes con cuidado y desecha a los que te generan pérdidas para poder invertir tiempo y energía en los que generan beneficios. Para ello debes conocer a tu cliente ideal y para eso necesitas datos personales o de empresa, dependiendo de quién sea tu cliente.
  27. Sé fiel a tu corazón. Él ya conoce el camino. Ana Cascales. Dear.Coach. Hacer algo que no te gusta y con lo que no estás de acuerdo no es forma de vivir. Busca lo que realmente te gusta y trata de fijarte objetivos para vivir alineado con tus necesidades y creencias.
  28. Tus resultados pasados y presentes no garantizan tus resultados futuros. Pon siempre el 100%. Carlos delgado. Level UP. No te duermas en los laureles. Siguen trabajando con cabeza cada día. Si no mejoras regularmente es que te has estancado.

La horda (equipos)

Hoy pensaba en un patrón de comportamiento de algunos equipos que he observado una y otra vez a lo largo de los años. Lo llamo “La Horda” y es algo que experimentado tanto como observador, como miembro activo u ordo.

Qué es y cómo funciona La Horda

La horda en equipos de desarrollo suele producirse cuando sucede algo que se percibe como importante, afecta a todos y además nadie sabe qué está pasando o qué implica realmente. El motivo puede ser variado: un error raro en un entorno de producción, un merge que salió mal y se ha extendido al resto de ramas, o una decisión sobre el código común. En esos momentos, la confusión y el caos se apoderan del equipo y los individuos pierden su identidad para convertirse en una masa, un grupo con mucha actividad y pocos resultados que realiza acciones sin coordinación y de forma más automática y emocional, que meditada.

En este “modo” de funcionamiento, los miembros del equipo no tratan de coordinarse o comunicarse de forma efectiva, sino de imponer su visión al resto, ya sea hablando sin escuchar o tratando de hacerse con el control de la horda (sin éxito dado el estado alterado general). En muchos casos algunos miembros de la horda actúan sin pensar provocando aún más caos. En otros la horda se divide en facciones que solo se comunican, o bien para defender intereses o bien por afinidades personales.

Al final, algo provoca que el tema se apague: el error de código desaparece, la gente se cansa o llega la hora de irse a casa. Entonces la horda se disuelve y vuelve a sus quehaceres. Lo interesante de este punto es que nadie se preocupa de ir más allá: el peligro ha pasado y no se siente la necesidad de dedicar más tiempo al tema. De este modo el origen del problema queda sin resolver, por lo que volveremos a ver una nueva horda en semanas o meses.

No creo que todo esto sea simple desorganización. Es más, tratar de organizar no ayuda, solo empeora las cosas o cabrea a los ordos.

Territorio Horda

Parece más fácil avistar una horda en equipos de desarrollo juniors que cuando hay seniors. Me refiero a veteranos de verdad, no gente con 1 año de experiencia repetido 20 veces. Supongo que esto se debe a que los veteranos están más curtidos y entienden que ciertas situaciones no son tan importantes o urgentes como puede parecer en un principio. También debido a que la experiencia adquirida les da más confianza en resolver el problema más pronto que tarde.

También parece más fácil que se forme la horda en entornos de desarrollo, que en entornos de sistemas. Mi hipótesis es que los equipos de desarrollo son más grandes que los de IT y con más especialistas (front-end, back-end, bases de datos…), dos características que generan problemas para mantener una visión de conjunto del trabajo (el conocimiento está muy fragmentado), aumentando el caos.

Además, tradicionalmente Sistemas no crea o genera cosas, sino que las administra, por lo que tiene más documentación y procesos que ayudan a mantener las cosas bajo control. Esto unido a que tienden a correr menos riesgos, evita que las cosas se pongan feas.

Defenderse de la horda

Creo que el problema de fondo que facilita la aparición de la horda es la falta de ganas de comunicación en el grupo. Es la escasez de tiempo lo que a menudo propicia esa falta, pero hay muchos otros factores que se suman día a día, a lo largo del tiempo, lo que genera hordas de forma cíclica.

Es normal que en un grupo que haya cierta brecha entre las experiencia y conocimientos de las personas y esto provoca que la comunicación requiera esfuerzo, como en el caso de padres e hijos. También es normal que existan diferencias de valores comunes y diversidad de caracteres, lo cual es sano y deseable. Sin embargo, cuando hay falta de interés en la comunicación (de serie o por razones externas), o si las personas del grupo desarrollan celos o rencillas (por sueldos, roles, rumores…), entonces la información tiende a ser, ocultada, distorsionada y se prejuzga con facilidad. Todo esto influye en que la comunicación se resienta, desembocando en hordas más o menos regulares.

La comunicación es algo difícil, requiere esfuerzo constante de todos y, aunque algunas personas puedan facilitarla en ocasiones, suele decirse con acierto que “no hay peor sordo que el que no quiere oír”: cuando alguien no quiere comunicarse, no hay forma de comunicarse y esto es un problema para el grupo muy difícil de resolver.

En mi opinión cualquier estrategia para evitar la formación de hordas requiere de tiempo y esfuerzo constante, y no siempre funcionará o será viable. Pero merece la pena intentarlo siguiendo estos pasos:

  1. Elige la capacidad de comunicación sobre la excelencia técnica en los miembros del equipo. Leer y escribir suelen ser buenos indicadores (no garantía) de que alguien disposición e interés en ello. Otros elementos de comunicación, como la escucha activa, son más complicados de detectar, especialmente en entrevistas. Y por supuesto entrena las capacidades de comunicación, no son algo que se aprende y ya está, hay que practicar, analizar, estudiar y mejorar constantemente.
  2. La paciencia y la experiencia variada ayuda a no caer en el pánico, facilitan la comunicación y el entender situaciones nuevas. Por eso ambas características son interesantes para cualquier grupo. Cuanta más y mejor distribuida, mejor.
  3. Reserva tiempo para comunicar a menudo. Si el equipo está sobrecargado esto se va a resentir. Pero eso no significa que una sola persona o un pequeño grupo sean los únicos responsables de buscar tiempo o iniciar la comunicación. Todos deben hacerlo.
  4. Emplea todos los canales de comunicación disponibles. Hablar es el más básico de los disponibles actualmente y probablemente el peor, porque que requiere poco esfuerzo (tiende a hacerse mucho y mal), solo funciona bien de 1 a 1, necesita que las personas sincronicen agendas, etc. Hace 6.000 años que tenemos escritura y desde hace bastantes décadas podemos grabar y transmitir audio y vídeo, amén de nuevos canales de comunicación escrita (chats, wikis…). Emplear exclusivamente el “sentarse a hablar” es negligencia.

Para acabar, dejo al lector una cita de Wikipedia que encontré leyendo sobre hordas de verdad. Me parece interesante para seguir reflexionando sobre el tema y me invita a pensar que quizá haya espacio para un antropólogo en los equipos de desarrollo. Al menos en los de las grandes ligas como Google, Amazon o Microsoft.

Jared Diamond define algunas características propias a las organizaciones sociales de los seres humanos en hordas:

  • Son las sociedades más pequeñas, entre 5 y 80 personas, estrechamente emparentadas;
  • Carecen de muchas instituciones como leyes, policía y tratados para resolver conflictos;
  • No tienen base de residencia;
  • Sociedad «igualitaria». Liderazgo informal;
  • Todos los humanos presumiblemente vivieron en hordas hasta la adopción de la agricultura;

Podando el árbol del conocimiento

arbol

Durante agosto he reducido mi lista de lectura de Pocket de 150 a tan solo 98 artículos (los más densos). Aún tengo horas de video de YouTube y Channel9 por ver, cursos pendientes por hacer en Microsoft Virtual Academy, Lynda (LinkedIn Learning) y Alison y docenas de libros y artículos por leer en PDF o papel.

No es que no lea, haga cursos y vea videos, es que no consigo hacerlo con la velocidad suficiente como para reducir su número. Llevo cerca de un año intentando reducir esas cifras, particularmente en Agosto, pero solo consigo frenar su aumento, que no es poco.

Revisando este blog es evidente que se trata de problema que está ahí desde hace tiempo, pero últimamente está empeorando debido a los múltiples roles que desempeño gracias al crecimiento profesional de mis últimos años: arquitecto de software, team leader, gestor de servicio, coach… Cada uno de ellos con unos requisitos de conocimientos y habilidades diferentes que no hacen sino ampliar el problema.

Entiendo que el origen de esto, no es tanto la cantidad de cosas que aparecen o toman relevancia en el plano técnico, como mi crecimiento profesional, mi dedicación a mi familia y mis años de experiencia y conocimiento acumulado. Esto último me hace más consciente ahora sobre lo que no sé en diversos dominios: tanto más allá de Microsoft, como más allá del desarrollo puro y duro. Otros han hablado ya del síndrome del impostor, pero este post no va de eso.

Creo que es momento de aceptar la realidad y dejar de nadar contra la corriente para empezar a navegar con ella. Dicho de forma menos poética esto implica reducir mi espectro de “intereses” y empezar a eliminar todo lo que no pueda traducirse en una mejora importante de mi vida. En particular, el tiempo que dedico fuera del trabajo a aprender o mantenerme al día debe tener una razón de peso para hacerlo y un impacto tangible. Por ejemplo, mi actividad en SwCraftersCLM continuará porque me carga las pilas aportar a una comunidad de forma directa y desinteresada. Además me pone en contacto con gente, problemas y soluciones fuera de las burbujas de Microsoft y Madrid, que siempre es algo bueno.

Escribo este artículo para obligarme a parar a pensar en este problema y en posibles soluciones; para ayudarme a seleccionar qué se queda y qué se va de todo ese conocimiento que tengo en cola; y para seleccionar una ruta más concreta de aprendizaje que mejore mi futuro.

Provisionalmente la lista de temas importantes para continuar aprendiendo o trabajando, es esta: Soft skills para mejorar lo que hago con personas, Arquitectura de Azure para no quedarme desactualizado al ritmo que lleva la nube en la que trabajo actualmente y Blockchain porque parece la tecnología con más potencial de los últimos 20 años… y además puede trabajarse en Azure.

NOTAS:

Dado que uso este blog como una bitácora donde apunto temas que quiero tener a mano en el futuro, he podido revisar mi proto visión de este problema a lo largo de los años (años ’10, ’11, ’12, ’15 y ’16).

Reproduzco aquí algunos extractos por si alguien tiene interés o ve paralelismos con sus propios problemas y le ayuda a resolverlos:

El mundo del desarrollo con Microsoft, a pesar de todas las facilidades, potencia y posibilidades de integración que ofrece, puede llegar a hacerse bastante cuesta arriba cada vez que sale una nueva versión de sus productos, algo que sucede, para bien o para mal, muy a menudo.

[…]

tenía ganas de soltarlo y pararme a pensar un rato sobre ello, porque el reciclaje constante, el cansancio acumulado gracias a mi pequeña Celia, y los proyectos pueden llegar a hacer pesados los días de I+D con límite de tiempo, y eso hay que atajarlo si no se quiere acabar con un síndrome de burnout.

Desde <https://jbolano.wordpress.com/2010/01/28/reflexion-sobre-el-desarrollo-de-software-tecnologias-y-herramientas-reciclaje-extremo/>

siempre hay que estar aprendiendo, pensando y probando, nunca puedes “apalancarte” y muchos acaban quemados o abandonando lo que parece una carrera de ratas. Al final los que quedan, son probablemente los que más y mejores soluciones conocen (por mera experiencia) y eso debería hacerlos valiosos por encima de modas.

Desde <https://jbolano.wordpress.com/2011/12/18/toma-de-decisiones-y-desarrollo-de-software/>

“¿cómo arreglamos este gap, este abismo de conocimientos que está cargándose la viabilidad de mi empresa?” La respuesta es, en mi opinión, que no se puede resolver, solo podemos tratar de minimizar el problema. Y para minimizarlo, al margen de reconocerlo en nosotros (sí, todos lo tenemos, no se libra ni Dios) y en los demás, debemos tratar de atacarlo a la mínima oportunidad: si vemos que nuestros compañeros desconocen algo o realizan tareas que debería estar realizando una máquina, debemos acercarnos y ayudar con ello. Se requieren también paciencia, curiosidad y humildad para reconocer nuestra propia ignorancia y ocasional estupidez. Y se requiere una voluntad de equipo para tratarla entre todos en el día a día, a pesar del estrés, los roces y los humos de cada uno de nosotros. Pero sobre todo, creo que se requiere valor y asertividad para cuestionarlo todo (independientemente de la jerarquía) y disentir públicamente.

¿Difícil? Sí. ¿Incómodo y desagradable en muchos casos? Desde luego. Pero la alternativa dada la velocidad de los acontecimientos, es el fracaso a medio y largo plazo. Y si no, que se lo digan a la industria musical (barrida por iTunes y el P2P), la industria del cine (barrida por Megaupload y los torrents) o la industria editorial (barrida por Amazon y los ebooks) entre otras afectadas por no tener un marco de conocimientos adecuado sobre la tecnología y las herramientas.

Desde <https://jbolano.wordpress.com/2012/08/14/el-abismo/>

el desarrollo de software ha pasado por muchas etapas en un periodo de tiempo muy comprimido y en cada una ha ido ganando complejidad, añadiendo capas de abstracción y mejorando todo lo existente anteriormente de manera fulminante (a ver quién se acuerda de Word Perfect, Altavista o Myspace). Y durante ese viaje, los desarrolladores hemos ido aprendiendo por las malas que cada problema es muy distinto y requiere distintas aproximaciones

Desde <https://jbolano.wordpress.com/2012/09/27/una-breve-historia-del-desarrollo-de-software/>

Creo que todas estas son buenas razones para esperar unos tiempos la mar de interesantes en todos los frentes, y estoy deseando ver qué pasa y cómo reaccionan competidores y mercados. Ver qué falla y que arrasa, y por supuesto qué más se saca todo el mundo de la manga.

Desde <https://jbolano.wordpress.com/2012/10/22/el-desembarco-de-normandia/?preview=true&preview_id=2446&preview_nonce=0f8b62d27f>

Para terminar solo quiero dejar una última reflexión: cuando veo desarrolladores que se enfrascan exclusivamente en su tecnología de trabajo actual y por falta de tiempo o curiosidad, saben poco o nada de otros campos, herramientas y tecnologías, pienso que es poco probable que sean capaces de aportar ideas nuevas y por lo tanto de evolucionar y mejorar. Y eso es malo para todos.

Desde <https://jbolano.wordpress.com/2015/03/22/reflexion-analogias-experiencia-directa-y-desarrollo-de-software/>

muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos cómo se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

Desde <https://jbolano.wordpress.com/2016/12/09/developer-timeline-1996-2016/>

Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SwCraftersCLM GDG Toledo y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 1.2 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017 2018.

El Excel es el siguiente: Developer Timeline 1996-2017

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

Las dos palabras que todo profesional debería usar más

Hace unos días, Manuel de la Peña twiteó un texto que comentaba una vieja historia (más bien fábula) de monos, jaulas, preguntas y procedimientos.

Eso me trajo a la memoria pequeño artículo que leí en Hardvard Business Review sobre el arte de hacer preguntas. Un artículo que en su momento me invitó a pensar en la importancia no tanto de las técnicas de hacer preguntas, como de lo esencial que es conocer el “por qué” de las cosas (y para lo que se necesita hacer preguntas, claro).

También me recordó este otro artículo sobre qué hacen las personas que son buenas escuchando y que en mi opinión es una consecuencia de interés genuino en entender los “por qué“.

La falta de interés y esfuerzo en tratar de entender las cosas, sus objetivos y contextos (esto es, el “por qué“) es un tema que me da mucha rabia observar (incluso en mi) y del que hace tiempo que tenía pendiente quejarme un poco en público. En público, porque tiene relación directa con todos los procesos que se realizan en cualquier empresa; también con las buenas prácticas (best practices) que parece que muchas personas se emperran en recomendar o exigir sin entender que dependen del contexto. Y por supuesto porque tiene que ver con los que critican (y criticamos) decisiones de terceros a nivel personal, de negocio o político casi a diario.

Hay por supuesto profesiones en las que en general se necesita hacer preguntas básicas constantemente de forma directa o indirecta, como en medicina (¿le duele aquí?, ¿puede caminar?), donde cada prueba médica es una forma de pregunta y cada mirada o toque está orientado a obtener una respuesta (el ojo clínico). Supongo que haber tenido un padre médico ayuda a ver ciertas cosas de cierta manera.

No obstante, la mayoría, durante la mayor parte del tiempo observa, juzga y condena sin conocer el “por qué” de una decisión. Pocos se molestan en hacer preguntas la mayor parte del tiempo. Mucho menos una tan básica como “¿por qué?“. Y desde luego nunca seguida de otro “¿por qué?” como en el método Toyota-Lean-Kaizen-Six Sigma de los 5 por qué para la mejora de procesos.

Me temo que hemos cogido miedo a hacer preguntas básicas, las más importantes, por miedo a parecer ignorantes y menos valiosos en nuestro entorno personal y puesto de trabajo, e irónicamente eso nos hace más ignorantes y menos valiosos.

Pero no acaba ahí el problema: como nadie hace preguntas para entender un contexto todos acabamos dando por sentado que este no importa y/o que todos tenemos la misma idea en la cabeza, lo que provoca errores y dificultad en la comunicación. Un desastre.

En fin, que las dos palabras que creo que todos deberíamos usar más son evidentemente “¿por que?”. Aunque hay otro par de palabras que, si se usasen con sentimiento real, también deberíamos usar más y mejoraría mucho nuestras vidas: “por favor”. Porque es sorprendente lo bien que responden algunas personas a un poco de interés y educación y como redunda eso en un win-win de libro.

Así que tras quejarme un poco y habiendo dejado algunos enlaces (espero) interesantes, solo puedo cerrar este post invitando a todos a preguntar más y mejor. Con inocencia y abiertos a escuchar.