Archivo de la etiqueta: desarrolladores

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.

El trabajo asíncrono le gana por mucho al trabajo duro

Creo que el trabajo asíncrono puede ser la clave para tener éxito en el 2023.

El éxito, independientemente de lo que signifique para cada quien, se consigue con el principio fundamental de identificar lo que funciona y lo que no, para luego hacer más de lo que funciona, y menos de lo que no.

El debate canónico entre líderes es sobre qué filosofía deberían impulsar en sus equipos para alcanzarlo: el trabajo duro, o el trabajo inteligente. Las personas que defienden cada punto piensan haber logrado encontrar la respuesta. Hay que trabajar más duro, y no tan inteligentemente — o al revés.

Incontables horas se han invertido en intentar encontrar el balance perfecto entre trabajar duro e inteligentemente. No te podría decir si se ha llegado a algo sustancial en esas discusiones, porque parece ser que la conclusión intelectualmente estimulante es que deberías de trabajar inteligente y duro al mismo tiempo.

Mi postura es que hay que ser lo suficientemente inteligente para identificar en qué trabajar duro. Y la filosofía de trabajo que te permite hacer eso, es el trabajo asíncrono.

Déjame explicarte. Vamos por partes.

Trabajo duro vs. inteligente

Analicemos la versión más polarizada de cada parte del argumento.

El que propone trabajar duro sugiere que el valor de la recompensa al final del camino es directamente proporcional al esfuerzo que costó conseguirla. Esta mentalidad te dice que mientras más tiempo y esfuerzo le inviertas a algo, mejor será el resultado. Y que si estás tomando atajos para conseguir tu objetivo, significa que no lo quieres tanto, ergo, no lo mereces. Sigue estrategias de productividad tradicionales y rudimentarias. Desvelos, estrés, sangre, sudor y lágrimas. El trabajador duro se siente orgulloso del sacrificio personal que significa conseguir su objetivo.

El que recomienda trabajar de manera inteligente busca atajos y la menor fricción posible. “El fin justifica los medios” es su frase favorita, y hará hasta lo imposible por ahorrarse tiempo, dinero y esfuerzo en virtud de obtener un resultado positivo. Encontrará fallas en los sistemas que le den una ventaja sobre sus competidores, y si resolver un problema no es cuestión de vida o muerte, no buscará la manera de hacerlo hasta que lo sea. El trabajador inteligente se siente orgulloso de haber logrado resultados adecuados por una fracción del esfuerzo que otros le invirtieron al mismo problema.

En ambos extremos de este espectro, los objetivos se cumplen y se llega al éxito.

El problema, y la razón por la que estos extremos son malos, es que ninguno de estos modelos de trabajo es sostenible a largo plazo en el contexto de un equipo u organización.

El trabajo duro termina por quemar a las personas. Las jornadas de trabajo son enloquecedoras, con horas interminables y retos imposibles, justificados por una cultura de sacrificio. Aquellas personas que forman parte de una cultura que glorifica el trabajo duro dejan de preocuparse por su bienestar y el de sus familias, y de alguna manera internalizan que cualquier cosa que valga la pena merece trabajo extenuante.

El trabajo inteligente, en su versión más extrema, produce soluciones frágiles e insostenibles. Estas soluciones, si bien cumplieron con objetivos puntuales, generan deuda técnica y organizacional, porque al estar construidas atajo sobre atajo, cambiar de dirección es cada vez más costoso y complicado. Además, una cultura en la que el fin justifica los medios, invita a sus integrantes a no buscar más allá de las soluciones rápidas y fáciles (“inteligentes”). Hace que las personas dejen de pensar de manera crítica, irónicamente.

Imagen usualmente usada para representar la diferencia entre trabajo duro y trabajo inteligente.

Los aspectos negativos de los extremos en este debate están representados en la imagen al inicio de esta sección.

Esta imagen, irónicamente, intenta comunicar los beneficios del trabajo inteligente. Pero analiza: los que empujan los cubos están trabajando obviamente de más, mientras que el que decidió esculpir una esfera tiene una tarea mucho más sencilla.

Observa cómo ninguno de los dos extremos resuelve el problema real: llevar un cubo de izquierda a derecha de la manera más eficiente posible. Los que trabajan duro llegaron tarde, cansados y probablemente no van a querer hacerlo de nuevo, mientras que el otro llegó con una esfera.

Cualquier extremo de esta discusión termina siendo perjudicial para la organización una vez aplicado. Es aquí donde debemos de buscar un punto medio que nos permita encontrar un balance entre el trabajo duro y el trabajo inteligente. Una manera de trabajar que nos permita tomar los mejores aspectos de los extremos y usarlos de una manera sana, que produzca resultados y que no cueste el bienestar de los miembros del equipo.

Ese punto medio es el trabajo asíncrono.

El trabajo asíncrono

Trabajar de manera asíncrona, en esencia, significa que cada miembro de la organización puede moverse de manera independiente, convergiendo en tiempo/espacio con otros solo en situaciones absolutamente necesarias.

Cuando se trabaja de manera asíncrona, los miembros de un equipo tienen el sentido de agencia necesario para tomar decisiones y hacerse responsables de sus consecuencias. Cuentan con la confianza de sus líderes, pues los objetivos son claros y los problemas a resolver tienen sustento. Trabajan en público, y son transparentes con sus procesos de deliberación. Sus mensajes son claros y asertivos, y no están atados a un horario de disponibilidad definido.

Valoran el resultado de su esfuerzo, no la magnitud del mismo.

Si el principio para alcanzar el éxito es hacer más de lo que funciona, y menos de lo que no, ¿cómo sabes cuál parte del proceso está funcionado y cuál no, si no tienes más que información anecdótica sobre ello? Al contrario de los modelos de trabajo síncronos, donde los problemas se resuelven en privado, a través de medios efímeros y con opacidad, el trabajo asíncrono deja una estela de información que puede ser utilizada para analizar y mejorar el proceso de toma de decisiones de la organización.

Hay que ser lo suficientemente inteligente para identificar en qué trabajar duro. Y el trabajo asíncrono ofrece un balance sostenible entre ambos mundos.

