Construyendo Seniority en TI

¿Te consideras Senior? ¿Lo eres en verdad? Antes de venderte como Senior, constrúyete y conviértete en Senior.

 

🦕 "Doce años" puede ser fácil de decir. Pero sin duda es un tiempo que implica bastante esfuerzo, evolución, crecimiento y retos. 🦖

Este artículo va dedicado con INMENSO cariño a toda la Tribu de Podemos Progresar, los que fueron desde un inicio, los que lo fueron en su momento, los que siguen siendo y son, y los que serán 🌱

OJO

Aunque parece que este artículo está enfocado en un perfil específico de Tecnología, las lecciones pueden servir a cualquier ajeno que les encuentre utilidad. Porque lo humanamente valioso en ser un profesional es ubicuo al área y los proyectos. Ojalá así sea.

En doce años:

• un manzano apenas comienza a dar frutos
• los amados caninos ya se consideran viejitos
• a sus doce años, Pearl Jam, mi banda favorita, visitó México por primera vez, en el Palacio de los Deportes (yo estuve ahí ;)
• se prepara la llegada a la mayoría de edad en la comunidad judía

Pero sobre todo, en doce años se aprende MUCHÍSIMO. Por eso, y por cada año que he pasado aquí, dejo una listita brevemente descrita de puntos que considero esenciales para crecer en esto de la creación y operación de las Tecnologías de la Información:

• Especializarse, aunque no del todo
• Amplitud vs Profundidad
• Soft-Skills
• Aprendizaje
• ... y Enseñanza
• Primero Tus Usuarios
• Liderazgo, volverse manager vs volverse staff
• Reconstrúyete
• DevOps
• Crea Soluciones, no software
• Antifragilidad: no robusto ni resiliente
• Ágil significa flexible, no veloz

Especializarse, aunque no del todo

Se suele decir que para lograr el éxito en cualquier área, la mejor estrategia es volverse un Especialista. Porque aquel que pretende dominar todo, termina no abarcando nada. Y aunque no estoy del todo de acuerdo, concuerdo que en TI hay tantas áreas y vertientes hacia dónde dirigirse, que sería difícil ir por varios caminos a la vez. Por lo menos elige UN camino, y si al tiempo te gusta y te trae satisfacción, continúa. Pero sin olvidar el siguiente punto.

Amplitud vs Profundidad

Si no estoy de acuerdo con el tema de especializarse para tener éxito ni con el de que si pretendes dominar todo no abarcas nada, es por esto. En realidad, a lo largo del tiempo, te podrás dar cuenta que eres especialista en VARIAS (no sólo una) áreas, pero que conocer de todo te dota de armas que sobre todo te dan visión: del bosque y no solamente de los árboles. Volverse experto implica también involucrarse con otras áreas que conectan con tus fuertes. Recuerda, nunca vas a poder abarcarlo todo, pero tendrás más skills y más y mejores armas.

Soft-Skills

Largo y ancho se ha debatido sobre que los ingenieros estamos hechos para ser anti-sociales, para trabajar con máquinas y pantallitas negras. Sin embargo no es así. Ni a la hora de tirar código lo haces sólo (a menos que tengas un proyectito para ti nada más), siempre formas parte de equipos colaborativos que construyen Productos Tecnológicos. Ni a la hora de que lo que creaste y sea usado te puedes (ni debes) hacer a un lado: aunque algunos puedan diferir, la verdad es que al final programar es una labor eminentemente social.

Aprendizaje

Si crees que basta con lo que aprendiste en la escuela para obtener tu título, o con lo que tuviste que aprender para colaborar en ese proyecto que tanto te costó es suficiente, vas por mal camino. En pocos años saldrá la nueva tecnología non-plus-ultra que cambiará (de nuevo) los paradigmas y esquemas y arquitecturas y lenguajes con los que trabajas. Esto es la selva, y sólo sobrevives si eres apto. ¿Lo eres?

... y Enseñanza

Jamás un "senior" lo será realmente si no aboca esfuerzos a mentorear a otros, a guiarlos, a enseñarle las piedras con las que ya se tropezó. Guiar a otros al crecimiento no sólo es un DEBER con las generaciones que te suceden, es también una forma de crecer y aprender más, y de realmente obtener el nivel que se necesita para considerarte Senior. Recuerda: el que enseña aprende dos veces.

Primero Tus Usuarios

