Archivo de la etiqueta: trabajo remoto

No tienes que convertirte en Manager después de ser Senior

El otro día, un amigo que ya estaba trabajando como programador cuando yo apenas iba en 6° de primaria, se sinceró conmigo.

A pesar de que en su trabajo le pagan bastante bien, y bajo todos los estándares, es un buen empleo, está extremadamente frustrado. “Ya estoy harto de hacer diario lo mismo.” Me platicó que su día a día se ha vuelto tan monótono, que hasta las ganas de programar se le están quitando.

“No hay nada interesante para hacer. Puros forms, maquetado, y resolver bugs de renderizado.”

Cuando le pregunté si había algo que pudiera hacer para cambiar su situación, su respuesta no me sorprendió en absoluto.

“Sí, ser manager. Pero me caga la gente.”

Algunas personas, cuando llegan a cierto nivel de seniority como desarrolladores, dejan de preocuparse por su carrera. Le dejan de prestar atención a su crecimiento profesional porque creen que el único paso que está delante es el convertirse en management. Algo que no quieren hacer.

Opino que esto viene de la idea de que únicamente existe un camino de crecimiento profesional. Como mencioné en la última Sesión Grupal de Soft Skills para Devs, esto es completamente erróneo.

Llegar a cierto nivel de seniority como desarrollador no significa que no puedes seguir avanzando en tu carrera. Después de convertirte en experto en tu tecnología, tendrás más oportunidades de aportar valor de una manera mucho más amplia. Si no te quieres convertir en manager, después de ser Senior, te podrás convertir en Staff Engineer. Y si quieres continuar por la ruta de contribuidor individual, es decir, sin tener que manejar personas, puedes incluso llegar a convertirte en Principal Engineer.

En la empresa correcta, una vez que eres Senior, convertirte en manager no es “lo que sigue”.

Pero hay una trampa: mientras más creces en tu carrera como contribuidor individual, menos se mide tu impacto en líneas de código. Habilitar a otros desarrolladores, aportar valor a otros equipos y áreas de negocio, dar visibilidad a problemas. Todas estas son competencias clave que vas a tener que desarrollar, sí o sí. Todas ellas, van a requerir que le pongas atención, de alguna u otra manera, a tus Soft Skills y a tus habilidades de colaboración con otras personas.

Está bien que no te guste (o te cague) la gente. No todas las personas somos sociales por naturaleza.

Pero la oportunidad de mejorar tu carrera ahí está. Si no quieres convertirte en manager, no tienes que hacerlo.

Lo que sí tienes que hacer, es asegurarte de estar en la empresa correcta para seguir creciendo sin tener que tomar tareas administrativas. Y trabajar en tus Soft Skills.

Convertirte en manager no es un ascenso. Es un cambio de carrera.

Si en tu empresa te quieren “promover” a manager porque eres la persona con mejores capacidades técnicas de tu equipo: felicidades. Acabas de ser víctima del Principio de Peter, que dice:

“En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia: la nata sube hasta cortarse.”

¿Hiciste un buen trabajo como Jr.? Felicidades, ahora eres Mid. ¿Seguiste haciendo un buen trabajo? Genial, ahora eres Sr. ¿Sigues siendo excelente en tu trabajo como desarrollador? Felicidades, ahora tienes un conjunto de responsabilidades para las que no estás preparado, y probablemente ni siquiera quieras tomar.

Las habilidades fundamentales que te hicieron tener éxito como contribuidor individual, no son las mismas que te harán tener éxito como manager.

Escribir “buen” código no se traduce en capacidad para analizar y resolver problemas organizacionales. Saber escoger el lenguaje de programación o framework adecuado para resolver un problema de arquitectura, no se traduce en saber entender las necesidades personales y aspiraciones profesionales de tu equipo, y alinearlas con las de la empresa.

Probablemente, dentro de tu organización, el convertirte en manager venga con aumentos salariales o mayores prestaciones. Pero ten en cuenta que es un trabajo completamente diferente. Convertirte en manager no es un ascenso. Es un cambio de carrera completo. Puede que estés trabajando en tu misma industria; incluso hasta con el mismo equipo. Pero tus responsabilidades ahora son completamente diferentes.