Trabajar de manera asíncrona puede ser considerado trabajo duro porque te reta a ser consciente de tus pensamientos y a estructurarlos para poder escribir ideas coherentes. Requiere que crees los sistemas de información necesarios en tu organización para poder delegar la toma de decisiones. Te obliga a confiar en tu equipo y a ser responsable de tu comportamiento y disciplina.

Trabajar de manera asíncrona también es trabajar inteligente porque estás haciendo que los miembros de tu equipo cuenten con la autonomía para tomar decisiones, incrementando su sentimiento de satisfacción y felicidad. ¿Sabes qué producen las personas satisfechas y felices? Buenos resultados. Eso es inteligente. Además, al trabajar de manera asíncrona, los miembros del equipo tendrán el tiempo y espacio necesario para ejercitar su creatividad y solucionar problemas de una manera más fundamental.

Trabajar duro en ser un mejor líder, y al mismo tiempo inteligente por fomentar una cultura laboral sana y que respete a las personas que se desarrollan en ella. No suena mal.

Conclusión

La decisión de trabajar duro o trabajar inteligente, a final de cuentas, termina siendo responsabilidad de cada quien.

Si tú, como líder, en tu organización fomentas una cultura de trabajo duro, hazlo con la conciencia de que las personas que trabajan contigo eventualmente van a cansarse y se van a ir.

Si, por el contrario, fomentas una cultura de trabajo “inteligente”, date cuenta de que probablemente estás creando una organización que produce soluciones frágiles y costosas.

Pero si fomentas una cultura de trabajo asíncrono, estarás asumiendo tu responsabilidad como líder de equipo. Crecerás personal y profesionalmente, mientras generas un ambiente de confianza, autonomía y responsabilidad compartida con tu equipo. Uno donde las personas se sentirán parte de una organización que respeta su tiempo, esfuerzo y pericia.

Así que, entre decidir trabajar duro o inteligente, recuerda que hay que ser lo suficientemente inteligente para identificar en qué trabajar duro.

Razones comunes para que los desarrolladores busquen nuevos empleos

StackOverflow compartió en su blog los resultados de una encuesta que aplicaron a 500 desarrolladores de software. La idea era encontrar los factores que actualmente están jugando un papel importante en el mercado laboral de desarrolladores.

Las respuestas podrían parecer obvias para cualquier persona que trabaje en el medio. Sin embargo, creo que es buena idea analizarlas un poco más allá simplemente compartir el número de personas que prefieren tal cosa en lugar de otra.

Los resultados

Para buscar nuevas oportunidades, 65 % lo hacen por un incremento de salario. Esto no debería de sorprenderle a nadie. En los últimos meses, sobre todo, se ha visto un incremento sustancial en la inflación de los salarios para personas que trabajamos en software. Hay varios factores que podrían estar influyendo en esto: la pandemia, la devaluación de la moneda, que cada vez hay empresas con más recursos para “quemar”.

Al momento de considerar empresas para unirse, el 56 % quieren que la empresa le ponga atención al developer experience. Este dato sí me sorprendió, pero tiene sentido. Conforme los retos se van haciendo más complejos y los equipos se van haciendo más distribuidos, lo que quieren los desarrolladores es que las empresas realmente inviertan en la infraestructura para soportar sus esfuerzos.

Hace unos años, la discusión sobre el developer experience era relativamente sencilla, porque había un alto grado de probabilidades de que los problemas se mitigaran simplemente eligiendo el cliente de git adecuado para el equipo. Hoy en día, los desarrolladores esperan que haya una infraestructura para colaborar, empujar código a producción, resolver conflictos, recabar datos, y más. Y no solo eso, sino que esperan que haya un equipo encargado de soportar dicha infraestructura.

Aquellas empresas que reparen en invertir en mejorar y facilitar el trabajo de los desarrolladores la van a tener muy difícil contratando y reteniendo talento.

Lo que hace que una empresa sea poco atractiva tiene que ver con el nivel de micromanagement de la organización. Me sorprendió conocer que hay algunas organizaciones prohíben a sus desarrolladores usar Stack Overflow. Fuera de eso, la mayoría de los desarrolladores están de acuerdo en que lo que quieren es que la cultura de la empresa no esté basada en el control y la desconfianza.

También me sorprendió la tercera razón más popular que hace que una empresa no sea atractiva para un desarrollador: que no tengan los recursos para darle confianza en su trabajo. ¿A qué se refiere esto? Algunas ideas:

Que no haya un proceso de retroalimentación establecido
Opacidad en el proceso de toma de decisiones
Una estructura organizacional demasiado plana
Y, retomando el punto anterior, indiferencia por el developer experience

La reputación de la empresa es primordial para el descubrimiento inicial de oportunidades. De acuerdo con los resultados de la encuesta, 47 % de los desarrolladores toman más en serio las recomendaciones de oportunidades que vienen de su red personal (familiares y amigos) que cualquier otro medio. Hace poco escribí sobre este fenómeno:

Es mucho más importante, para tu desarrollo profesional y tu superación personal, estar con las personas correctas, que en la compañía con el nombre más conocido.

Bien dicen que la publicidad de boca en boca es la más efectiva.

Conclusiones

El mercado laboral está más “caliente” que nunca. Y veo que muchas de las conversaciones al rededor del tema se enfocan en cómo se puede hacer para contratar más personas, pero lo que leo entre líneas de estas respuestas es que deberíamos estar hablando mucho, mucho más de cómo retener el talento que ya tenemos en nuestras compañías.

Si pudiera hacer sugerencias accionables para 1) retener al talento que tienes y 2) hacer tu compañía más atractiva para otros desarrolladores, te diría, en orden de importancia:

Invierte en facilitar el trabajo de tu equipo. Desarrolla infraestructura que ayude a que tus desarrolladores se puedan enfocar más en el qué, y no el cómo de hacer su trabajo. Pule los procesos de desarrollo, despliegue y revisión de código. Establece procesos claros par resolver conflictos.
Mejora tu cultura de colaboración. Promueve el dar y recibir feedback de manera orgánica y constante. Asegúrate de que los desarrolladores tienen la visibilidad necesaria para tomar decisiones y hacerse responsables de sus acciones. Empodera a tu equipo.
Hazlos sentir orgullosos de trabajar en tu compañía.
Súbeles el sueldo. Índice de inflación anual, multiplicado por 2. Al menos.

