Archivo de la etiqueta: liderazgo

Cómo crecer tu carrera en software de manera responsable

En el mundo del desarrollo de software, muchas veces nos centramos en la tecnología y en aprender nuevos lenguajes de programación o herramientas.

Sin embargo, hay un aspecto que suele pasar desapercibido: la agencia que cada desarrollador tiene sobre su carrera profesional. En este artículo, exploraremos la importancia de tomar las riendas de nuestro propio crecimiento y éxito.

Elegir dónde y con quién trabajar: un aspecto clave

Es común que los desarrolladores pongan mucho énfasis en la tecnología con la que trabajarán, pero elegir dónde y con quién trabajar es igual o más importante. Un ambiente laboral tóxico o poco estimulante puede frenar nuestro desarrollo profesional, además de afectar nuestra calidad de vida y salud mental. Por ello, es crucial investigar y seleccionar cuidadosamente las empresas y equipos con los que colaboraremos, asegurándonos de que compartan nuestros valores y objetivos.

Sí, está bien que una de tus metas sea trabajar con la tecnología de moda — llámese Elixir, Clojure, o TypeScript. Pero toma en cuenta que toda la tecnología es una ola, nada más. Se va a ir, y mañana habrá algo nuevo que será la sensación.

¿Sabes qué es lo que no se va tan fácil? El daño de sufrir burnout por haber trabajado en una empresa sin visión clara, con comunicación horrible, y con liderazgo tóxico.

No te quemes de a gratis.

El éxito es encontrar un camino hacia delante

Todos enfrentamos obstáculos y desafíos en nuestra carrera profesional. El éxito no se trata de tener un camino perfecto y libre de problemas, sino de nuestra habilidad para encontrar soluciones y avanzar entre las opciones que realmente tenemos a nuestro alcance.

Ser resilientes y adaptarnos a las circunstancias nos permitirá seguir creciendo a pesar de las dificultades.

Las habilidades blandas: el secreto para crecer profesionalmente

Es fácil caer en la trampa de pensar que, como desarrolladores, solo necesitamos mejorar nuestras habilidades técnicas. Pero las habilidades blandas, como la comunicación, el trabajo en equipo y la empatía, son extremadamente importantes para nuestro crecimiento profesional. Estas competencias nos permiten colaborar eficazmente con nuestros colegas, resolver conflictos y generar soluciones creativas a los problemas que enfrentamos.

Aparte, toma en cuenta que cada día que pasa, si lo único que sabes es programar, tu carrera está en más riesgo.

Impacto vs. conocimiento: crecimiento exponencial

Medir nuestro progreso solamente en función de cuánto sabemos puede hacernos crecer de manera lineal, es decir, mejorar poco a poco en nuestras habilidades técnicas sin realmente avanzar en nuestra capacidad para resolver problemas reales y generar valor. Sin embargo, si nos enfocamos en buscar tener un mayor impacto en nuestro trabajo y en la comunidad, nuestro crecimiento será exponencial. Colaborar en proyectos de código abierto, compartir nuestro conocimiento con otros y contribuir al desarrollo de nuevas soluciones nos ayudará a aumentar nuestra influencia y a expandir nuestras oportunidades profesionales.

La responsabilidad es tuya

La responsabilidad de crecer en la carrera de desarrollo de software va más allá de aprender nuevas tecnologías y herramientas. Debemos elegir cuidadosamente dónde y con quién trabajamos, ser resilientes ante los desafíos, desarrollar nuestras habilidades blandas y buscar tener un mayor impacto en nuestro entorno. Al tomar las riendas de nuestra carrera profesional, no solo mejoraremos como desarrolladores, sino que también contribuiremos al crecimiento de nuestra comunidad y de la industria en su conjunto.

Ser Engineering Manager: los primeros aprendizajes

A finales de 2019 decidí cambiar la dirección de mi carrera profesional y probar suerte como Engineering Manager.

Para este entonces, tenía un poco más de 10 años de experiencia desarrollando software como contribuidor individual.

Hoy me encuentro iniciando mi tercer año como Engineering Manager, y creo que es una buena oportunidad para reflexionar sobre estos primeros dos años. Te quiero compartir algunos aprendizajes que he adquirido, con la intención de que te sean de utilidad si es que decides seguir un camino similar al mío.

Pero antes…

¿Cómo me convertí en Engineering Manager?

Llegué al puesto de Engineering Manager con un set de ideas bastante claras sobre el tipo de líder que quería ser, así como de las estrategias particulares que emplearía para lograrlo. El tema de liderazgo y la psicología organizacional siempre me han llamado la atención, y continuamente estoy aprendiendo y educándome en estas áreas.

Durante mi tiempo como desarrollador, tuve la oportunidad de experimentar de primera mano los beneficios de tener líderes que genuinamente procuraban mi bienestar y mi crecimiento. También me tocó tener jefes, de los clásicos que nadie debería tener. Pude ver, gozar, y sufrir, gran parte del espectro de los tipos de líderes que existen.

También es importante compartir que adquirí mi experiencia profesional, principalmente en un ambiente de startups de Estados Unidos y Europa. Esto jugó un papel considerable en mi transición, pues mis primeros dos años como Engineering Manager fueron trabajando para empresas Mexicanas. A pesar de que soy mexicano, habiendo trabajado principalmente con personas extranjeras, sentí el cambio cultural.

Lo que aquí te voy a compartir no son verdades universales ni reglas. Tómalas como lo que son: interpretaciones de situaciones que viví a través de mis valores, experiencias propias y deseos personales.

Tus decisiones, por más pequeñas que sean, tienen grandes implicaciones

Como gerente de ingeniería, tus decisiones tienen la capacidad de influenciar desde la composición técnica de tu proyecto, hasta aspectos fundamentales del negocio. Pero, mayormente, tus decisiones afectan la carrera profesional de las personas a tu cargo.

Cualquier decisión que tomes, debes de factorizar el impacto a mediano y largo plazo que esta va a tener en la carrera de las personas con las que trabajas.

Sí, el producto es importante. Pero sin un equipo sano, todo pasa a segundo plano.

Tu trabajo como Engineering Manager es habilitar a tu equipo

Es demasiado sencillo llegar a un puesto de Engineering Manager pensando que lo que se espera de ti es que asignes tareas, y te asegures de que se cumplan a tiempo. Y hay personas que podrían argumentar que sí, ese es el trabajo. Yo creo que es un poco más complicado que eso.