Antes de aceptar el “ascenso”, pregúntate: ¿sabes a qué te estás metiendo? ¿Estás consciente de las implicaciones del nuevo rol? Y más importante aún, ¿quieres hacerlo?

No tener claras las respuestas a estas preguntas te pone en riesgo de sufrir burnout.

Estarás jugando otro juego. Uno que no conoces. ¿Cómo vas a ganar?

Qué hacer si presencias acoso en tu trabajo o comunidad

Acabo de participar en un entrenamiento para prevenir acoso y discriminación en equipos de trabajo.

Me pareció que esta información debería compartirse. Así que aquí tienes 6 cosas que puedes hacer si presencias acoso en el trabajo, comunidad o sociedad en general, incluso si no eres manager.

Interrumpe la conversación

Haz algún comentario que desvíe la conversación e interrumpa el acto de acoso. Puede ser una broma, un cambio drástico de tema, o simplemente hacer un ruido que cambie el foco del grupo.

Pregúntale a la persona cómo se encuentra

Acércate a tocar base, y pregunta si hay algo que puedas hacer para ayudarle.

Aborda a la persona cometiendo el acoso

Especialmente en ambientes donde no estamos sensibilizados en cuestiones de acoso, es importante dar visibilidad y resaltar acciones imprudentes y dañinas.

Asume que la persona es ignorante de efecto de su comportamiento, y ofrece una perspectiva diferente: “Sé que tal vez no quisiste decir esto, pero este fue el efecto de tu comentario.”

Apela a la amistad y empatía con la víctima

Hazle saber que tiene aliados, y que no está solo o sola. Reconoce que presenciaste lo que sucedió, y que estás ahí para apoyarle en lo que necesite, aunque sea simplemente moralmente.

Da retroalimentación directa y clara en el momento

“Aquí no hacemos o decimos eso, bajo ninguna circunstancia.”

Niégate a ser parte de la situación, y llévate a otros contigo

El mensaje más valioso que puedes mandar es que no te vas a prestar a crear un foro para este tipo de actos.

En cuanto te percates de que alguien está siendo acosado, retírate de la situación y busca que otros te sigan.

A veces lo que se necesita es alguien a quien seguir.

Ponerle un alto al acoso es responsabilidad compartida

“Acoso” puede significar cosas diferentes dependiendo el contexto. Apela a tus valores, o las reglas de convivencia del grupo, para aprender a identificarlos.

Pero hay un tipo de acoso que es incuestionable: calumnias, bromas sexuales, transgresión del espacio personal, comentarios hirientes o fuera de lugar.

Si observas cualquier tipo de acoso y no haces nada para resaltarlo y detenerlo, también eres parte del problema.

¿Cómo le hacen los que no pueden usar Git en su trabajo?

Un usuario de Reddit escribe:

Esta mañana, gasté 3 horas reescribiendo lo que hice ayer, porque mi compañero lo eliminó accidentalmente en la carpeta de Windows Server que usamos para desarrollar. No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git. ¿Alguno de ustedes ha trabajado en algún lugar así y encontrado una manera de sobrellevarlo?

Obviamente, las respuestas recomendándole que huyera de ahí lo más rápido posible no se hicieron esperar.

Hace casi 22 años, Joel Spolsky publicó en su blog su popular checklist para determinar si un equipo de desarrollo de software es bueno o no: 12 Pasos Hacia Mejor Código. La primera pregunta es: ¿Tu equipo usa manejador de versiones?

Aunque es fácil caer en la tentación de burlarse del creador del hilo en Reddit, me gustaría reflexionar sobre su situación.

Recordando que muchas personas crecimos con la idealización del trabajo duro, no es difícil ver cómo esa forma de pensar podría llevarnos a la progresión lógica de que cualquier cosa que le haga al programador la vida más fácil significaría que entonces la empresa no lo está aprovechando al máximo. Estoy seguro de que podrás identificar alguna persona en tu vida (probablemente alguien mayor, o “de la vieja guardia”) que defendería esta retórica. “Los programadores de verdad compilan su propio IDE.” Esto es lo que pasa cuando personas con esta mentalidad dirigen empresas.

