Una matriz es un mapa, no una nota
Los equipos suelen crear matrices cuando la contratación es inconsistente o las promociones se vuelven subjetivas. Poner niveles del uno al cinco parece preciso, pero no sirve si nadie puede explicar qué evidencia separa un nivel de otro.
Empieza por capacidades que producen trabajo observable: investigación, redacción y edición, arquitectura de información, API, herramientas, coordinación de releases, automatización de calidad y gestión de stakeholders.
Describe alcance e independencia
Para cada capacidad, explica qué clase de problema puede resolver la persona y con cuánta autonomía. Un perfil inicial puede actualizar un procedimiento existente con revisión. Uno más experimentado puede descubrir el flujo, validarlo con ingeniería, diseñar la estructura y crear el proceso de revisión.
Eso es más útil que adjetivos como “excelente comunicador”, porque se puede señalar trabajo real.
Separa oficio y conocimiento de dominio
No conviertas el stack de un producto en la definición de seniority. Kubernetes puede ser esencial en un puesto e irrelevante en otro. Mantén separadas las habilidades duraderas de documentación y el conocimiento local.
Lo mismo vale para herramientas: conocer Git puede ser un requisito, pero dominar un generador concreto no define por sí solo un nivel profesional.
Usa la matriz en ambas direcciones
Debe ayudar a managers a explicar expectativas y a writers a elegir qué practicar después. Añade evidencias: rediseñar navegación, crear una referencia API con ejemplos probados, migrar terminología o introducir un quality gate.
Revísala cuando cambie el trabajo
La IA, el contenido estructurado y la ingeniería de documentación cambian la distribución del trabajo. Actualiza la matriz cuando cambie el trabajo real, no cada vez que aparezca un término de moda. La pregunta estable es: ¿qué problema valioso de documentación puede asumir esta persona de forma fiable?
Ejemplo aplicado
Usa «Una matriz de habilidades para technical writers que mida trabajo útil» como ejercicio de equipo, no como una lista de cargos. Toma una tarea reciente y reconstruye quién descubrió la necesidad del usuario, quién obtuvo los hechos técnicos, quién diseñó la estructura, quién revisó el contenido y quién será responsable de la siguiente revisión.
Describe capacidades observables:
- qué problema puede asumir una persona sin supervisión paso a paso;
- con qué expertos puede trabajar y discrepar de forma constructiva;
- qué riesgos de calidad detecta antes de publicar;
- qué proceso de documentación puede mejorar, no solo utilizar.
Un buen modelo profesional debe orientar el siguiente problema difícil que conviene practicar. Si solo produce etiquetas como «junior», «senior» o «buena comunicación», es demasiado vago para guiar desarrollo o contratación.
Lista rápida de revisión editorial
- Una matriz es un mapa, no una nota. Los equipos suelen crear matrices cuando la contratación es inconsistente o las promociones se vuelven subjetivas.
- Describe alcance e independencia. Para cada capacidad, explica qué clase de problema puede resolver la persona y con cuánta autonomía.
- Separa oficio y conocimiento de dominio. No conviertas el stack de un producto en la definición de seniority.
- Usa la matriz en ambas direcciones. Debe ayudar a managers a explicar expectativas y a writers a elegir qué practicar después.