Presentación: Cómo mis Soft Skills me volvieron mejor desarrollador

Tuve el honor de ser invitado a participar en el meetup de Perú .NET Development. Hablé sobre cómo los Soft Skills me ayudaron a convertirme en un mejor developer, y aquí está la grabación de mi participación.

Mil gracias a Julissa por la invitación.

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:

Cuando tu modelo mental y la realidad no concuerden, la realidad siempre gana
Los modelos mentales no cambian, la realidad sí
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/

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.

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.
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.
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.
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.
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.
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.”
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.
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”.
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.
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.
Necesitas una red de apoyo. Sí o sí. Rodéate de gente que te quiera ver crecer y que comparta tus principios y valores.
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.

3 consejos para que mejores tu Inglés

¡Escucha Inglés para Devs! Un podcast donde Darwin Pinto me explica cómo pronunciar un término de la industria del software, y yo le explico lo que significa. Miles de personas lo escuchan en Spotify.

Trabajar en la industria del software es un acto de balance entre mejorar tus habilidades técnicas y tus soft skills.

Como probablemente sabes, el lenguaje por defecto en tecnología es el Inglés. Así que es de vital importancia que, cuanto antes, aprendas a comunicarte en ese lenguaje. No estoy diciendo que si no hablas Inglés no podrás trabajar en esto. Pero sí estoy diciendo que si sabes comunicarte en el lenguaje universal de la tecnología, desarrollarte profesionalmente será una tarea mucho más sencilla.

Como publiqué hace un tiempo, hablar Inglés ya no es una ventaja competitiva. Es igual (o más importante, algunos argumentan) que saber programar bien.

Si no sabes por donde comenzar, aquí te dejo algunos tips que comparto cada vez que alguien me pregunta sobre este tema. Estos tips me ayudaron personalmente, y he visto cómo también han ayudado a muchas personas a sobrepasar la barrera del Inglés.

[convertkit form=2572581]

Lo que importa es que la idea llegue lo menos golpeada posible

Primero aclaremos algo: no es necesario que hables Inglés perfecto. Con que logres comunicar la idea de manera eficiente es suficiente. Si encima de ello logras dominar las inflexiones, expandir tu léxico y neutralizar tu acento, estarás en el 1% de la población que no habla Inglés como su primera lengua.

El lenguaje, la comunicación, es una cualidad imperfecta. Al contrario de un lenguaje de programación, que puedes aprender leyendo un manual, el Inglés (o cualquier otro lenguaje) no tiene un proceso de evolución determinado por una organización. Cada quién habla su propia versión del Inglés, y lo único que te toca es intentar apegarte lo más posible a las reglas gramaticales y fonéticas. Todo lo demás es un producto secundario del que lo está hablando, cómo lo aprendió y lo que quiere comunicar.

Pregúntale a cualquier persona que haya trabajado para un cliente que hable Inglés, o que trabaje en una empresa estadounidense. El día a día de trabajar con personas hablando Inglés es una batalla constante por descifrar qué es lo que están diciendo.

Sucede lo mismo con el Español, por cierto. Como lo aprendiste desde muy pequeña, sientes que lo dominas y ahora te tomas ciertas libertades para comunicar ideas. Porque lo que importa no es que lo hables perfecto, sino que la otra persona entienda lo que le quieres decir. Estos “atajos“ están determinados por el contexto dentro del cual te desarrollas. Así, mandar código a producción se dice “deployear“, cerrar un Pull Request se dice “mergear“ y eliminar los problemas de tu programa se vuelve “debuggear“. ¿Crees que alguien que no domina el Español va a entender de qué estás hablando?

Así que no seas tan dura contigo misma. Y si estás pensando que las personas que trabajan en E.E.U.U. hablan un Inglés perfecto, no podrás estar más lejos de la realidad.

Groovy!

Exponte a situaciones reales

Nadie nunca va a hablar como los audios que te ponía tu maestra en el curso de listening. Quítate esa idea de la cabeza.

El día al día de trabajo usando Inglés se trata, como ya te dije, de descifrar qué es lo que realmente está sucediendo. Y mientras esos audios son una herramienta bastante buena para aprender la manera correcta de pronunciar una palabra, la verdad es que en el día a día no importa tanto como crees. La cosa es que difícilmente vas a lograr desarrollar la habilidad de entender cómo realmente se comunica una persona normal en Inglés si no te expones a situaciones que lo propicien.

La ventaja de estar vivo en 2021 es que ya no necesitas viajar a Estados Unidos para mejorar tu Inglés. Hoy en día es tan fácil como suscribirte a un podcast y escuchar hablar a dos amigos de la infancia, uno de Boston y otro de Ohio, e intentar descifrar qué es lo que están diciendo. ¿Cómo habrías podido vivir esa experiencia hace 20 años? Viviendo un año en Boston, otro en Ohio, y luego inventándote la conversación en tu cabeza.

Algunas personas recomiendan películas o audiolibros. Y aunque ciertamente no puede perjudicarte escucharlos, me gustaría que quedara claro que no son situaciones reales. Los medios que están producidos para las masas están, justamente, producidos. Son artificiales.

Pero un podcast entre dos amigos rara vez va a estar cuidado para que todo mundo le entienda. Y ahí es justo donde sucede la magia.

Identifica un tema que te llame la atención, busca un podcast en Inglés que hable de ello, and go to town.

Práctica, práctica, práctica…

Y para terminar, el consejo principal de este artículo: práctica.

Práctica, práctica, práctica.

Cualquier músculo por no ejercitarse se atrofia. Y el Inglés no es una excepción. Ojalá fuera así de fácil, y que pudieras estudiar algo una vez sin olvidarlo jamás.

Este consejo ata los otros tips en uno solo. Atrévete a escribir y hablarlo sin preocuparte de si está perfecto o no, y hazlo en situaciones lo más parecidas a la realidad posible.

Escribe en foros, participa en conversaciones de comunidades adeptas a tu área.
Escribe blog posts o documentación en Inglés.
Únete a un grupo de Discord de tu videojuego favorito y comenta.
Comparte tus opiniones en proyectos de código abierto.
Haz entrevistas de práctica.
Acuerda con alguna amistad que los jueves únicamente se van a hablar en Inglés.

El chiste es no quitar el dedo del renglón.

