Hace casi dos años, postulé a puestos en los que me hacían preguntas de todo tipo, era algo extraño pero como era la primera vez –en años– en la que buscaba conectarme al mundo laboral –y bueno, esos procesos me causaban curiosidad– decidía continuar con las entrevistas,

¿Sabes BPM? ¿Oracle? ¿SAP? ¿Android? ¿AWS? ¿GCP? ¿Go? ¿C#? ¿Java?¿MySQL? ¿JavaScript? ¿Linux? ¿TDD?

Me gustaría decir que estoy exagerando, pero dicha entrevista existió (y se repitió en al menos un par de procesos más). Por mi parte no veo inconveniente en responder, pues es un hecho que nadie sabe todo, así que decía la verdad en cada caso. Y bueno, como me gusta conversar, al culminar una de las reuniones, le pregunté al entrevistador la causa de ese nivel de detalle, de eso encontré tres cosas:

1. Se trataba de un cuestionario que le habían pedido llenar tal como estaba descrito (por eso en casi todas las situaciones la respuesta debía ser “sí” o “no” o incluso encontré preguntas que estaban mal formuladas),

2. El entrevistador era consciente de que eso excedía los requisitos del rol pero era “por si acaso alguien sabía todo eso”, y

3. Hasta ese momento no encontraban a nadie así (pero esperaban hacerlo)

Creo que es muy importante que una búsqueda se centre en el rol esperado, o al menos lo mínimo para cubrirlo, es decir, confirmar si una persona encaja a lo que vaya a necesitar ni bien empiece su asignación. Luego de cubrir esto, se podría pensar en elementos adicionales.

¿Por qué menciono esto? Porque experimenté una realidad en la que me encuentré con un rol cuyo título parecía interesante pero o la descripción era “algo extraña” o, como describí líneas arriba, las entrevistas del proceso te confirman que hay “algo raro con ese rol”. Habiendo dicho eso, estoy seguro que han visto anuncios similares y el que siempre viene a mi mente es la búsqueda de perfiles “semi-senior”, pues, en serio, ¿no les suena raro ese título? ¿cómo le explicarían a su mamá de qué trabajan? “Hola mamá, soy programador semi-senior” (les dije, suena raro)

Ok, nuevamente, puede sonar a exagerado y a pesar de haber conversado de esto con algunos amigos, no he averiguado a detalle –porque cuando leo la descripción y los requisitos del rol, pierdo las ganas de seguir investigando– pero quizá es una forma de decir que se busca a alguien que es “casi” senior, o por decirlo de otra forma “alguien que le falta muy poco para ser senior”, aunque también he escuchado/leído comentarios como “quizá buscan a un senior que cobre menos”.

Independiente al nombre o cómo se describa el rol, lo que he notado –y vivido– varias veces, es que cuando entras a trabajar a un lugar, la complejidad de las tareas asignadas aumentará dependiendo de lo rápido que puedas resolver las anteriores. Es algo “normal” que muchas veces no se vea reflejado con el sueldo acordado al entrar a trabajar, pues valgan verdades, las negociaciones de aumento de sueldo a veces toman meses.

Siendo concretos, no estoy de acuerdo con perfiles cuya descripción y/o requisitos no estén acorde a la realidad y/o el título del rol.

Antes de continuar, me gustaría aclarar que esto no tiene que ver con mis amigos head-hunters, quienes muchas veces no cuentan con el detalle suficiente de lo que se busca o actúan como intermediarios usando una descripción y requerimientos técnicos cuya complejidad –y a veces alejamiento de la realidad– ya está definida desde antes de iniciar la búsqueda. Lo cual es normal –hasta cierto punto–, pues me ha pasado y estoy seguro que también a muchos de ustedes.

El tema es el siguiente, y esta es una suposición, de haber un problema con los roles de tipo “semi” ¿habrá forma de eliminar dicho rol? Yo creo que es complicado pues el término existe desde hace buen tiempo (yo diría que por lo menos cinco años) y hasta parece aceptado por buena parte del mercado laboral (no veo que nadie se queje de eso o deje de postular a ciertos roles), pero –también creo– se aplica de forma errónea y lo confirmo al revisar el detalle de ciertas ofertas laborales.

Ahora, ¿la solución es compleja? Claro que lo es, pero lo primero que se me ocurre es sincerar la dificultad del trabajo por el que pasa un desarrollador de software, entender que hay niveles de complejidad y quizá usar eso para también pensar en niveles del rol. En fin, sin ánimo de extenderme más, podríamos usar roles como estos:

