Job misclassification

 

Junior por elección o por conveniencia: cuando tu trabajo habla más que tu cargo

“Siento que a veces leer las experiencias de otros ayuda a saber que no estamos solos.” Y así empieza esta historia. Una historia que podría ser la tuya, la mía o la de cualquiera que alguna vez usó la etiqueta "junior" más tiempo del necesario.

La gorra de “junior” y el peso simbólico del título

Es normal —y hasta saludable— empezar una carrera con una gorra que diga “soy junior”. Es una etapa de aprendizaje, de adaptación, de ensayo y error.
Pero llega un momento en el que esa gorra ya no ajusta. Empezás a asumir otras tareas, a tomar decisiones, a resolver problemas complejos… y te das cuenta de que creciste.
El problema es que muchas veces ese crecimiento no se traduce ni en el título, ni en el salario, ni en el reconocimiento.

 - El caso personal (que no es tan personal)

En uno de mis primeros roles como QA, me involucré con pasión. Desde el día uno, hice más de lo que el rol “junior” pedía. Me anticipaba a los problemas, proponía mejoras en los procesos, acompañaba a clientes y facilitaba la comunicación del equipo. Mi PM me dijo una vez:

“No deberías ser junior. Hacés más que muchos seniors.”

Y aunque lo dijo como un halago, con el tiempo entendí lo que realmente significaba: hacía más, pero seguía cobrando menos.

Años después, lideré un proyecto móvil que nadie lograba estabilizar. Me convertí en una figura clave. ¿El resultado? Me ascendieron... a Junior Level 2.
¿La causa? Me habían visto como “Open to Work” en LinkedIn.
¿El título real que debía tener? Posiblemente QA Lead.
¿El cargo que figuraba en el sistema? El de siempre.

Y no era solo mi percepción. Compañeros me preguntaban por qué, si yo lideraba procesos, facilitaba decisiones y explicaba funciones a otros, seguía siendo “junior”.

🧐 La teoría que explica lo que vivimos

La situación tiene nombre: desalineación entre responsabilidades, habilidades y reconocimiento formal.
En teoría organizacional, esto se conoce como job misclassification, y es más común de lo que parece en la industria del software.

Según un informe de LinkedIn Talent Insights (2023), muchos equipos tech optan por contratar juniors como una forma de reducir costos, con la promesa implícita de que “más adelante viene el crecimiento”. Pero sin políticas claras de evaluación ni trayectorias profesionales definidas, muchos terminan estancados con un título que ya no los representa.

Y acá entra el problema: el trabajo en software es dinámico, pero los cargos suelen ser estáticos.

💻 ¿Qué implica ser junior realmente en IT?

Un rol junior en QA o desarrollo no se define solo por el tiempo de experiencia, sino por la autonomía, la complejidad de las tareas que maneja y la capacidad de análisis frente a problemas.

Pero en la práctica, muchas veces:

• Se espera que un junior “resuelva como un senior”, sin ser molesto.

• Se les da ownership sin acompañamiento.

• Se premia la iniciativa con… más tareas, no con reconocimiento.

🔬 Reflexión final: ¿junior por elección o por conveniencia?

Quizás alguna vez elegiste ser junior para aprender, y eso está bien.
Pero cuando llevás tiempo resolviendo problemas, proponiendo soluciones, liderando proyectos y ayudando a otros, y aún así seguís con un cargo que no refleja eso… entonces ya no es una elección. Es conveniencia ajena.

Como dijo Lisa Crispin, referente en testing ágil:

“Cuando asumimos responsabilidades que impactan en el producto, no somos solo testers. Somos impulsores del valor. El título es lo de menos. Lo que importa es lo que hacemos.”

 

---

Lo viejo y lo nuevo

 

Fuerzas instituidas e instituyentes en el desarrollo del Software

Cuando empecé a sumergirme en el mundo de la gestión de proyectos, una pregunta me dio vueltas en la cabeza desde el inicio: ¿Puede un PM ser realmente ágil si su equipo no lo es?

Esta duda me persigue cada vez que la palabra “cambio” aparece en escena. Durante la facultad, en una materia llamada Instituciones y los grupos en la universidad de Humanidades, aprendí dos conceptos que me marcaron profundamente: lo instituido y lo instituyente. Desde entonces, los aplico como lentes para observar cada proyecto o proceso en el que participo.

Para explicarlo mejor, lo traigo al mundo IT:
En muchos proyectos existen formas de trabajo instituidas, heredadas de mandos anteriores o rutinas que, si bien no son eficientes, son conocidas. Y lo conocido da seguridad. Por eso se sostienen. Es la famosa zona de confort organizacional, donde se privilegia evitar riesgos por sobre innovar.

Ahí es donde entra en juego lo instituyente: aparece un nuevo PM, o un CEO con hambre de mejora. Llega con visión de cambio, con ideas de automatización, optimización de riesgos, y foco en el éxito del producto. Es ahí donde choca lo nuevo con lo viejo. La intención de transformar contra la fuerza de lo ya establecido.

Y, por supuesto, ahí entra la palabra mágica: agilidad.

---

“Somos ágiles. Hacemos daily todos los días.”
— Escuchado en una reunión donde los entregables se gestionaban en una planilla de Excel llamada Urgente_final_2_real_ahora_SÍ_v2

---

La agilidad está de moda. Scrum, Kanban, XP, Design Thinking… todos quieren sumarse. Los post-its se reproducen como si fueran stickers de WhatsApp.
Pero hay una verdad incómoda: 🌟La agilidad no es un rol. Es una cultura.

Y si el equipo no la comparte, el PM se convierte en una especie de actor secundario con acceso limitado a Jira.

El PM que quiere, pero no puede

