• ¿La carrera de un desarrollador de software se termina a los 35?

    Cuando hablo de Soft Skills con “programadores de hueso colorado”, la reacción más prevalente es la de “¿por qué dejaría de programar, si es lo que más me gusta en la vida?” Pero la medida en que te guste algo no es siempre indicativo de los ánimos que tienes de hacerlo.

    Este artículo explora lo que sucede con algunos desarrolladores de software cuando cumplen 35 años. Esta es una edad interesante porque, digamos, si iniciaste a programar en tus veintes, a los 35 es probable que ya tengas una década, o más, de experiencia. 10 años haciendo lo mismo es suficiente tiempo como para comenzar a cuestionarte si te ves haciéndolo por otros 10. Para algunos, la respuesta es sí. Para otros, como yo, la respuesta es un resonante no.

    Algunas de las conclusiones a las que llega el autor:

    • Dejas de llamarte “programador” y comienzas a especializarte en resolver cierto tipo de problemas para el mejor postor
    • Pones tu negocio o startup
    • Te sales de la industria completamente

    Mi objetivo con Soft Skills para Devs y con mi newsletter, es ampliar el panorama de los desarrolladores de software de LATAM. Lo que quiero es ayudarte a que desarrolles habilidades que te permitan tener opciones para hacer un cambio en tu carrera cuando ya no quieras programar. ¿Estás lista?

  • Como pensar en términos de sistemas, de forma segura

    El mundo es tan diverso, y la historia de la humanidad tan amplia, que sería extremadamente raro que te toparas con un problema que no haya sido resuelto por alguien antes. Los Modelos Mentales te ayudan a extrapolar la experiencia de otras personas resolviendo cierta categoría de problemas, para que tú puedas tomar decisiones para problemáticas puntuales.

    Algunas reglas para que tengas cuidado cuando uses modelos mentales para resolver problemas:

    1. Cuando tu modelo mental y la realidad no concuerden, la realidad siempre gana
    2. Los modelos mentales no cambian, la realidad sí
    3. Todos los modelos omiten información; algunos modelos mentales omiten información crucial

    Tip: Si bien usar modelos mentales es una buena estrategia para hacer una aproximación a una respuesta acertada, no es garantía de que obtendrás respuestas correctas el 100 % de las veces.

    Si quieres conocer más sobre modelos mentales, te recomiendo que veas esta entrevista que me hizo Héctor, de The Dojo, hace unos meses.

    Enlace: https://lethain.com/how-to-safely-think-in-systems/

  • ¿Cuál es el peor escenario si deja de funcionar la región us-east-1 de AWS?

    Buen recordatorio de que la línea entre Internet y “la vida real” ya no existe.

    En esta publicación, Tim Bray explora qué es lo que podría ocasionar que la región us-east-1 de AWS dejara de funcionar. Y va un paso más allá, a explorar también cuáles serían las implicaciones en “la vida real” si esto llegara a pasar.

    Aunque es improbable, no es imposible. Aun así, la exploración del tema se me hizo bastante interesante, y creo que es una lectura que te puede dar mucho contexto del impacto de tu trabajo.

    Enlace: https://www.tbray.org/ongoing/When/202x/2021/10/08/The-WOrst-Case

  • Software Habitable

    En la industria del software estamos constantemente hablando de cómo hacer mejor software. Pero rara vez nos detenemos a preguntarnos qué, realmente, es lo que significa que una aplicación sea mejor.

    El autor de esta publicación ofrece una forma interesante para pensar acerca de esto: los programadores deberíamos de crear software habitable.

    La habitabilidad es la característica de un código fuente que le permite a programadores, codificadores, arregladores de errores y personas externas, integrarse a trabajar en él entendiendo su construcción e intención, para poder cambiarlo cómodamente y con confianza.

    Al crear software habitable, las personas que trabajan en él tendrán más oportunidades de crear valor para sus usuarios.

    Algunas cosas que contribuyen a hacer que un software sea inhabitable, por ejemplo: abuso de abstracciones innecesarias, sobreingeniería y atajos innecesarios.

    Enlace: http://akkartik.name/post/habitability

  • Enseñándole a un auto a estacionarse en 500 líneas de código

    Un tutorial sobre cómo enseñarle a un automóvil a estacionarse de manera autónoma, usando un algoritmo genético (un tipo de algoritmo que hasta hoy no sabía que existía).

    Sí, la implementación de código es interesante. Pero me gustaría orientar tu atención la forma en que el autor te lleva de la mano para explicarte el por qué y el cómo. Primero, comparte un bosquejo del plan. Luego, paso a paso, te va diciendo qué es lo que está haciendo, y por qué.

    Tip: recuerda que, cuando se trata de comunicar ideas y compartir conocimiento, es importante que conozcas a tu audiencia. Este artículo claramente está pensado para personas que tienen un entendimiento básico de inteligencia artificial, y que se están buscando mejorar sus habilidades con algoritmos genéticos. Observa cómo cada parte del artículo está cuidadosamente diseñado para ser útil para ese público.

    Enlace: https://trekhleb.dev/blog/2021/self-parking-car-evolution/

  • No escribas bugs

    “En vez de utilizar debuggers, ¿por qué no podemos simplemente escribir programas sin bugs?”

    Curiosa exploración de la respuesta a esta pregunta, por el autor de Elements of C Style. Un consejo puntual para reducir sistemáticamente la cantidad de errores que escribes en tus programas: re-lee tu código frecuentemente.

    Puedes encontrar más ideas y consejos pragmáticos sobre programación aquí.

    Enlace: https://www.teamten.com/lawrence/programming/dont-write-bugs.html

  • Cómo evaluar ofertas de trabajo en startups – una guía para principiantes

    Hablando del prospecto de cambiar de trabajo, aquí te dejo esta guía para principiantes para entender cómo evaluar ofertas de trabajo en startups.

    Las ofertas de startups son interesantes porque muchas tienen estructuras compuestas de diferentes beneficios. Claro, está la paga, pero algunas otras ofrecen opciones, beneficios y hasta acciones. Esta guía te explica paso a paso qué significa cada una de esas cosas, cómo considerarlas, y hasta trae un archivo de Excel que puedes usar como plantilla.

    Tip: recuerda que un startup se trata de validar un negocio con tecnología, y en contra del reloj. El potencial de poder ser parte de algo enorme que pueda cambiar tu vida (y la de millones) siempre irá acompañado de cierto riesgo. Así que, antes de aceptar trabajar en algún startup, asegúrate de que entiendes las implicaciones, riesgos y beneficios potenciales a los cuales estás inscribiéndote.

  • ¿Para qué regresar a la oficina si de todos modos vas a estar en videollamadas todo el día?

    Estamos a pocas semanas de que la pandemia cumpla 2 años, y muchas empresas no han logrado acostumbrarse al trabajo remoto. Hay algunas compañías que están desesperadamente buscando cualquier pretexto para validar su idea de que el trabajo real sucede dentro de una oficina.

    Lo que no están considerando, creo, es que aunque las empresas no están tan a favor del trabajo remoto, las personas sí. Y, ¡sorpresa! Una empresa está conformada por personas.

    Cada día hay más y más historias de gente que prefiere renunciar antes que tener que regresar a una oficina a trabajar.

    Tip: si estás en una posición en la que puedes hacer tu trabajo desde una computadora (como programar, por ejemplo), la realidad es que no necesitas estar en algún lugar físico. Considera esto antes de creer en cualquiera que sea el pretexto que tu compañía vaya a usar para intentar convencerte de regresar. El mercado de trabajo remoto está más activo que nunca.

    Enlace: https://www.computerworld.com/article/3635102/why-return-to-the-office-if-you-re-just-zooming-all-day-anyway.html

  • 6 lecciones aprendidas en 6 años trabajando en tecnología

    Esta es una traducción de Six lessons from six years in tech.

    En 2015, llegué a San Francisco y pensé que había encontrado mi hogar para siempre. Cuatro empresas más tarde (Microsoft, Bain, Snapchat, Faire), ya no creo en un hogar para siempre. Pero sí creo en las lecciones ganadas con esfuerzo.

    Aquí hay seis que se destacan.

    Adoración al fundador

    Es fácil quedarse deslumbrado cuando conoces a personas detrás de negocios multimillonarios.

    Lo que sigue normalmente es una completa decepción. Los fundadores genios pueden ser excepcionales en algunos aspectos, pero tienden a ser excepcionalmente malos en otros, como administrar personas y realmente preocuparse por ellas. 

    Sin embargo, los adoramos como superhéroes. De hecho, cada vez que alguien se hace conocido, intentamos emular todo lo que hace: lo bueno, lo malo y lo horrible.

    El equilibrio y el talento extremo rara vez coexisten. En lugar de depender de un genio a quien emular, aprende lo mejor de cada persona con la que trabajas.

    El caos es el estado natural de las cosas

    Detrás de las escenas de cada empresa idolatrada hay en realidad un desastre que funciona libremente. Las cosas que quieres que se resuelvan, no están ni cerca de ser prioridad. Las personas que esperas que sean eficaces no lo son. Este último es especialmente cierto en las empresas más grandes. ¿Cómo es esto posible?

    1. La mayoría de las empresas funcionan a pesar de sí mismas; en todo caso, ¡es una señal de un modelo de negocio sólido! Cuando muchas cosas salen mal, pero el negocio prosigue, es cuando sabes que has encontrado oro.
    2. Su problema es tu oportunidad; Si resuelves sus problemas más importantes y haces que tu equipo se vea bien, rápidamente te establecerás como un jugador valioso.
    3. En medio de incendios interminables, puede optar por desanimarse o trabajar para descubrir las semillas de nuevas ideas.

    La disfunción es el estado natural de las cosas. Te contrataron para mejorar las cosas, aunque sea un poco.

    El modelo de negocios determina la cultura

    Muéstrame su modelo de negocios y te mostraré su cultura. Cuando leí esto por primera vez, todo hizo clic. Siempre me he preguntado por qué la vida dentro de una empresa es tan diferente de sus valores anunciados. Esa diferencia es el incentivo para hacer crecer el negocio.

    Cuando el modelo de negocio son los anuncios, ninguna misión puede escapar a la gravedad de capturar los ojos a toda costa. Cuando el modelo de negocio consiste en vender nuevos proyectos, los mejores en ventas suben a la cima, incluso si tienen grandes defectos de carácter. Cuando el modelo de negocio es el volumen de transacciones, todos están incentivados para que la gente compre más y repetidamente.

    La cultura es derribada por lo que se tolera. Y es extremadamente conveniente tolerar a un idiota cuando tienen una maestría única en hacer crecer el negocio.

    La buena noticia es que puedes profundizar en un modelo de negocio antes de comprometerte con una emresa. Investiga.

    Cada fortaleza es también una debilidad

    Nombra tu mayor fortaleza. Luego lanza una moneda. Si sale cara, tu fuerza te ayuda. Si sale cruz, su fuerza se convierte en un lastre.

    ¿Suena absurdo? Bueno, ¡sucede en la vida real! El lanzamiento de la moneda es tu ambiente profesional.

    Por ejemplo, enfocarse en los detalles es una fortaleza cuando eres un colaborador individual. Pero cuando te distrae del panorama general como gerente, se convierte en un lastre. Incluso la determinación puede ser una responsabilidad cuando se persigue una empresa condenada al fracaso.

    Dado que cualquier fuerza puede funcionar en tu contra, he encontrado dos cursos de acción confiables:

    1. Busca entornos que valoren tus fortalezas y toleren sus responsabilidades
    2. Modula tus fortalezas con base en tu entorno (esto es mucho más difícil)

    El horizonte temporal lo cambia todo

    Todo el mundo quiere ganar dinero y tener razón. La pregunta es ¿cuál es tu horizonte de visibilidad en tiempo?

    Si son los próximos 2-3 años, es mejor que trabajes en FAANG. Si son los próximos 10 años o más, te va a ir bien si consideras hacerte un jugador valioso en una compañía grande, a largo plazo.

    El trabajo duro no es suficiente. Incluso ser “genial” no es suficiente. Lo que se recompensa en un universo de abundancia es lo contrario: la escasez. Ser bueno en cosas que otras personas no son.

    Tu ventaja a largo plazo proviene de tener un conjunto único de habilidades y relaciones. Trabajar en FAANG significa que estás entre más de 500.000 personas en el mismo barco. Buen viento en las velas, pero aun así necesitas estar involucrado en el día a día.

    ¿Cómo se obtienen habilidades y relaciones únicas? Por definición, no hay un camino fijo, pero existen algunos principios atemporales:

    1. Encuentra lo que es divertido para ti, pero difícil para la mayoría de la gente: tu entusiasmo te mantendrá en el juego y te hará ganar puntos de reconocimiento.
    2. Prueba el muestreo de carreras de alta velocidad desde el principio; esto te brinda una perspectiva inusual sobre lo que las personas necesitan y en lo tú eres bueno.
    3. Consume y trabaja en cosas que son inusuales para las personas con ty experiencia, creando tu propia pila de talentos

    En la escuela, la mayoría de nosotros intentamos jugar el mismo juego que todos los demás, tratando desesperadamente de encajar. En el mundo real, y especialmente en la tecnología, el poder proviene de ser diferente.

    Suerte accidental

    La tecnología está llena de suerte accidental. Conozco a varios multimillonarios (de papel). Algunos de ellos trabajaron muy duro, todos ellos estaban en el lugar correcto en el momento correcto. Todos ellos tuvieron ventajas en modelos de negocio increíbles.

    Irónicamente, cuanto más sólido sea el modelo de negocio, menos confrontará las realidades de sus propias habilidades. Un modelo de negocio sólido es como un viento silencioso, pero constante que sopla en tu dirección. Amplifica toda buena decisión y suaviza el golpe de cada mala decisión.

    Si bien estas experiencias se ven impresionantes, aprenderás más trabajando en cosas que no funcionan por defecto. Cuando las cosas funcionan mágicamente, es fácil atribuirlo al talento y al trabajo duro. Cuando las cosas no lo hacen, te ves obligado a moverte más rápido, probar más cosas y confrontar suposiciones erróneas.

    Los aprendizajes vienen del dolor y reflexión. Desordenado durante el proceso, pero gratificante al final.

  • ¿Por qué hay una guía de estilo para JavaScript?

    Jeduan Cornejo compartió este enlace en Twitter, y tuve que incluirlo acá. Se me hace muy curioso cómo es tan fácil ver el lado negativo de las cosas.

    Cuando Airbnb introdujo su guía de estilo para JavaScript, alguien se quejó. Preguntó que por qué intentaban arruinar un lenguaje tan flexible como JavaScript con una guía de estilo. “Es como si a Picasso le hubieran dicho el estilo en el que debía pintar.”

    La respuesta del creador de la guía de estilo es, por decir menos, exquisita. :chef_kiss:

    Tip: Intenta ver las cosas de forma positiva. Si alguien hace una contribución, seguramente es porque está resolviendo un problema. Pregúntate: ¿qué no estás viendo que hace que ese esfuerzo tenga sentido?

    Enlace: https://github.com/airbnb/javascript/issues/102#issuecomment-28157738

  • Ruby remueve lenguaje que promueve el abuso

    Aquí vamos de nuevo. Alguien en una comunidad de programadores hizo una broma sexista, y en vez de tomar medidas al respecto, se pusieron a discutir sobre los matices que hacían que la broma fuera aceptable. ¿Sorprende? No. ¿Aceptable? Tampoco. ?‍♂️

    Si salió algo positivo de todo esto, es modificaron la página oficial de Ruby, removiendo lenguaje que promovía este tipo de conductas abusivas.

    Creo que nunca me había puesto a pensar el efecto en las comunidades que la frase “los miembros deben asumir que los comentarios tenían buenas intenciones”.

    Tip: Independientemente del comentario, la intención y el impacto de tus palabras no son equivalentes. Por mejores que sean tus intenciones, si tu comentario tiene un impacto negativo, eso es lo que cuenta. Sé responsable.

    Enlace: https://github.com/ruby/www.ruby-lang.org/pull/2690/files

  • No, no podemos tener una llamada para eso

    Después de casi dos años de que el trabajo remoto se volviera la norma, hay algunas organizaciones que siguen intentando simular el trabajo en oficina desde casa.

    Es el pan de cada día intentar sacarle la vuelta a las llamadas completamente innecesarias.

    Seguramente este video te ayudará a articular mucho mejor el por qué no puedes tener “una llamada rápida” la próxima vez que alguien te lo pida. Por coherencia, el autor también publicó la charla como un artículo que puedes leer en 15 minutos en vez de aventarte 45 minutos de video.

    Tip: Todos tenemos diferentes fortalezas y debilidades. Para algunas personas, romper los viejos hábitos de comunicación síncrona es algo tan difícil como respirar bajo el agua. “Old habits die hard”, dijo Mick Jagger. La próxima vez que alguien te pida una llamada para algo que no creas es necesario, recuerda que no lo hace por molestarte. Eduquemos con el ejemplo y con compasión.

    Enlace: https://www.youtube.com/watch?v=NVnci3tyDa4

  • La importancia de tener expertos en casa

    Se me hizo interesante este artículo de un ingeniero de Twitter, que comparte la razón por la que Twitter tiene un equipo de ingeniería que es experto en el Kernel de Linux.

    Resumen: cuando trabajas a cierta escala, tener equipos especializados en los aspectos más nucleares de la tecnología paga dividendos.

    Incidentalmente, al leer este artículo me recordó al Tweet de mi amigo Ivan.

    ¡Sorpresa! Dos de esas compañías tienen a varios core developers de Ruby en su nómina, y la última es literalmente la creadora del framework más popular del lenguaje.

    Enlace: https://danluu.com/in-house/

  • Mejora tu currículum: evita cometer el error más grande

    Un error en tu currículum está haciendo que las empresas que realmente te van a aportar a tu carrera te pasen de largo; pero también hace babear a las empresas que únicamente quieren exprimirte.

    Muchas personas, al inicio de nuestra carrera, pensamos que el problema más grande que nos vamos a topar es encontrar empleo.

    La realidad es que, afortunadamente, en la industria del software es relativamente sencillo encontrar empleo. Lo difícil es encontrar un buen empleo. Muchas ofertas laborales que he visto en el mercado siguen favoreciendo prácticas anticuadas que no te aportan nada a ti como persona, pero sí al negocio. Y creo que es momento de cambiar eso.

    La diferencia entre un empleo y una carrera

    Si has escuchado alguno de mis podcasts, o has leído mi boletín informativo, sabrás que yo estoy más a favor de tener una carrera que de tener un empleo. La diferencia radica en el mindset en el que te colocas en cada una de esas situaciones.

    Cuando te enfocas en un empleo, buscas oportunidades que satisfagan tus intereses y necesidades inmediatas. Únicamente buscas perseguir lo que te llama la atención momentánea, sin poner atención a cómo esa experiencia va a repercutir en tu futuro. Si bien es cierto que de toda experiencia se puede aprender algo, no estás buscando la mejor manera de sacarle el mayor provecho posible a tus esfuerzos. “Si me va bien, bueno. Si no, también. Pero que me paguen.”

    Cuando te enfocas en una carrera, buscas oportunidades que te hagan crecer profesional y personalmente. Tienes un ojo crítico para saber si realmente la empresa para la que estás pensando aplicar te ofrece algo más allá de “sueldo competitivo y prestaciones por ley”. Tienes claro que es importante que tú puedas obtener algo de esa experiencia, tanto como es importante para la empresa que realmente tengas las habilidades necesarias para desempeñarte correctamente.

    Este último punto es crítico. Y es ahí donde tienes que poner atención a la hora de crear un currículum que te abra las puertas.

    El error en tu currículum: te estás enfocando demasiado en el aspecto técnico de tu trabajo

    ¿Suena contra indicativo, no? La idea de que enfocarte demasiado en el aspecto técnico de tu trabajo es un error, cuando estás buscando trabajo en el área de desarrollo de software… suena rara.

    Uno de los aspectos que menos me gustan de la cultura del software es que tenemos la tendencia de ignorar que trabajamos con y para solucionarle problemas a personas. Es tan emocionante cuando logramos resolver problemas de lógica, escalabilidad o arquitectura, que se nos olvida que, al final de todo, nuestro trabajo es hacerle la vida más fácil a otras personas. Desafortunadamente, hay muchas empresas y comunidades que no solamente son partícipes de esto, sino que además lo fomentan. ¿Las entrevistas técnicas en las que buscan hacerte tropezar? ¿La deshumanización de los procesos? ¿La glorificación de trabajar hasta altas horas de la noche, y “bajo presión”?

    ¿Te gustaría que únicamente se te valorara por tus habilidades técnicas?

    ¿Entonces por qué le das tanta importancia en tu currículum a los lenguajes, tecnologías y frameworks que conoces?

    Las organizaciones que valen la pena se preocupan por ti como persona

    Una cosa que me quedó clara a la mitad de mi carrera en software, es que sí, es importante saber cómo hacer las cosas. Que tienes puntos extras si además las sabes hacer bien. Pero que nada, nunca, será más importante poder resolver problemas reales y agregar valor a las personas que usarán tu solución.

    Cuando me di cuenta de esto, recapacité sobre cómo había estado intentando crecer hasta entonces. Noté que las veces en las que peor me la había pasado, habían sido aquellas en las que había caído en la trampa de dejar de lado mi valía como persona, para solamente prestarle atención al aspecto técnico de mi profesión. En ese momento, tuvo todo el sentido del mundo que me sintiera tan frustrado y amargado en ciertas situaciones.

    Con el tiempo, he aprendido que las organizaciones que realmente valen la pena, y de las que quiero formar parte, son aquellas que tienen un interés real por mí como persona. Por mi bienestar, metas, pasiones y objetivos. Y, obviamente, por lo que tengo que aportar al equipo.

    ¿Entonces qué debería incluir en mi currículum?

    Recientemente, revisé varias docenas de currículums. Me llamó la atención uno de una chica, en particular. Ella se encuentra al inicio de su carrera, y únicamente tenía listada sus prácticas profesionales en un hospital. Mencionó las tecnologías con las que había trabajado, pero nada más. Git, JavaScript, HTML, etc. ¿Crees que sea lo único que aprendió al trabajar en el software de un hospital?

    Esta es parte de la retroalimentación que le compartí. Hay muchísimo más valor, pienso yo, en la sensibilidad que adquiriste de tratar en un software que impacta directamente la vida de los pacientes, que en la versión de JavaScript que utilizaste. Más allá de la arquitectura de la aplicación, cuéntame sobre lo que aprendió de la importancia de tener buenos procesos de pruebas para sistemas que manejan información crítica. Platícame, por favor, cómo te cambió como persona y como profesional la experiencia de trabajar en un hospital.

    Personas que se jacten de saber JavaScript encuentro aventando una piedra en el centro de mi ciudad. ¿Qué es lo que te hace única y diferente de todos los demás que también saben programar en el mismo lenguaje que tú?

    Eso es lo que debería de venir en tu currículum.

    Como he dicho antes, tu currículum es una herramienta de marketing. La idea es que puedas iniciar una conversación, no que te contraten. Y la mejor forma de hacer eso es dejando ver un poco más de tu esencia como persona.

  • Síndrome del Impostor: usa este método para vencerlo

    Todos sufrimos del síndrome del impostor.

    Tan solo basta con hacer una búsqueda en Twitter para darte cuenta de que no estás sola. A unos nos vuelve paranoicos. A otros nos paraliza completamente, mientras que a varios simplemente nos atormenta en cada decisión que tomamos en nuestra vida profesional.

    Cuando hablamos del síndrome del impostor también estamos hablando, hasta cierto punto, de vergüenza. Seguramente a ti también en tu niñez te dijeron que estar mal es algo que deberías de evitar a toda costa. Probablemente en varias ocasiones te dijeron, como a mí, que si no tenías algo bueno que aportar, mejor no aportaras nada.

    Vivir el día a día con síndrome del impostor es agobiador. Sobre todo si trabajas en equipo. Y aún más, si trabajas en un ambiente ultra competitivo como lo es el desarrollo de software. El miedo de exponer una idea y quedar mal, como el que no sabe. El síndrome del impostor hace que nada de lo que tienes que aportar pueda salir a la luz. Pero todo esto se puede prevenir.

    Considera lo siguiente: así como no mandarías código a producción sin probarlo o validarlo, tampoco deberías de convertir ideas en código sin antes pulirlas con tu equipo.

    La próxima vez que sientas miedo de quedar “mal parada” por compartir tu idea de solución con el resto del equipo, recuerda: eso también es hacer software. Estás probando la viabilidad de la idea. Si escribir tests te ayuda a confiar más en tu implementación, exponer tus ideas con tu equipo y recibir feedback de ellas te ayuda a confiar más en que vas por el camino correcto.

    Cómo tratar el Síndrome del Impostor

    Si bien cada quien lo experimenta de manera diferente, todos en algún momento de nuestra vida nos hemos identificado (o nos vamos a identificar) con este síndrome. Creo que es una de las pocas cosas en las que todos podemos estar de acuerdo: el síndrome del impostor es algo que tenemos que tratar.

    Y considero que es responsabilidad de todos los que estamos en esta industria buscar maneras de erradicarlo.

    Recientemente, me compartieron una técnica que ha hecho maravillas para mí y mis equipos. Nos ha ayudado a bajar la barrera de entrada a discusiones, y al mismo tiempo, ha ayudado a que las soluciones a las que llegamos como equipo sean más diversas y ricas en perspectivas.

    La técnica se llama Wrong Answers Only, o “respuestas incorrectas únicamente”, pero me gusta más el nombre en inglés.

    Wrong Answers Only se trata de poner como regla, en cualquier discusión de equipo, que únicamente se vale compartir respuestas incorrectas

    La barrera de entrada ahora es mucho más baja, porque ahora lo que no quieres es estar en lo correcto. Dale rienda suelta a tu imaginación, y di lo primero que se te venga a la mente. Conforme va avanzando la reunión, la abundancia de ideas que no están atadas a la expectativa de tener que estar bien comienza a ofrecer un panorama mucho más amplio y diverso de soluciones posibles.

    Síndrome del impostor, cómo vencerlo
    Síndrome del impostor, cómo vencerlo

    Poco a poco, utilizando esta técnica, los miembros del equipo ganamos confianza en nosotros mismos y aprendemos que estar mal es parte del proceso de aprendizaje. Y mientras más nos demos cuenta de lo anterior, más se rompe la asociación de que estar en lo incorrecto es un juicio directo sobre nuestra valía y capacidades como profesionales.