Archivos de la categoría Organizaciones

Inteligencia Artificial reemplazará 7,800 empleos en IBM; pausan contrataciones

Reuters reporta que IBM busca reemplazar miles de empleos con inteligencia artificial:

La contratación específicamente en funciones de oficina, como recursos humanos, se suspenderá o disminuirá, dijo Krishna, agregando que el 30% de los roles que no interactúan con clientes podrían ser reemplazados por inteligencia artificial y automatizaciones en cinco años.

Definitivamente, estamos entrando en una nueva era del desarrollo profesional.

El 2 de julio del 2021 escribí en este blog:

Lo que uno como desarrollador de software está buscando constantemente es la automatización de tareas mecánicas y manuales. La ironía es que, en sí, programar también es una tarea mecánica y manual. Y como tal, eventualmente también será automatizada.

En aquel entonces, hablaba sobre GitHub Copilot y sus implicaciones en la industria del desarrollo de software. Continúo:

La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales.

Esto ya está sucediendo. Puede ser que los empleos de desarrollador de software aún no se vean directamente afectados por la automatización, pero el equivalente ya está sucediendo en otras industrias.

Trabajar en tecnología en tiempos de recesión: ¿deberías preocuparte?

Si trabajas en la industria de la tecnología, es posible que hayas notado que muchas empresas están haciendo reducciones de personal. Pero ¿deberías preocuparte por tu trabajo en tiempos de recesión?

En la industria de la tecnología, las reducciones de personal no solo ocurren ante o durante una recesión. Las empresas pueden hacerlas en cualquier momento, incluso en tiempos de crecimiento económico. Y aunque es común que las empresas sigan las tendencias de la industria, muchas de las que están haciendo reducciones de personal son aquellas que contrataron de manera indiscriminada durante la pandemia.

En lugar de preocuparte por una posible recesión, es mejor centrarse en tomar oportunidades cuando se presentan. Si una buena oportunidad llega a tu puerta, no debes preocuparte por el futuro. Nadie puede predecir con certeza lo que va a pasar, y es mejor trabajar con lo que se tiene.

Pero, ¿qué hay de tu trabajo actual? Si bien no puedes predecir si tu empresa hará reducciones de personal en el futuro, puedes tomar medidas para proteger tu carrera en la industria de la tecnología. Asegúrate de estar al tanto de las últimas tendencias y tecnologías, y busca maneras de mejorar tus habilidades y conocimientos.

Busca oportunidades, mejora tus habilidades y conocimientos. Enfócate en ser alguien que agrega valor. Todo lo demás es circunstancial.

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?

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

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.

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.

Cómo es trabajar como desarrollador en Amazon

Ben Adam, compartió en su blog su experiencia entrevistando y trabajando como Sr. Design Technologist en Amazon. La historia que comparte Ben está interesante, tomando en cuenta que solamente duró 10 meses en la organización.

Aquí te comparto algunas de los aspectos de su historia que más me llamaron la atención.

Amazon funciona como un conglomerado de mini-empresas

Cada una con sus propias metas, presupuestos, organigrama y formas de trabajar. La manera en como se coordinan es más similar a una empresa contratando los servicios de otra, que un equipo trabajando para un bien común. Por ejemplo, si un equipo necesita ayuda de otro para cumplir uno de sus objetivos, el primero puede financiar el incremento de personal del otro para hacerlo.

La normalización de procesos y estrategias únicamente existe únicamente dentro de estas mini-empresas

El puesto de Ben, como Sr. Design Technologist, es el puente entre los equipos de diseño y de desarrollo. Naturalmente, una de las primeras cosas que hizo fue intentar entender cómo funcionaba el sistema de diseño para las herramientas internas. Resulta que no había uno, sino 56.

En una empresa del tamaño de Amazon, donde solamente en el grupo en el que trabajó Ben eran 29 mil empleados, es imposible intentar planchar todo. Las necesidades de cada elemento de la organización son diferentes, y por eso es necesaria tanta granularidad en cómo se hacen las cosas.

Creo que se necesita una personalidad muy particular para poder funcionar en un ambiente así.

Muchos procesos siguen siendo manuales

Por más que nos quejemos de Excel, la realidad es que la mayoría de los negocios existen gracias una o más hojas de cálculo compartidas por correo electrónico. Y Amazon no es la excepción.

Como desarrolladores, por más que queramos automatizar absolutamente todo, tenemos que hacer las pases con la idea de que nuestros usuarios lo que quieren es resolver un problema — no usar tu software. Y si tu cliente puede resolver su problema con Excel (o cualquier herramienta que ya conozca, domine y tenga a su disposición), créelo: lo va a hacer.