Si programar es una labor social, esto tiene un corolario mucho más importante que el constatar que siempre trabajamos en equipo. Al final, construimos software PARA que ALGUIEN lo USE. O como diría un viejo cuestionamiento filosófico: ¿Hace ruido un árbol al caer si nadie está ahí para escucharlo? Esta pregunta, que sobre todo a los típicos computines les hace ruido en sus mentes racionales y científicas no tiene otro propósito que cuestionarse el SENTIDO de las COSAS. Evidentemente un árbol al caer produce vibraciones en el aire que se pueden identificar científicamente como sonido. Sin embargo, el ruido es sonido que es escuchado y por tanto intepretado por ALGUIEN.

En nuestro caso, lo que construimos, ¿Sirve si no hay nadie ahí para USARLO? Cuestionarse el sentido de las cosas que hacemos debería ser el primer paso al elegir hacerlo. Podemos responder que programamos para trabajar y ganar dinero, y así viajar, asistir a conciertos y disfrutar del fruto del esfuerzo. Evidentemente sí. Pero sobre todo producimos VALOR para alguien, y ese VALOR no sirve, o se degrada, si no consideramos a quién lo consumirá. Y por mucho que nos aguante entregándole valor degradado, siempre podrá elegir cambiarnos, y nos quedamos sin entrada y sin viajes y sin disfrute. Y me dirás: "¡El mercado es amplio! ¡Ya habrá lugar para mi!" Simple y llanamente: un verdadero Senior no va por la vida usando esto como su estrategia profesional.

Liderazgo, volverse manager vs volverse staff

Cuando empecé en esto de desarrollar tecnología, y no voy a mentir, cuando empecé a trabajar para Podemos Progresar, en mi inexperiencia pensaba que la aspiración final de un Dev era terminar convirtiéndose en manager de otros Devs. Esto no me ilusionaba ni tantito. Reconozco el papel fundamental de los managers, pero no me considero uno de ellos. De hecho he tenido un poquito de experiencia siéndolo, y no diré que lo hago pésimo, sólo que no me encanta y quizá eso refleja un poco algunos resultados.

En fin, que con el paso del tiempo aprendí distintos paths que pueden seguirse para el crecimiento. La pregunta esencial es esta: Ya soy Senior, o aspiro a ser Senior ¿qué sigue? Ser manager es una de las respuestas. Pero hay otras: ser líder técnico; abocarse a la creación de Productos Tecnológicos; volverse arquitecto; desarrollar a niveles más allá del software (infraestructura por ejemplo); y uno que recién descubrí: volverse Staff Engineer, una especie de Senior potenciado con características de algunos de los anteriores, y que sirve a varios equipos de desarrollo a la vez. En el libro Staff Engineer de Will Larson (famoso por ser autor también de An Elegant Puzzle, sobre el path del Engineer Manager), se retrata el perfil del Staff Engineer como alguien con experiencia técnica y de negocio, que suele durar bastante tiempo en una misma empresa... (¿me estás diciendo algo a mi, Will?)

Reconstrúyete

Hace rato mientras pensaba en este artículo tuve una muy cálida llamada con Fernando, el CEO de Podemos Progresar. Y mencionó algo que no había pensado y le dio la clave a este punto. Si algo ha pasado con mi perfil en doce años es que, así como Podemos ha sufrido evoluciones y cambios, unos más radicales que otros, lo mismo ha pasado con mi perfil. Heme aquí, una especie de staff engineer de facto con habilidades de desarrollo en python (modestia aparte) supremas, y en camino de aprender más sobre creación de tecnología en la nube. Ahora díganle al Javi de 2011 que tenía un año de experiencia en Python que haría eso y ríanse de su cara de incredulidad.

Si en tu trabajo te encuentras con oportunidades de cambio, de aprender y afrontar nuevas tecnologías, nuevos retos, nuevos frentes para crear tecnología (aunque no fuera programando), piénsalo y ¿por qué no? ¡afróntalos!

DevOps

No hay mejor trabajo que el que no se tiene que hacer. Pero no porque lo barres debajo de la alfombra, ni porque se lo delegues a alguien más incauto. Sino porque en último término, el trabajo seguirá necesitándose (hasta que se vuelva obsoleto: ve al siguiente punto para esto.) El truco: automatiza, automatiza, automatiza. Que tu entrega de valor y en lo que brillas sea lo que necesites hacer a mano como el artesano que moldea barro, pero todo lo demas, QUE SE NECESITA HACER, automatízalo. Como Senior no esperas que sea la chamba de alguien más, si te toca, afróntalo, pero inteligentemente.