Y sí, puede ser que te cueste trabajo al inicio, pero ¿qué cosa que valga la pena no cuesta trabajo? Tú puedes.

P.D. — Escucha Inglés para Devs en Spotify.

Cómo trazar tu futuro en el desarrollo de software y alcanzar tus objetivos

Para las personas que pensamos de manera lógica es tan divertido programar, que tendemos a enfocarnos únicamente en ello.

El prospecto de aprender una nueva tecnología o herramienta es suficiente para que la adrenalina nos mantenga despiertos hasta altas horas de la madrugada. Pero cuidado: no caigas en el shiny new toy syndrome.

Es válido aprender por mera curiosidad. Después de todo, así es como muchos descubren sus verdaderas pasiones. Sin embargo, hay una delgada línea entre explorar ideas con el objetivo de ganar nuevas perspectivas y ser complacientes.

Yo dibujaría esa línea en el punto en que el tiempo que pasas aprendiendo cierta tecnología se convierte en potencial y esfuerzo desperdiciado. Por ejemplo, yo sabía desde un inicio que quería trabajar haciendo iOS de bajo nivel. ¿Me habría servido ponerme a estudiar Kubernetes?

Probablemente sí, para conocer la herramienta y entender las implicaciones. Pero no tanto como para haber buscado una certificación, o invertir tiempo y dinero en un curso para dominarlo.

Para alguien con Cerebro de Programador™ puede resultar bastante complicado ver un poco más allá de la parte práctica y técnica — programar. La idea de definir qué es lo que quieres hacer probablemente te parezca completamente ajena. Y con razón — la industria te ha hecho creer que tu tarea es resolver tickets. No es hasta que te topas con la necesidad de poner los pies en la tierra y decidir qué es lo que realmente quieres hacer, que se comienza a poner interesante.

Aunque no es sencillo, definir para qué quieres aprender tal o cual tecnología es un proceso asequible. Lo único que necesitas es un poco de dedicación, y autocompasión.

La manera más sencilla que te puedo compartir para resolver este problema es que diseñes tu progresión de carrera — y lo hagas lo antes posible.

Para comenzar, plantéate las siguientes preguntas:

¿Qué tipo de problemas te gustaría resolver?
¿En qué industria?
¿Rodeado de qué tipo de personas?

Una vez que tengas tus respuestas, tendrás una estrella norte para seguir. Ahora tu tarea es hacer ingeniería inversa, y buscar las herramientas, experiencias y contactos que necesitarás para llegar a ella.

Haz este ejercicio cada 3 o 5 años.

Atrévete a fallar. En público.

Incrementar tu masa muscular duele. Tienes que ir al gimnasio y lastimar tus músculos. Y no será sino a través de la consistencia y dedicación que, después de un tiempo, comenzarás a ver los resultados. Tus músculos estarán más definidos, y tendrás más vitalidad.

Lo que nadie te dijo es que es exactamente el mismo proceso — complicado, arduo y tedioso a veces — para crecer profesionalmente. A diferencia del físico, para crecer en tu carrera profesional no necesitas lastimar tus músculos. Necesitas lastimar tu ego. Y lastimar el ego duele mucho más, de manera más profunda, que un trícep recién ejercitado.

Fallar significa que estás conociendo tus límites. Ese sentimiento de fracaso, aprenderás eventualmente, es en realidad el trampolín a aprender cosas nuevas. Así como una Roomba debe de primero pegarse en todos los muebles para saber dónde no puede limpiar, tú necesitas fallar en muchas tareas para saber qué no sabes. Aún.

Pero a diferencia de la Roomba, tú sí puedes tumbar esa pared, o mover ese mueble.

Todos tenemos miedo de fallar. Sobre todo a fallar en público o con un equipo. Desafortunadamente la educación que recibimos la mayoría de nuestra generación nos enseñó que un error era algo que lamentar. Probablemente creciste creyendo que un error, o un fallo, debes evitar a toda costa. Cuando en realidad, los errores son el principal catalizador del crecimiento — en todos los ámbitos.

Fallar es parte de crecer. Es recibir feedback.

Una idea que no se pone a prueba está segura. Porque no se puede robar, ni modificar, ni pervertir. Pero tampoco se puede criticar, mejorar ni usar en el mundo real.

Puedes pasar toda tu carrera estudiando y aprendiendo nuevas cosas — tecnologías, metodologías, herramientas, etc. Pero no será hasta que salgas, intentes hacer algo y lastimes un poco tu ego en el proceso, que todo el conocimiento adquirido se sintetizará en aprendizajes.

Atrévete a fallar. En público. Serás imparable.

Cómo tener más de 24 horas al día

Todos tenemos las mismas 24 horas en el día. Tú, que programas en Java, cuentas exactamente con el mismo número de minutos de sol que tu compañera experta en React. Ambos trabajan en la misma compañía. En el mismo proyecto, incluso. Entonces, ¿por qué pareciera que ella puede hacer más, con más calidad, mientras tú batallas por cumplir con tus entregas a tiempo?

La respuesta es que tu compañera sabe cómo sacarle más provecho a su día. No se distrae, y encontró la manera de tener más de 24 horas en el día — pareciera.

La correcta gestión del tiempo es un Soft Skill esencial para cualquier desarrollador de software que valga su peso en sal.

Si gestionas bien tu tiempo, creerás que tienes más de 24 horas disponibles cada día de lo mucho que puedes hacer. Es por eso que debes de priorizar crear espacios en los que tu creatividad pueda no solamente nacer, sino florecer. Libre de distracciones. Y es que muchas personas de la industria tienen la concepción errónea de que desarrollar software es una tarea meramente técnica. Cuando en realidad es un proceso 100% creativo.

Irónicamente, tu trabajo sucederá la mayor parte del tiempo en frente de una computadora, donde las distracciones están a la orden del día.

Por fortuna, existen estrategias que puedes implementar para que, efectivamente, puedas tener más de 24 horas efectivas en tu día.

Reclama tu tiempo

Lo primero que debes hacer es establecer reglas para que puedas ser eficiente. James Clear dice en su libro Atomic Habits: “no subes al nivel de tus metas, sino que caes al nivel de tus sistemas.”

Lo primero que debes hacer para asegurarte de que no vas a perder tiempo efectivo de tu día es controlar tu ambiente.