Tu trabajo es entender la necesidad de la persona y hacer lo sensato para resolverla. Algunas veces tu solución tomará la forma de una solución a la medida, que diseñas y construyes desde cero. Algunas otras, agregarás valor simplemente al sentarte con tu cliente y explicarle cómo podría hacer su trabajo más fácil si organiza su información de cierta manera en la hoja de cálculo.

Mientras más rápido asimiles esto — que desarrollar software no siempre es escribir código — mejor.

La documentación es esencial

Jeff Bezos, famosamente, prohibió las presentaciones de PowerPoint en Amazon. En su lugar, todas las decisiones sustanciales se hacen acompañadas de documentos cuidadosamente redactados para un propósito en particular. Y sí, el proceso de redactar un documento puede ser un poco más tardado, pero al final de todo, termina siendo tiempo empleado de una manera mucho más efectiva.

Algunos de los documentos con los que se toman decisiones en Amazon:

  • PRFAQ – Press Release and Frequently asked questions: para presentar una nueva idea o inversión de tiempo o recursos. Empieza por cómo terminarías vendiendo esto a los stakeholders e intenta adelantarte a las preguntas que saldrán como parte de este anuncio.
  • OP1 – El plan a un año del equipo: qué van a hacer y cómo lo van a lograr. Este documento es un poco más completo, y entra en detalles estratégicos de cómo lograr los objetivos.
  • BRD – Business Requirement Document: qué es lo que se necesita hacer desde el punto de vista de negocio. Lista las cosas que deben suceder, a detalle, para lograr los objetivos.
  • Design Document – Documento de ingeniería donde se listan los detalles técnicos de la implementación y alternativas consideradas. 
  • 1 Pager – resumen ejecutivo con todos los detalles relevantes para poner a cualquier persona al día con la iniciativa.

Como he dicho antes, escribir documentación no tiene más que beneficios para la organización y los proyectos. Y si algún día quieres trabajar en Amazon, aprender a escribir buena documentación es una de las primeras cosas que tienes que aprender.

Trabajar en una compañía grande no es para todos

Finalmente, Ben, después de 10 meses de trabajar en una empresa a la que muchos aspiran entrar, se dio cuenta de que no era un buen lugar para él. Como dije anteriormente, este tipo de empresas requiere que tengas aspectos de tu personalidad muy particulares. Una excelente adaptabilidad al cambio, comodidad con la incertidumbre y al caos, etc.

Por mejor desarrollador que seas, si no estás cómoda con tu ambiente de trabajo será bastante difícil que lo puedas disfrutar y crecer sin sacrificar tu salud mental.

 

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.

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.

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

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

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

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

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

Incentivos

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

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

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

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

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

Eres lo que haces

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

Analiza su historial de liderazgo.

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

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

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

Renuncia

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

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

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

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

Renuncia.

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

SQLite no usa Git: ¿por qué?

Interesante página en el sitio de SQLite, explicando por qué no usan Git para administrar el código del proyecto:

SQLite no usa el sistema de control de versiones Git. En su lugar, usa Fossil, que es un sistema de control de versiones específicamente diseñado y escrito para soportar SQLite.

Personalmente no sabía de la existencia de Fossil, pero su propuesta de valor se ve bastante atractiva. Especialmente si tomamos en cuenta las razones que motivaron a que los administradores del código de SQLite decidieran que Git no era una opción para ellos:

  1. Git no ofrece visibilidad granular del contexto en el cual se hizo alguna contribución
  2. Hace demasiado difícil encontrar los sucesores de algún commit en particular
  3. El modelo mental de Git es innecesariamente complejo
  4. Git no lleva el recuento histórico de los nombres de las ramas
  5. Requiere soporte administrativo
  6. Es una experiencia de usuario pobre

Observa cómo ninguna de las razones que SQLite expone para no usar Git tienen que ver con la validez de la tecnología, sino con el impacto que esta tiene en las personas que tendrán que interactuar con ella.

Tip: Recuerda que tu software existe para resolverle un problema a tu usuario. Independientemente de la excelencia técnica de tu solución, si esta no le ayuda a tu usuario a resolver su problema, no estás cumpliendo tu cometido.

Tienes HiPPO y no sabías

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

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

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

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

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

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

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

Para desarrollar y ejercer tu Sentido de Agencia, recuerda:

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

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

Mejorando la visibilidad de información en equipos remotos

