Eine Matrix ist eine Landkarte, kein Zeugnis
Teams bauen Kompetenzmatrizen oft dann, wenn Hiring inkonsistent oder Beförderungen subjektiv werden. Stufen von eins bis fünf wirken präzise, helfen aber nicht, wenn niemand erklären kann, welche Evidenz Stufe drei von vier trennt.
Beginne mit beobachtbaren Fähigkeiten: Recherche, Schreiben und Editing, Informationsarchitektur, API-Verständnis, Tooling, Release-Koordination, Quality Automation und Stakeholder-Arbeit.
Beschreibe Umfang und Selbstständigkeit
Definiere für jede Fähigkeit, welche Art von Problem jemand lösen kann und wie viel Unterstützung nötig ist. Ein Junior kann ein bestehendes Verfahren unter Review aktualisieren. Ein erfahrener Writer kann den Workflow ermitteln, mit Engineers verifizieren, strukturieren und einen Review-Prozess etablieren.
Das ist nützlicher als Formulierungen wie „kommuniziert hervorragend“, weil reale Artefakte als Beleg dienen.
Trenne Handwerk und Domänenwissen
Mache den Tech-Stack eines Produkts nicht zur Definition von Seniorität. Kubernetes kann in einer Rolle wichtig und in einer anderen irrelevant sein. Dauerhafte Dokumentationsfähigkeiten sollten getrennt von lokalem Fachwissen betrachtet werden.
Das gilt auch für Tools: Git kann Pflicht sein, aber ein bestimmter Generator definiert keine Karrierestufe.
Nutze die Matrix in beide Richtungen
Sie soll Managers Erwartungen erklären lassen und Writers bei der Wahl des nächsten Lernziels helfen. Beispiele für Evidenz: neue Navigation, getestete API Reference, Terminologiemigration oder ein CI Quality Gate.
Aktualisiere sie, wenn sich die Arbeit ändert
AI-gestütztes Schreiben, strukturierter Content und Documentation Engineering verändern die Arbeit. Aktualisiere die Matrix bei echten Veränderungen, nicht bei jedem neuen Buzzword.
Die stabile Frage lautet: Welches wertvolle Dokumentationsproblem kann diese Person zuverlässig verantworten?
Praxisbeispiel
Nutze „Eine Kompetenzmatrix für Technical Writer, die echte Arbeit misst“ als Teamübung statt als Liste von Rollen. Rekonstruiere bei einer aktuellen Dokumentationsaufgabe, wer den Nutzerbedarf erkannt, technische Fakten beschafft, die Struktur entworfen, geprüft und die nächste Revision übernommen hat.
Beschreibe beobachtbare Fähigkeiten:
- welches Problem jemand ohne Schritt-für-Schritt-Aufsicht übernehmen kann;
- mit welchen Fachleuten konstruktiv gearbeitet und widersprochen werden kann;
- welche Qualitätsrisiken vor der Veröffentlichung erkannt werden;
- welcher Dokumentationsprozess verbessert und nicht nur benutzt werden kann.
Ein gutes Berufsmodell zeigt, welches schwierigere Problem als Nächstes geübt werden sollte. Reine Labels wie „Junior“, „Senior“ oder „kommunikativ“ reichen dafür nicht.
Kurzer Redaktionscheck
- Eine Matrix ist eine Landkarte, kein Zeugnis. Teams bauen Kompetenzmatrizen oft dann, wenn Hiring inkonsistent oder Beförderungen subjektiv werden.
- Beschreibe Umfang und Selbstständigkeit. Definiere für jede Fähigkeit, welche Art von Problem jemand lösen kann und wie viel Unterstützung nötig ist.
- Trenne Handwerk und Domänenwissen. Mache den Tech-Stack eines Produkts nicht zur Definition von Seniorität.
- Nutze die Matrix in beide Richtungen. Sie soll Managers Erwartungen erklären lassen und Writers bei der Wahl des nächsten Lernziels helfen.