El Engineering Manager, a diferencia de un Project Manager, se encarga de entender las necesidades y visión del negocio. Además, asimila las fortalezas, debilidades, y deseos de su equipo. El reto es alinear estos dos mundos de una manera coherente, sostenible y humana.

Parte de tus responsabilidades es procurar que los proyectos salgan a tiempo y en forma. Pero no asegurarte. ¿Qué vas a hacer, obligar a tu equipo a que trabaje horas extras? ¿Preguntarles “cómo vamos” cada 3 horas? ¿Intentar comprar su felicidad con pizzas y refresco? Todos hemos tenido (o por lo menos escuchado de) gerentes que usan esas tácticas. Personas para las cuales lo más importante es la fecha, el cliente y su reputación, no su equipo.

Reflexiona: ¿te gustaría (volver a) trabajar con una persona así?

Por eso digo que el Engineering Manager procura que las cosas salgan bien. Entiende las necesidades de su equipo (las personas), tiene conciencia de un balance adecuado entre vida y trabajo, y además reconoce y asimila las capacidades de cada uno de los miembros de su equipo. Después toma toda esta información, y crea estrategias, procesos y formas de trabajo que produzcan resultados fiables, en tiempo y forma. En este video exploro un poco más este tema.

Tienes que buscar un balance sostenible

La analogía que me gusta utilizar para este punto es la de las mascarillas de oxígeno en los aviones. Antes de despegar, el personal del avión hace las demostraciones de seguridad pertinentes, y comentan al respecto: “en caso de despresurización, antes de intentar ayudar a otras personas, asegúrese de tener la mascarilla bien puesta usted”.

El mismo consejo aplica para alguien en el rol de Engineering Manager.

Como alguien que desarrolla software (y más si vienes de la cultura Latinoamericana), probablemente te acostumbraste a glorificar el trabajo duro y pensar que estar ocupado es un símbolo de que estás haciendo algo importante. Cuando tienes ese bagaje cultural y de repente te encuentras en un rol de gerencia, naturalmente vas a buscar formas de mantenerte ocupado.

Lo que para ti pudiera parecer ayuda, para tu equipo se convierte en un perjuicio.

No solamente importan las decisiones que tomas, sino cómo las tomas. El equipo que manejas aprende de tu estilo de resolución de problemas. Si no eres cuidadoso, precavido, diligente, transparente y disciplinado, le estás enseñando a tu equipo que está bien tomar decisiones “al ahí se va”.

Al inicio de mi carrera como Engineering Manager tenía lo anterior bien claro. A pesar de esto, no pude evitar caer (algunas veces) en la comodidad de tomar decisiones por mi cuenta y simplemente asignar tickets a mis equipos. No fue sino hasta después de un par de iteraciones, que me di cuenta de que la forma de trabajo que estaba impulsando no era sostenible. No solamente me estaba creando más trabajo, sino que además estaba afectando directamente el crecimiento de mis equipos.

Fue ahí cuando “hizo clic” la idea de que para ser un buen Engineering Manager, tenía que preocuparme más por habilitar a otras personas, que por hacer el trabajo yo mismo.

El feedback loop es muy largo

Tus decisiones deberían de estar basadas en el bienestar, sostenibilidad y productividad de tu equipo. Y los resultados de los cambios que implementes para fomentar una cultura de trabajo positiva tardan bastante ser aparentes.

Si tomas una decisión en función de prevenir el burnout de tu equipo, por ejemplo, el rango de tiempo para darte cuenta de si la estrategia está funcionando o no, podría ser de meses. No solo porque los cambios organizacionales son complejos y tardados, sino porque es muy difícil tomar una medición discreta del bienestar de una persona. Aunque tengas 1on1s recurrentes con cada miembro de tu equipo, las variaciones de estado de ánimo de una semana a otra pueden ser bastante grandes — y no siempre gracias a factores que tú puedas controlar.

Es por eso que como Engineering Manager tienes que enfocarte en las tendencias que ves en el equipo, no en datos discretos. Todos tenemos días malos, y si ves que alguien no la está pasando tan bien en tu equipo, no necesariamente tienes que hacer algo de manera inmediata (a menos que la situación lo amerite). Pero cuando ves que alguien ya lleva varias semanas pasándola mal, es momento de cambiar algo.

Cambiando el paradigma

Creo que hoy, más que nunca, es importante que humanicemos nuestro trabajo, y dejemos de glorificar las horas extras y el sacrificio del bienestar mental y emocional de las personas. Y considero que el Engineering Manager tiene un papel fundamental en esta transición.

Convertirme en Engineering Manager ha sido un proceso interesante. He aprendido mucho sobre mí y mis sesgos. Me he enfrentado a mi propio ego, y me ha ayudado a entender que el mundo en el que vivimos tiene muchos más matices de los que pensaba.

¿He tenido mis momentos difíciles? Sí. ¿He cometido errores? También.

Pero también he aprendido, y he crecido. Y si reflexiono un poco sobre estos primeros dos años en esta carrera, siendo honesto, considero que lo estoy disfrutando más de lo que disfruté mis primeros dos años como desarrollador.

Algunas reflexiones extras:

  • No todas las empresas necesitan Engineering Managers. Hay algunas empresas que simplemente necesitan un Project Manager con nociones de ingeniería de software, pero no un Engineering Manager. Asegúrate de que sabes qué es lo que realmente necesitan.
  • Ser Manager significa algo diferente para cada empresa. No te quedes simplemente con el título, indaga un poco más en cuáles son realmente las tareas y expectativas del puesto.
  • Ser Manager no es para todos. Muchas personas creen que la progresión natural de una carrera en esta industria apunta hacia puestos de gerencia, pero no es así. Ser bueno escribiendo software desafortunadamente no te hace buen manager.
  • Para ser Manager, necesitas renunciar a tu identidad como desarrollador. Ve este video.

“A esta empresa se viene a trabajar, no a ponerse sentimental”

Una de las banderas rojas más grandes es si tu jefe te contesta “a esta empresa se viene a trabajar, no a ponerse sentimental” cuando le comentas que una situación de tu trabajo te está afectando a nivel personal.

Para mí, esa es una señal inequívoca de estar en el lugar incorrecto para crecer profesional y personalmente.

https://twitter.com/Swanros/status/1472986970947080193