Estás teniendo una acalorada discusión con tus compañeros de trabajo acerca de cómo resolver ese problema con el que llevan atorados un par de semanas. Todos están trabajando de manera remota, y están teniendo la discusión en el canal de chat de la empresa. Han intentado varias propuestas de diferentes miembros del equipo, pero ninguna parece terminar de lleno con el problema.

De repente a una de tus compañeras le llega a la cabeza la solución ideal que sí va a funcionar. Rápidamente la redacta y la publica en el mismo hilo de conversación que han estado usando para coordinar los esfuerzos de resolución de la situación. “Si quieren lo platicamos en una llamada”, escribes. Presionas Enter en tu teclado, y unos minutos después todo el equipo está platicando cara a cara en un Google Meet repasando el plan de acción.

Todos aceptan, entienden su rol, y comienzan a trabajar. Por fin encontraron la solución que les permitirá continuar con la siguiente fase de su proyecto, y la implementarán en tiempo récord.

Todo parece estar tranquilo. Un éxito seguro, un problema menos, y todo gracias a la excelente colaboración de los miembros del equipo.

Hasta que tiempo después alguien hace la pregunta: ¿Me pueden explicar por qué se resolvió esto así? Pero hace 6 meses que la persona que propuso la solución se fue de la organización.

La problemática

El escenario que describo anteriormente sucede más de lo que te imaginas, y no es exclusivo de organizaciones o empresas grandes. Seguramente alguna vez te has preguntado por cómo llegaste a cierta decisión en tu vida personal, o en tu proyecto individual. No es raro.

El cerebro humano está diseñado para generar ideas (y es excelente en ello), no para almacenarlas. El dicho reza que dos cabezas piensan mejor que una, no que dos cabezas recuerdan mejor que una. Reconociendo esto, podemos tomar acciones concretas para no complicarnos la vida a nosotros mismos al momento de que necesitemos recordar cómo fue que llegamos a una decisión.

Una técnica para esto es pensar en las ideas y acuerdos en términos de Flujo y Stock.

Flujo y Stock

Seguramente habrás escuchado en alguna ocasión que cierto producto se encontraba fuera de stock al momento de intentar comprar algo en una tienda. “Nos llega pedido en 15 días,” como es de costumbre.

En el mundo de la economía, los negocios, y la logística existe el término Flujo y Stock, que nos permite pensar de diferentes maneras en las unidades más importantes para un determinado contexto. Al enmarcar la unidad con la que estamos lidiando en el concepto de Flujo y Stock, se vuelve mucho más sencillo determinar cómo deberíamos de manejar dicha unidad.

Una manera más amigable para asimilar el concepto de Flujo y Stock es pensar en que tenemos una tienda de libros. Piensa en cuáles libros pondrías en las vitrinas para atraer clientes. Estarás de acuerdo que la respuesta es que en las vitrinas deberían ir los libros actuales, novedosos o que están en auge, pues son ellos los que atraerán a la tienda a los clientes potenciales que van pasando.

Y entonces, ¿cuáles libros deberías guardar en tu almacén? Los libros clásicos, de conocimiento antiguo; no son tan populares, pero debes tenerlos a la mano de una manera relativamente accesible porque eventualmente va a llegar un cliente a preguntarte por uno de ellos. Es ahí cuando dices “permíteme tantito, déjame ir por él a la bodega”.

De manera concreta:

  • Flujo hace referencia a una transacción que se haga con una unidad de medida durante un periodo de tiempo. Cuántos libros vendes por hora. Estos libros van en la vitrina.
  • Stock hace referencia a una unidad de medida en un marco de tiempo en particular. Cuántos libros tienes disponibles para venderhoy. En tu stock tienes los libros clásicos.

Flujo y Stock del conocimiento

Podemos categorizar cómo administramos nuestros bienes físicos, y determinar si los debemos de guardar en un almacén, o tenerlos en las vitrinas de una tienda. De la misma manera, podemos categorizar el conocimiento y la información que manejamos en el día a día. El concepto de Flujo y Stock, al ser asimilado y transportado al reino del conocimiento, nos permite discernir con mayor claridad cómo deberíamos administrar una idea.

Podremos decidir si un pedazo de información es de flujo (novedosa, popular, y que debería ir en la vitrina), o de stock (de valor histórico, clásica, y que debería ir en el almacén).

La información que determinemos flujo va en las vitrinas de la era digital: aplicaciones de chat, videollamadas, correos electrónicos, o cualquier otro medio de comunicación cuya naturaleza sea efímera. Estos medios de comunicación están hechos para ser consumidos “al pasar”, al igual que un exhibido afuera de una tienda.