Practicante / Intern / Trainee: Profesional o estudiante de tecnología/ramas afines (en adelante persona) sin experiencia, que luego de un plazo no mayor a 6 meses debería buscar aplicar al siguiente nivel.

Junior developer I: Persona con al menos seis meses de experiencia que podrá aplicar al siguiente nivel bajo condiciones como:
– Entre 6 y 12 meses en el puesto (6 meses, si cuenta con aprobación del líder inmediato superior)
– Al menos 1 proyecto de 6 meses de duración
– Las actividades realizadas en el último proyecto deberán ser de complejidad media/alta (acordadas/validadas con el líder inmediato superior)

Junior developer II: Persona con al menos 1 año de experiencia que podrá aplicar al siguiente nivel bajo condiciones como:
– Entre 1 y 2 años en el puesto (1 año bajo aprobación del líder inmediato superior)
– Al menos 2 proyectos de 6 meses cada uno (o proyecto/tiempo equivalente)
– En todos los casos las actividades realizadas en el último proyecto deberán ser complejidad media/alta (acordada con el líder inmediato superior)
– Mentor técnico de al menos un Trainee o Junior developer I (el cual debe mostrar mejoras del mentoring)

Aquí viene algo que considero muy importante, no debe haber punto medio entre ser junior y senior pues se presta a confusiones, creo que las cosas deben ser tal como indica la lógica (o eres o no eres). Ojo, eso no quita que exista una diferenciación que nos ayude a determinar otros niveles de seniority.

Senior Developer I, Senior Developer II, Senior Developer III: Aquí la clave para diferenciar cada nivel de este rol se puede basar en:
– Cantidad y complejidad de proyectos
– Impacto y efectividad del trabajo realizado
– Liderazgo, mentoría e influencia sobre el resto del equipo
– Capacidad para diseñar soluciones técnicas
– Capacidad para resolver problemas/conflictos
– Capacidad para explicar lo ocurrido/resuelto sin necesidad de entrar en detalles.

Como notarán, no he detallado los criterios (como por ejemplo, tiempo y/o experiencia) pues estos deben ser cuantificables y acordes a la realidad de la organización/mercado. Eso sí, no creo saludable que una persona deba pasar más de dos años en el mismo rol, a menos que tenga la capacidad demostrable de escalar al siguiente nivel, pero de quedarse, que sea por decisión personal.

Un segundo elemento a considerar, es que no creo que deban haber más de tres niveles para el rol senior. Si sacan la cuenta, hasta este momento habrían más de 6 niveles en la organización –hay algunas que tienen estructuras más complejas, pero eso ya me parece demasiado, y bueno, estamos hablando de corporaciones de talla mundial– y eso conlleva manejar un orden que involucra salarios que deben ir acorde con cada nivel en el que se encuentre cada persona.

Por otro lado –y este sería el último punto, lo prometo–, no he mencionado otros roles, pues además de que hace mucho se puso de moda el rol del Arquitecto –y que ahora existen arquitectos para todo–, también hay conceptos como Principal Developer o bueno, Principal Architect, que para mí, son roles que suenan bien y generan impacto en los proyectos, pero si lo ven en perspectiva, terminan siendo developers con mayor seniority que tienen la capacidad de tomar decisiones acordes a la necesidad técnica del proyecto.

¿Por qué no los he mencionado? Porque creo que debería ser decisión de la organización contar solo con uno de dichos roles (eso no quiera decir que solo haya una persona, esa también debe ser una decisión a tomar), ya que a la larga, podrían generar confusión tanto dentro como fuera del equipo (pero bueno, quizá solo sean ideas mías)

Tampoco he mencionado roles como por ejemplo, el de las personas que prueban, pero creo que podría aprovecharse la propuesta considerando que en la actualidad en un equipo de desarrollo de software (como habrán notado me centré en este tipo de equipos) las pruebas se automatizan con mayor frecuencia, por lo que fácilmente se puede definir esa actividad como una responsabilidad/especialización/función de un senior developer o un junior developer o de un practicante que quiera seguir ese camino.

No estoy seguro si se haya cubierto lo que buscaba compartir (pues admito he perdido algo de práctica en escribir/editar/corregir publicaciones técnicas) pero sigo creyendo que existen roles sobredimensionados y que dependerá de nosotros ayudar a que esto cambie en el tiempo. Una forma es proponiendo desde nuestro frente cambios que permitan eliminar ambigüedades o malosentendidos sobre lo que debe o no cubrir un rol técnico, pues si se trata de una definición técnica ¿quién mejor que nosotros para ayudar a delimitar mejor ese alcance?

Les mando un abrazo,
JD