Muss man State of the Art Technologien einsetzen, um gute Entwickler:innen einzustellen? Oder sollte sich ein:e CTO davon frei machen, welche Technologien und Sprachen in der Community beliebt sind? Ein Gastbeitrag über wirtschaftliches und nachhaltiges Recruitment von Entwickler:innen.
Python ist als Trend noch nicht bei den Unternehmen angekommen
Mit welchen Programmiersprachen wollen Entwickler:innen zukünftig arbeiten? Und wie sieht es bei den Unternehmen aus? Dieser Frage ist die Job Matching Plattform matched.io nachgegangen und hat die Daten von über 2.000 Entwickler:innen und 160 Unternehmen analysiert. Gibt es einen gemeinsamen Nenner?
Betrachtet man den Wunsch Tech Stack der Entwickler:innen, die auf matched.io registriert sind, verteilt dieser sich auf 490 Sprachen, Modelle, Methoden, Datenbanken und Frameworks. Der Tech Stack, welcher von Unternehmen gefordert wird, auf 153.
Während viele Unternehmen und Entwickler:innen in Deutschland sowohl Java als auch JavaScript als gemeinsamen Nenner finden, geht die Schere bei Python zum Beispiel auseinander. Entwickler:innen stellen fest, dass es verhältnismäßig wenig Python Umgebungen bzw. Produkt-Teams in Deutschland gibt - lediglich 7,5% der auf matched.io registrierten Unternehmen arbeiten mit Python. Jedoch ist die Nachfrage auf der Entwickler:innen-Seite groß - über 16% der auf matched.io registrierten Entwickler:innen, und somit Platz 3 auf deren Wunsch-Tech-Stack Liste, würden gerne mit Python arbeiten.
Bedeutet dies im Umkehrschluss, dass Unternehmen auf Python setzen sollten, um eine technisch attraktive Umgebung für diese Entwickler:innen zu bieten? Nein.
Zunächst sollte man sich die Frage stellen, in welcher Phase man sich mit seinem Produkt befindet. Unternehmen müssen den Fokus auf den Use-Case legen, um langfristig agil und wirtschaftlich zu handeln. Dabei müssen Skalierbarkeit und Wartbarkeit berücksichtigt werden. Ein CTO mit einem offensiv-agilen Mindset kann z.B. auf Microservices in einer Java Umgebung setzen. Das “cutting-edge” Startup kann hingegen auf einen Monolithen mit Python/Django setzen - an dieser Stelle sei erwähnt, dass Instagram mit genau diesem Tech Stack begonnen und diesen noch immer in Betrieb hat.
Der Trend ist im Weg
CTOs, Manager:innen und POs müssen sich trügerisch die Frage stellen, welches Ziel mit dem Einsatz einer Technologie erreicht werden soll. Leider ist es in der Realität häufig so, dass nicht jedes Unternehmen sich seines Ziels bewusst ist. Daher gilt: Klares Ziel definieren und die Suche nach der richtigen Technologie gemeinsam mit dem Team angehen. Das Team wird es zu schätzen wissen.
“Die Features vom Wettbewerber müssen umgehend auch bei uns integriert werden.” - ist ein Satz, den man von POs regelmäßig hört. Drastisch formuliert: Ein Todesurteil für jedes Produkt. Fängt man an, die Umgebung nach Eventualitäten und Mutmaßungen zu bauen, wird man sie voraussichtlich verbauen. Verliert wertvolle Zeit. Und macht sich so zum Spielball der Community. Deshalb ist eine gesunde Anfangs-Struktur mit klaren Anforderungen und Zielen elementar. Das heißt nicht, dass man nicht offen für Feedback und äußere Einflüsse sein soll. Es heißt nur, dass man nicht jedem Ball hinterherlaufen muss. Sondern vielmehr in iterativen Entwicklungszyklen planen und vom User Verhalten lernen sollte.
Ich brauche dringend eine:n COBOL Entwickler:in!
Oder war es doch ein:e Fortran Entwickler:in für unser neues Team, das unser Produkt auf Verteilten Systemen noch agiler bauen soll? Die Ressourcen bzw. die Beschaffung der Ressourcen spielt eine essentielle Rolle.
Unumstritten handelt es sich bei COBOL um eine bestimmte Fachkenntnis. Ein:e ambitionierte:r CTO hat jetzt mehrere Optionen:
A. Man versucht, die/den Cobol Entwickler:in zu finden, um ein bestehendes Problem zu lösen.
B. Man definiert den Use-Case erneut aus einer anderen Perspektive, um ggf. eine andere Technologie für die Umsetzung zu verwenden.
C. Man stellt eine:n Entwickler:in ein, der/die sich in wenigen Wochen in Cobol einliest, um den Use-Case eigenständig umsetzen zu können.
Doch welche dieser Optionen ist die richtige?
Um das beantworten, muss man das Unternehmen, die Strukturen, den Use-Case, die finanziellen Mittel sowie die Ressourcen ins Verhältnis setzen.
C wie Mindset
Man darf das Mindset von Entwickler:innen nie unterschätzen. Entwickler:innen lieben es, neue Dinge zu lernen. Deshalb ist Antwort C nicht abwegig. Fast ein Viertel der Entwickler:innen gibt an, dass sie gerne in einem Umfeld arbeiten möchten, von dem sie lernen können.
Deshalb sollten Unternehmen auch mal über das Skillset hinausschauen. Gute Entwickler:innen bringen Lernbereitschaft, Eigenmotivation und Problemlösungs-Fähigkeiten mit. Und wenn es im Unternehmen noch kurze Entscheidungswege gibt und man an der Produkt-Roadmap mitwirken kann, stehen alle Zeichen auf Erfolg.
Fazit
Deshalb sollte man sich bei der Einstellung von Entwickler:innen nicht nur Gedanken über den Tech Stack machen, sondern auch die Geschäftslogik und das Mindset berücksichtigen. Das heißt: Ein klares, gemeinsames Ziel definieren und die Entwickler:innen in die Roadmap einbeziehen. So stellt man nicht nur erfolgreich neue Entwickler:innen ein - so schafft man auch Vertrauen und Commitment. Denn ein ambitioniertes Software Team, das ein Ziel vor Augen hat, findet eine Lösung für jede Herausforderung.