Como líder de un equipo, tengo claro que mi objetivo principal no es exprimir el talento de las personas con las que tengo el privilegio de colaborar. Mi trabajo es propiciar las condiciones necesarias a nivel organizacional para que ese talento florezca por sí solo, y luego potenciarlo. Desafortunadamente, muchos “líderes” de equipo realmente funcionan como jefes, exigiendo sin aportar, promulgando sin poner el ejemplo. Y la frase “a esta empresa se viene a trabajar, no a ponerse sentimental” es el reflejo de esa mentalidad, donde lo que importa es el resultado y no la persona. Un medio para un fin.

Hace unos meses escribí:

Tú y yo somos parte de un sistema que, hora tras hora, está buscando exprimir la mayor cantidad de productividad de cada uno de nosotros. Eficiencia, dicen, es lo principal. Ser eficientes. Ser productivos. Si no estás siendo productivo, estás desperdiciando recursos. Si no maximizas tus horas de trabajo, estás siendo irresponsable.

Gran parte del reto es el contexto cultural en el que nos desarrollamos — especialmente en Latinoamérica, donde muchos hemos crecido con la idea de que lo que importa es el trabajo duro, y que reprobar (o que te corran) es lo peor que te podría pasar. Peor incluso que vivir angustiado, amargado o con ansiedad. Y cada día que paso trabajando con personas y buscando la manera de honrar su individualidad, metas y objetivos personales, me doy cuenta de la mucha falta que hace que los líderes en esta industria sean más humanos.

Si logras identificar las banderas rojas en tu empleo, y estás inseguro sobre si deberías buscar otro camino, déjame decirte que tienes muchas cosas a tu favor. El mercado está más caliente que nunca, y hay muchas empresas y organizaciones que están decidiendo apostar por la persona, más que por el output que generan. Solo tienes que levantar la cabeza y buscarlas.

Primero, hazte consciente de tu valía como persona, analiza tu propuesta de valor y, como dice Vicente Plata, no aceptes abusos.

Cómo saber si deberías dejar ir a un miembro de tu equipo

Un Engineering Manager en una posición no tan ideal me envió la siguiente pregunta:

¿Cómo lidias con la banda que no comunica (ausentes en chat, no confirman llamadas, etc) PERO que sí da resultados?

El que uses la palabra “lidiar” me dice que, muy dentro de ti, sabes que no te está dando buenos resultados, y es momento de hacer algo al respecto.

Desde el punto de vista de un Engineering Manager, si alguien es un buen ejecutor, pero tienes que estar invirtiendo tiempo y recursos para asegurarte de que lo está haciendo de una manera que no afecte negativamente al resto del equipo, esa persona no funciona. Aunque esa persona cumpla con sus responsabilidades a nivel técnico.

Tu rol es establecer procesos y generar estrategias para que se cumplan las expectativas del equipo.

Como Engineering Manager, una de tus preocupaciones principales debería de ser evitar cuellos de botella y silos de información. Tener a un miembro del equipo que no comunica eficientemente, ni trabaja en equipo, es la antítesis lo anterior. Sobre todo si esta persona sabe que sus habilidades técnicas de alguna manera justifican sus deficiencias en comunicación y colaboración. Esta es una receta para que eventualmente tengas a alguien que sabe mucho del proyecto y del negocio, que sea una carga negativa para el equipo, y que no podrás correr porque con él se iría todo el conocimiento de los proyectos en los que trabajó. Bus factor al millón.

Un estándar de calidad es lo que se tolera, no lo que se promueve. Puedes invertir tiempo y esfuerzo en promover buenas prácticas de comunicación y trabajo en equipo, pero mientras no tomes decisiones administrativas en pro de defender los procesos y estrategias que promueves, estarás trabajando en vano.

El mejor momento para remover a ese elemento del equipo era antes de que te pusiera en esta situación.

El segundo mejor momento es ahora, que estás buscando hacer malabares por alguien que no te está haciendo, ni a ti ni a tu equipo, el trabajo más sencillo.

¿Cuándo es hora de renunciar a tu trabajo?

Las cosas en la empresa no pintan bien. Estás al borde del burnout, y pareciera que la situación, en vez de mejorar, se va a poner más complicada.

Se siente una desconexión entre el ánimo con el que se presentaron los nuevos proyectos y la realidad al momento de ejecutarlos. Sí, vienen grandes retos, proyectos que tienen el potencial de generar un gran impacto en la industria. Sin embargo, algo no está bien. Los compromisos, exigencias y variables siguen creciendo, pero no así el respaldo que sientes por parte de la empresa para lograr tus metas.

A pesar de todo esto, cada vez que hablas con tu líder y le haces saber cómo te sientes, por alguna razón, sales aliviado. Lograste desahogarte, y probablemente hasta sentiste algo de empatía por él o ella. Te hizo saber entre líneas que realmente está haciendo todo lo que puede para que cambien las cosas.

No obstante, la pregunta no deja de rondar en tu cabeza: ¿debería renunciar ya, o le doy otra oportunidad? Esta vez seguro será diferente.

Incentivos

En algunos lugares, se gana siendo el que más vende. En otros, resolviendo la mayor cantidad de tickets. Desafortunadamente, en algunas organizaciones se gana siendo el favorito del jefe.

¿Cómo se “gana” en la cultura de tu empresa? Esta es la pregunta más importante que deberías de contestar.

Si te das cuenta de que en tu organización se gana siendo el que más vende en números brutos, pero tú trabajas como desarrollador de productos internos, y no como vendedor, tienes un problema. Porque tu usuario hará lo necesario por vender más, independientemente de lo que tú y tu equipo estén haciendo o quieran hacer. Tomarán atajos, desarrollarán sus procesos por fuera, y tu trabajo será cada vez más difícil: crear un producto para personas que no quieren ni tienen que usarlo. Es posible contrarrestar esta situación, sí, sin embargo, requiere que la persona al frente de tu equipo tenga bastante capital político dentro de la organización para poder influenciar el comportamiento de otras áreas.

Si en tu empresa se “gana” siendo el que más vende, ¿qué significa eso para ti, que no vendes nada? ¿Cuál es realmente la probabilidad de que tu tarea sea factible? ¿Tiene tu líder el suficiente capital político para poder influenciar otras áreas de la organización y alinear sus incentivos con los suyos?

Charlie Munger dijo, “muéstrame los incentivos y te mostraré el resultado.”

Eres lo que haces

Para este punto te habrás dado cuenta de que estás en una situación poco ideal, pues los incentivos de tu empresa no están alineados para que tú también puedas ganar. Pero tu líder insiste en que las cosas van a cambiar pronto.

Analiza su historial de liderazgo.