Pero no se lleven a engaño, DevOps no es automatizar, en DevOps se automatiza por una razón mucho más grande (que al final comento).

Crea Soluciones, no software

Muchas veces como Devs nos vemos siempre pensando como Devs. Se nos olvida que no somos en realidad Devs, somos creadores de soluciones tecnológicas. Quizá seamos excelentes Devs, y geniales en el lenguaje X y la plataforma Y y la nube Z. Pero no pienses en esos términos al afrontar un requerimiento (venga de un Usuario, el área de Producto o un colega). Piensa en el problema, y luego en la solución. Piensa fuera de la caja. Por supuesto que una posible solución será tirar código. ¿Pero y si el código no necesita hacerse? ¿Y si hay otras maneras más eficientes, escalables, mejores de resolverlo?

Y sólo por eso, como dicen, enamórate del problema y no de la solución. Cualquiera que sea no te enamores de tu código y tu infraestructura. Sino del problema. Cuando el problema mute, muta la solución. Cuando el problema se acabe, depreca la solución. Sin falsos enamoramientos.

Antifragilidad: no robusto ni resiliente

Un atributo no funcional que suelen pedirle al software es que este sea ROBUSTO. Es decir, que aguante los embates de las caídas de red, las entradas de usuario inimaginadas y las interacciones frontend-backend no previstas. Cuando mucho lo imaginamos RESILIENTE, es decir que se auto-repare ante esos problemas y continúe como si nada.

¿Qué tal pensar en términos mucho mayores? Una solución que conforme ocurren los problemas, la solución se transforma. Conforme surgen las situaciones inesperadas, que las habrá, la solución aprende y mejora. Conforme surgen los cisnes negros, la sorpresa no es tanta, la solución se adapta y lo asimila: se vuelve Antifrágil.

OJO: no estoy sugiriendo que la solución solita deba ser creada para hacer todo esto, estoy diciendo que como ingenieros tenemos que poner los mecanismos y los procesos y los patrones y todo lo necesario para poder adaptar el APRENDIZAJE en la solución. Tendremos que meterle mano, seguro, pero estaremos con la mente predispuesta a hacerlo.

Ágil significa flexible, no veloz

Una confusión muy grave que se ve en todos lados donde se habla de agilidad, es pensar que eso significa rapidez. Se piensa en las liebres, y se olvidan que la liebre por muy rápida terminó perdiendo ante la tortuga.

Ágil es flexible, y la flexibilidad le da velocidad. Significa que no tengas ni procesos rígidos, ni reglas rígidas, ni sistemas rígidos, ni actuar rígido. Significa que no creas que todo va a salir como lo planeas, y por eso no planeas con un mes de antelación, te acoplas, te adaptas, y si el plan se frustra no te pierdes ni desmotivas ni castigas, el CAMBIO es parte de ser ágil.

Y otras tantas cosas más

Sólo por dejarlo en doce puntos dije que serían doce, pero la verdad es que faltan TANTAS cosas... en cuanto a liderazgo, en cuanto a capacidades técnicas, en cuanto a soft-skills y aprender a colaborar mejor...

• También se busca ser un buen comunicador. Y no es que tenga que presentar conferencias o escribir un blog. También debe poder crear documentación para sus pares, explicar su trabajo, su código mismo debe expresar la intención.
• Y no violar el undécimo mandamiento (No Estorbarás). Cuando hablé de DevOps más arriba, lo dejé muy corto. En realidad, DevOps busca liberar cuellos de botella, optimizar procesos, poner las cosas listas para entregar Soluciones y Valor cada vez más rápido. Si me ponen un requerimiento, y sólo digo No se puede. Me rompe esto. Sucede aquello. Pero fuera de eso no propongo una alternativa, planteo riesgos, costos y me comporto profesionalmente, entonces estaré estorbando.

Seniority

Al final, el asunto del seniority se puede ver como algo tan insulso como pensar en tener un título y un sueldo, o tan amplio como un hito en una carrera profesional.

En Podemos tenemos un valor en particular: Nada es imposible, nunca nos rendimos 🌱. Podemos TI es 100% los valores de Podemos Progresar, pero sobre todo es éste último.