Entre las características de los medios de comunicación ideales para transmitir información de flujo se encuentran:

  • se centran en la facilidad de transmitir, no preservar, la información (chats privados, videollamadas por Zoom o Google Meet),
  • usualmente ofrecen una experiencia personalizada para cada usuario (Facebook, Twitter, Instagram, WhatsApp), y
  • generan silos de información dentro de una organización (correo electrónico).

Por el contrario, la información que determinemos stock debería de ir en nuestros repositorios digitales de información: documentos en la nube, notas compartidas, o almacenes de código a los que todos los miembros del equipo tengan acceso. Si contrataras un nuevo vendedor en tu librería, él o ella necesitaría acceso a tu bodega de libros para poder hacer su trabajo. Sucede exactamente igual con el conocimiento.

Entre las características que hacen que un medio sea apto para almacenar información de stock se encuentran:

  • la habilidad de que todos los miembros de la organización estén viendo el mismo contenido al mismo tiempo (carpetas compartidas, como Google Drive o Dropbox),
  • la posibilidad de colaborar simultáneamente en la edición del contenido (Google Docs, Office365, Dropbox Paper)
  • la preservación de un historial de modificaciones, con marca de tiempo y detalle del cambio (Google Docs hace esto también)
  • el contenido es indexable y se pueden realizar búsquedas complejas

También es de vital importancia asegurarse que la información stock debe de contener todo el contexto necesario para ser útil. Para esto, te recomiendo que sigas el PURLÚ (Principio de la URL Única). De nada sirve tener información guardada, si es dificil interpretarla.

¿Cómo saber si una pieza de información es Flujo o stock?

Una definición muy personal para la información que considero como flujo en mi día a día es preguntarme si la idea podría caber en un Tweet. Si la respuesta es sí, entonces comunico la idea a través de un canal apto para información fluctuante.

Ejemplos de información que considero flujo:

  • Notificar al equipo que un proyecto se completó de manera exitosa.
  • Confirmar un dato con alguno de mis compañeros.
  • Pedir o dar una actualización de estatus de una iniciativa.
  • Pedir por referencias sobre algún trabajo previo.
  • Información relacionada con ocio.

Por otra parte, cualquier pieza de información que tenga un valor histórico dentro del contexto en el cual está siendo manejada, debería de ser considerada información de stock.

Notificar que un proyecto se completó de manera exitosa es claramente información de flujo, y podríamos hacer dicho anuncio a través de Slack, Google Chat, o en un correo electrónico sin problema. Sin embargo, el historial y resumen de entrega del proyecto completado es información de stock, y por lo tanto deberíamos de preservarlo en un folder compartido de Google Drive o Dropbox, al cual tienen acceso los miembros del equipo a quienes podría servirles dicha información.

Puedes aplicar esta misma forma lógica en tu día a día para determinar si algo debería ser comunicado como información de flujo, o información de stock. Además, puedes ir un paso más allá y pensar también en organizar los canales de comunicación de tu equipo, algo de lo que también escribí.

Conclusión

Estudiar otras áreas de la vida nos expone a ideas que podemos moldear para resolver problemas que ni siquiera estábamos conscientes que teníamos. En esta ocasión, hemos explorado un concepto de economía, nos hemos quedado con su esencia, y lo adaptamos a un área de interés muy particular: la administración de la información y conocimiento.

Ser eficiente, en esencia, se trata de remover fricciones. Al remover la fricción de recuperar conocimiento e información, estamos elevando nuestras probabilidades de tener éxito en lo que sea que estemos haciendo. Aplicando el concepto de Flujo y Stock en nuestro trabajo y vida personal, dejaremos de tener la incertidumbre naciente de la falta de organización del conocimiento.

Cuidado con el Home Office

Muchas empresas ofrecen la posibilidad de hacer “home office” como un perk para atraer talento, argumentando que podrás trabajar desde tu casa (o donde quieras, según dicen) un par de días a la semana (o indefinidamente, depende de qué tan cool se quieran ver).

Ver “home office” listado como uno de los beneficios que tendrás puede ser muy motivante para buscar esa posición dentro de una organización. Pero cuidado, más que una ventaja, puede ser el inicio de un proceso doloroso en el que creerás que el trabajo remoto es una trampa.


La razón por lo que comento lo anterior es porque, como he dicho en algunos otros posts en esta página, trabajar de forma remota no es tan simple como no ir a la oficina, o tener un un “horario flexible”.