Eres lo que haces, no lo que dices que quieres hacer. Esto es especialmente verdad en roles de liderazgo.

Esta es una conversación delicada, porque estamos hablando de una persona en particular. Vale la pena hacer zoom out: también es miembro de la organización, y tiene un rol que debe de cumplir. El hecho de que sus incentivos no estén alineados con los tuyos no es un juicio de su persona. Algunas veces lo que tú quieres no tiene nada que ver con lo que tu jefe/líder necesita de ti como miembro de una organización, y esto no significa que no sea una buena persona, o que quiera hacer las cosas mal a propósito.

Habiendo mencionado esto, es completamente válido hacerte las siguientes preguntas sobre tu líder: ¿Cuál es el incentivo de su puesto? ¿Qué significa “ganar” para él/ella? ¿Cuántas veces te prometió algo y no llegó? ¿En cuántas ocasiones las cosas han estado a punto de cambiar, pero nunca lo hicieron?

Renuncia

Mucho se habla en la cultura latinoamericana de “ponerse la camiseta”, y una de las cosas que más me gustaría cambiar de la cultura laboral en México y LATAM es la idea de que los empleos se deben “aguantar”.

Creo fielmente en que un empleo o un trabajo debería de ser algo vigorizador, no agobiador. Sé, por experiencia, que una de las maneras más sencillas de lograr llegar a ello es desarrollar conciencia de qué es lo que queremos y necesitamos para crecer. Y luego hacer algo al respecto.

La respuesta es simple: si los incentivos de tu empresa no están alineados de manera homogénea, y tu jefe o líder no tiene un buen historial de entregas a nivel liderazgo, es momento de que salgas de ahí.

Somos afortunados de trabajar en una industria que nos permite trabajar desde casa y con aire acondicionado, por decir los menores de los beneficios. Con ese privilegio vienen ciertas responsabilidades, y una de ellas es hacer algo con las respuestas a preguntas que no todos se pueden hacer.

Renuncia.

Repite lo que dices, múltiples veces

Tomasz Tunguz, escribiendo en su blog:

Los grandes líderes entregan sus mensajes con palabras memorables que repiten constantemente.

Muchas personas creen que liderar significa dar órdenes. Pero no es así. Liderar significa lograr que un grupo de personas le pongan esfuerzo, atención y empeño a resolver un problema en particular. Y una de las mejores formas de hacer eso es tener un mensaje claro.

Tip para ser mejor líder: ponle nombre a tus iniciativas, y repítelas como si no conocieras otra palabra.

Cosas que no te enseñaron en la escuela, pero debes saber para trabajar en la industria del software

A continuación te comparto cosas que no te enseñaron en la escuela, pero que debes de saber si quieres trabajar en la industria del software.

  1. Tú te pones tus propias metas. En la escuela tenías la comodidad de llevar un “plan de estudios”. Sabías lo que seguía en cada paso. Acá afuera nadie va a entregarte un plan de estudios para tu carrera profesional. Tienes que definirlo por ti misma.
  2. No tienes que pedir permisos. ¿Quieres aplicar para un trabajo? ¿Te urge cambiar de tecnología? ¿Te gustaría ganar en dólares y vivir en LATAM? ¿Tu sueño es trabajar para un unicornio? ¿Lo que quieres es pasar más tiempo con tu familia? Date. Nadie te detiene.
  3. Debes de tomar decisiones por tu cuenta. En la escuela te condicionaban a aprender una metodología preestablecida. Salirte del protocolo era castigado. En la vida real tienes que aprender a tomar decisiones y a hacerte responsables de sus consecuencias. Nada más.
  4. Puedes irte en cualquier momento. Tenía un profe que se quejaba de los alumnos diciendo “es que ustedes creen que las cosas van a ser como ustedes quieran”. ¿Y por qué no? Si estás en un trabajo o situación que no te favorece, ¿para qué te quedas? No te pongas la camiseta.
  5. Se espera que sepas colaborar, no que te sepas todos los lenguajes de programación del mundo. Saber más lenguajes de programación solo significa que sabes más lenguajes de programación. Aprende a resolver problemas colaborando — técnicos, de negocio, de usuario.
  6. Saber hacer la pregunta correcta es más importante que ser una enciclopedia de conocimiento. Expandiendo en el punto anterior un poco. “No es la respuesta de StackOverflow, es que sepas lo que tienes que Googlear para encontrarla.”
  7. Programar es un medio para resolver problemas, no un fin. Sí, yo sé que es bien divertido programar. Te aconsejaría que no te clavaras únicamente en eso. Puedes programar toda la vida y no resolver ningún tipo de problema. Y te van a pagar por resolver problemas.
  8. Una solución que es correcta el día de hoy, mañana puede ser considerada ineficiente. Yo creo que en software no hay soluciones “exactas”, sino soluciones “ideales para la situación actual, con el conocimiento que tenemos”.
  9. Existen lenguajes más aptos para resolver ciertos tipos de problemas. Hay desde “lenguaje especializado” que es complicado de aprender, pero te dará soluciones compactas, a “lenguaje genérico” que es fácil de aprender, pero será lejos del ideal para resolver todo.
  10. Mientras más “escalas” de posición, se trata menos del código y más de las personas. Las habilidades más valiosas de alguien considerado “Sr.” son las sociales y de liderazgo. Gente que programe “bien” hay un montón.
  11. Necesitas una red de apoyo. Sí o sí. Rodéate de gente que te quiera ver crecer y que comparta tus principios y valores.
  12. Aprende a valorar tu trabajo. Costo ≠ Valor.  No cobres por el esfuerzo físico que lleva hacer una tarea. Cobra por el valor del problema que estás resolviendo.

Originalmente compartí este hilo en Twitter, donde también puedes seguirme.

Liderazgo efectivo: La importancia de las reuniones 1on1 en equipos de desarrollo

Profesionalmente, crecí en un ambiente que desde muy al inicio me enseñó la importancia de ver primero a la persona y luego su utilidad. Y aún recuerdo el primer 1on1 (one-on-one, o una plática uno a uno) que tuve con mi líder.

Hoy sé lo afortunado que fui.

Aún no tenía tanta experiencia en la industria. Y, como muchos, pensaba que el rol del líder era regañarme, presionarme o criticar mi trabajo (luego entendí que lo que yo pensaba era un líder, en realidad era un jefe). La sorpresa que me llevé cuando en mi primer 1on1 con él, durante una hora, en vez de reclamarme por lo que es lo que estaba haciendo “mal” (a mi parecer), me preguntó que cómo me podía ayudar para que lo que estaba haciendo bien fuera más sencillo.