(Dándoles el beneficio de la duda: es probable que esta persona esté trabajando en una industria donde únicamente se pueden utilizar tecnologías aprobadas y validadas por algún tipo de organismo o estándar. En este caso, entendería que, por regulación, no estuviera permitido que usaran tecnologías de código abierto.)

Por otro lado, es probable que el autor original del hilo simplemente se encuentre rodeado de gente que ignora la existencia de los controladores de versiones, así como sus beneficios. Un par de veces en mi vida me he encontrado con personas que encuentran abrumadora la idea de tener que aprender otra tecnología (Git) además del lenguaje de programación en el que están especializándose. Así que simplemente hacen lo que pueden con lo que saben: ponen su código en Dropbox, Google Drive, y listo. No es hasta que salen problemas que el valor de usar controladores de versiones se vuelve aparente.

La parte clave de su mensaje es esta:

No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git.

Apostaría que la persona que escribió esto encaja en el siguiente perfil: alguien joven, al inicio de su carrera en software, con grandes aspiraciones, en su primer trabajo formal. Probablemente, la empresa sea de una industria vieja (finanzas, construcción, legales, donde las cosas se hacen por regulación) que se está intentando renovar, y lo están haciendo contratando programadores, pero sin crear una cultura de desarrollo de software.

No conozco al autor del hilo, pero no me sorprendería si tuviera una carrera próspera en su futuro. Después de todo, está demostrando una capacidad que (desafortunadamente) no todos tienen: la de cuestionar el statu quo. No se está quejando, está haciendo una pregunta para educarse y crecer. Está buscando datos, consejos y soluciones.

Algunas lecciones que me gustaría que todos nos lleváramos de esta experiencia:

  1. No en todas las empresas se puede desarrollar software. Ve esta porción de una de mis charlas para entender más sobre esto.
  2. Algunas empresas solamente quieren programadores, no desarrolladores.
  3. Desarrollar software es mucho más que escribir código.
  4. Se vale preguntar, cuestionar y decidir si la situación en la que estás es en la que quieres estar.

El Open Source no se trata de ti

Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

No inviertas más en tu educación. Invierte más, y mejor.

Publiqué este Tweet justo antes de inscribirme en un curso algo costoso. Me dio curiosidad saber cuánto dinero invierten las personas en su educación al año.

USD $500 (MXN $10,000) es también más o menos lo que había estado invirtiendo anualmente en mi educación, en promedio, hasta 2020.

Me puse a reflexionar, y me di cuenta de que, por lo menos en mi caso, durante mi proceso de formación, nunca se me inculcó la importancia de invertir en educación. Claro, se me mencionó que la educación continua era importante. Pero nunca se me dijo que una de las formas de mantenerme educado continuamente era “aventándole dinero al problema”.

Suena raro, ¿no? Hasta parece obvio.

Sin embargo, en mi caso, creo que interpreté la idea de “educación continua” como “aprende lo más que puedas de las situaciones que se te presenten”. Que es un consejo sabio, y lo aplico. Pero nunca me pasó por la cabeza que podía influenciar directamente la calidad de la educación que recibía incrementando la cantidad de dinero que le destinaba a ello.

Hasta que lo intenté. Dejé de buscar cantidad, y me enfoqué en calidad.

Hoy en día prefiero mil veces tomar el toro por los cuernos y trabajar con un especialista en sesiones individuales de coaching, que comprar 10 cursos diferentes a 95 % de descuento (tú sabes de qué plataforma hablo) — simplemente para nunca realmente darme el tiempo de ver los videos y hacer mi tarea.

Cada uno de nosotros aprende de manera diferente. Yo encontré que me funciona mucho más tomar clases en vivo, acompañado de una cohorte de alumnos, que suscribirme a una plataforma de videos y verlos por mi cuenta. Descubrí que me funciona más comprar libros físicos y tenerlos a la mano de manera tangible, que buscar PDF gratuitos y leerlos en mi iPad.

Muchas personas confundimos cantidad con calidad. Creemos que simplemente comprar libros, videos y suscripciones, cuenta como educarnos. No leer, ejecutar o participar. Comprar.

Tener acceso a más información no es lo mismo que tener mejor educación.

¿Tú cuánto inviertes en tu educación al año? Y si tuvieras que duplicarlo, ¿simplemente invertirías más? ¿O invertirías más y mejor?

El Triángulo de la Documentación de Código