Apaga tus notificaciones. Tan simple como puede sonar, de verdad no necesitas estar al pendiente de todo lo que está pasando en tu compañía en todo momento. Y no, tampoco necesitas saber cuál es el último #lord en Twitter.

Cierra Slack y tu cliente de correo. De verdad, está bien. No necesitas responder de manera inmediata.

Agrega en tu calendario bloques de tiempo específicos en los que tu única tarea sea revisar tus mensajes pendientes.

Bloquea distracciones. Estar en la zona es difícil. Tu cerebro buscará cualquier oportunidad para presionar ⌘T en Chrome y comenzar a escribir “faceb”. A menos que hayas desarrollado un nivel de conciencia bastante bueno como para poder cacharte a ti mismo y detenerte, la solución más sencilla es que simplemente no puedas acceder a distracciones.

Modifica tu archivo para bloquear todos los dominios que sabes que son un agujero de conejo para ti. Aquí hay una lista de más de 2 mil dominios que Facebook usa – agrégalos y no solamente no podrás distraerte viendo memes, sino que tampoco te podrán seguir en internet. Aquí hay una de Twitter.

Si quieres un poco más de flexibilidad, puedes usar una aplicación como SelfControl, que es en esencia lo mismo.

Sé más celoso de tu tiempo. No quiere decir que tengas que decir que no automáticamente a todo, o que no te conectes a absolutamente ninguna llamada. Pero sí es bueno que te comenzaras a preguntar si realmente necesitas dedicarle tiempo a algo en medio de una sesión de debugging.

Puedes comenzar con estos tips para que evites llamadas innecesarias.

Otra técnica que me ha funcionado tremendamente es configurar mi iPhone para que las llamadas de números que no tengo registrados se vayan directamente a buzón. Puedes activar esto yendo a Ajustes > Teléfono > Silenciar desconocidos.

Estos consejos te ayudarán a no perder tiempo. Ahora veamos como puedes dar el siguiente paso y ganar tiempo.

Compra tiempo y automatiza

Puede que esta parte sea la más atractiva porque tiene que ver más con herramientas y menos con disciplina. Pero es importante que sepas que si no arreglas primero tu problema de pérdida de tiempo, los consejos en esta sección no tendrán tanto efecto.

Habiendo dicho esto…

Compra el tiempo de otros. Haz una lista de cosas que no te gusta hacer en tu día a día. Puede ser cocinar, lavar la ropa, buscar estacionamiento, hacer el súper. Cuando tengas esta lista, analiza cuánto tiempo te toma hacerlas. Saca la cuenta de cuántas horas le inviertes a estas actividades, en conjunto, a la semana.

Supón que tú ganas $50 USD por hora y surtir tu comida te toma 2 horas a la semana. Si le puedes pagar a alguien para que lo haga por ti pagando menos de $100 USD a la semana, hazlo.

Paga por herramientas que te resuelvan problemas muy específicos. Hay cientos de miles de personas que comparten el mismo tipo de problemas. Y por más oscuro que sea lo que quieras resolver, seguramente hay un servicio que lo puede hacer por ti. Considera usarlo.

Por ejemplo, en mi caso, gran parte de mi trabajo sucede en consultas con miembros de esta comunidad. Durante un tiempo intenté administrar mi agenda de manera manual, pero muy pronto me di cuenta de que mi tiempo podría estar mucho mejor empleado en otras tareas. Así que decidí dejar de preocuparme puntualmente por mi agenda, y ahora es un trabajo que hacen Calendly y Zapier por mí.

Abstrae y simplifica las tareas más repetitivas de tu día. Busca que tu workflow no sea tan complicado — mantenlo simple.

Utiliza un administrador de snippets para que no tengas que estar escribiendo lo mismo una y otra vez. En lo personal utilizo Alfred, pero podrías considerar también TextExpander, si es que buscas una herramienta más robusta.

Alfred me gusta porque también tiene un administrador de portapapeles integrado, que también es una herramienta indispensable para mí. Un administrador de portapapeles te permite tener, básicamente, un historial de todo lo que has copiado durante un determinado periodo de tiempo. Ya no te tienes que preocupar por pegar antes de copiar otra cosa. Cambia el juego completamente.

Conclusiones

No tener una buena gestión del tiempo no solamente es un problema en tu cabeza. Tiene consecuencias reales en nuestra productividad y en nuestra propia percepción de qué tan bien estamos haciendo nuestro trabajo.

El objetivo, a fin de cuentas, no es que tengas más horas al día, sino que le puedas sacar mucho más provecho a las mismas 24 horas que tengo yo y todas las demás personas en el mundo.

Si aplicas estos puntos, sí es posible que sientas que tu día ahora tiene más de 24 horas como por arte de magia. Pero no, no es magia. Es disciplina.

¿Saber Inglés sigue siendo una ventaja competitiva?

Un lector y miembro de la comunidad pregunta si solamente es necesario saber inglés para sobresalir en el mercado de desarrollo.

Adjunto el correo completo:

Desde el comienzo de la pandemia he seguido a personas que trabajan remoto y una de las cosas que veo que más se repite es “habla ingles” y con eso ya lo tienes resuelto. Llevo 7 años trabajando para consultorías y solo hasta ahora me di cuenta de este nuevo mundo pero no estoy seguro qué estoy haciendo mal o qué no estoy haciendo para entrar a esta zona (trabajo remoto internacional).

He visto los sitios donde hay vacantes pero bueno como un menu de restaurant a veces uno no sabe qué es lo indicado por elegir o si esta decisión será la peor por tomar, ahora que te escribo puedo pensar que es miedo o inseguridad y que a nadie les dicen como hacerlo.

Habiendo explicado un poco creo que mis preguntas son:

como empiezo?

debo comenzar diferente con base a mis años de experiencia?

como calculo cuanto pedir de lo que percibo actualmente a una vacante remota?

el mercado solo busca reactjs? (ajajaj es la mas popular pero como front end dev pareciera que ahorita es el unico camino, o solo ideas mias)

que recomiendas para perder el miedo de equivocarnos?

he pensado que tener contactos te da una entrada a estas vacantes mejor que en los sitios… alguna recomendacion de como hacer amistades en linea?

Mi respuesta:

Tener el objetivo claro te permitirá seguir motivado ante todas estas preguntas que te estás haciendo.

Saber inglés ya no es una ventaja competitiva. Es el mínimo requerimiento.

Tener tantos años de experiencia sí es algo que puedes usar a tu favor. Dependiendo de los proyectos en los que hayas participado, podrías incluir en tu currículum ejemplos de tus contribuciones. Pero personalmente, lo que aprecio más en un currículum, es que me ayudes a entender más allá del código que escribiste, el impacto que causaste en las organizaciones donde has trabajado.

¿Identificaste problemas por tu cuenta e hiciste propuestas para solucionarlos? ¿Tuviste responsabilidades claves dentro de tu organización? ¿Apoyaste a implementar nuevos procesos que dieron como resultado mejoras para los clientes?

Respecto al salario que debes de pedir al trabajar de manera remota, te recomiendo que leas estas respuestas. También, te incluyo uno de mis Tweets que representa muy bien mi filosofía:

https://twitter.com/swanros/status/1331389389495218176?s=21

No, el mercado no solamente busca ReactJS, pero debes de estar listo para balancear tus habilidades con la demanda que existe. Si estás enfocado en desarrollo web al 100%, probablemente ReactJS sea algo de lo que no podrás escapar. En ese momento es cuando debes de tomar una decisión, basada en tu objetivo final, sobre si aprender esa tecnología es lo que te pone en una mejor posición para llegar a tu meta. Si no, hay otras mil tecnologías de desarrollo en las que te podrías volver experto, y así diversificar tu propuesta de valor para cualquier empresa.

Habiendo dicho esto, el miedo a equivocarse es natural. No lo pierdes, aprendes a lidiar con él. Te recomiendo que inicies buscando un ambiente laboral en el que los errores sean vistos como oportunidades de aprendizaje, y no como medios para castigar a las personas. Pero lo más importante, es que nunca pierdas las ganas de intentarlo. Tener tu objetivo claro te mantendrá en el camino correcto.

Para finalizar, te dejo esto: deberías considerar tu CV como tu principal herramienta, pero únicamente en tu primera vez buscando empleo. Conforme vas avanzando en tu carrera, tu principal fuente de opciones y de oportunidades viene de la comunidad en la que estás envuelto. Gente con la que has trabajado, colaborado, o compartido. Personas que ya conocen la calidad de tu trabajo, lo inteligente de tus preguntas, y tu habilidad de recibir y dar retroalimentación objetiva.

Así que sí, estás en lo correcto, te conviene comenzar a rodearte de personas y comunidad más que de páginas de internet. Mi recomendación acá es que te acerques a comunidades en línea y comiences a hacer ruido, compartir cosas, y ayudar a otros miembros. Twitter también es una herramienta bastante poderosa si la usas a conciencia.

Algunas comunidades a las que te puedes unir:

Espero que estas respuestas te den un norte para seguir adelante.

Evitar llamadas de trabajo innecesarias: 3 consejos

“Esta llamada pudo haber sido un correo” es algo que todos hemos pensado en alguna ocasión. Independientemente de si tu equipo Google Meet, Zoom o Microsoft Teams la herramienta no es el problema. Es cómo colaboramos. Gran parte de la población mundial descubrió hace un año, por primera vez, el mundo del trabajo remoto. Lo que antes se resolvía en charlas en los pasillos de la oficina, ahora se tiene que resolver a la distancia — probablemente coordinando 2 o más husos horarios diferentes.

Desafortunadamente la transición al teletrabajo no ha sido tan suave para todos. Algunas personas y organizaciones han decidido que la única manera de sentirse productivos es (adivinaste) teniendo tantas llamadas como puedan caber en un día. De primera mano he visto amigos y familiares que vienen de industrias tradicionales que desde que comenzó la pandemia tienen llamadas constantes de 9 am a 6 pm, dejando muy poco espacio para realmente trabajar. Y lo peor, la mayoría de esas llamadas sí pudieron haber sido un simple correo.

Después de más de una década trabajando de manera remota, te quiero compartir algunas técnicas que he aprendido para evitar tener reuniones innecesarias en Zoom o Google Meet.

Bloquea tu calendario

Tan sencillo como esto. Si usas Google Calendar, debes de saber que existe la capacidad de crear un tipo de evento especial para bloquear espacio en tu calendario. Automáticamente rechazará cualquier invitación a un evento que te hagan durante ese marco de tiempo.

Personalmente bloqueo de lunes a viernes el espacio de 2 pm a 3 pm, mi hora de comida, y de 5 pm a 10 pm. Hace años que no tengo una llamada de trabajo después de las 5 pm, y mi hora de comida es sagrada.

Es posible que no uses Google Calendar, o que no tengas activada la opción para crear ese tipo de evento. En ese caso, puedes simplemente crear un evento con un nombre opaco, como “FUERA” o “NO DISPONIBLE”.

Esta solución es parcial, puesto que hay personas a las que simplemente no les importa la agenda de las demás y mandan invitaciones a eventos sin siquiera verificar si los invitados tienen disponibilidad. Pero, por lo menos, si utilizas la opción de fuera de la oficina, Google rechazará la invitación por ti.

¿Sabes qué quieres decir?

Probablemente en más de una ocasión hayas recibido un mensaje como este:

Hola, ¿cómo estás? ¿Me regalas 10 minutos para rebotar unas ideas?

La respuesta por defecto a una proposición de este tipo debería de ser “no”.

La cultura laboral latinoamericana es muy propensa a querer complacer a nuestros colegas, líderes o jefes. Se nos ha hecho creer que poner nuestro bienestar y productividad por delante es hacerle falta a la compañía. Se dice que no estamos jugando en equipo, y que no tenemos “puesta la camiseta”.

Lo que muchas personas no saben es que al decir que no a una propuesta de este tipo no estás siendo egoísta. En realidad estás ayudando a evitar perder el doble del tiempo que la persona que quiere hablar contigo cree. 10 minutos tuyos, y 10 minutos de ellos.

Dependiendo de tu situación, te invitaría a contestar la invitación a una llamada de 10 minutos con una versión de lo siguiente:

Ahora estoy algo ocupado, lo siento. Si no te molesta, déjame tus preguntas o tu idea aquí en el chat y cuando tenga tiempo la reviso y te comparto mis comentarios.

