Teammitglieder haben in der Regel unterschiedliche Erfahrungen und Fähigkeiten. Nicht jeder möchte und kann Führungskraft werden, häufig ist dies aber die einzige Karriereoption. Welche Perspektive können Unternehmen gefragten Spezialisten wie beispielsweise Software Engineers alternativ aufzeigen? Und wie mit den unterschiedlichen Qualifikationen umgehen? Alle(s) gleich machen? Wir zeigen die gängigen Qualifikationsstufen im Software Engineering im Kontext der Fachlaufbahn als eine hilfreiche Alternative auf.

Inhalt

• Inhalt
• Hintergrund
• Einstieg
• Aufstieg
• Allgemeine Merkmale
• Umsetzungsaspekte
• Kritik
• Schluss

Hintergrund

Karriere war klassisch mit der Übernahme von Führungsaufgaben, sei es projektbezogen als Projektleiter oder in der Linie als Vorgesetzter, verbunden. Organisationsbedingt existieren aufgrund der pyramidalen Struktur weniger Führungsstellen als Mitarbeiter. Und insbesondere im IT-Umfeld verfügt nicht jeder technisch versierte Mitarbeiter auch über die für eine Führungsaufgabe notwendigen Fähigkeiten und Interessen. Darüber hinaus werden durch agile Vorgehensweisen bewusst Befugnisse vom Management auf die Teams verteilt. Die Führungsaufgabe verändert sich also (»Management 3.0«) und Unternehmen versuchen, Hierarchien abzubauen. Auch deshalb etabliert sich bereits seit einigen Jahrzehnten die Fachlaufbahn als weitere Karrieremöglichkeit in Unternehmen. Aufgrund ihres sich aufspaltenden Charakters wird dabei zum Teil auch vom »Y-Modell« gesprochen.

Die Qualifikationsstufen der Führungslaufbahn entsprechen dabei den Hierarchiestufen eines Unternehmens, also in der Regel vom Team- über den Abteilungs- zum Bereichsleiter. In der Fachlaufbahn hat sich bislang die aus dem Angelsächsischen übliche Unterteilung in Junior, »Normal« (der Zusatz entfällt in der Regel) und Senior etabliert. Aufgrund der internationalen Vergleichbarkeit haben sich diese Qualifikationsstufen gerade auch in der IT in Deutschland durchgesetzt. Dabei besteht allerdings alleine schon durch die Namensgebung die Gefahr, sich ausschließlich am Senioritätsprinzip zu orientieren. Erschwerend reichen im Umfeld Software Engineering drei Stufen für eine differenzierte Betrachtung häufig auch nicht aus.

Einstieg

Um wirklich gut in einer Disziplin zu werden, braucht man mindestens 10.000 Stunden Übung. Das entspricht bei 8 Stunden pro Tag und 220 Arbeitstagen im Jahr rund 6 Arbeitsjahren. Demzufolge ist die übliche Unterteilung der Qualifikationsstufen in Junior, »Normal« und Senior nach Anzahl der Berufsjahre durchaus eine legitime erste Möglichkeit zur Gruppierung:

Häufig wird sich dabei dann aber auch ausschließlich an der Anzahl an Berufsjahren orientiert. Nur wie viele Stunden einer beispielsweise fünfjährigen Berufstätigkeit konnte jemand dann auch wirklich auf die Ausübung seiner Disziplin aufwenden? Und was ist mit dem außergewöhnlich talentierten Programmierer, der bereits nach drei Jahren, da er Tag und Nacht programmiert, die 10.000 Stunden erreicht hat? Und wie soll die Ausbildung angerechnet werden? In der IT kommt der extrem schnelle Technologiewandel erschwerend dazu. Der Junior Software Engineer frisch von der Uni kennt das neueste Entwicklungs-Paradigma oder -Framework vielleicht schon früher, als der erfahrene Entwickler, aber wie soll das »verrechnet« werden, gerade da »Kennen« ja auch nicht sofort »Können« bedeutet?

Eine Metrik alleine ist, wie so oft auch in diesem Fall offensichtlich nicht wirklich ausreichend. Und was einen Senior Software Engineer nun eigentlich genau ausmacht, ist keinesfalls leicht zu beantworten. Kleinster gemeinsamer inhaltlicher Nenner scheint uns diesbezüglich zu sein, wie viel Anleitung jemand in seiner Arbeit selbst benötigt beziehungsweise anderen gibt:

Die alleinige Beherrschung des jeweiligen Fachgebiets ist allerdings auch nicht ausreichend. Qualifikation beschreibt im Personalwesen »das personenbezogene Arbeitsvermögen, das sich aus Fach- UND Sozialkompetenz zusammensetzt«. Teil des Curriculums des US-amerikanischen DevBootCamps ist beispielsweise Engineering Empathy und Google legt seinen Engineers vermutlich nicht ohne Grund »Mindfulness« ans Herz.

Aufstieg

Üblicherweise teilt sich das Y-Modell erst nach dem erreichten Senior-Level in die Fach- oder Führungslaufbahn auf. Somit bedarf es aber auch noch weiterer Qualifikationsstufen für die Fachlaufbahn als Gegenstück zu den entsprechenden Hierarchiestufen der Führungslaufbahn.

Auf Ebene Teamleitung findet sich häufig der sogenannte Lead, Professional oder Chief Engineer. Die Vokabel Lead kommt dabei unserer Einschätzung nach am häufigsten vor, ist allerdings auch zum Teil ungeschickt, da dies einen wie auch immer gearteten Führungsanspruch impliziert, den man ja eigentlich gerade zu vermeiden versucht. Professionell arbeitet hoffentlich auch schon der Junior, weshalb Professional Engineer zumindest in Deutschland auch nicht immer die beste Wahl ist. Und beim Chief besteht die Verwechselungsgefahr mit dem C-Level, also der Geschäftsführung (CEO, CFO, etc.) des Unternehmens, auch wenn Chief ohne Officer formal auf Ebene Abteilungsleitung anzusiedeln ist.

Auf der nächsten Fachlaufbahn-Ebene findet sich dann der in der Regel unstrittige Principal Engineer. Größere Organisationen (Apple, Google, Microsoft, Telekom, …) führen für jedes Fachgebiet häufig noch einen sogenannten (Technology) Evangelist. Hier gilt es insb. auch hinsichtlich der im eigenen Unternehmen vorherrschenden Kultur und anhand der notwendigen Hierarchieebenen mit entsprechend Fingerspitzengefühl an die Benennung der jeweiligen Qualifikationsstufen der Fachlaufbahn für das eigene Umfeld heranzugehen.

Allgemeine Merkmale

Je Unternehmen, Fachgebiet und Aufgabenstellung weichen die konkreten Aufgaben und Verpflichtungen der einzelnen Qualifikationsstufen natürlich erheblich voneinander ab. Der Senior Platform Engineer bei Github wird sich vermutlich operativ um die Weiterentwicklung der Rails-Plattform kümmern, wohingegen der Principal Software Engineer bei Google im Chrome-Team die Javascript-Roadmap voranbringen wird. Über die jeweiligen technologischen Fachspezifika hinaus erkennen wir aber gewisse Gemeinsamkeiten in den Qualifikationsstufen im IT Engineering:

Der Junior Engineer lernt und arbeitet auf Modul-Ebene und unter Anleitung; er fokussiert sich dabei in der Regel zunächst auf Detailfragen. Der Engineer wendet sein Wissen auf System- beziehungsweise Mikro-Ebene eigenständig an und kann seine Entscheidungen entsprechend vertreten. Der Senior Engineer leitet andere an; er überblick die Makro-Architektur und hat auch Einblick in benachbarte Bereiche; er vertritt sein Aufgabengebiet im Unternehmen, beispielsweise in Scrum of Scrums oder ähnlichen Gremien. In größeren Organisationen kommt manchmal zusätzlich ein Lead Engineer zum Einsatz, dem als Servant Leader die technische Führung (mehrerer) Systeme in einer Organisationseinheit obliegt; er vertritt sein Aufgabengebiet dann auch nach außen, also beispielsweise durch Vorträge auf Konferenzen, beziehungsweise leitet seine Teams dazu an. Abhängig von der Größe der Organisation und den Hierarchiestufen verschwimmen insbesondere die Stufen des Senior und Lead Engineer aber zum Teil auch. Der Principal Engineer entwickelt das Unternehmen technologisch weiter und denkt dabei langfristig sowie strategisch; auch hier verschwimmen die Grenzen zur nächsten Stufe, dem (Technology) Evangelisten, der wenn eher in sehr großen Organisationen anzutreffen ist.