Hace un tiempo propuse que deberías escribir código que se documente solo, y luego agregarle documentación. En el artículo original, escribí:

La idea de que “tu código debería de documentarse solo” no es un get out of jail free card para no documentar tu código. Las ocasiones en tu carrera profesional donde escribir documentación no agrega valor a tu trabajo son muy pocas. Tan pocas, de hecho, que no se me viene ninguna a la mente. ¿Tal vez cuando estás trabajando en un proyecto propio? Pero hasta Damian Conway dijo que “la documentación es una carta de amor que le escribes a tu yo del futuro”.

Hoy me encontré una idea que aumenta mi punto: El Triángulo de la Documentación de Código.

Este modelo mental nos dice que toda pieza de código está documentada en 3 dimensiones distintas, cada una respondiendo una pregunta muy particular.

  • ¿Qué?: Tu código, en sí, explica lo que estás haciendo.
  • ¿Por qué?: Los comentarios que le agregas a tu código, explican tu proceso de toma de decisiones y la razón de tus soluciones.
  • ¿Cómo?: El contexto dentro del cual estás desarrollando tu programa; la descripción original del problema.

Si te enfocas en escribir código que “se documente solo”, en un futuro no sabrás por qué llegaste a esa solución, ni cómo esa solución es apropiada para el problema original.

Recuerda, agregar documentación a tu código (en forma de comentarios, glosarios, RFCs, pruebas, etc.), no es una admisión que no fuiste lo suficientemente inteligente para escribir “buen” código, sino un acto de compasión. Demuestra tu interés porque la siguiente persona que modifique tu código pueda enfocarse en agregar valor al proyecto — y, muy probablemente, esa siguiente persona vas a ser tú.

Fomenta una cultura de privacidad, no de secretos

El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”

Adam Thomas escribió brillantemente al respecto (traducido por mí):

La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.

En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.

Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.

A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.

Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación de secresía. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.

Durante los más de 12 años en la industria del software, he aprendido a identificar que si sientes que necesitan comunicar algo en secreto (por DM, en una llamada, o por medios fuera de la compañía), significa que inconscientemente no confías en tu compañía. La cultura está rota.

La diferencia entre trabajar en producto vs. consultoría

Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.

Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.

Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.

Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.

Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.

La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.

No todas las empresas que dicen querer contratar Seniors lo dicen en serio

Un verdadero Senior no va a caer en la trampa de simplemente ir a implementar cosas sin pensar en sus posibles consecuencias e implicaciones a largo plazo. Un Senior no va a aceptar mediocridades, y va a presionar para mejorar procesos — no solamente dentro de su área.

Pocas organizaciones están preparadas para lidiar con el pushback que esto representa.

Muchos que dicen querer contratar Seniors, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no quieren Seniors.

Demuestra por qué no se debería de implementar la propuesta

Subhro Saha comparte en su blog la siguiente idea: cuando muestres una propuesta para hacer algo nuevo, asegúrate de incluir el por qué no se debería de implementar en primer lugar.

El argumento es que al enfocarte únicamente en lo que podría salir bien, y los beneficios que podría traer la implementación de tu idea, te estás cegando a lo que podría salir mal. Al hacer el ejercicio de complementar tu propuesta con algún argumento de por qué lo que estás proponiendo sería una mala idea, tu propuesta se vuelve mucho más completa.

Subhro comenta:

El objetivo debería de ser presentar el argumento de “hombre de acero” — eso es, presentar las razones más interesantes del por qué no se debería de hacer algo.

En mis equipos de ingeniería promuevo crear RFCs para coordinarnos y definir el panorama de los proyectos en los que trabajamos. Una de las secciones más importantes del RFC para mí es la de “Implicaciones y puntos ciegos” de la propuesta. En esta sección, la tarea del autor es listar los efectos secundarios y cambios necesarios que deberían de ocurrir en la organización una vez que los cambios sean introducidos, así como cualquier punto ciego del que se tenga consciencia.

En el pasado, es justamente en esta sección donde nos hemos dado cuenta de que no solamente deberíamos implementar la solución propuesta, sino que deberíamos hacerlo rápido.