En ese momento fue cuando entendí el trabajo de un líder: crear conexiones con las personas con las que trabaja, entender qué los motiva y buscar la manera en que sus labores diarias sucedan en la periferia de sus intereses personales.

En una industria que está tan acostumbrada a enfocarse en el aspecto utilitario de las cosas, una conexión humana puede sentirse como un vaso de agua fría en el desierto.

A lo largo de mi carrera en software he conocido personas que, a pesar de llevar años trabajando con su equipo, nunca han intercambiado una palabra más allá de un reporte de progreso. Líderes que no saben que su equipo está quemándose porque no están haciendo aquello que los motivó a aplicar a su empresa en primer lugar. Contribuidores individuales que únicamente tienen visibilidad de lo que tienen que hacer de aquí al viernes.

No es sorpresa que tantas personas estén descontentas con lo que hacen 8 horas al día.

Líder: ¿cuándo fue la última vez que saliste de una llamada con tus reportes y saliste con un mejor entendimiento de qué puedes hacer para ayudarles a tener más éxito?

Ten 1on1s regulares. Hablen de qué los motiva. Hablen de qué les causa estrés. Haz un esfuerzo por ir más allá del dashboard de Jira, y si algo no está funcionando, entiende por qué. Luego busca la manera de arreglarlo. Sé ese líder que van a recordar porque no solo pedía resultados, sino que ayudaba al equipo a conseguirlos.

El 1on1 es una oportunidad para ambas partes. No la desaproveches.

Ser bueno técnicamente es solamente una parte de lo que te toca hacer

Ser bueno técnicamente en X o Y tecnología no te hace bueno en todo lo demás que conlleva trabajar en esta industria. Necesitas ponerle más atención a eso.

Es muy de programadores creer que como somos buenos en X, automáticamente somos buenos en Y. Pero eso está muy lejos de la realidad.

Puedes dominar Linux, y carecer aún de la empatía necesaria para poder ser líder de un proyecto.

Puedes ser un experto en Ruby on Rails, y necesitar ayuda para saber cómo arreglar una discusión en tu equipo.

Puedes haber escrito el libro sobre trabajo remoto y aún así regarla horriblemente… porque nunca desarrollaste el hábito de resolver problemas desde la empatía y la compasión.

Y ejemplos como estos hay miles. Todos hemos conocido alguien muy bueno en la parte técnica, pero que funcionalmente es más un blocker que un apoyo (o una molestia, cuando menos) para el equipo.

Un líder…

  • con actitud de “quítate yo lo hago”…
  • que responde preguntas de manera condescendiente…
  • que no protege a su equipo…

… pero que es muy bueno en Linux. ¿… yay?

El argumento de que necesitas ponerle más atención a tus soft skills no es una negación de que la tecnología es importante. A final de cuentas es la parte operativa que te toca desempeñar.

Y es ahí donde se abre la discusión.

¿Cómo le vas a hacer para darte cuenta de que la parte técnica es únicamente eso, UNA PARTE, de lo que te toca hacer en esta industria?

Encontremos la respuesta juntos.

La trampa de la productividad sin consciencia

¿Por qué quieres incrementar tu productividad? La respuesta más común a esta pregunta es “para poder hacer más cosas”. Habiendo yo mismo dado esta respuesta múltiples veces, intento reflexionar en qué parte del proceso de crecimiento comenzamos a asociar la cantidad de cosas que hacemos con nuestro valor como personas.

La idea de ser más productivo no debería de estar enfocada en hacer más, sino en reducir la fricción para que hagamos lo que tenemos que hacer de la manera más tranquila posible. De la manera más humana posible.

Tú y yo somos parte de un sistema que, hora tras hora, está buscando exprimir la mayor cantidad de productividad de cada uno de nosotros. Eficiencia, dicen, es lo principal. Ser eficientes. Ser productivos. Si no estás siendo productivo, estás desperdiciando recursos. Si no maximizas tus horas de trabajo, estás siendo irresponsable.

Mientras más enfoque le das a ser productivo y a incrementar tu eficiencia, más estás renunciando a lo que te hace humano: la imperfección. Al espacio para tener sentimientos, opiniones y reacciones a las circunstancias que se te presentan.

A alguien que idealiza la como una medida para determinar su valor le costará mucho entender que lo que te hace único es tu perspectiva, experiencia de vida y tu humanidad. La misma humanidad que te hace a veces fallar en tus metas, y no completar tu lista de tareas a tiempo. Colectivamente, mientras más nos enfoquemos en ser productivos y eficientes por el simple hecho de hacer más, nos haremos menos humanos. Porque entonces necesitaremos menos personas.

“Suena la campana que aún puede sonar. Olvida tu ofrenda perfecta. Hay una grieta en todo. Es así como entra la luz.” Leonard Cohen inicia su canción “Anthem” con esa reflexión.

La próxima vez que te quieras sentir mal por no ser “suficientemente productivo”, recuerda: hay una grieta en todo. Es así como entra la luz.

Ser líder: ¿quieres el puesto o la responsabilidad?

El puesto de liderazgo está sobrevalorado.

Muchas personas asociamos ser “únicamente” seguidores, o miembros de un equipo, con sentimientos negativos. Como si no tener el reconocimiento del puesto nos hiciera menos personas. Y como si el hecho de no tener un nombramiento oficial significara que no podemos ejercer el rol de liderazgo que sentimos merecemos.

En realidad, dentro de una organización, todas las personas están siguiendo los pasos de otras. Nadie es un líder sin ser liderado.

Hay líderes, y hay seguidores. Y así como hay buenos y malos líderes, hay buenos y malos seguidores.

Un buen líder da dirección y provee al equipo de herramientas y frameworks para cumplir objetivos a largo plazo. Un mal líder reparte tareas y espera que las metas se cumplan porque sí.

Un buen seguidor puede tomar la dirección de un buen líder, estar en desacuerdo, y buscar maneras de hacer saber que la premisa de la tarea es incorrecta. Un mal seguidor tomará la tarea, y aún sabiendo que la dirección no es la correcta, la implementará. Después culpará al líder.

Un buen seguidor a su vez es un buen líder. Pues ser un líder no significa que sabes más o que tienes el control — o que tienes un nombramiento, necesariamente. Sino que tienes una responsabilidad con tu equipo. Cómo materializas esa responsabilidad es lo que te definirá como un profesional.