Así la otra persona se ve en la necesidad de estructurar sus ideas o preguntas para poder escribírtelas. Este proceso es primordial, pero muchas veces ignorado. ¿Sabes realmente lo que quieres decir o simplemente quieres escupir un montón de pensamientos? Este es un buen Litmus test.

Cuando comiences a emplear esta técnica para rechazar “llamadas rápidas” tendrás una epifanía. Te darás cuenta de que la mayoría de las veces, al intentar escribir las preguntas o definir la idea, se responden ellos mismos y tu opinión ya no será necesaria.

Ejerce tu derecho a rechazar invitaciones

Me atrevería a apostar que todas las aplicaciones de calendario tienen la opción de rechazar una invitación a un evento. ¿Cuántas veces has presionado ese botón?

Durante mi proceso de formación profesional creía que una invitación a un evento era algo que se tenía que tomar sí o sí. Conforme fui creciendo y agarrando experiencia me di cuenta de que, en virtud de hacer mejor mi trabajo, vale más la pena proteger mi tiempo y creatividad que tomar una llamada — en la mayoría de los casos.

Así que fui desarrollando una serie de políticas personales en las que me baso para determinar si acepto o no una invitación a un evento en el calendario. Te las comparto a continuación.

Política #1: Procuro no enviar o aceptar invitaciones para el mismo día. Soy introvertido por naturaleza, y “encender” el “modo llamada” me cuesta muchísima energía. Prefiero tener por lo menos un día de margen para poder llegar preparado y asegurarme de que puedo aportar el valor necesario a la llamada. ((Esto no siempre es posible, y hay veces en las que simplemente se tiene que entrar a la llamada — sobre todo en situaciones críticas. Ni modo.))

Política #2: Si el nombre o la descripción del evento no te dicen exactamente de qué se va a tratar la llamada, no acepto la invitación. En algunas ocasiones selecciono “Posiblemente” y respondo la invitación pidiendo clarificación sobre el propósito de la llamada. Una vez que esté claro el por qué es importante reunirnos, puedo decidir si acepto o no.

Política #3: Actualizaciones de estado se hacen por correo, no por llamadas. Las reuniones para actualizar al equipo sobre progreso son el ejemplo primordial de llamadas que pudieron ser un correo. Para estos casos, si sé que puedo hacer llegar la información que me van a pedir por correo así lo hago y rechazo la invitación. Y como manager te comparto: es liberador cuando un miembro de mi equipo me responde con un “aquí está lo que me necesitas saber” y rechaza la invitación a la llamada.

Política #4: Los horarios personales son sagrados. La hora de la comida, vacaciones y cualquier hora después de las 4 pm son intocables.

Conclusiones

El trabajo remoto fluye con muchas menos complicaciones si aceptamos la idea de que estar ocupado no es lo mismo que ser productivo. Y, te anuncio, las llamadas te mantienen ocupado.

Como con todas las herramientas, también debemos de asegurarnos que estamos usando la herramienta adecuada para resolver cada problema. Si bien tener una llamada puede sonar como un atajo para atender una situación de manera más rápida, lo cierto es que intentar resolver absolutamente todo en llamadas es contraproducente. Si pasas 8 horas en llamadas todos los días, ¿a qué hora trabajas?

Puedes encontrar el hilo de esta publicación en Twitter.

La diferencia entre el freelancing y el trabajo remoto

Se dice que alguien hace freelancing, o que es contratista, cuando la relación con el cliente tiene fecha de expiración. Se trabaja por proyecto, y puede que al terminar la encomienda actual no se vuelva a trabajar con el cliente.

Se dice que alguien trabaja de manera remota cuando la persona tiene un rol definitivo, de largo plazo, dentro de una organización.

Un freelancer rara vez puede influenciar a la organización, pues se le contrató para un trabajo en particular. Sus contribuciones están acotadas al dominio del problema actual que tiene el cliente.

Sin embargo, una de las implicaciones más importantes de la diferencia entre ser freelancer y un trabajador remoto es realmente cuál es tu trabajo.

Aunque parezca raro, la principal habilidad que un freelancer debe de desarrollar no es aquella por la que lo están contratando. Es la de ponerle precio a sus contribuciones y, aún más importante, la de cobrar.

Aprendiendo a valorar y cobrar por tu trabajo

Un error común que todos cometemos nuestras primeras veces haciendo freelancing es creer que todo va a salir bien. Que entendimos la idea del cliente, y que nos aceptará nuestras soluciones sin ediciones.

Pensamos que la transacción concluirá en tiempo y forma. Cuando la realidad es que cuando tomamos un proyecto de freelancing, es casi seguro que durante la marcha saldrán imprevistos que alterarán el costo, tiempo, o complejidad del proyecto.

Teniendo esto en cuenta, ¿cómo abordar la creación de un presupuesto de un trabajo, en tiempo y dinero?

Recientemente alguien me preguntó esto por correo electrónico. Esta persona acababa de tener su primera experiencia con un proyecto que no salió como esperaba.

¿Qué posibles soluciones u opciones darle al cliente para que salgamos en buenos tratos? Por último, supongo que es casi imposible no caer en este tipo de situaciones, pero ¿habrá una manera de disminuir el riesgo a que sucedan?

La diferencia entre el trabajo remoto y el freelancing es que, en realidad, el trabajo del freelancer es dominar el arte de realizar estimaciones y cobrarle al cliente.

Para bien o para mal, vas a tener que lidiar con muchos proyectos y clientes antes de que te conozcas lo suficiente como para determinar cuál es tu punto justo en cuanto a estimaciones. Desafortunadamente, esta es una habilidad que no puedes aprender en un libro, o experimentar en cabeza ajena. Vas a tener que hacerlo muchas veces hasta que entiendas cuáles son tus límites.

¿Cómo estimar proyectos para clientes?

No hay una solución definitiva para este problema. Por naturaleza, cuando tomas un proyecto nuevo no sabrás con qué te vas a encontrar. Así que, más que pensar en una solución particular para este problema, propongo pensar en términos de un marco de trabajo que puedas usar para lidiar con estas situaciones.

El marco de trabajo que más me ha funcionado, en particular, es el de “ser eficiente comunicando”. Sobrecomunica. No te esperes a la fecha de entrega para avisar que algo no va a estar listo. Da todos los detalles en cuanto los tengas disponibles.