Tu tarea: procura complementar tus propuestas con argumentos en contra de ellas. Aunque suene contraproducente, hacer esto te ayudará a hacer propuestas más completas y con menos puntos ciegos y efectos secundarios indeseados.

El trabajo asíncrono es más tardado, pero produce mejores resultados

El principal factor que desmotiva a algunos líderes de intentar el trabajo asíncrono, dicen, es que “es más tardado.”

Está codificado en nuestro ADN preferir resultados inmediatos. Si bien no podemos cambiarlo, sí podemos desarrollar la consciencia necesaria para entender que las personas (y por ende, organizaciones) que están dispuestas a demorar la gratificación inmediata, tienden a tener menos problemas, son más estables y gozan de mayor éxito.

Tomemos como ejemplo la imagen clásica que se usa para intentar comunicar la diferencia entre el trabajo duro y el trabajo inteligente.

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

Observa cómo ambas soluciones aparentan resolver el problema de una manera u otra — pero ninguna de manera sostenible. Los que trabajan duro llegan tarde, cansados y probablemente no van a querer hacerlo de nuevo, mientras que el otro llegó con una esfera cuando le pidieron un cubo.

Una cultura de trabajo asíncrona les habría permitido considerar de manera consciente sus opciones. Darse cuenta de que empujar el cubo no es viable si quieren seguir trabajando ahí, y que llegar con una esfera tampoco lo es porque lo que les pidieron fueron cubos. Probablemente, un equipo trabajando de manera asíncrona, con todo lo que eso significa, habría llegado a la conclusión de que para llevar cubos de un lugar a otro, la mejor opción es rentar una camioneta que lo haga.

Sí, el trabajo asíncrono es un poco más tardado. Porque te pide disciplina, orden y que consideres cuidadosamente, a consciencia, las implicaciones de tus decisiones.

Sí, el trabajo asíncrono puede ser un poco más caro. Porque hace mucho más que apagar síntomas de los problemas.

El trabajo síncrono e inmediato subsana síntomas. El trabajo asíncrono y a conciencia resuelve problemas de raíz.

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.

“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.

Analogías, principios básicos y modelos mentales para resolver problemas

Aprende a buscar analogías y modelos mentales que te ayuden a razonar mejor las soluciones que propones.

Regresa a los principios básicos de cómo se resuelven diferentes tipos de problemas, y extrapola sobre eso para tu caso de uso particular. Por ejemplo, si necesitas crear un sistema para que usuarios suban y validen documentos, analiza cómo lo resolvieron en 1989 con el protocolo HTTP. Construye sobre ese principio.

La gran mayoría de problemas que te va a tocar resolver en tu carrera no son nuevos. Y muchas de las dificultades técnicas con las que te vas a enfrentar vendrán de tu propia renuencia a levantar la cabeza para buscar soluciones externas, y de tu tendencia de reinventar la rueda cada vez.

Estás construyendo sobre los hombros de gigantes. Aprovéchalo.

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

Why are you looking for, or open to, a new job? 65% Better salary/pa, 39% wanting to work with new technologies, 36% Better work /life balance, 35% Growth or leadership opportunities

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 experienceEste 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 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.

Agregando una opción de ”ninguna de las anteriores” a formularios

El Gobierno de Reino Unido publicó una guía de diseño para agregar “ninguna de las anteriores”  como opción a las formas que usen checkboxes en sitios oficiales.

The ‘Register your trailer to take it abroad’ service on GOV.UK on a laptop

Frankie Roberto explica por qué en el blog de diseño:

A veces, está bien contestar uan pregunta dejando todas los checkboxes vacíos. Sin embargo, algunos equipos en el gobierno han encontrado algunos problemas con esto.

Observaron que:

  • los usuarios podrían estar inseguros si pueden hacer esto — lo cual puede resolverse usando elementos de guía, pero no todos los usuarios los van a ver
  • algunas veces, los usuarios quieren dar una respuesta concreta, especialmente si les preocupa contestar las preguntas con confianza y con la verdad
  • dejar los checkboxes desmarcados significa que los usuarios podrían pasar la pregunta por accidente, tal vez pensando que podrían regresar a ella después

Tengo varios comentarios respecto a esto.

Primero, el hecho de que el Gobierno de Reino Unido tenga un blog dedicado a compartir notas de diseño para sus sistemas internos me voló la cabeza.