Un buen líder a su vez es un buen seguidor. Pues sabe que la retroalimentación de las personas a las que está liderando no siempre será fácil de digerir, pero que el resultado neto será siempre positivo.

¿Quieres el puesto, o la responsabilidad? Porque la responsabilidad está lista para que la tomes. Todo lo demás es tu ego hablando.

Tienes HiPPO y no sabías

Probablemente tienes HiPPO y aún ni te das cuenta.

HiPPO es el acrónimo de Highest Paid Person’s Opinion. Tener HiPPO te hace pensar que las ideas de las personas que ganan más que tú son automáticamente mejores o más válidas que las tuyas.

Sabes que el HiPPO está jodiéndote la vida cuando sales de una llamada refunfuñando porque la jefa tuvo una pésima idea, y ahora sientes que tienes que rehacer todo tu trabajo. Pero no dijiste nada. Porque la jefa dijo.

Reality check: cuánto gana una persona es menos un reflejo de sus habilidades, y más un reflejo de qué tan buen vendedor es.

Tener HiPPO es bastante cómodo. Después de todo, deferir la responsabilidad de la toma de decisiones a un líder o un jefe es conveniente. Quejarse y amargarse es mucho más sencillo que decir “no estoy de acuerdo”. Si algo sale mal, fue él o ella el que tomó la decisión — tú solo ejecutaste.

Afortunadamente hay un antídoto para quitarte el HiPPO, y no es que te asusten, o que te pongan un hilo rojo en la frente. Se llama Sentido de Agencia. Se dice que alguien tiene bien desarrollado el Sentido de Agencia cuando esa persona sabe que sus acciones tienen consecuencias, y está dispuesta a afrontarlas.

El Sentido de Agencia ejercido es lo que marca la diferencia entre alguien que vive para trabajar y alguien que trabaja para vivir.

Para desarrollar y ejercer tu Sentido de Agencia, recuerda:

  • Si gana más no es porque sabe más.
  • Todos tienen algo que aportar en la mesa.
  • De todos modos no te conviene trabajar en un lugar donde no valoran tu opinión.

Quítate el HiPPO. Atrévete a cuestionar. Confía en tu expertise.

5 Soft Skills para dominar si desarrollas software

Los Soft Skills son imprescindibles para cualquier desarrollador de software. Puede que seas capaz de codificar mientras duermes, pero si no tienes la capacidad de comunicarte te encontrarás en una situación incómoda. Y a menos que pretendas trabajar por tu cuenta para siempre, no es lo ideal.

Un estudio en el estado de Sonora demuestra que los mismos desarrolladores de software dicen que los Soft Skills son igual o más importantes que conocer ciertas tecnologías.

Este artículo te enseñará los Soft Skills principales que pueden ayudarte a hacer o deshacer tu carrera como desarrollador de software.

Comunicación

La buena comunicación es una habilidad esencial para cualquier trabajo profesional. Pero es especialmente importante para los desarrolladores de software que son serios con su trabajo. Desarrollar software, a final de cuentas, se trata de resolver problemas — para y con otras personas.

No importa si trabajas por tu cuenta como freelancer o en un equipo de desarrollo, vas a tener que comunicar ideas complejas a otras personas. Lo único que cambia es el medio. El diseño de una API comunica cómo debería ser utilizado tu servicio. Cómo redactas reporte de un bug comunica muchas veces no solamente lo que se debe de resolver, sino cómo debería de resolverse.

Los desarrolladores de software, como personas lógicas que somos, tendemos a pensar en términos de unos y ceros. Pero tener esta misma mentalidad al momento de comunicarnos con otras personas, especialmente personas que no tienen nuestra misma formación, no hace otra cosa más que perjudicar nuestra carrera.

Aprende a comunicar, y verás cómo tu código e ideas se vuelven 100% más efectivos.

Negociación

Los desarrolladores de software también tendrán que negociar con personas. Es raro el escenario en el que no tendrás la necesidad de discutir con otra persona para resolver un problema.

Si trabajas eres freelancer, por ejemplo, tendrás que negociar fechas de entrega, alcance del proyecto y hasta tu compensación. Si eres parte de un equipo, tendrás que encontrar la manera de llegar a acuerdos con respecto a metodologías de trabajo, herramientas y hasta qué convenciones seguir.

¿Usarás tabs o spaces?

¿Por qué deberíamos de usar Ruby y no Elixir?

¿Deberíamos desarrollar este feature antes de refactorizar el sistema?

No hay manera de que te escapes de tener que negociar cuando desarrollas software. Incluso, si lo piensas, diseñar una API se trata meramente de negociar qué es lo que el usuario te debe de dar vs. lo que tú le vas a regresar.

Ser excelente negociando hará tu vida desarrollando software mucho más productiva. No

Habilidades interpersonales

Empatía, tacto, persuasión, liderazgo, entre otras. Las habilidades interpersonales son importantes cuando hay que interactuar con otros miembros del equipo para que no se sientan molestos o disgustados por tu presencia. No es divertido tener un compañero grosero, combativo, que se queja de todo y no sabe cómo adaptarse al grupo.

Pero, yo diría, son mucho más importantes porque desarrollar software, al final del día, se trata de resolverle problemas a las personas.

Muy rara vez se desarrolla un software para que funcione en un vacío. Es casi seguro que si estás desarrollando una aplicación o sistema, o implementando un algoritmo, es porque alguien, en algún lado, necesita resolver un problema. Es aquí donde las habilidades interpersonales marcan la diferencia entre un software mediocre (dogmático, apegado a las ideas del programador) y un software realmente útil (usable, que resuelve los problemas del usuario).

Cuando desarrollamos software tenemos que tener siempre en mente a nuestro usuario. Por más novedosa que sea nuestra arquitectura, o más eficiente sea nuestro algoritmo — nada de eso importa si no estamos resolviendo el problema de la persona que usará nuestro desarrollo.

Sucede exactamente lo mismo en el contexto del equipo de desarrollo: ¿de qué sirve que seas el que más sabe de algún tema si nadie quiere trabajar contigo?

Eres una persona, y te mueves en un mundo de personas. No dejes que tus habilidades interpersonales se echen a perder.

Trabajo en equipo

Complementando a las habilidades interpersonales, viene el trabajo en equipo. Que es similar, pero no lo mismo. El trabajo en equipo es uno de los Soft Skills más citados en currículums, pero no muchos saben realmente qué significa.

