Hace ya más de dos años que terminé mi aventura como manager en Openbank, de la que hablé de forma extensa hace tiempo.

Cuando dejé ese puesto me incorporé como desarrollador en Marketgoo. Sé que decir desarrollador tiene poco glamour, y es más guay decir que eres IC (individual contributor) pero si hay diferencias, pocas veo. Puesto de ejecución sin responsabilidad de gestión ni personas a mi cargo*.

Como sea, vengo con una nueva turra. He dividido el post en dos partes. Lo que he sentido y lo que he aprendido.

Vamos a ello.

*Lo sé, hay matices en esta afirmación. Pero es mi blog y generalizo como quiero.

Lo que he sentido

¿Es un paso hacia atrás?

Salarialmente está claro. Y no solo/tanto en mi caso. El nivel de impacto de un desarrollador normalmente es menor y eso implica que los rangos salariales tienden a ser más bajos. Eso, además, está muchísimo más acentuado en España donde el rol de IC escala mal. Hay muy pocas empresas españolas que rompan los techos de sueldo habituales para un dev, por senior que sea. Pocas no es sinónimo de ninguna. Las hay, pero es mucho más complicado conseguirlo en otros tipos con personal al cargo.

Ahora bien, la pregunta me la hice, desde luego. Antes de dar el cambio y tras hacerlo: ¿es realmente un paso atrás?

Pues dependerá y mucho de los objetivos de cada uno, lo que consigue aportar desde -y no solo desde- el código, y cómo te despiertas cada mañana de cara a sacar tu jornada adelante. Para unos liderar un equipo puede ser un paraíso. Habrá algunos que disfruten tutorizando a los más juniors y haciéndoles crecer a nivel profesional y técnico, y quizá otros que prefieran la soledad de un reto técnico mayúsculo. No creo que unos sean mejor que otros, y todos acaban siendo necesarios en un momento u otro. Será un paso hacia atrás o hacia adelante dependiendo de dónde te dirijas.

No descarto ni desmiento volver a otro tipo de puesto. Me quedan 30 años de carrera, igual termino de carpintero o de electricista, ¡a saber!

Te desoxidas rápido

La verdad es que pensaba que iba a tardar más en volver a cogerle el ritmo a ejecutar. Pero no fue así.

Es cierto que solo estuve dos años y medio de manager, pero también que aterricé en un equipo con un stack tecnológico diferente del que estaba acostumbrado y con unas cuantas tecnologías (para mi) nuevas. Y la verdad es que no me costó demasiado volver a ser productivo.

No tengáis miedo de eso.

Tienes el ownership por castigo

Estás acostumbrado a echarte a la espalda el peso de los proyectos y a hacer que las cosas pasen. Siempre intenté que fuese así pero tras un tiempo en gestión esto estaba mucho más presente.

Entender la importancia de agarrar las cosas y hacerlas tuyas. Ser el responsable.

Como IC hacerlas tuyas implica resolver mucho más de lo que resolvías como manager (donde parte del rol implica perseguir a la gente) así que es un poco más fácil. Depende de ti pero, al menos, solo de ti*.

*Sí, esto es otra simplificación. Por favor, no me toméis al pie de la letra.

Se puede liderar desde el código

Hay jefes y hay líderes. Esto lo sabemos y hay libros enteros hablando de esto. Pero al igual que estás acostumbrado a tener ese ownership, estás acostumbrado a liderar equipos. Y se puede liderar desde el código. Apoyando a compañeros, siendo una referencia, siendo el que da la cara cuando hace falta, etc. Aportando no solo a tu parcela codificada.

Creo que pasar por esa etapa más de gestión me dio confianza para poder abordar este liderazgo cuando hace falta sin ningún problema ni trauma. Que siempre hubo un poco, pero ahora, pues un poco más.

Cosas que he aprendido

O más que cosas que he aprendido, quizá mejor se puede interpretar como cosas que he aprendido que son clave. Es decir, darle a estas habilidades, características o como queráis llamarlo el valor que se merecen; porque son la diferencia entre ser un desarrollador normalito o ser uno de un valor realmente alto.

Y creo, además, que en una etapa como la que nos encontramos donde la IA va a paliar parte de las carencias técnicas que puede tener un desarrollador (es una ayuda bestial en ese respecto) son si cabe más importantes.

Comunicar de forma efectiva, clara, temprana y proactiva.

Sobre todo en crisis y sobre todo hacia arriba. Pero no solo.

No diré que la comunicación es muy importante que hay que hacerlo bien, y mucho, etc. Eso es evidente. En todos los puestos. Hasta si haces muebles o vendes pescado. Solo suma. Pero no me refiero a eso.