El trabajo remoto requiere buy-in de todos los involucrados para hacer que funcione, y esto no siempre va bien con las personas que toman las decisiones, puesto que uno de los valores fundamentales que se deben de tener para lograr esto es que los que están a cargo confíen plenamente en el equipo que contrataron.

Me da mucha tristeza reportar que, desafortunadamente, lo anterior es algo tan poco común como ponerte de buenas al pegarte en el dedo chiquito del pie con algún mueble a las 3 de la mañana. En industrias convencionales, aún te pagan por hacer horas nalga, no por el valor que aportas a la organización.


En ejemplo práctico, imagina que uno de tus clientes (es decir, no tu empleador de tiempo completo) no está consciente de lo que significa que trabajes de forma remota, como…

  • que la comunicación debe ser asíncrona,
  • que tu trabajo no está atado a un “horario de oficina”,
  • que es mucho más productivo sobre-comunicar en texto (correos, mensajería instantánea) que entrar a “una llamada rápida” a cada rato

¿Cuánto crees que dure la relación laboral en una situación así? Probablemente tu cliente va a comenzar a desesperarse porque no contestas los correos inmediatamente, o porque no te encuentra si te llama a las 8 AM un sábado.

En una relación proveedor-cliente, la realidad es que todo se puede solucionar de forma bastante sencilla, dentro de lo que cabe. Pero cuando eres parte de una organización y existe un desconecte de expectativas de ésta magnitud , las cosas pueden ponerse feas — sobre todo si la organización tiene un departamento de “recursos humanos”… ugh…


Hacer home office significa que las expectativas y requerimientos serán exactamente los mismos que si estuvieras presente en la oficina, con la desventaja de que estarás trabajando en un lugar donde no trabajas usualmente y probablemente con un equipo que probablemente no está consciente de los retos que presenta trabajar de forma remota.

Si estás considerando entrar a trabajar a una empresa donde listan la posibilidad de hacer home office unas cuantas veces al mes, por favor no te confundas y pienses que eso significa que tendrás las mismas libertades (y responsabilidades) que tendrías en un trabajo remoto. Es una receta para el desastre, y seguramente terminarás odiando la idea de trabajar remotamente, cuando en realidad lo que sucedió es que no lo hiciste ni en el momento ni con el equipo adecuado.

Evita las horas nalga: ir a la oficina no es lo mismo que trabajar

Una de las grandes mentiras de los últimos tiempos, me atrevo a decir, es que ir a la oficina es lo mismo que trabajar.

Horas nalga. Así es como se le conoce al tiempo que se desperdicia en cosas no productivas en el espacio del trabajo. Y si bien este concepto no aplica exclusivamente cuando se tiene que ir a trabajar a una oficina (bien podría yo sentarme en mi estudio y no hacer nada productivo), sí es mucho más prevalente en la modalidad de trabajo “normal”, ya que parte del compromiso de trabajar en una oficina, muchas veces, es llegar a las 8 e irte a las 4. Sin importar que durante ese periodo no hayas hecho nada productivo.

Te están pagando por existir en una oficina. Qué hueva.


El trabajo remoto nos permite aprovechar al máximo nuestras rachas de productividad, las cuales difícilmente pueden ser programadas para funcionar exclusivamente durante horas de oficina.

Requiere cooperación de todas las personas involucradas. No puedo simplemente querer dejar de ir a la oficina y dejar de “hacer horas nalga” si la organización no tiene la infraestructura y mentalidad adecuadas.

Se tiene que poner atención a estos detalles y tomar una decisión en caso de que nos demos cuenta de que nuestros valores no están alineados con los de la empresa. Ignorar los signos de fricción solamente va a llevar a frustración y potencialmente vamos a terminar con un mal sabor de boca, o peor, quemando puentes.


Como administrador de un negocio o empresa, me estaría preguntando si realmente vale la pena seguir pagando por el espacio si me doy cuenta que la mayoría, o gran parte, de mi equipo de trabajo, viene a la oficina porque es requisito de la empresa, no porque realmente necesiten estar físicamente dentro del edificio.

También como empleador es muy importante ver a los miembros de mi equipo de trabajo como personas, no como “recursos” (estoy en contra de que haya un departamento llamado “recursos humanos”). Cada persona con la que colaboro tiene objetivos, ideas, y una individualidad que necesita ser respetada.

Con esto, debo de darles la confianza necesaria para hacer su trabajo de la mejor forma: por esto los contraté, no porque quiero que estén sentados en la oficina durante 8 horas diarias porque sí.