Más allá de poder comunicar ideas complejas a tus compañeros, y de poder “llevar la fiesta en paz”, la habilidad de trabajar en equipo se podría resumir en la siguiente frase: tú no eres lo más importante del equipo.

Debes de ser capaz de observarte dentro del contexto del equipo, y ver cómo puedes apoyar, no cómo puedes obtener más control. Un desarrollador que sabe trabajar en equipo gestiona soluciones, delega responsabilidades y apoya en lo que puede. Pero nunca bloquea esfuerzos, acapara responsabilidades o tiene actitud de “quítate, yo lo hago”.

Seguramente has escuchado el término 10x Programmer — hace referencia a un programador que hace el trabajo de 10 personas, presumiblemente porque es tan bueno. Pero piénsalo de esta manera: un 10x Programmer no solamente hará el trabajo de 10 personas, sino que hará que 10 personas no quieran trabajar con él o ella. Y, a largo plazo, esa es una posición en la que no quieres estar. Muy bueno tirando código, pero insoportable al momento de colaborar.

No seas ese rockstar.

¿Quieres ser un 10x Programmer? Trabaja en equipo y haz que 10 personas crezcan para cumplir sus metas y objetivos.

Paciencia

Seguido me preguntan qué es lo que se necesita para poder desarrollar software profesionalmente. Muchas personas no se esperan que la respuesta que usualmente comparto es: paciencia. Un Soft Skill que usualmente pasa desapercibido porque es personal.

Desarrollar software es como armar un rompecabezas en tu cabeza. Solamente que no sabes cómo se debería de ver el diseño final, ni qué tamaño debería tener, ni si está en la orientación correcta. Si te frustras fácilmente, no sabes cómo lidiar con incertidumbre, y buscas la gratificación inmediata de todas tus experiencias, probablemente serás miserable desarrollando software.

No solamente deberás ser paciente con tus propios problemas — cuando estés intentando encontrar un error en un programa o aprendiendo una nueva tecnología. También deberás de ser paciente con personas que no hablan el mismo idioma que tú, o que no tienen la misma experiencia empírica. Tendrás que explicar conceptos complejos a personas que no saben de lo que estás hablando, y te harán preguntas sin sentido. Deberás lidiar con cientos de intentos fallidos para configurar alguna parte de tu stack.

Desarrollar software es un ejercicio de paciencia constante.

Si no eres paciente contigo mismo, y con las personas que te rodean en tu industria, probablemente la pasarás mal.

Y si estás leyendo esto porque apenas estás considerando iniciar tu carrera desarrollando software, te ofrezco una disculpa. Sé que puede sonar nada divertido, y hasta como una advertencia de que no lo hagas. Pero, por experiencia propia te digo: hasta las veces que perdí la paciencia y lloré porque no podía configurar una simple tabla en mi aplicación de iOS valieron la pena. Porque durante los siguientes 10 años pude aprender de los mejores, viajar por el mundo, hablar en conferencias y mi código hoy corre en cientos de millones de dispositivos. Porque fui paciente.

Manual de Swanros

¡Hola, $NOMBRE!

Hey, es un gusto tenerte por acá. ¡Vamos a trabajar juntos! Me quise tomar el tiempo de escribir este documento para explicarte un poco cómo funciono, me conozcas y sepas qué es lo que puedes esperar de mí como tu manager. Hago esto porque creo fielmente en el trabajo con personas, y sinceramente me hubiera gustado saber qué era lo que motivaba a algunos managers que he tenido en el pasado. Espero te sea de utilidad.

Durante las próximas semanas vamos a conocernos y a aprender cómo nos gusta trabajar. Por lo pronto, aquí está una radiografía de una semana trabajando en equipo.

Nuestra semana típica

Una semana típica colaborando es bastante relajada desde el punto de vista de comunicación entre nosotros. El micromanagement es la antítesis de cómo trabajo y es lo último que puedes esperar de mí. Habiendo dicho esto, me gusta estar cerca del equipo para saber cómo puedo apoyar, así que nos mantendremos en contacto constante.

Tendremos una llamada semanal para ponernos al día. Durante esta llamada discutiremos cosas importantes o de visión general — no es un standup — y no necesariamente debes de traer algo preparado. Solamente quiero saber cómo vas y establecer una rutina en la que podamos colaborar más allá de tareas puntuales. El objetivo de esta llamada será resolver la siguiente pregunta: ¿cómo podemos potenciar nuestro trabajo?

Además de nuestra llamada 1:1, tendremos una llamada con tu equipo para integrarnos más. Otra vez, no es un standup, sino una oportunidad para mejorar la dinámica que tenemos como equipo. Para estas reuniones crearemos un documento compartido al cual todos tendrán acceso. En él, cualquier miembro del equipo podrá agregar los temas de los que les gustaría hablar, así como las notas de los acuerdos a los que llegamos en la llamada.

Algunos puntos generales que debes de tomar en cuenta sobre nuestro día a día como colaboradores:

  • No es necesario que me pidas permiso para salir si es que lo necesitas. Confío en que tu manejo del tiempo es el mejor posible, y estoy consciente de que hay ocasiones en que la vida se va a interponer en nuestros días. Está bien — lo único que te pido es que no dejes el trabajo tirado.
  • El tiempo personal es primero que el trabajo. Todo mi esfuerzo está en fomentar una dinámica de trabajo que nos permita cerrar la computadora sin preocupaciones al final de un día de trabajo.
  • Procuro responder de manera oportuna a los mensajes. No siempre se logra, pero puedes esperar una respuesta de mi parte.

Principios

Los siguientes son los principios cardinales que guían mi trabajo. Te los comparto de manera únicamente informativa. 

Personas antes que números. Un OKR cumplido, una entrega a tiempo, etc., son efectos secundarios de un equipo contento, motivado y retado lo suficientemente para que el trabajo se mantenga interesante. Mi manera de trabajo está enfocada en optimizar para que tú puedas hacer tu mejor trabajo sin complicaciones.

Tu principal responsabilidad es decir que no. No hay nada que valore más en un equipo que las opiniones propias. Mi rol se trata de crear un ambiente para que tú puedas hacer tu mejor trabajo — pero, al final, el trabajo lo harás tú. Esto significa que tú te podrás llevar los éxitos, pero también el aprendizaje y la responsabilidad de solucionar los problemas cuando algo salga mal. Es por eso que lo mínimo que espero de ti es que puedas defender tu punto de vista cuando no estés de cuerdo con algo que yo u otra persona del equipo proponga.