Hablo de la respuesta ante el problema. Cuando todo el mundo corre en círculos, la mierda ha llegado al ventilador y el equipo de negocio está preguntando qué pasa porque los clientes están quejándose o porque algo está roto.

Ahí he notado más las tablas en gestión.

Mantener la calma, informar de forma clara, sencilla y concisa cuál es el problema, qué se está haciendo para solucionarlo, cuándo va a estar solucionado y qué vamos a hacer para que no se vuelva a repetir. Vamos, responder a lo que preguntaba a mi equipo de desarrollo cuando teníamos el marrón encima de la mesa pero yo no era el encargado de arreglarlo.

Y reitero los adjetivos que no están puestos al azar: clara, sencilla y concisa. Sin rodeos, entendibles para cualquiera y sin dar lugar a equívocos.

Por otro lado, fuera del drama de la crisis también es importante comunicar de forma temprana y de forma proactiva. Esto quiere decir que es clave levantar la mano cuando creas que dispones de información relevante para los demás y hacerlo lo antes posible. Si no llegas a una entrega o si vas a acabar mucho antes de tiempo (y, por tanto, necesitarás otra tarea), si ves un bug que hay que resolver que nadie ha reportado, o si localizas una posible amenaza que pueda hacer que todo salte por los aires.

Localizar el origen del dolor

Relacionado con el punto anterior, en situaciónes de crisis o errores, saber qué duele y por qué es fundamental.

Que no se vea una imagen correctamente en la pantalla puede ser un error banal y sencillo de corregir, aparentemente poco importante. ¿Por qué crea tanto ruido? ¿Por qué está la gente tan nerviosa? Buscar el motivo del dolor para paliarlo es vital desde el punto de vista del desarrollador porque aporta tranquilidad.

Si conoces por qué eso aparentemente insignificante está creando ruido en otras capas de la empresa puedes buscar una solución alternativa para apagar el ruido, y después atajar el problema con calma.

Primero calmar el dolor, después sanar la herida.

Visibilidad proactiva

Sé que digo mucho esta palabra pero es diferencial llevar la iniciativa si quieres considerarte senior. Pocas cosas me creaban más estrés (y mala leche, dicho sea de paso) que la falta de visibilidad para con mis desarrolladores. ¿Han avanzado? ¿Cómo va esta tarea? ¿Llegarán a tiempo a la entrega? ¿Con qué estará este ahora mismo? ¿Tendrá bloqueos? ¿POR QUÉ DIABLOS NO SÉ NADA? (perdón, lo recuerdo y me exalto).

Y no, esas preguntas no tienen que responderse obligatoriamente de forma síncrona en una daily. A la que, entre tú y yo muchas veces no se le hace ni p caso. Vale con actualizar las herramientas de seguimiento (Jiras, Trellos, etc.) e informar cuando haya novedades o bloqueos.

Cuesta poco, haces descansar mucho.

La historia esa de la mujer del César

La verdad es que lo de “No solo hay que ser la mujer del César, sino también parecerlo” ha envejecido un poco mal. Pero bueno, tiene 2000 años, ya está bien que envejezca. Ruego no me crucifiquéis por usarla, es que no he encontrado ninguna otra comparación con la misma fuerza.

No solo hace falta hacer las cosas bien. También se tiene que saber que las haces. Hay que poner en valor las cosas que hacemos. ¡Vaya! que una vez más hay que comunicar. Pero es que es importante. Traté con más de un desarrollador que hacía mucho más de lo que parecía… y también los había al revés. Adivinad a cuál se tenía en mejor estima.

No se trata de tirarse flores ni de engañar a nadie. Pero ponte las medallas que te merezcas, que no pasa nada. Pon en valor la importancia de corregir ese bug de seguridad que a negocio igual de primeras le importa poco: explica las consecuencias de no haberlo hecho. De hecho, no tengas problemas en comentar también lo que no has podido hacer. La honestidad siempre es bien.

• He estado toda la mañana intentando resolver esto pero no he sido capaz porque patatas
• Realizando esta tarea me di cuenta de que teníamos un caso de uso por cubrir y he aprovechado para cubrirlo ya que estaba tocando esa parte de la aplicación
• He actualizado todas las librerías de front y es importante por XXX y YYYY
• …

Claro, para hacer todas esas cosas de más, te tienes que preocupar por el proyecto, hacerlo tuyo, darle amor… Pero de eso ya hemos hablado antes.

Que tu día a día no sea un infierno

Y eso es todo. ¿Tienes pensado volver a ser IC? ¿Tomar caminos de gestión? O, quizá, ¿pasar completamente de ellos de momento?

No hay caminos mejores o peores. Mi consejo sincero, y llevo en esto mś de 15 años y he pasado por bastantes sitios y puestos… Es que estés donde estés el día que tu día a día no sea ilusionante. Vete mirando Linkedin o hablando con Manfred.