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

  • Un demo te ahorra o te compra problemas

    Para un desarrollador de software es sencillo comprender por qué un proyecto se puede complicar. Entendemos las implicaciones y complejidades de desarrollar soluciones.

    En una empresa tradicional, para bien o para mal, las personas que terminan tomando decisiones no siempre tienen el mismo nivel de entendimiento.

    Tener el hábito de hacer demostraciones, demos, de tu trabajo ayuda a achicar esta brecha de entendimiento.

    Un demo tiene el potencial de comprarte o ahorrarte problemas. Si del demo salen con más preguntas que respuestas, te compraste problemas. Si salen inspirados, con más ideas, te ahorraste problemas.

    Es por eso que es importante que tomes los demos con seriedad. Porque a final de cuentas, desde un estricto punto de vista de negocio: si algo no funciona no sirve, y si algo no sirve, ¿para qué lo quiero? Un buen demo es tu oportunidad de evitar que alguien con poder de decisión a nivel negocio se haga esta pregunta.

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

  • El nombre que le pones a las cosas sí importa

    “En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

    La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

    La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

    Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

    Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

    El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

    Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

    Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

    Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?

  • Por qué hacer over-engineering

    Luis Lira, escribiendo en su nuevo blog:

    Over Engineering es cuando nos gusta complicarnos la vida, algo como ser masoquistas, pero programando. Cuando estamos creando un proyecto y queremos sufrir por voluntad propia porque para un problema sencillo usamos una solución compleja. De hecho, este sitio es una muestra de eso.

    En mi pueblo hay un dicho: salió más caro el caldo que las albóndigas.

    Continúa:

    Este Portafolio/Blog que hice aproximadamente en 10 días — aunque aún le falten cosas — pude haberlo hecho en unas horas y solo con unos cuantos clics, comandos en una consola o simplemente pagando una suscripción en algún sitio que me diera todo esto listo.

    En vez de irse por la solución “integrada”, Luis decidió experimentar ensamblando su blog manualmente.

    Se dice que algo está over-engineered (o diseñado de más) cuando la solución tiene cuesta más (tiempo, recursos, esfuerzo) que el problema mismo. Pero existe una distinción importante que me gustaría recalcar: construir algo desde cero cuando existe ya un paquete que resuelve el problema no es hacer over-engineering.

    El término over-engineering es inherentemente negativo. Expresa que el diseño de tu solución está over, o de más. Es inútil, extra. Te lo pudiste haber ahorrado.

    Lo que está haciendo Luis es algo sumamente positivo: tomar un problema que pudo haber resuelto con unos cuantos clics, desmenuzarlo y explorar creando una solución que se adapte exactamente a lo que él quería. Eso no es over-engineering, eso es engineering. 

    A través de este ejercicio, Luis no solamente está aprendiendo y explorando nuevas herramientas de desarrollo, sino que está razonando un dominio de problema al que no estaba expuesto anteriormente. Este razonamiento seguramente le ayudará a comprender mucho mejor 1) la complejidad real del problema, y 2) la toma de decisiones que juegan un papel importante en hacer que WordPress, Ghost, Tumblr, etc., sean exitosos.

    Eso es verdadero aprendizaje.

    La cultura de desarrollo de software actual empuja a las personas a creer que entender las premisas básicas de los problemas que resuelven es algo negativo. ¿Para qué invertir tiempo en eso, si ya hay un paquete de JavaScript que lo resuelve? Sin embargo, es refrescante ver que aún hay personas que intentan comprender el problema antes de obviar el entendimiento del mismo y correr a implementar soluciones sin fundamentos.

Ayudo a personas que trabajan con software a mejorar sus carreras profesionales.

Los miembros tienen acceso a Pathways, pueden comentar en las publicaciones, interactuar con la comunidad, y muchos otros beneficios. Conoce más.

Agrégame a tu lector RSS, o suscríbete a mi newsletter para recibir los nuevos artículos que publique.