Zufriedene Mitarbeiter kann man nicht abwerben. Andere Mitarbeiter sind hingegen weniger glücklich und damit ein Einfallstor für Headhunter mit den entsprechenden Folgekosten einer Neueinstellung: Unruhe im Unternehmen, Verteilung der Aufgaben an andere Mitarbeiter, Stellenausschreibung, Jobportale, Vorstellungsgespräche, und ggf. die Kosten für den Headhunter.
In unserer Reihe Kündigungsgründe stellen wir häufige und / oder für uns interessante Motive vor, die unsere Kandidaten zum Jobwechsel bewegen. Unser Ziel ist es, bei Arbeitgebern ein besseres Verständnis für die Bedürfnisse der Mitarbeiter und die Situation im eigenen Unternehmen zu schaffen. Schafft man es, diese zu verbessern, sinken die Risiken einer Abwerbung deutlich. Allerdings ist das gerade beim Thema technische Schuld ein schwieriges Problem.
„Und, warum wollen Sie eigentlich den neuen Job? In dieser Firma?“
Diese Standardfrage bringen wir bei Sachsentalent in der einen oder anderen Form seit mehr als drei Jahren bei jedem Kandidaten-Interview. Unser Kunde will schließlich wissen, warum jemand ausgerechnet zu diesem Unternehmen wechseln möchte. Von Interesse ist auch, ob die Erwartungen im neuen Unternehmen überhaupt erfüllt werden können. Hier haben wir von kurzen Stichworten bis hin zum 15minütigen Vortrag schon so ziemlich alles erlebt. Eine der auf den ersten Blick weniger offensichtlichen Begründungen für einen Wechsel innerhalb der IT-Branche sind technische Schulden, die im Laufe der Zeit angehäuft werden. Doch was bedeutet dieser Begriff überhaupt?
Technische Schuld
Der Begriff wurde ursprünglich von Marc Cunningham geprägt, um Nicht-ITlern im Management deutlich zu machen, dass Abkürzungen auch in der Software-Entwicklung negative Konsequenzen haben können. Nimmt ein Unternehmen monetäre Schulden auf, um ein Projekt zu finanzieren, reduziert es mittelfristig seine finanzielle Stabilität, wenn die Schulden nicht abgetragen werden. Gerade in der Software-Entwicklung sind derartige Schulden für Außenstehende oft nicht konkret erfassbar. Hinzu kommen oft die üblichen Verdächtigen: Enge Deadlines, die nächsten Projekte sind schon im Anmarsch, und es gibt zu wenig Leute für zu viel Arbeit. Also wird etwas gestrickt, von dem alle im Team wissen, dass es eigentlich nicht zu 100% okay ist, aber erst mal seinen Zweck erfüllt. Geschieht dies über einen längeren Zeitraum, wachsen die technischen Schulden. Die Gefahr steigt, dass Bug-Fixes an einer Stelle unerwünschte Nebenwirkungen an anderer Stelle hervorrufen und schon flackert das Dashboard in munterem Kirschgrün. Die Vermeidung unerwünschter Interaktionen im stetig wachsenden Code bzw. die Behebung derselben reduziert jedoch die Produktivität der Entwickler. Schließlich muss mehr Zeit in das Flicken des bestehenden Codes investiert werden, die nicht mehr für neue Projekte zur Verfügung steht. Das Entwickler-Universum zerstört sich selbst. Doch wie kommt es eigentlich zu technischen Schulden, obwohl Cunningham schon Anfang der 90er davor warnte?
Vom Start-Up zum Grown-Up zum seelenlosen Großkonzern
Jedem Anfang wohnt ein Zauber inne, wusste schon Goethe. Wovon Goethe allerdings nicht wissen konnte, ist die extrem schnelle Unternehmensentwicklung, die gerade in der IT so manches Unternehmen durch die Decke gehen lässt.
Start-Up: 3 Entwickler (x/y/*), 5 Pizzen und 8 Rechner
Und eine Vision. Die ersten Kunden. Und gleich mit großen Projekten. Nachtschichten werden eingelegt, Pizza- und Kaffeekonsum steigen. Die ersten Kunden werden als Referenzkunden genutzt, weitere Kunden werden gewonnen, im Büro riecht es allmählich ein bisschen strenger.
Die weiteren Kunden wünschen sich Erweiterungen, das sind gute Impulse. Die Software hat wirklich Potential. Jemand kennt jemanden aus der Uni, der macht jetzt auch mit. Der Gründer trägt nun ganztags Augenringe wie ein Waschbär. Weitere Kunden.
Ein erster Investor ist interessiert und kann überzeugt werden. Die Finanzen werden systematisiert, eine Projektassistenz reanimiert die Büropflanze. Der Vertrieb wird systematisiert, ab und zu muss der IT-Leiter trotzdem noch als Deko mit zum Akquise-Termin. Weitere Kunden, weitere Anpassungswünsche, weitere Erweiterungen. Features werden für alle ausgerollt, diesmal soll es keine Extrawürste geben. Sauberer Code, für immer, schwören sich IT-Leiter und CEO beim letzten Glühwein der ersten Weihnachtsfeier.
Grown-Up: Coole Leute, coole Story, da wollen Entwickler arbeiten
Die Firma ist cool. Professionelles Marketing, nach innen und außen. Coole Leute, coole Story, da will man arbeiten. Weitere Investoren wurden gewonnen, der Markt wird global. Allerdings kriechen nun auch die ersten Wettbewerber aus den Löchern und fangen an, den Markt mit me-too-Produkten zu fluten. Nun geht es um die Wurst, denn Marktanteile müssen gewonnen und gehalten werden. Die Investoren haben klare Benchmarks. Und es kommen weitere Kunden. Da kann man einfach nicht mehr jedes kleine Detail abarbeiten. Aber das machen wir irgendwann, das ist wichtig, nächstes Jahr nehmen wir uns dafür Zeit, wirklich! Man sieht dem IT-Leiter übrigens gar nicht mehr an, dass neulich der Server geschmolzen ist. Nur dieses leichte Zucken im Augenlid hört einfach nicht mehr auf. Früher gab es mal Coding Dojos, aber heute sind einfach alle zu müde. Und warum brauchen die Neuen eigentlich so lange, um sich in den Code reinzuarbeiten?
Ein seelenloser Großkonzern: Entwickler haben keine Lust mehr
Ist es IBM? Ist es das Katasteramt? Nein, es ist das Start-Up, das mal cool war. Nun ist es ein Unternehmen mit 5 Management-Ebenen. Was früher durch den Entwickler einfach so entschieden werden konnte, muss nun durch 5 Meetings und ca. 30 Mails, klappt aber trotzdem nicht. Dafür kümmert sich nun jemand hauptberuflich um die Pflanzen. Von Außen sieht es immer noch cool aus, doch die ersten Entwickler haben keine Lust mehr. Man hört immer öfter ein leises: „Es ist einfach nicht mehr so wie früher“. Tja. Und dann kommen wir.
Technische Schuld als Kündigungsgrund?!
Entwickler sind inhaltlich getrieben. Entwickler wollen gute Arbeit leisten. Wenn Entwickler keine gute Arbeit leisten können, werden Entwickler unglücklich und Personalberater glücklich. Mittendrin wird auch Customer Care unglücklich und irgendwann auch der Controller. Technische Schuld ist –sehr hart formuliert- Verrat am Produkt und damit am Kunden, der in gutem Glauben für eine gut gemachte Software zahlt. Es ist aber auch Verrat an den eigenen Entwicklern und an der Vision vom Unternehmen.
Entwickelt sich das Unternehmen nicht organisch und / oder gut geplant, jagt ein bottleneck den nächsten, auch in der IT. Was beim Start-Up noch irgendwie witzig rüberkommt, weil sich alle die gleiche Pizza teilen und den Code noch überblicken, kann bei 30 Entwicklern zum Horrortrip werden. Wir kennen Software-Unternehmen, die trotz eines extremen Wachstums in der Lage waren, ihren Code unter Kontrolle zu halten. Wir kennen aber auch Unternehmen, die in ihrem Wachstum weder die Entwickler noch ihr Produkt in die nächste Phase mitgenommen haben. Und so hören wir immer mal wieder: „Es ist nicht mehr wie früher.“ Oder: „Ganz ehrlich, die technischen Schulden sind riesig, es ist einfach zu viel.“ Oder auch: „Ich hab da keine Lust mehr. Jedes Update ist der Horror. Keine Sau weiß, was damals warum wie gemacht wurde. Ich hab versucht, das anzusprechen. Es ändert sich nichts.“ Weitere nachdenklich machende O-Töne gibt es hier.
Und die Moral von der Geschicht –
– ignoriere den Entwickler nicht.
Wir sind als Personalberatung natürlich inkompetent, was die konkrete Vermeidung von technische Schuld anbelangt. Allerdings sehen wir, dass extremes Unternehmenswachstum zu schlechten Kompromissen beim Produkt führen kann (nicht nur in der IT…) Der weitere rasante Unternehmenserfolg kann dann verhindern, dass technische Schulden abgetragen werden. Das Unternehmen benötigt immer mehr Entwickler und wird trotzdem weniger produktiv. Und damit weniger attraktiv als Arbeitgeber. Hier kommen natürlich auch Themen wie Unternehmensorganisation, Kommunikation und individuelle Entwicklung der Devs ins Spiel, doch die Quintessenz, auch für HR bleibt: Wenn der Maschinenraum permanent überlastet oder die Software „historisch“ ist, sind Eigenkündigungen deutlich wahrscheinlicher. Mehr zu Mitarbeiterzufriedenheit und weiteren Management-Themen finden Sie hier