Wer in der Softwareentwicklung arbeitet, kennt vermutlich die Titel Junior, Expert und Senior. Aber was steckt dahinter und was bringen sie eigentlich? Diese Fragen haben uns letztes Jahr vor einige Herausforderungen gestellt, deswegen haben wir entschieden, eine klare Definition zu entwickeln. Das Ziel: Ein System, das die Entwicklung unserer Software Developer, UX/UI Designer und Product Owner in den Fokus stellt und fördert. Wie wir das gemacht und geschafft haben, verrate ich euch in diesem Blogartikel.
- Autorin
- Jamine Ponudic
- Datum
- 10. Juli 2024
- Lesedauer
- 6 Minuten
Die Herausforderung
Wenn es keine klare Definition für die Aufgaben und Kompetenzen eines Expertise-Levels gibt, herrschen unterschiedliche Annahmen darüber, was es bedeutet, z. B. ein »Senior Software Developer« zu sein. Das führt dazu, dass manche Entscheidungen nicht nachvollziehbar sind. Conclusio: Ein System, das ursprünglich als Hilfestellung und Perspektive zur Weiterentwicklung dienen und klare Erwartungshaltungen schaffen sollte, sorgt für Unzufriedenheit.
Diese und weitere Symptome haben wir durch das offene Feedback unseres Teams rechtzeitig bemerkt und uns war klar: Entweder wir machen die Expertise-Levels richtig oder gar nicht.
Projektstart
Es gibt kaum einen größeren Fehler, als davon auszugehen, das Problem verstanden zu haben. Je besser wir das Problem ergründen, desto stabiler wird das Fundament des neuen Systems. Also haben wir mit einer Analyse gestartet und alle Stakeholder ins Boot geholt: Teammitglieder, Coaches und Founder. In individuellen Workshops haben wir ergründet, was mit dem System nicht gut läuft, ob wir es überhaupt brauchen und wenn ja, welche Anforderungen es erfüllen muss.
Eine dieser Anforderungen lautete, dass wir keine Wissenschaft aus unserem Expertise-Levels-System machen wollen und es für alle Personen verständlich ist, auch für jene, die nicht an der Erarbeitung beteiligt waren. Ich suchte nach Systemen, die in der Praxis bereits gängig sind und von denen wir uns etwas abschauen konnten. Glücklicherweise gibt das Internet sehr viel dazu her. Unternehmen wie Buffer und StackOverflow geben tiefe Einblicke in ihre Strukturen. So konnte ich von den Best Practices und aus der Literatur über Personalentwicklung vieles für unsere Struktur ableiten und musste das Rad nicht komplett neu erfinden.
Das neue System
Das www und Bücher geben zwar gute Einblicke, lassen aber viele Fragen offen. Meist sind weder Erfahrungswerte noch Herangehensweise bei der Einführung ausgeführt. Doch genau da wird’s interessant: Wie sind die Unternehmen vorgegangen? Welche Erfahrungen haben sie gemacht?
Mit diesen Fragen habe ich mich an meine LinkedIn Community gewandt. Mein Learning: Es gibt extrem viele hilfsbereite Menschen, die ihre Erfahrung bereitwillig teilen. Ich hatte Gespräche mit Personen aus der Unternehmensberatung, Organisations- und Personalentwicklung und HR. Zusätzlich zu den inhaltlichen Details war es sehr inspirierend, deren Perspektiven kennenzulernen und aus der eigenen Bubble rauszukommen.
Nachdem ich vielerlei Inputs gesammelt hatte, musste eine Entscheidung her. Anhand der geschaffenen Basis konnte ich mit gutem Gefühl das Konzept für unser neues System fixieren:
Im Grunde genommen ist es keine Rocket Science – genauso wollten wir es auch. Aber starten wir von vorne: Wir haben im Konzept mit vier Expertise-Levels gerechnet. Wie viele es tatsächlich sind, wird sich später herauskristallisieren.
Jedes Level verfügt über Anforderungen, die wir in Kompetenzen beschreiben – ein sogenanntes Kompetenzmodell. Zu den Levels liefern wir noch mehr Input, um die Weiterentwicklung in den Fokus zu stellen. In sogenannten »Steps« halten wir fest, was zwischen den Levels gemacht werden kann, um die eigenen Kompetenzen weiterzuentwickeln. Je mehr Erfahrung jemand hat, desto individueller wird sein/ihr Weg und umso schwieriger ist es, klare Steps vorzugeben. Ab einem gewissen Punkt sollte das System also als »Baukasten« gesehen werden, von dem man sich inspirieren lassen kann.
Das sieht nach ganz schön viel Arbeit aus und ganz ehrlich: Das ist es auch. Aber wir wollten es »khörig« machen und sehen das Projekt als wichtiges Investment an.
Ausarbeitung des neuen Systems
Das neue Konzept wurde von den Foundern abgesegnet und auch das Team hatte jederzeit die Möglichkeit, Feedback einzubringen. Damit konnte die Ausarbeitung der Inhalte beginnen. Wir starteten mit der Disziplin »Software Developer«. »UX/UI Designer« und »Product Owner« sollten später folgen.
Ziel war es, die Anforderungen an die Rolle eines Level A, B, C und vielleicht auch D Developers zu definieren. Aber wie kommt man dahin? In der Vorarbeit beschäftigte ich mich mit verschiedenen Methoden der Anforderungsanalyse und entschied mich für folgenden Weg:
Wir arbeiten hierarchisch von den Organisationszielen abwärts, bis wir bei den Anforderungen landen. Die Organisationsziele haben wir dank der Arbeit mit OKR schon parat. Gemeinsam mit Head of Development David leitete ich davon die Positionsziele ab: Auf welche der Organisationsziele zahlt die Rolle ein? Welche Ziele verfolgt die Organisation mit dieser Rolle?
Ab den Aufgaben wurde es für mich knifflig: Ich konnte zwar Vorschläge machen, aber die Passung der unterschiedlichen Aufgaben in die Levels mussten die Expert:innen vornehmen.
Mit einem Projektteam aus freiwilligen Expert:innen veranstaltete ich einen Workshop, in dem ich die Organisations- und Positionsziele vorstellte, um anschließend an den Aufgaben zu arbeiten. Mit Hilfe des www und ChatGPT brachte ich pro Level Vorschläge für Aufgaben mit, über die wir im Team diskutieren konnten. Diese Diskussion filterte heraus, welche Aufgaben zu welchem Level gehören.
Ergebnis des ersten Workshops: Die Kernaufgaben sind finalisiert. Es folgte die Definition der Anforderungen. Mir war wichtig, dass ich die Gruppe nicht mit Vorschlägen beeinflusse. Ich hatte zwar ein Beispiel dabei, aber alles weitere sollte aus der Feder der Expert:innen kommen.
So sind wir für den zweiten Workshop im selben Projektteam zusammengekommen und haben für jedes Level besprochen, was wir von den Personen erwarten und über welche Kompetenzen sie im jeweiligen Level verfügen sollten. Wir haben uns stark an den zuvor definierten Aufgaben orientiert und uns immerzu gefragt: Über welche Kompetenz muss eine Person verfügen, damit sie die Aufgabe erfolgreich übernehmen kann? Welches Verhalten zeigen Personen, die über diese Kompetenz verfügen? Das Endergebnis war zwar etwas chaotisch, aber dafür eine sehr fundierte Basis für die weitere Ausarbeitung.
Im nächsten Schritt ordnete ich das Chaos und übersetzte es in Kompetenzen. »Unter Kompetenz wird in der breiteren Bildungsdiskussion allgemein die Verbindung von Wissen und Können in der Bewältigung von Handlungsanforderungen verstanden.« (BIBB, abgerufen am 03.07.2024)
Kompetenzbegriffe wie »Selbstreflexion« sind relativ abstrakt. Wir haben alle eine andere Vorstellung davon und gerade wenn es um das Messen und Verbessern von Performance geht, ist es wichtig, eine allgemeingültige Definition zu schaffen. Es macht also Sinn, den Begriff vorerst generalistisch zu erklären. Das schaut in unserem Fall so aus:
Selbstreflexion beschreibt die Fähigkeit, die eigene Haltung und das eigene Handeln kritisch zu hinterfragen sowie die Bereitschaft, bei Bedarf Hilfe anzunehmen. Selbstreflexive Personen akzeptieren, dass sie nicht alles wissen können, und sind offen dafür, ihre Wissenslücken zu erkennen und zu schließen. Zudem verstehen sie konstruktive Kritik als Möglichkeit zur persönlichen Weiterentwicklung und nutzen sie, um ihre Fähigkeiten und Kenntnisse zu verbessern.
Das klingt schon konkreter, aber um festzustellen, ob und wie man selbst oder andere diese Kompetenzen erfüllen, fehlt noch etwas: Die Kompetenz muss operationalisiert werden. Das bedeutet, dass sie in konkrete, für die Rolle relevante, beobachtbare Einheiten übersetzt werden muss. Im Beispiel »Selbstreflexion« lautet das wie folgt:
- Hinterfragt die eigene Haltung und Meinung regelmäßig
- Hält die eigene Haltung und Meinung nicht für die Wahrheit und ist offen für andere Standpunkte
- Kann Fehler vor sich selbst und anderen eingestehen
- Ist offen dafür, die eigene Haltung bei Bedarf zu verändern
Damit ist schon deutlich klarer, was erwartet wird und in welchen Bereichen ggf. Potentiale zur Weiterentwicklung bestehen. Genau das macht das Kompetenzmodell zu einem wahnsinnig wirksamen Tool in der Personalentwicklung, in der Führung und in vielen weiteren Bereichen.
In mehreren Loops sind wir schlussendlich zu einem tollen Ergebnis gekommen, das wir nach einem Testlauf mit einzelnen Teammitgliedern finalisieren konnten. Die Kompetenzen sind alle nach dem gleichen Schema aufgebaut:
Da wir das Projekt im Rahmen von OKR unter dem Objective »Das MVP des verbesserten Expertise-Level-Systems ist live.« fokussiert haben, durften wir es bei der OKR Demo dem gesamten Team präsentieren. Und von dem gab es neben großem Interesse auch sehr positives Feedback.
Zu den offenen Punkten, an denen wir im nächsten OKR Sprint arbeiten, stand zum Schluss noch das Namings der Level an. Bisher wurden sie in A, B, C und D unterteilt. Nach einigen Schleifen kamen wir zu den folgenden – nicht bahnbrechenden, aber in der Branche gängigen– Namen für die Levels:
Junior → Intermediate → Expert → Senior.
Und was steht nach der erfolgreichen Entwicklung und Demo eines MVP an? Genau – das Release aka Go-live. Das ging smooth über die Bühne, was uns natürlich sehr gefreut hat. Aus meiner Sicht ist das der partizipativen Herangehensweise und den sehr kompetenten Menschen geschuldet, die an diesem Projekt mitgearbeitet haben.
Deshalb an dieser Stelle nochmal ein herzliches Dankeschön an das gesamte Projektteam und alle Personen, die uns mit Rat und Tat zur Seite gestanden sind.
Disclaimer: Wir haben das »Kompetenzmodell« nicht nach Lehrbuch eingeführt und uns an einigen Stellen auf eine pragmatischere, für uns passende Form geeinigt.