Podés tener al PM más comprometido del universo. Que arma retrospectivas en Miro, planifica sprints con criterio, y celebra entregas con GIFs de perritos en Slack.
Pero si los desarrolladores no se hacen cargo del producto, si QA vive apagando incendios, y si Producto cambia las prioridades como quien cambia de pestaña…
Houston, tenemos un waterfall con daily.

¿Qué dice la teoría?

Martin Fowler, uno de los firmantes del Manifiesto Ágil, lo resume así:

“Being agile is not about following a recipe, it’s about continuous learning and adapting.”

Y para que eso ocurra, todos tienen que estar en sintonía.

Ejemplo real:

Una startup implementó Scrum. Todo pintaba bien… hasta que los devs se negaron a participar de las retrospectivas (“eso es pérdida de tiempo”) y los stakeholders exigían releases “para ayer”.

😓Resultado: PM frustrado, equipo estresado, y el Scrum Master meditando en la cocina.

Pero sería ingenuo decir que con eso alcanza. Porque cambiar lo instituido no es un proceso mágico. Requiere trabajo, paciencia, acompañamiento, entrenamiento y —sobre todo— convicción.
Cuando se introduce agilidad, muchas veces aparece resistencia, confusión, entorpecimiento. Y ahí, el cambio se vuelve costoso. Tanto, que algunas empresas prefieren dar marcha atrás. Volver a ese método anterior que no era ideal… pero al menos, funcionaba.

Reflexión final

Si tu entorno no permite experimentar, si equivocarse se castiga, si la planificación es solo una excusa para imponer fechas, entonces no sos ágil.

Sos waterfall con daily👀

De QA a Product Manager

 

De QA a Product Manager: ¿Ascenso natural o cambio radical?

Hace un tiempo, me hice esta pregunta: ¿Un QA puede convertirse en un gran Product Manager o es un salto demasiado grande?

Mi camino no empezó en gestión de producto. Fui líder de equipo en operaciones y luego trabajé como QA manual, dos roles que parecían estar lejos de la estrategia de producto. Pero cada experiencia me estaba preparando para ser un PM con una visión más completa y profunda del proceso de desarrollo.

Como QA Manual: Aprendí a cuestionar todo. No solo me dedicaba a encontrar errores, sino que me enfocaba en entender el porqué detrás de cada parte del producto. En mi internship, uno de los QA Senior que nos enseñaba mencionó a Michael Bolton y su frase me marcó profundamente "Testing no es solo encontrar bugs, es cuestionar suposiciones." – Michael Bolton

Este enfoque cambió mi perspectiva por completo. Aprendí que el verdadero valor del QA no está solo en detectar fallos, sino en cuestionar las decisiones y las suposiciones subyacentes del producto. Testing no es solo un proceso de validación, sino de aprendizaje constante. Esta idea se convirtió en la base de mi enfoque como Product Manager.

Priorizo con base en impacto y riesgos reales, no solo en deadlines,

Durante mi tiempo como QA, uno de los problemas más comunes era la falta de claridad en los requerimientos. Esto no solo dificultaba las pruebas, sino que también llevaba a errores costosos cuando se implementaba la funcionalidad de manera incorrecta o incompleta. Como PM, esa experiencia me enseñó a priorizar la claridad en los requerimientos desde el inicio. Por ejemplo, cuando los requisitos no definen bien las expectativas de usabilidad, como en una función de registro que no especifica cómo deben gestionarse los errores de entrada, puede generar una experiencia de usuario frustrante. Esto puede no ser un "bug", pero sin duda es un riesgo de usabilidad que debe abordarse.

Entiendo a los equipos técnicos y operativos porque estuve en su lugar.

En QA, me enfrentaba a la frustración de trabajar con requerimientos incompletos o ambiguos, lo que resultaba en test cases que no cubrían todos los aspectos del producto. Como PM, puedo identificar estos vacíos en la documentación y evitar que se repitan. Por ejemplo, si un equipo de desarrollo recibe una especificación vaga sobre el flujo de pago en una aplicación y no hay detalles sobre la validación de tarjetas, esto puede generar errores graves. Mi experiencia me ayuda a comunicar la importancia de una documentación clara y a asegurar que todos los involucrados tengan la misma visión del producto.

Valoro la calidad desde el inicio, no como una fase final del desarrollo.

Como QA, aprendí que los problemas de calidad no son algo que se pueda dejar para el final. El desarrollo de software no es una cadena de montajes en la que los defectos pueden ser corregidos en etapas posteriores, sino que deben ser identificados y abordados desde el principio. En proyectos donde los requerimientos no estaban claramente definidos o los aspectos de usabilidad no se especificaban correctamente, los errores no solo afectaban la funcionalidad, sino que también perjudicaban la experiencia del usuario. Esta experiencia me enseñó que, como Product Manager, debo asegurarme de que la calidad esté integrada en cada fase del proceso, desde la planificación hasta la implementación. Además, como líder de hackathones, experimenté de primera mano cómo la falta de claridad o los detalles insuficientes pueden generar caos y errores, especialmente cuando el tiempo es limitado. Ahí, la calidad tuvo que ser asegurada desde el inicio, incluso en condiciones de presión, para garantizar que las soluciones fueran funcionales y de alto impacto. Detectar problemas de usabilidad, diseño o lógica en etapas tempranas evita grandes retrasos y costosos reworks en el futuro. La calidad debe ser un compromiso constante, no un parche final.

🌟"Cada paso en tu camino te prepara para el siguiente desafío. Ser QA no es solo encontrar errores, sino aprender a cuestionar, entender y mejorar. Esa mentalidad es la que te convierte en un gran Product Manager. Confía en tu experiencia, porque cada lección te acerca a tu próximo gran logro."