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.
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.
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.
En Amazon, 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 mundo del desarrollo de software libre ha estado en las noticias últimamente. Desde la vulnerabilidad de Log4j que mandó a todo mundo a actualizar sus servidores, hasta las controversias por grandes compañías construyendo servicios y productos encima de productos de código libre sin honrar la naturaleza del mismo.
Con iniciativas como GitHub Sponsors, las compañías que dependen del software libre buscan incentivar que las personas que mantienen los proyectos sigan trabajando en ellos. Sin embargo, el panorama no se ve tan alentador para aquellos que tienen que lidiar con las implicaciones de mantener proyectos que son usados por millones de personas.
Esto es deprimente, por decir lo menos. Es deprimente porque no veo otra alternativa más qu dejar de escribir software. Después de todo, no puedo encontrar trabajo, no puedo hacer dinero trabajando en software libre, y el código que escriba puede terminar dañando a más personas de las que ayuda.
Mi interpretación del problema es que el propósito del software open source se ha pervertido a lo largo de los años. Inicialmente, la idea era poder colaborar para crear mejores soluciones. Durante un tiempo, cuando se construían las bases de la industria de la tecnología, eso era una realidad. Hoy en día, el que una solución sea de código abierto se utiliza como excusa para no dedicar tiempo a entender sus fundamentos.
¿Cuándo fue la última vez que realmente te dedicaste a entender la solución que un paquete de NPM implementaba? No importa, porque es de código abierto, y seguramente alguien más encontrará lo que está mal en ella — si es que hay algo mal, en primer lugar.
La comunidad de código abierto aporta muchísimo beneficio a la industria. ¿Cómo se logrará hacer que reconozca estos beneficios y corresponda de igual manera a la comunidad que habilitó su creación en primera instancia?
Aquí una idea de cómo puedes comenzar a influenciar un cambio positivo: si el producto en el que trabajas depende de una pieza en particular de código open source, pídele a los líderes de tu organización que asignen una parte del presupuesto para contribuir económicamente al mantenimiento de ese proyecto. Si la persona encargada no tiene habilitado un perfil de GitHub Sponsor, estoy seguro de que estará más que contenta de recibir un wire transfer mensualmente con la contribución de tu empresa.
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.
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.
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.
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.
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.
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.
“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.
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?
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.
Un Engineering Manager en una posición no tan ideal me envió la siguiente pregunta:
¿Cómo lidias con la banda que no comunica (ausentes en chat, no confirman llamadas, etc) PERO que sí da resultados?
El que uses la palabra “lidiar” me dice que, muy dentro de ti, sabes que no te está dando buenos resultados, y es momento de hacer algo al respecto.
Desde el punto de vista de un Engineering Manager, si alguien es un buen ejecutor, pero tienes que estar invirtiendo tiempo y recursos para asegurarte de que lo está haciendo de una manera que no afecte negativamente al resto del equipo, esa persona no funciona. Aunque esa persona cumpla con sus responsabilidades a nivel técnico.
Tu rol es establecer procesos y generar estrategias para que se cumplan las expectativas del equipo.
Como Engineering Manager, una de tus preocupaciones principales debería de ser evitar cuellos de botella y silos de información. Tener a un miembro del equipo que no comunica eficientemente, ni trabaja en equipo, es la antítesis lo anterior. Sobre todo si esta persona sabe que sus habilidades técnicas de alguna manera justifican sus deficiencias en comunicación y colaboración. Esta es una receta para que eventualmente tengas a alguien que sabe mucho del proyecto y del negocio, que sea una carga negativa para el equipo, y que no podrás correr porque con él se iría todo el conocimiento de los proyectos en los que trabajó. Bus factor al millón.
Un estándar de calidad es lo que se tolera, no lo que se promueve. Puedes invertir tiempo y esfuerzo en promover buenas prácticas de comunicación y trabajo en equipo, pero mientras no tomes decisiones administrativas en pro de defender los procesos y estrategias que promueves, estarás trabajando en vano.
El mejor momento para remover a ese elemento del equipo era antes de que te pusiera en esta situación.
El segundo mejor momento es ahora, que estás buscando hacer malabares por alguien que no te está haciendo, ni a ti ni a tu equipo, el trabajo más sencillo.
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.
StackOverflow compartió en su blog los resultados de una encuesta que aplicaron a 500 desarrolladores de software. La idea era encontrar los factores que actualmente están jugando un papel importante en el mercado laboral de desarrolladores.
Las respuestas podrían parecer obvias para cualquier persona que trabaje en el medio. Sin embargo, creo que es buena idea analizarlas un poco más allá simplemente compartir el número de personas que prefieren tal cosa en lugar de otra.
Los resultados
Para buscar nuevas oportunidades, 65 % lo hacen por un incremento de salario. Esto no debería de sorprenderle a nadie. En los últimos meses, sobre todo, se ha visto un incremento sustancial en la inflación de los salarios para personas que trabajamos en software. Hay varios factores que podrían estar influyendo en esto: la pandemia, la devaluación de la moneda, que cada vez hay empresas con más recursos para “quemar”.
Al momento de considerar empresas para unirse, el 56 % quieren que la empresa le ponga atención al developer experience. Este dato sí me sorprendió, pero tiene sentido. Conforme los retos se van haciendo más complejos y los equipos se van haciendo más distribuidos, lo que quieren los desarrolladores es que las empresas realmente inviertan en la infraestructura para soportar sus esfuerzos.
Hace unos años, la discusión sobre el developer experience era relativamente sencilla, porque había un alto grado de probabilidades de que los problemas se mitigaran simplemente eligiendo el cliente de git adecuado para el equipo. Hoy en día, los desarrolladores esperan que haya una infraestructura para colaborar, empujar código a producción, resolver conflictos, recabar datos, y más. Y no solo eso, sino que esperan que haya un equipo encargado de soportar dicha infraestructura.
Aquellas empresas que reparen en invertir en mejorar y facilitar el trabajo de los desarrolladores la van a tener muy difícil contratando y reteniendo talento.
Lo que hace que una empresa sea poco atractiva tiene que ver con el nivel de micromanagement de la organización. Me sorprendió conocer que hay algunas organizaciones prohíben a sus desarrolladores usar Stack Overflow. Fuera de eso, la mayoría de los desarrolladores están de acuerdo en que lo que quieren es que la cultura de la empresa no esté basada en el control y la desconfianza.
También me sorprendió la tercera razón más popular que hace que una empresa no sea atractiva para un desarrollador: que no tengan los recursos para darle confianza en su trabajo. ¿A qué se refiere esto? Algunas ideas:
Que no haya un proceso de retroalimentación establecido
Opacidad en el proceso de toma de decisiones
Una estructura organizacional demasiado plana
Y, retomando el punto anterior, indiferencia por el developer experience
La reputación de la empresa es primordial para el descubrimiento inicial de oportunidades. De acuerdo con los resultados de la encuesta, 47 % de los desarrolladores toman más en serio las recomendaciones de oportunidades que vienen de su red personal (familiares y amigos) que cualquier otro medio. Hace poco escribí sobre este fenómeno:
Es mucho más importante, para tu desarrollo profesional y tu superación personal, estar con las personas correctas, que en la compañía con el nombre más conocido.
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.
Si eres uno de los millones de usuarios de Spotify, seguro compartiste tu Wrapped la semana pasada. Si no fue en tus redes sociales, por lo menos lo comparaste con los de tus amigos y conocidos que sí lo hicieron.
Desarrollar productos que no solamente sean útiles para tus usuarios, sino que también los deleiten, no es tarea fácil. Ni es barato. Para Wrapped, muchísimos equipos dentro de Spotify comienzan a trabajar con meses de antelación. Marketing, datos, ingeniería, diseño — todos trabajando en conjunto para poder ofrecer, al fin de año, lo que muchas personas de la industria considerarían como algo sin valor real: una “simple visualización” de datos.
Las compañías que conocen la importancia de agregar valor a sus usuarios, y crean productos que son mucho más que simples utilidades, son las que terminan ganando. Y no solamente en números brutos, sino en la percepción del público y en el lugar que ocupan en nuestras cabezas.
Ah yes, Spotify Wrapped day, or as I like to think of it “punishment for being an Apple Music user while everyone else gets to have fun with their music recaps” day.
Una empresa que no reconociera la importancia de ofrecer algo más que una simple utilidad, difícilmente invertiría en una iniciativa como Wrapped. Afortunadamente, Spotify no es esa empresa, y cada año cimientan aún más su valía en la mente de sus usuarios, dejándolos ser parte de una conversación global. Además, virtualmente gratis, reciben una campaña de marketing de primera calidad impulsada por sus mismos usuarios.
Y es así como, un diciembre más, contemplo seriamente la idea de dejar de usar Apple Music para volver a Spotify.
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.