La honestidad es lo más importante.

Procuro entender por qué llegamos al problema, y resolver eso. Encontrar soluciones parciales o incompletas no es como me gusta hacer mi trabajo. Estoy consciente de que hay situaciones en las que vamos a tener que comprometer la calidad del producto, pero estas deberían ser las excepciones.

Es primordial para mí que las personas que trabajan conmigo se conduzcan con respeto.

Mi calendario es tuyo. Te repito, mi rol dentro de la organización es crear un ambiente favorable para ti. Esto significa que a veces vamos a necesitar sentarnos a discutir un tema en particular — puede ser algo que sientas que no está funcionando como debería, o una idea que te gustaría implementar. No tienes que preguntarme si puedes hablar conmigo — simplemente usa el enlace que te pasé para agendar una llamada y listo.

El tiempo es sagrado, y procuro usarlo responsablemente. Te invitaría a hacer lo mismo, pero esta ese una decisión personal. Mi regla es esta: si voy a poner un evento de 1 hr en el calendario, más vale que sea la hora más productiva del día — y asumo esa responsabilidad con seriedad.

No me gusta usar metodologías que tienen un nombre. “A X empresa le funcionó Y” no es un argumento que me emocione para intentar aplicar Y en nuestra organización. Por el contrario, si vamos a analizar por qué funcionó, y lo vamos a intentar adaptar a nuestro caso particular, ahora tienes mi atención.

Trabajo por algo, no en algo. Afortunadamente en nuestra industria hay miles de oportunidades para hacer software, manejar gente, o diseñar cosas. Cuando trabajo en algún lugar en particular, lo estoy haciendo por algo.

Comunicación

Mi método preferido de comunicación es escrito. Creo que escribir algo es la mejor manera de asegurarme de que entiendo de manera clara lo que quiero comunicar. Reconozco que eventualmente será necesario tener una llamada para resolver algún problema en particular, y sigo algunos lineamientos en estos casos.

Procuro no tomar ni buscar llamadas que no estén en el calendario con por lo menos 24 horas de anticipación. Lo último que alguien necesita es una llamada de imprevisto, y estoy consciente de ello. Si necesito tener una llamada contigo, tendrás por lo menos un día completo para prepararte. Esperaría que tuvieras la misma consideración conmigo.

Nunca te enviaré invitaciones a llamadas que no tengan un objetivo claro. Tanto el título del evento en el calendario, como la descripción del mismo, tendrán toda la información que debes saber para llegar preparado a la llamada. En caso de que vaya a pedirte actualización de algún proyecto, por ejemplo, sabrás exactamente qué espero de ti.

El calendario tiene la opción para rechazar invitaciones a eventos. Úsala. Como dije antes, las llamadas para mí son un último recurso para colaborar. Si algún día te envío una invitación a una llamada, pero crees que sería mejor simplemente mandarme la información escrita, siéntete con la libertad de rechazarla. El tiempo es lo más importante y no me lo tomaré a mal si prefieres no tenerla. Si de verdad es crucial que tengamos la llamada, ya sea porque algo urge, o estamos en una situación de alerta, te lo haré saber.

Aprecio cuando todos los participantes de la llamada tenemos la cámara prendida. Trabajamos de manera remota, y es fundamental para mí establecer una relación con las personas que son parte de mi equipo. Vernos la cara es primordial para este propósito. Te pido que, dentro de lo posible, también prendas tu cámara cuando entres a una llamada conmigo — sobre todo si vamos a estar hablando sobre temas valiosos, como tu desarrollo dentro del equipo.

Respeto mi tiempo y el de los otros. Siempre procuro estar ya en la llamada uno o dos minutos antes de que de la hora pactada. Si tengo varias llamadas seguidas, es probable que me pueda demorar unos minutos en entrar a la siguiente. Si esto pasa, y tú eres mi siguiente llamada, te haré saber con anticipación que llegaré unos minutos tarde. No es normal que esto suceda.

Desarrollo profesional

Vamos a establecer objetivos de crecimiento para ti, y vamos a procurar que estos se encuentren en la intersección de lo que tú quieres para tu carrera y lo que la empresa necesita. Tendremos un documento compartido donde colaboraremos en la creación de tu plan de acción, al cual le daremos seguimiento cada 3 meses.

Debes de saber que nuestra relación no será de una sola vía. Es decir, no solamente se trata de pedirte cosas o que llegues a ciertas metas, sino de que entre los dos lleguemos a un acuerdo sobre qué es lo que tú quieres hacer, lo que la empresa necesita, y cómo yo te puedo apoyar.

También debes de tomar en cuenta que las revisiones de este documento no serán las únicas ocasiones en las que podemos compartir retroalimentación. Soy fiel proponente de la comunicación asertiva, y si hay algo que corregir me aseguraré de hacértelo saber en tiempo y forma, y espero que hagas lo mismo conmigo.

Notas extras

Uso muchas analogías cuando explico cosas. Sobre todo cuando algo me gusta demasiado. No te asustes si de repente quiero explicar cómo funciona un sistema literalmente con perros y gatos.

Soy fanático de trabajar por las mañanas, mi día comienza antes de las 6 am regularmente. Te pido que no sientas la presión de estar disponible en mis mismos horarios, y si te mando un mensaje temprano no tienes que contestarme de inmediato.

Soy muy celoso de mis tardes, y procuro no tener compromisos de trabajo después de las 4 pm. Sin embargo, soy flexible, y si hay algo que se necesita hacer a esa hora, estaré ahí. Pero todo mi día y forma de trabajo se centra en poder tener mis tardes libres.

Ser líder es como jugar una partida de póker

No sabes qué cartas te van a tocar. Pero cuando te las dan, debes de tomarte el tiempo para analizar cada una y ver cómo encaja con las otras que tienes en tu mano.

Una sola carta, aislada, no gana una partida. No importa si en tu mano tienes un 10, A, Q, J y K, si no sabes que juntos hacen una Escalera Real. Solamente tenías que cambiar el orden en que la veías.

Sucede lo mismo con las personas.

Liderar un equipo no se trata simplemente de cumplir metas o de alcanzar resultados estrictos. Se trata de reconocer las habilidades (y debilidades) de cada uno de los miembros del equipo.

Como líder, así como cuando juegas una partida de póker, tu única tarea es optimizar para sacarle el mayor provecho a las piezas con las que cuentas. Y la manera más sencilla de perder es no saber reconocer lo que tienes.