Segundo, todos podemos aprender de su razonamiento para resolver este tipo de problemas. Cuando se trata de sistemas internos, o en este caso, de gobierno, los que los producimos debemos de tener en cuenta que el 90 % de las veces, las personas que los van a utilizar quisieran no tener que hacerlo. ¿Cuándo fue la última vez que te dio gusto emplear un sistema de gobierno? Aquí, claramente están poniendo como prioridad crear soluciones que realmente le ayuden a su usuario a reducir su carga cognitiva y, por ende, ayudarles a hacer lo que quieren hacer de una manera más confiable.

Un programador podría argumentar, lógicamente, que la ausencia de un valor podría considerarse como una opción válida. Después de todo, no contestar es, en sí mismo, una respuesta. Por otro lado, el usuario argumenta que un no es en sí también una respuesta explícita, y debería de poder usarla.

Qué bueno que ganó la empatía por el usuario, y no los tecnicismos.

Cómo usar Google Calendar para evitar distraerte

En los equipos de ingeniería con los que trabajo, les pido a mis colaboradores que por favor bloqueen su calendario — que lo segmenten y organicen para poder saber cuándo es apropiado invitarlos a una llamada con la confianza de que no estaré interrumpiendo una racha de productividad.

Por alguna razón se me había pasado que se había agregado una nueva opción a Google Calendar. Un nuevo tipo de evento, que en español se llama “Enfocar horario” que te permite rechazar automáticamente eventos a los que te inviten durante ese periodo de tiempo.

Antes de que Google Calendar activara esta opción, crear un evento para segmentar tu tiempo productivo no era tan efectivo porque hay algunas personas que aún no están acostumbradas a la realidad del trabajo remoto y la comunicación asíncrona. La cantidad de veces que alguien me invita a una llamada sin verificar primero que ese espacio esté libre en mi calendario es impresionante. Esto lleva a un espiral de tener que contestar manualmente, buscar otro horario, etc.

Previo a este cambio, la única manera de proteger tu tiempo en el calendario de manera automática (y real), era crear un evento de “fuera de la oficina”. Pero es claramente el mensaje equivocado. Ahora, con un evento de “Enfocar horario”, el mensaje es mucho más certero y claro: este tiempo lo estoy reservando para algo importante que necesita de mi completa atención, por favor respétalo.

Poco a poco nos estamos haciendo más conscientes de que no todos funcionamos en el mismo horario, que no todos tenemos las mismas horas productivas. Pero aún hay mucho por hacer — sobre todo en organizaciones grandes. Este es un paso en la dirección correcta, creo.

La documentación de este nuevo tipo de evento está disponible aquí.

Soft Skills para Devs y EmpleosTI anuncian Hireline Spaces

Desde que inicié el proyecto de Soft Skills para Devs, mi principal objetivo ha sido traer, a la mesa de discusión, temas de los que casi no se habla en esta industria.

Hace unas semanas, tuve la oportunidad de participar en un Twitter Space organizado por EmpleosTI. Durante la plática, Rafa y yo nos dimos cuenta de que había un gran potencial de colaboración; ambos estábamos conscientes de la importancia hablar de los temas que para muchos son nice to haves. Temas como el desarrollo de carrera, productividad consciente, salud mental y, en general, la importancia de los Soft Skills para poder tener una carrera sostenible.

Nos quedamos con ganas de ponerle más énfasis a estos temas, así que decidimos hacer algo al respecto. Hoy, me complace anunciar Hireline Spaces, una colaboración de Soft Skills para Devs y EmpleosTI.

Cada 2 semanas, los miércoles, podrás escucharnos a través de Twitter Spaces, en la cuenta de @EmpleosTI. Rafael Montúfar, CTO de EmpleosTI, y yo platicaremos con un algún miembro de la industria, a quien le preguntaremos sobre sus perspectivas sobre desarrollo de carrera, soft skills y mucho más.

La primera edición de Hireline Spaces es este miércoles 10 de noviembre a las 17:00 CST, y tendremos de invitado a José Dimas Luján. Platicaremos de su experiencia profesional, tanto académica y de publicaciones, para intentar descifrar sus aprendizajes de lo que hace a un desarrollador exitoso.

¡No te lo pierdas!