Maneja las expectativas de manera correcta.

Esto te hará parecer mucho más profesional con tus clientes, y te ayudará a ganar una reputación que en el futuro te dará una ventaja competitiva sobre otros contratistas.

Ganando experiencia

Algo que le digo a las personas que trabajan conmigo es “enfócate en el proceso, no en los resultados”. Trabajar en modalidad de freelancing es complejo, y no es para todos. Pero puede ser bastante redituable para aquellas personas que saben cómo navegar sus altibajos. Enfocarte en el proceso, y no en el resultado de un proyecto en particular, te ayudará a aprender más sobre tu práctica, y cómo le puedes sacar más provecho.

En este artículo, Curtis Hebert comparte su experiencia con un freelancer novato. Leerlo te puede ayudar a comprender cómo se ve todo desde el otro lado de la mesa.

Después de todo, si no costara trabajo, la experiencia no se ganaría.

Cómo destacar tu currículum en el mundo del desarrollo de software

Lo he dicho en algunas ocasiones, en mi pódcast y en mis seminarios web: si juegas bien tus cartas, tu currículum solamente lo necesitarás la primera vez que busques empleo. Al inicio de tu carrera.

Aun así, probablemente te verás en la necesidad de mandar un CV, currículum, carta de vida, o como le digas, a una empresa para solicitar empleo. Y por eso te quiero regalar un consejo como alguien que constantemente revisa currículums de candidatos: cuéntame una historia.

Al contarme una historia, tu currículum te hará ver muchísimo más atractivo, y podremos entablar una conversación. Si todo sale bien, te ofreceré un empleo.

Te explico.

No digas lo obvio

Imagina conmigo la siguiente situación: entro a una tienda de deportes porque quiero comprar una bicicleta. ¿Crees que alguien me va a convencer de comprar una bicicleta diciéndome que tiene dos ruedas?

Por supuesto que no.

Sucede exactamente igual con un currículum. Cuando aplicas a una posición que requiere habilidades especiales, y dentro de tu CV solamente listas que sabes esas habilidades, no estás diciendo nada. No me estás llamando la atención. No te estás diferenciando.

¿Qué te hace diferente?

Ahora imagina que el vendedor se toma el tiempo de preguntarme para qué quiero una bicicleta, si ya tengo experiencia, y demás. ¿Qué pasaría si aprovecha esa información? Me ofrecería una bicicleta que me ayudará a cumplir mi meta de hacer ciclismo de montaña. Me contaría cómo el marco de fibra de carbono es más ligero pero más resistente, y por qué eso es bueno para mí. Haría una demostración de por qué el tamaño de la rueda de esta bicicleta en particular me ayudará a cansarme menos.

El vendedor entendió mis necesidades, y creó una historia al rededor de ellas para vender el producto. Jugó bien sus cartas, y el resultado es que yo salí de la tienda con mi bicicleta nueva.

Te invito a cuestionarte si realmente listar que sabes usar Photoshop e Illustrator le agregan valor a tu propuesta como diseñador gráfico. O si decir que sabes hacer balances de cuentas te diferencia como contador.

Cómo contar una historia en tu currículum

En mi artículo ¿A los 36 ya soy muy viejo para buscar trabajo en TI?, compartí lo siguiente:

Te aconsejaría tomar nota de cuáles sí son tus habilidades que te distinguen, y aprender a venderlas mejor a empresas que sí busquen lo que tienes que ofrecer.

Regla #1 del marketing: conoce a tu cliente. ?

Es una pena que las escuelas actualmente hagan ver la creación de un currículum como algo burocrático, cuando en realidad es 100 % marketing. Recuerda, el marketing se trata simplemente de vender.

Y la regla #1 del marketing es conocer a tu cliente.

Volvamos al escenario del vendedor de bicicletas. Yo quería comprar una bicicleta para hacer ciclismo de montaña. ¿Crees que habría comprado una bicicleta en esa tienda si me hubieran ofrecido una bicicleta de pista? Obviamente no. Pero el vendedor hizo algo crucial: investigó cuáles eran mis necesidades.

¿Sabes qué es lo que quiere la empresa para la que estás aplicando? Porque por ahí deberías comenzar. Y una vez que sabes por qué están buscando nuevos integrantes para su equipo, puedes comenzar a crear una propuesta de valor adecuada.

En este punto debería de comenzar a hacerte sentido lo que te digo. No simplemente listes tus habilidades. Evita decir cosas obvias. Enfócate en vender tu historia, y responder las siguientes preguntas:

¿En dónde culminan tus habilidades?
¿Cómo las has usado antes?
¿Qué resultados favorables hubo?

Habiendo dicho esto, a continuación te muestro cómo puedes traducir una lista de habilidades en un párrafo que hará que tu currículum sobresalga.

Proceso creativo: esto es lo que te hace diferente. Tienes un proceso creativo, y gracias a él es que eres tan prolífico con tus contribuciones.
Tanto gráfico, como web y de correo: les estás diciendo que tus habilidades de diseño son multidisciplinarias. Implicas que conoces varias herramientas y sabes cómo utilizarlas para su propósito específico.
Incrementar sus ventas en un 35 %: esto es lo que ata con moño tu historia. Es por esto que todas tus habilidades son relevantes para la empresa. En este caso, les estás diciendo por qué te deberían contratar. Contigo en el equipo aumentan sus probabilidades de vender más.

El conjunto de esos tres factores, aderezados con datos particulares de tu perfil, es la historia que te va a hacer sobresalir.

Esto es casi una plantilla. Úsala a tu conveniencia.

Notas finales

Recuerda que un buen currículum no hará que te contraten. La idea de un currículum es entablar una conversación. Vender la idea de por qué vale la pena enviarte un correo pidiéndote una llamada. Hacerte parecer lo suficientemente interesante para que cuando te hablen, te pregunten por tu proceso creativo, no por comandos de Photoshop.

Pero sobre todo, ten en cuenta que el mejor currículum no es el que se envía, es el que se demuestra. Como dije al inicio, si juegas bien tus cartas, tus contribuciones, aportaciones, experiencia, y colegas hablarán por ti.

Que tu trabajo sea excelente.