Umsetzungsaspekte

An die Qualifikationsstufen oder auch »Titel« knüpfen sich einerseits gewisse Erwartungen, andererseits aber auch entsprechende Aufgaben und Verpflichtungen. Wichtig ist unserer Erfahrung nach, dass man dies explizit und nachvollziehbar gestaltet. Andernfalls droht das Modell nicht ernstgenommen zu werden.

Nimmt der Evangelist an den gleichen Führungsgremien teil bzw. hat gleichen Zugang zur nächst höheren Hierarchiestufe wie der Bereichsleiter? Liegen der Teamleiter und Lead Engineer in einer ähnlichen Gehaltsgruppierung? Bekommt der Abteilungsleiter einen Dienstwagen gestellt? Dann sollte dies dem Principal Engineer auch gewährt werden. Gerade die monetären Aspekte schrecken nach unserer Erfahrung viele Unternehmen davon ab, transparente Qualifikationsstufen und ein Fachlaufbahnmodell einzuführen, denn die Vergleichbarkeit ist damit natürlich in beide Richtungen gegeben. Wie gehe ich mit eventuell sichtbar werdenden Ungleichgewichten beziehungsweise auch ungerechten Situationen um? Was ist mit Betriebsvereinbarungen? Und bilden sich in wenigen Jahren gegebenenfalls »Klumpen« in gewissen Stufen, habe ich also irgendwann nur noch Senior Engineers? Die Einführung von Qualifikationsstufen sind nur der Anfang und der Prozess muss dauerhaft gemanaged werden.

Kritik

Die Einführung agiler Methoden geht in der Regel mit der Reduzierung klassischer Führungshierarchien einher. Die Vermutung liegt nahe, dass sich das Thema Qualifikationsstufen auf fachlicher Ebene damit auch erledigt hätte, aber auch in selbstorganisierenden Teams bilden sich Hierarchien, ob implizit oder explizit. Die jüngeren, unerfahreneren oder introvertierteren Mitarbeiter werden sich unserer Erfahrung nach an den älteren, erfahreneren oder eben auch an den extrovertierteren orientieren. Bereits 1962 hat Herbert Simon in The Architecture of Complexity festgestellt:

»Complex systems [like social ones] have a […] hierarchic structure.«

Ob und wie den Leistungs- und Qualifikationsunterschieden von Mitarbeitern einer Organisation Rechnung getragen werden sollte und kann, hängt zum Großteil von der Kultur des jeweiligen Unternehmens ab. Einige Unternehmen experimentieren hierzu mit neuartigen Ansätzen. Zappos, ein durchaus erfolgreiches Online-Handelsunternehmen mit 1.500 Mitarbeitern und rund 1 Milliarde USD Umsatz pro Jahr begegnet dem Thema Hierarchien, Entscheidungsfindung und Bürokratie beispielsweise mit einer holokratischen Organisationsform. Ob dies der Schlüssel zum bisherigen Erfolg war und wie nachhaltig selbiger ist, wird sich unserer Einschätzung nach erst noch herausstellen müssen. Andere, auch modernere Unternehmen, wie beispielsweise Google verzichten andererseits in ihren Stellenausschreibungen auch schon wieder auf die Angabe von Qualifikationsstufen.

Schluss

Es gibt also auch bei diesem Thema nicht den einen richtigen Weg. Mit den hier gezeigten qualitativen Kriterien lässt sich aber wesentlich differenzierter arbeiten, so dass die alleinige Anzahl an Berufsjahren nur noch indikativen Charakter für die Eingruppierung in eine Qualifikationsstufe bekommt; das reine Senioritätsprinzip hat unser Einschätzung nach ausgedient. Und noch nicht jede Organisation ist schon reif für vollständig selbstorganisierte Teams beziehungsweise verfügt über die Kultur für entsprechende Organisationsformen. Wenn auch nicht perfekt, so dürften die gezeigten Qualifikationsstufen doch besser sein, als das Thema dem Zufall zu überlassen. Der Ansatz ist dabei auf unterschiedliche Engineering-Disziplinen übertragbar, sei es der Junior Consultant, Senior Software Engineer oder auch Principal Platform Engineer; es handelt sich um international gängige und im gewissen Rahmen somit auch vergleichbare Bezeichnungen für die unterschiedlichen Qualifikationsstufen in technischen Entwicklungsberufen.