Was ist die normale Fluktuationsrate unter Entwicklern und wirkt sie sich auf die Produktivität aus?

Kein Technikfreak, aber wissen Sie, dass Technikfreaks hier zu finden sind, also frage ich hier. Ich bin eine relativ neue generalisierte HR-/Talentbeschaffungsperson bei einer Bank, wo wir immer mehr Entwickler einstellen müssen, und ich wurde kürzlich zu diesem Projekt versetzt. Wir haben insgesamt etwa 25 Entwickler und müssen etwa 35 pro Jahr beschaffen.

Die Einstellung wurde zu einem Projekt, weil die Gruppe von Projektverzögerungen geplagt ist und weil ein leitender Manager den Manager der Technologiegruppe angeschrien hat, weil er Projekte nicht rechtzeitig liefern konnte. Das löste eine Beschwerde aus, und da der Manager eine Frau und der Senior Manager ein Mann ist, muss dieses Problem mit dem Schreien behoben werden. Manager möchte mehr Entwickler, da alle neu in der Codebasis sind.

Für mich ist diese Fluktuationsrate verrückt und ich denke, dass in der Abteilung selbst etwas nicht stimmt. Das ist sowieso mein Instinkt. Ich kann sehen, dass es viele Verzögerungen beim Onboarding von Entwicklern und so weiter verursacht. Aber der Entwicklerfreund, den ich im Team habe, sagt, dass "wir glücklich sind, sie so lange zu behalten." Er ist erst seit 6 Monaten hier und hat nach Referenzen gefragt.

Ich bin in Toronto, Kanada, für alle, die fragen.

Kommentare sind nicht für längere Diskussionen gedacht; Diese Konversation wurde in den Chat verschoben .
Ich wollte dies, insbesondere den Titel, bearbeiten, da er nicht wirklich mit den Antworten unten übereinstimmt, aber ich bin mir nicht sicher, was Sie hier eigentlich erreichen möchten. Ist es einfach zu bestätigen, ob diese Fluktuationsrate verrückt ist? Oder möchten Sie auch herausfinden, wie Sie die Ursache finden / das Problem beheben können?
Weiß Ihr Management, dass es nicht dazu da ist, die Mitarbeiter zur Einhaltung von Fristen zu zwingen, sondern alles in ihrer Macht Stehende zu tun, damit die Mitarbeiter optimal arbeiten können, um die Frist einzuhalten? Ich denke, das Problem ist, dass Ihr Manager denkt, er kann einfach sitzen und warten, während Sie in Problemen ertrinken, anstatt tatsächlich das Management zu übernehmen, um Ihnen zu helfen. Das Problem liegt nicht auf der Entwicklerseite.
Interviews beenden. Was sagen Sie? Das wird Ihnen die Antworten geben, die Sie brauchen.
@Lilienthal Das war der Grund für meine enge Abstimmung. Die im Titel gestellte Frage ist zu spezifisch, um eine angemessene Frage-und-Antwort-Antwort zu geben, und hat eine Reihe interessanter Antworten auf benachbarte Fragen gesammelt, ohne die gestellte Frage zu beantworten.

Antworten (10)

Was ist die normale Fluktuationsrate unter Entwicklern?

Deine Fluktuationsrate erscheint mir verrückt. Es ist eher das, was ich von Callcenter-Agenten erwarte. Wenn Sie wirklich meinen, Sie müssten 35 Mitarbeiter anwerben, um Ihre konstanten 25 aktiven Entwickler zu halten, hätten Sie eine Fluktuationsrate von 140 %. Sollte zwischen 10 und 20 % liegen. (Im Jahr 2017 fand ich im IT-Bereich eine Gesamtfluktuationsrate von 16 % für Deutschland und (2) 18 % in den USA im Jahr 2016)

und wirkt es sich auf die Produktivität aus?

Ja, es wirkt sich stark auf die Produktivität aus. Nur eine schnelle Schätzung:

  1. Ihre neuen Entwickler müssen den Tech-Stack, den Entwicklungsprozess, die Geschäftsanforderungen usw. lernen. Nehmen wir an, das kostet sie in den ersten 6 Monaten die Hälfte ihrer Zeit (100 % - 0 % in einer linearen Degression). Das sind ~3 verlorene Monate genau dort.

  2. Die richtige Arbeitsatmosphäre, Teamdynamik und Büroeinrichtung kann sich stark auf die Produktivität eines Entwicklers auswirken – einige Untersuchungen (1) legen einen Faktor von 10 nahe!

Wenn Ihr durchschnittlicher Entwickler also nur etwa 8,5 Monate bleibt, um zu lernen, und dann schnell demotiviert wird, hat Ihr 25-köpfiges Team ungefähr die Produktivität eines glücklichen und professionellen Teams von 2-3 Entwicklern!


Edit wegen Kommentaren: Einige Jobs haben einfach eine höhere natürliche Fluktuationsrate. Typischerweise handelt es sich dabei um Niedriglohnjobs mit geringer Qualifikation. Diese Jobs werden oft von Leuten übernommen, bis sie etwas Besseres haben, zum Beispiel von Studenten usw. Das heißt nicht, dass das überall gut ist. Das Ersetzen eines Mitarbeiters kostet Sie immer Geld und schadet normalerweise sowohl der Qualität als auch der Produktivität!

Jedes Unternehmen, das Menschen als entbehrlich betrachtet, schadet sich selbst!

Wenn Sie mit dem Management darüber sprechen, hilft es manchmal, dies monetär auszudrücken. Abgesehen von den Rekrutierungskosten investieren Sie im Laufe der Zeit auch Geld in die berufliche Entwicklung und das Erlernen von Domänenwissen jedes Mitarbeiters. Das ist das Humankapital des Unternehmens. Sobald der Mitarbeiter kündigt, verlieren Sie diese Investition. Das ist ungefähr so, als würden Sie auf einen Ölwechsel in Ihrer Firmenflotte verzichten und stattdessen Ihre Fahrzeuge alle halbes Jahr kaputt gehen und ersetzen lassen. Auf diese Weise können Sie leicht Millionen verlieren!


Außerdem wollen Sie nicht auf null Fluktuation kommen. Ein kleiner Zufluss an neuen Ideen tut gut und nicht alle passen für immer ins Team. Das Gefährliche ist, dass Sie in einem so giftigen Arbeitsumfeld wahrscheinlich die guten Leute verlieren und nur diejenigen behalten, die keinen besseren Job finden oder einen Weg gefunden haben, weiter bezahlt zu werden, während Sie sich so weit von dem Unternehmen distanzieren, das sie nehmen wenig Interesse an seinen Zielen (sie haben innerlich gekündigt). (3)


(1) Wie im Buch „Peopleware“ von Tom de Marco und Timothy Lister erklärt

(2) https://www.glassdoor.com/employers/blog/turnover-retention-rates/

(3) Blog-Artikel über den Verlust des Talents, danke an @Josh Johnson

Sie können das wahrscheinlich weiter reduzieren, da ein Team von 2-3 Entwicklern effektiver kommunizieren kann als 25.
+1 für Lernanforderungen usw. Und eine großartige Gelegenheit, noch ein weiteres Buch zu erwähnen: The Mythical Man Month. Sie werden nie wissen können, wie viele Entwickler wie lange brauchen, um zu entwickeln [eine Software einzufügen], wenn Sie ständig neue Entwickler mit der Aufgabe beauftragen. Denken Sie nur daran, wie die Dokumentation aussehen soll , wenn Sie versuchen, mit so einem hohen Umsatz erfolgreich zu sein!
Um Ihre Antwort zu ergänzen, gibt es die zusätzlichen Kosten, dass bei so viel Umsatz mit so vielen Entwicklern die Codebasis wahrscheinlich scheiße aussieht (da es keine Möglichkeit gäbe, all diese Arbeit zu koordinieren). Selbst wenn die Managementprobleme gelöst sind, fühlt es sich an, als müssten alle Projekte in den Müll geworfen und von vorne begonnen werden, um nicht jeden neuen Mitarbeiter in Panik zu vertreiben. Und je länger sie die Lösung der Managementprobleme hinauszögern, desto höher werden die zukünftigen Kosten sein.
@Alexander Dein Link ist sehr interessant, aber er spricht von "normalem" altem Code, der seit einiger Zeit getestet wurde und funktioniert. Und eine Faustregel bedeutet, dass es meistens wahr ist, nicht immer. Die Kosten für das Refactoring müssen mit den Kosten verglichen werden, die entstehen, wenn man keinen Entwickler länger als ein paar Monate halten kann. Ich weiß, dass ich die Codebasis von OP nicht einmal für das Doppelte meines Gehalts mit einem Stock anfassen würde.
@Echox: Was ich tun würde, wenn dies mein Unternehmen wäre, würde ich das Team so arbeiten lassen, wie es ist. Gleichzeitig würde ich mir einen guten IT-Manager suchen, der befugt ist, ein externes Team von 3-4 Personen aufzubauen. Dann fing ich an, ihnen eine Aufgabe nach der anderen in der Reihenfolge ihrer Wichtigkeit zu geben, bis ich das ursprüngliche Team nicht mehr brauchte.
Sollten Entwickler wie Callcenter-Agenten betrachtet werden, da sie leicht ausgetauscht werden können?
@MapleLeafsFan: Ist das meine Antwort? Sorry, ich bin hier etwas geschockt! Niemand sollte als leicht austauschbar angesehen werden. Zumindest nicht, wenn Sie ein gesundes Geschäft wollen. Habe hier in Deutschland einige Zeit für ein Callcenter gearbeitet und tatsächlich eine statistische Auswertung gemacht. Das Ersetzen eines Agenten kostete uns ca. 10.000 €, daher war es ein Ziel, die Fluktuation zu senken, um echtes Geld zu sparen. Das Ersetzen eines Programmierers kostet Sie sicherlich zwischen 50.000 und 300.000, je nach Gehalt, Können und Zeit im Unternehmen. Abgesehen davon, dass es der Produktivität schadet, ist es verdammt teuer!
@MapleLeafsFan Nein. Nein, sollten sie nicht. Dies ist leider anscheinend eine verbreitete Einstellung unter einigen Managern und selbst ein führender Indikator für andere toxische Einstellungen und Praktiken am Arbeitsplatz.
@MapleLeafsFan nicht für die meisten Operationen; Unternehmen haben viel Geld verloren, indem sie versuchten, so zu tun, als seien keine Fachkenntnisse erforderlich. Sie sind näher an zugelassenen Fachleuten wie Rechtsanwälten und Buchhaltern, auch wenn der Beruf nicht zugelassen ist. Es gibt einen Grund, warum Google seinen Entwicklern mehrere Hunderttausend Dollar zahlt.
Ihre Antwort ist in Ordnung, aber es ist auch gut zu wissen, dass Deutschland etwas spezifisch ist, wenn es um die durchschnittliche Verweildauer von Menschen im Job geht. Nein, ich habe mir keine Statistiken angesehen, sondern in mehreren Ländern gearbeitet und in keinem anderen Land sind Jobwechsel so verpönt wie in Deutschland.
@BigMadAndy Haben Sie einige empirische Beweise, die Ihre Behauptung stützen? Ich arbeite seit 25 Jahren in Deutschland in der IT-Branche. Dass das verpönt ist, habe ich noch nie erlebt - abgesehen vom Job-Hopping, das überall verpönt ist, zumindest wenn man der Antwort auf die zahlreichen Fragen zu diesem Thema hier Glauben schenkt.
@BigMadAndy Ich finanziere eine Zahl für die USA von 18%, die ungefähr in meiner Reichweite liegt und wahrscheinlich weitgehend durch die in den USA üblichen Arbeitsgesetze "nach Belieben" erklärt werden kann, im Vergleich zu einer typischen Kündigungsfrist von 3 Monaten in deutschen Verträgen.
Der Prozess, bei dem gute Mitarbeiter auf grünere Weiden aufbrechen und die weniger talentierten Mitarbeiter mit weniger Aussichten zurücklassen, wird The Dead Sea Effect genannt brucefwebster.com/2008/04/11/…
@JoshJohnson Danke! Kenne diesen Begriff nicht. Werde es mir mal anschauen und eventuell in die Referenzen aufnehmen.

[...] die Gruppe von Projektverzögerungen geplagt wird und weil ein leitender Manager den Manager des Tech-Konzerns angeschrien hat, weil er Projekte nicht rechtzeitig liefern konnte und dies eine Beschwerde auslöste und weil der Manager eine Frau und der leitende Manager ist ein Mann ist, muss dieses Problem mit dem Schreien behoben werden.

Es ist absolut kein Problem mit Umsatz oder Entwicklern. Es ist eine giftige Umgebung und folglich ein falsches PM-ing-Problem!! Es muss so schnell wie möglich behoben werden, damit das Projekt gerettet werden kann .

Manager möchte mehr Entwickler, da alle neu in der Codebasis sind.

Das Brooks-Gesetz (danke @Benjamin, aber ich habe einen anderen Link verwendet) beweist, dass das Beste, was Sie tun können, um das Projekt zu beenden, darin besteht, mehr Personal einzustellen, in dem falschen Glauben, dass es die von Ihnen angesammelten Verzögerungen ausgleichen wird.

Jede neue Einstellung ist neu in der Codebasis, und jeder muss hochgefahren werden.

Lassen Sie mich ein ikonisches Zitat darüber hinzufügen, was in Ihrem Unternehmen passiert

Wenn Sie heute 9 Frauen schwanger bekommen, werden Sie am Ende von 9 Monaten 9 Babys bekommen, nicht 1 Baby nach einem Monat

Im Rahmen des Projektmanagements erfordert das Hinzufügen neuer Ressourcen das Anhalten einer vorhandenen Ressource aus der Aktivität (Codierung), um neue Mitarbeiter zu schulen. Dies hat den unmittelbaren Effekt, dass sich das Projekt verzögert, was das Gegenteil der Erwartungen Ihres Vorgesetzten ist.

Ein leidendes Projekt profitiert nicht von zusätzlichen Ressourcen, insbesondere in der Softwarebranche: Es leidet einfach unter den Neueinstellungen. Ich werde nicht absichtlich unhöflich sein, aber es klingt, als käme Ihr Management aus der Welt der Landwirtschaft und Landwirtschaft, wo Sie über Nacht einen neuen Mähdrescher mieten können.

Am Ende ist Ihr Umsatz verrückt, weil das Projekt Managementprobleme hat. Ich kann nicht auf die Details der Sanierungsstrategie eingehen, aber eine Neuverhandlung der Fristen wäre sicherlich meine erste Wahl. Und am Ende ist das Projekt an diesem Punkt so kritisch, dass es gerettet oder getötet werden muss.

Meiner Erfahrung nach können sich manche Projekte aus politischen oder Marketinggründen eine Verzögerung nicht leisten.

auch bekannt als en.wikipedia.org/wiki/Brooks%27s_law -> Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später
Das landwirtschaftliche Beispiel passt nicht. In der Corona-Krise fehlen deutschen Landwirten ausgebildete Erntehelfer aus Osteuropa. Die Ausbildung deutscher Studenten oder Arbeitsloser, die möglicherweise nach einigen Monaten (aufgrund der harten Arbeit) abreisen, kostet die Landwirte viel Zeit. Manche Landwirte wollen deshalb keine deutschen ungelernten Erntehelfer beschäftigen. Zumindest im Bereich Spargel und Erdbeeren ist dies der Fall. Ich weiß nicht, ob die Apfelernte ähnlich betroffen ist ... . Wie auch immer: Landwirtschaft ist ein schlechtes Beispiel ;-)
@daniel.neumann: Ich glaube, ich würde den Landwirtschaftsvergleich verteidigen. Gehen Sie von geschulten Erntehelfern aus, nicht von völlig ungeschulten. Wer auf einem Hof ​​Spargel pflücken kann, kann auf einem anderen innerhalb eines Tages produktiv sein. Aber selbst erfahrene, geschulte Programmierer haben eine Anlaufzeit von ca. 6 Monaten, um in einem anderen Software-Shop produktiv zu sein.
Das ist eine gute Antwort. Leider ist der Irrglaube, dass das Hinzufügen zusätzlicher Mitarbeiter ein verzögertes Projekt beschleunigen würde, in der IT, aber auch in anderen Funktionsbereichen/Branchen, unglaublich verbreitet.
„Heute 9 Frauen schwängern“ – glauben Sie mir, ich versuche es. Es ist schwieriger als es klingt!
@DanielR.Collins Du musst ausgebildete Spargelernter mit ausgebildeten Erdbeerernter vergleichen ;-) . Aber natürlich ist der Zeitrahmen für die Schulung der Erntehelfer kürzer.
Ein "Projekt", aus Lehrbüchern, ist A unique and unrepeatable resource demanding set of complex tasks that has novelty and risks [...]. Landwirtschaft ist kein Projekt, Zugfahren ist kein Projekt (erfordert aber Qualifikation und Zertifizierung), Stewarding eines Flugzeugs ist kein Projekt (Qualifikation für Flugzeugtyp erforderlich), Software ist immer ein Projekt

Wenn Sie sie mit 8 Monaten verlieren, entscheiden sie sich, mit 6 zu gehen.

Ich gehe davon aus, dass die meisten Menschen andere Jobs antreten. Es dauert normalerweise einige Zeit, einen anderen zu finden, der Teilzeit sucht und davon ausgeht, dass er etwas wählerisch ist. Sagen wir einen Monat, vorausgesetzt, sie sind ein guter Entwickler. Fügen Sie einen weiteren Monat hinzu, um einen Gehaltsscheck zu sammeln, während Sie auf den Beginn des neuen Jobs warten. Das macht die Entscheidung, nach 6 Monaten zu gehen.

Ihre Entwickler geben ihm im Grunde die Probezeit und entscheiden sich danach, woanders hinzugehen.

Aber der Entwicklerfreund, den ich im Team habe, sagt, dass "wir glücklich sind, sie so lange zu behalten."

Er kommentiert Ihr Unternehmen, nicht den Entwicklermarkt im Allgemeinen. Ich wette, er ist selbst auf Jobsuche.

Ob eine hohe Entwicklerabwanderung dem Projekt schadet, ich habe in den letzten 8 Monaten nur an einem System gearbeitet. Der andere Entwickler des Projekts ist seit einem Jahr hier. Das Projekt ist 4 Jahre alt. Ich würde schätzen, dass 1/4 der Arbeit, die ich geleistet habe, auf die eine oder andere Weise doppelt ausgeführt wurde, da wir nicht wussten, dass die Funktionalität bereits erstellt wurde. Problematisch genug für Sie?

"Ich wette, er ist selbst auf Jobsuche". Keine Notwendigkeit zu wetten, die Frage lautet "Er ist gerade 6 Monate hier und hat nach dem Verfahren nach Referenzen gefragt. "
So ein toller Punkt. Wenn man die normale Hochlaufzeit bis zur Produktivität von ~6 Monaten schätzt, führt dies zu der Möglichkeit, dass absolut niemand in letzter Zeit produktive Arbeit geleistet hat. Ich frage mich: Hat dieses Team jemals etwas geliefert?
@BenVoigt Ich habe es völlig versäumt, die nächste Zeile dort zu lesen. Ja, er ist schon auf dem Weg nach draußen...
@DanielR.Collins, meine Freunde bei Banken mussten schnell Code pushen, also vermute ich, dass die Antwort ja ist, aber ... Sie haben mir nicht viele Details über Code gegeben, aber ein anderer Freund ist Junior in einer Firma und sie eine Webseite haben, die 160 API-Aufrufe zum Laden macht, da sich niemand die Mühe gemacht hat, etwas zu konsolidieren. Also vermute ich, dass sie einfach alles versenden.

Wenn Sie die Frage stellen, ist klar, dass Sie wissen, dass Sie ein Umsatzproblem haben. Das sind keine neuen Informationen. Viele Antworten beziehen sich auf die Auswirkungen und die Beschreibung der Kosten, die mit dieser Art von Umsatz verbunden sind. Das sind alles wirklich großartige Informationen, und nichts davon hilft Ihnen, das Problem zu beheben.

Großartig, Ihr Problem hat enorme Auswirkungen und Sie müssen es beheben. Aber was ist dein Problem? Umsatz ist ein Symptom, nicht das Problem.

Sie haben ein Kulturproblem.

Sie haben Menschen, die einander weder vertrauen noch respektieren, und sie werden eindeutig auch nicht dazu ermutigt. Während die Statistiken den Umsatz für die Organisation zeigen, wie viele Leute haben Sie, die seit mehr als 5 Jahren dort sind? Dies können einige Ihrer Problembereiche sein. Was sind Ihre Entwicklungspläne? Wie stufen Ihre mittleren Manager Ihre einzelnen Mitwirkenden ein? Was ist ihr Weg zur Empathie für ihre Altersgenossen?

  1. Sie müssen feindseliges oder toxisches Verhalten sofort beseitigen.
  2. Identifizieren Sie Ihre ältesten Mitarbeiter. Sind sie vertrauenswürdig? Sind sie respektvoll? Wie heben sie die Menschen um sich herum? Wenn Sie diese Fragen nicht positiv beantworten können, dann ist dies Ihr erster Lösungspunkt. Sie müssen in Soft Skills, Führung und Empathie geschult werden. Wenn dies nicht der Fall ist, müssen sie ersetzt werden.
  3. Hören Sie sich die Schmerzpunkte an. Ihre einzelnen Mitwirkenden werden eine Menge Beschwerden haben. Binden Sie sie zu gemeinsamen Prozesspunkten zusammen und verwenden Sie diese, um die Prozessverbesserungen zu identifizieren, die diesen Schmerz lindern.
  4. Trennen Sie die Menschen von dem Problem. Beschreiben Sie das Problem jemandem, der keine Ahnung hat, wovon Sie sprechen. Verwenden Sie keine Namen; Verwenden Sie nur Rollen. Wenn Sie die Person nicht vom Problem trennen können, ist die Person das Problem .

Großartig, Sie haben begonnen, den Prozess zu reparieren - Was ist mit den Menschen?

Menschen wollen sich im Allgemeinen gebraucht und geschätzt fühlen. Sie möchten, dass ihre Arbeit für jemand anderen von Bedeutung ist. Sie wollen besser werden in dem, was sie tun, und sie wollen in der Lage sein, mehr zu tun. Sie erreichen dies durch ihre Manager und Vorgesetzten.

  1. Wie sehen Ihre Trainingsprogramme aus?
  2. Welche Förderungsmöglichkeiten gibt es?
  3. Wie werden erfolgreiche Aktionen belohnt?
  4. Wie werden Einzelpersonen für Fehltritte zur Rechenschaft gezogen?
  5. Wie wird ihre Arbeit zu einem wertvollen Ort?

Diese Fragen müssen Sie sehr überzeugend beantworten können. Wenn Sie das nicht können, dann verlassen Ihre Mitarbeiter das Unternehmen, weil das Unternehmen sie nicht so schätzt, wie sie geschätzt werden möchten.

Was ist mit den giftigen/wütenden Leuten?

Viele Leute werden Ihnen sagen, dass sie gefeuert werden müssen. Viele Menschen sind bereit, sie aufzugeben. Jemand, der wütend oder frustriert wird, ist jemand, der dir zeigt, wie wichtig er dir ist. Sie interessieren sich im Moment vielleicht nicht für die richtigen Dinge, aber sie investieren in das, was sie tun und wer sie in ihrer Position sind. Ich ermutige Sie, diese Menschen nicht aufzugeben. Ich habe in der Vergangenheit in meine toxischen Individuen investiert, und es hat sich in riesigen Dividenden ausgezahlt. Diese Leute sind zu meinen Leistungsträgern geworden.

  1. Sie müssen ihnen zuhören. Hören Sie ihre Probleme. Hilf ihnen, an ihnen vorbeizukommen. Das braucht Zeit. Es braucht Ermutigung.
  2. Verbinden Sie sie mit ihren Kollegen. Informieren Sie sie darüber, wie sich ihr Verhalten auf die Menschen in ihrer Umgebung auswirkt. Erwarte besseres von ihnen. Sag ihnen, dass das nicht akzeptabel ist und dass du ihre Hilfe brauchst.
  3. Finden Sie ihre Wertpunkte und helfen Sie ihnen, sie zu erreichen. Wenn es darum geht, vor einem Kunden zu arbeiten, tun Sie, was Sie können, um ihm dabei zu helfen. Wenn es mit anderen Bereichen der Organisation interagiert, finden Sie Möglichkeiten, dies zu verwirklichen.
  4. Identifizieren Sie ihr toxisches Verhalten und gehen Sie sofort darauf ein, wenn es passiert. Du musst die Leute nicht hämmern. Machen Sie einfach deutlich, dass Sie zuschauen und Besseres erwarten.

Wow, hier gibt es viel zu tun. Bin ich das Problem?

Du könntest es sein. Es ist möglich, dass sie dem Unternehmen oder der Führung nicht vertrauen. Wenn Sie im Management sind, ist es wichtig, dies zu erkennen. Dies ist oft darauf zurückzuführen, dass die Führungsbotschaften nicht mit den Führungsaktionen übereinstimmen. Oft ist es nur die Wahrnehmung von Respektlosigkeit, die mit der Trennung von Informationen einhergeht.

  1. Seien Sie gegenüber Ihren Mitmenschen so ehrlich und transparent wie möglich.
  2. Die Führung muss eine kohärente und konsolidierte Botschaft aufrechterhalten.
  3. Das Management muss ihre individuellen Beiträge respektieren und alles tun, um sie anzuheben.

Servant Leadership hat bei mir immer funktioniert. Wenn Ihre einzelnen Mitwirkenden glauben, dass die Arbeit des Managements zu ihrem Nutzen getan wird, werden sie Berge heben. Es braucht Ehrlichkeit. Es braucht Glauben. Wenn von Menschen erwartet wird, dass sie sich nach einem höheren Standard verhalten, müssen ihre Führungskräfte diesen Standard vorleben. Wenn Sie möchten, dass Ihre einzelnen Mitwirkenden respektvoll und einfühlsam sind, dann müssen Sie respektvoll und einfühlsam sein. Wenn Sie wollen, dass sie hart arbeiten, müssen Sie hart arbeiten. Sie werden die Kultur kultivieren, die Sie verdienen, nicht die Kultur, die Sie wollen.

Bis die Kultur feststeht, werden die Leute weiterhin gehen und der Umsatz wird weiterhin auf epischen Niveaus liegen.

Wenn ich nicht bereits in einem großartigen Team arbeiten würde, würde ich sofort für Sie arbeiten.
@psaxton - Danke, das weiß ich zu schätzen.
Ich glaube, ich habe ein ganz anderes Verständnis von toxic people. In meinen Augen gibt es einen großen Unterschied zwischen Menschen, die sich ärgern/beklagen/kritisieren/... und Menschen, die tatsächlich Gift für die Umwelt sind. Die Arbeit mit Beschwerdeführern kann Ihnen tatsächlich ihre Loyalität verschaffen und Ihnen helfen, sich als Organisation (oder als Einzelperson) erheblich zu verbessern. Tatsächlich toxische Personen (und davon gibt es wenige) müssen jedoch einfach entfernt werden.
@fgysinreinstateMonica: Wenn Sie eine toxische Person nicht rehabilitieren können oder nicht bereit sind, den Aufwand zu investieren, der erforderlich ist, dann - Ja, das ist absolut richtig. Wenn Sie Zeit und ein wenig Geduld haben, kann eine toxische Person rehabilitiert werden, und oft kann diese Person zu einer bedeutenden Wertquelle zurückgeführt werden. Hinzu kommt die Wertbeurteilung, ob der Wert am Ende die Investition wert ist. Ist der Reha-Versuch mehr oder weniger wert, als einen Ersatz zu finden? Ehrlich gesagt gibt es einige Personen, für die sich diese Investition nicht auszahlt.

Man braucht 35 Leute im Jahr, um 25 Stellen zu besetzen.

Selbst bei dem langweiligsten, unbefriedigendsten Job, den man sich vorstellen kann, sollten Sie am Ende einen Haufen Leute haben, denen das egal ist und die froh sind, morgens anzukommen, abends zu gehen und am Ende ihr Geld zu nehmen der Monat.

Das hast du nicht. Das bedeutet, dass Ihre Jobs die Leute nicht nur nicht anziehen, es gibt etwas, das die Leute aktiv vertreibt. Zwei Bosse, die ausnahmslos alle sexuell belästigen? Tatsächliche Gewalt am Arbeitsplatz? Ein übler Geruch im Büro, der mich an Tote unter den Dielen denken lässt? So etwas muss es doch geben. 140% Fluktuationsrate ist einfach nicht normal.

Wirkt es sich auf die Produktivität aus? Welche Produktivität? Ich würde da überhaupt keine Produktivität erwarten. Sie haben Neuankömmlinge, die die Umgebung erst lernen müssen – und es gibt keinen Erfahrenen, der ihnen etwas beibringen kann. Vier Monate lang keine Produktivität bei den neuen Leuten und reduzierte Produktivität bei den nicht ganz so neuen. Dann, wenn sie gerade bereit sind, etwas Arbeit zu erledigen, verlässt die vorherige Generation und die nächste Gruppe muss unterrichtet werden. Sobald das erledigt ist, haben sie genug und gehen. Es wird keine Arbeit geleistet.

Sie haben einige harte Arbeit vor sich. Ich würde sagen, Sie brauchen acht bis zehn echte Profis mit guten Gehältern, die sich durchsetzen, egal was passiert. Sie müssen freie Hand haben, um sich gegen Hindernisse zu wehren (z. B. wenn der CEO sie anschreit, um ihn oder sie ohne Angst vor Konsequenzen physisch zu entfernen). Mit freier Hand, um Entwicklungsentscheidungen zu treffen (falls Sie ein idiotisches Management haben, das die Ziele nicht eine Woche lang unverändert lassen kann).

35 Leute für 25 Plätze bedeuten nicht, dass sie ALLE ersetzen. Sie könnten leicht einen giftigen Mitarbeiter haben, der mit einem ernsthaft schlechten Management zurückbleibt.
@DarkMatter: Wenn sie nicht alle 8 Monate alle ersetzen, ersetzen sie alle 4 Monate das halbe Team. Das macht es kaum besser.
Ich gehe davon aus, dass sie einen Kern von 6-12 giftigen Mitarbeitern haben, ein dysfunktionales Management, und neue Leute brauchen 2-3 Wochen, um zu erkennen, wie schlimm das ist, und ein paar Monate, um eine neue Anstellung zu finden. Also ja, "besser" ist nicht das richtige Wort, aber das ist es wahrscheinlich.

Es gibt zwar keine perfekte Antwort auf die Frage "Was ist ein normaler Umsatz mit Entwicklern?" (es wird von Unternehmen zu Unternehmen unterschiedlich sein und jeder ist anders), würde ich sagen, dass Entwickler meistens versuchen werden, mindestens 2 oder 3 Jahre im selben Unternehmen zu bleiben, wenn sie können.

Es macht sich gut im Lebenslauf, man hat die Zeit, sich in das Thema einzuarbeiten und eine gute Beziehung zu Menschen aufzubauen. Nach 2 oder 3 Jahren können Sie den Job wechseln, um eine schöne Gehaltserhöhung zu erhalten und mit neueren Technikern an neuen Projekten zu arbeiten.

Wenn ein Entwickler nicht länger als ein Jahr bleibt, bedeutet das, dass ihm etwas nicht gepasst hat. Ein so früher Abgang könnte seiner Karriere schaden :

  • er wird sich in zukünftigen Vorstellungsgesprächen für einen so kurzen Aufenthalt rechtfertigen müssen.
  • Es wird schwierig sein, diese wenigen Monate Erfahrung in Gehaltsverhandlungen einzusetzen. Karrieretechnisch ist es verlorene Zeit.

Ich würde also sagen, dass jedes Unternehmen, das einen Umsatz von weniger als einem Jahr hat, Dinge wirklich, wirklich falsch macht. Aber dann geben die Antworten von Daniel und usr-local-ΕΨΗΕΛΩΝ bessere Erklärungen zu diesem Thema.

Es gibt Statistiken über den durchschnittlichen Umsatz in einem bestimmten Bereich. Das könnte man als "normal" ansehen
Es hängt vom Bereich, der Unternehmensgröße, der Erfahrung der Rekruten, dem Land ab ... Vielleicht findet jemand die Statistiken zum Umsatz von Junior-Entwicklern in Banken in Toronto (was genau die Situation von OP ist), aber ich habe Lust auf meine Antwort gibt einen ausreichend guten Durchschnitt.
Wenn der Branchendurchschnitt bei etwa 15 % liegt und Sie etwa 20 % haben, können Sie sagen, dass er höher als normal ist - vielleicht erklärt durch den regionalen oder demografischen Unterschied oder eher durch die Unternehmenskultur. Woher hast du auch, dass OP nur Junior-Entwickler einstellt?
Ich steige selbst als Entwickler ein. Ich betrachte eine 2-jährige Tätigkeit in einem Unternehmen als Minimum. Die einzigen Fälle, in denen ich früher gegangen bin, waren, wenn die Firma mich nicht unterstützen konnte (eine wurde geschlossen, die andere hatte keine Arbeit mehr für mich). Der einzige andere Grund, warum ich vorher gehen würde, wäre, wenn es eine wäre wirklich feindseliges oder giftiges Arbeitsumfeld, oder wenn etwas in meinem Privatleben passiert ist.
@Daniel Es ist nicht geschrieben, aber ich habe vermutet, dass es erfahrenen Menschen leichter fällt, giftige Unternehmen zu erkennen und sie zu meiden. Außerdem habe ich das Gefühl, dass wir viel zu viele Worte für die Einleitung zu meiner Antwort mit einem Satz ausgegeben haben. Sind Sie mit der 2- oder 3-Jahres-Schätzung nicht einverstanden? Möchten Sie etwas hinzufügen?
@Echox Ich möchte diese Frage positiv abstimmen, da sie die Perspektive der Mitarbeiter hervorhebt. Aber es ist einfach falsch zu sagen, dass es für mein Verständnis des englischen Wortes wie in (normal = einem Standard entsprechen; üblich, typisch oder erwartet.) kein "normal" für Schwankungen gibt. Ich würde auch sagen, basierend auf empirischen Daten und Erfahrungen, dass 2-3 Jahre für den ersten Job typisch sein können, aber der Branchendurchschnitt liegt eher im Bereich von 5-7+ Jahren.

Wenn Sie 35 Entwickler pro Jahr einstellen müssen, um 25 Positionen zu besetzen, bleibt Ihr durchschnittlicher Entwickler 8,6 Monate. Das ist in der Tat wahnsinnig kurz.

Fluktuationsraten wie diese können einen enormen Einfluss auf die Produktivität haben. Dazu tragen mehrere Faktoren bei:

  • Je nach Projektkomplexität und Erfahrung benötigt ein Dev zwischen einigen Wochen und einigen Monaten, bis er seine Höchstleistung erreicht, da er sich an die vorhandene Codebasis, seinen Co-Dev-Programmierstil, Unternehmensstandards, externes gewöhnen muss Komponenten und Sachen als solche. Nehmen wir zur Vereinfachung der Mathematik an, dass das Onboarding 2 Monate dauert und ein Entwickler 8 Monate bleibt. In 2 Jahren sind das 6 Monate Onboarding. Sie hätten 4 Monate Onboarding gespart, wenn er 2 Jahre geblieben wäre.
  • Auch der Rest des Teams muss sich an den neuen Entwickler gewöhnen. Dazu gehört alles, was Sie aus Projektmanagementgründen wissen müssen: Wie schnell ist er? Wie kompetent ist er? Kommuniziert er gut? Hat er besondere Bedürfnisse? Ohne all diese Informationen basiert Ihr Projektmanagement auf wackeligen Annahmen.
  • Eine hohe Fluktuation verstärkt einige typische Softwareentwicklungsprobleme, wie schlechte Prozesse oder schlechte Dokumentation. Wenn jeder weiß, was von ihm erwartet wird und sich sowieso mit der Codebasis auskennt, sind diese Punkte immer noch wichtig, aber Sie können Kompromisse eingehen. Wenn Sie dies in einer Umgebung mit hoher Fluktuation tun, wird jeder der vielen neuen Entwickler viele, viele Stunden seiner (und anderer!) Zeit damit verschwenden, herauszufinden, wie alles funktioniert und was genau er tun muss.
  • Wissen geht verloren und muss neu erworben werden. „Oh, Sie müssen wissen, wie man X und Y integriert? Nun, Dave hat das vor 2 Jahren gemacht, er hat sich einen Monat lang durch die Spezifikationen gegraben. Er ist gegangen, und alle, mit denen er jemals darüber gesprochen hat Wiederholen Sie es. Hier finden Sie die Spezifikationen ...".
  • Es ist viel schwieriger, Prozesse zu finden, die für Ihr Team funktionieren, da Ihr Team sehr unbeständig ist.

Der andere Teil Ihrer Frage, nämlich "Was ist die normale Fluktuationsrate unter Entwicklern", ist viel schwieriger zu beantworten. Also werde ich eine Art Framechallenge machen: Frag nicht, was eine normale Rate ist, frag, was deine Rate sein soll und wie du sie erreichen kannst. Ihr Unternehmen unterscheidet sich von allen anderen Unternehmen, sodass Ihre Antwort möglicherweise von der Norm abweicht. Es gibt sogar einige seltene Fälle, in denen eine hohe Fluktuation überhaupt kein Problem darstellt.

Notiz! Es basiert hauptsächlich auf Meinungen. Kann aufgrund meiner eigenen Erfahrungen und meiner Bekannten der Verzerrung durch „anekdotische Beweise“ unterliegen. Objektivere Annahmen finden sich im Abschnitt „Zusammenfassung“.

Ich möchte eine Antwort aus völlig entgegengesetzter Sicht posten.

Sie haben erwähnt, dass es sich um eine Bank oder ein anderes Finanzinstitut handelt. Es ist ganz normal, dass sie ein toxisches Arbeitsumfeld haben und eine große Fluktuation haben. Was sie im Gegenzug anbieten, ist ein etwas höheres Gehalt. Ich weiß nicht warum. Vielleicht haben einige Bankster immer noch die korrupte Denkweise, dass sie alles mit Geld bekommen können, oder dass Bankgeschäfte einfach so profitabel sind.

Ich werde ein wenig von meiner eigenen Geschichte erzählen. Ich arbeite seit kurzer Zeit (nur 4 Monate) in der Bankenbranche. Es war kurz nach dem Studium, weil sie Studenten über eine Art Karrieremarkt rekrutierten , der an meiner Universität organisiert wurde.

Ich kann sagen, dass das Gehalt ziemlich beeindruckend war, aber es bot keine Position, in der ich meine Fähigkeiten so entwickeln konnte, wie ich wollte, und das Umfeld war ein bisschen toxisch. Es hat mich dazu gebracht, meine Pläne zu ändern. Ich habe mich entschieden, einen Job mit niedrigerem Gehalt, aber besseren Möglichkeiten zum Erlernen neuer Programmiertools / -technologien und einem freundlichen Arbeitsumfeld zu finden.

Aber einige meiner Freunde blieben bei dieser Firma und es gefiel ihnen. Sie haben das Gehalt genossen und sich einfach an den stressigen Arbeitsplatz gewöhnt.

Ich habe auch einige Leute getroffen, die von meiner jetzigen zu meiner früheren Firma gewechselt sind, und es macht ihnen mehr Spaß. Es ist unglaublich, aber jeder hat seine eigenen persönlichen Vorlieben, die schwer zu bestreiten sind.

Zusammenfassung

Zusammenfassend lässt sich sagen, dass hohe Fluktuation unter bestimmten Bedingungen keine schlechte Sache sein kann:

  • Sie rekrutieren eine große Menge junger Arbeitnehmer, hauptsächlich frische Absolventen.
  • Sie verfügen über einen effizienten Onboarding-Prozess und Tutorials, die auf dem neuesten Stand und einsatzbereit sind. In der Regel werden Arbeitnehmer, die mittel- bis kurzzeitig gearbeitet haben und neu eingestellt werden, gerade jüngere Kollegen eingestellt. Veteranen bleiben auf ihre eigenen wichtigen Aufgaben konzentriert. Sie werden nur belästigt, wenn es nötig ist.
  • Die meisten Arbeitnehmer, die das Unternehmen verlassen haben, sind Personen, die dort weniger als 1 Jahr gearbeitet haben.
  • Menschen, die in ein bestimmtes Arbeitsumfeld passen, bleiben dort jahrelang.
  • Personen, die spezifische und wichtige Domänen-/Geschäftskenntnisse erworben haben, bleiben in der Regel im Unternehmen. Sie werden normalerweise durch eine höhere Gehaltserhöhung/Beförderung motiviert.
Uh... Sie sind also gerade in der Arbeitswelt und haben Erfahrung mit einer bestimmten Bank - und Sie sind bereit, nicht nur Bankjobs im Allgemeinen zu beurteilen, sondern auch, dass die Leute, die diese Jobs annehmen, von Gier motiviert sein müssen . Meine Güte. Meine Frau arbeitet bei einer Bank, und da herrscht die entspannteste Atmosphäre überhaupt. Ich habe Freunde, die in Banken Programmieren, und sie sagen, es sei eine ziemlich langweilige Kultur.
Ich stimme @Kevin darin zu, dass Fintech-Organisationen in ihren Umgebungen und Kulturen sehr unterschiedlich sind. Einige sind extrem entspannt und wirklich großartige Arbeitsplätze. Andere sind Haifischbecken.
Buah, ich habe in mehreren Branchen gearbeitet und würde Banking definitiv nicht als die schlechteste bezeichnen. Es ist auch schwierig, Dinge wie Kultur zu verallgemeinern. Ich habe einmal im selben Unternehmen in zwei Ländern gearbeitet, und die Kultur war sehr unterschiedlich (ich kenne die beiden Länder gut genug, um zu wissen, dass die Unterschiede in der Unternehmenskultur nicht auf den kulturellen Unterschieden zwischen den Ländern beruhten).

Bedenken Sie, dass Sie eine Diskrepanz zwischen dem, was Sie von den Leuten verlangen, und der Art und Weise, wie Sie einstellen und Dinge tun, haben. Technologie ist in der Regel keine weiche Wissenschaft. Wenn Sie das Unmögliche verlangen, werden die Leute aufhören. Stellen Sie also sicher:

  1. Dass die Erwartungen an Ihre Entwickler realistisch sind.
  2. Dass Ihre Mitarbeiter genügend Zeit haben, um diese Aufgaben auszuführen.

Was Tech-Ungewohnte nicht verstehen, ist: Nichts kann einen wirklich genau auf den anstehenden Job vorbereiten. Außer diesen Job zu machen. Jetzt ist es sehr schwer abzuschätzen, wie viel Zeit Sie benötigen würden, um produktiv zu werden. Aber es ist auch schwer, eine Aufgabe zu erledigen, die aus Ihrer Sicht unendlich groß ist.

Daher ist es sehr wichtig, dass Sie tatsächlich einen leitenden Entwickler haben, dessen Aufgabe es ist, Aufgaben in überschaubare Teile aufzuteilen. Und es hört sich wirklich so an, als hätten Sie Ihr gesamtes Koordinationstalent verloren, also gibt es niemanden, der die neuen Leute auf Touren bringt.

Die Lösung besteht wahrscheinlich nicht darin, die Anzahl der Menschen zu erhöhen, sondern sie zu verringern. Sie können nicht einfach in unendlicher Geschwindigkeit neue Entwickler reinpumpen. Sie werden es den wenigen, die effektiv arbeiten könnten, nur unmöglich machen, effektiv zu arbeiten.

Ein anderer kann ständig von sich ändernden Bereichen überwältigt werden. Mitarbeiter müssen wissen, dass sie etwas erledigen. Sie müssen also in der Lage sein, einen Teil der Arbeit zu übernehmen und diesen Teil der Arbeit zu erledigen. Nachdem der Chunk erledigt wurde, muss bestätigt werden.

Nur weil der Chunk nun als obsolet gilt, ist nicht die Schuld der Arbeiter. Es ist die Schuld der Führung. Der Arbeiter hat den Brocken erreicht, den er sich vorgenommen hat, und das sollte richtig sein. Zum Beispiel: Der Maler ist nicht schuld, wenn die Bürowand grün ist, als Sie ihn gebeten haben, grün zu streichen. Obwohl Sie vielleicht entschieden haben, dass es rosa sein sollte, nachdem er mit dem Malen begonnen hat. Der Maler kann nur Dinge ausführen, die vereinbart wurden. Trotzdem kann man nur so oft den Teppich unter die Person ziehen.

Die Leute können einfach gehen, weil Ihr Prozess nicht funktioniert.

Ich habe in einer Reihe von Unternehmen in mehreren Ländern gearbeitet; Meiner Erfahrung nach erwarten Entwickler normalerweise, dass sie 2-3 Jahre in einer Rolle bleiben; sie suchen dann eine Beförderung oder gehen. In den meisten Unternehmen, in denen ich gearbeitet habe, schien dies zu einer jährlichen Fluktuationsrate von etwa 20 % zu führen; Wir könnten das reduzieren, indem wir die finanziellen Belohnungen erhöhen, die Möglichkeiten zur Karriereentwicklung verbessern und coole Projekte finden, an denen die Leute arbeiten können.

Die Ausnahmen waren Unternehmen mit einem Kulturproblem - wie andere Antworten andeuteten, haben Sie ein Kulturproblem.

Sie haben auch ein Teufelskreisproblem.

Senior management have high, possibly unrealistic expectations.
They put pressure on middle management to deliver against those expectations.
Middle management tries what they can; adding more developers (thus bumping into Brooks' law), and then shouting.
Shouting leads to reduced morale among the team.
Reduced morale reduces productivity - unhappy people don't work as hard.
Reduced morale causes people to leave, which also reduces productivity.
Growing the team leads to a reduction in productivity through recruitment efforts, and Brooks' law.
Reduced productivity further increases the gap between expectations and output.

Ausspülen und wiederholen...

Diesen Kreislauf zu durchbrechen ist unglaublich schwer. Diese Art von Umfeld schafft Anreize für die Menschen, in die Politik zu investieren, anstatt in die Umsetzung – die Überlebensstrategie lautet „nicht für schlechte Ergebnisse verantwortlich gemacht werden“ statt „für gute Ergebnisse zu arbeiten“.

Es reicht nicht aus, mit dem Geschrei aufzuhören (notwendig, aber nicht ausreichend) – das Team wird weiterhin auf die Anreize reagieren und gehen, wenn ihm die Umgebung nicht gefällt. Entwickler in Toronto haben viele Möglichkeiten.

Der erste Schritt besteht darin, sich von der Geschäftsleitung bestätigen zu lassen, dass Sie ein Problem haben und dass das Weitermachen mit dem, was Sie tun, nicht dazu führen wird, dass sich das Projekt auf magische Weise von selbst löst. Kulturelle Probleme und Teufelskreise erfordern normalerweise die Geschäftsleitung, um den Wandel voranzutreiben – meistens definieren sie die Kultur, und sie haben die Hebel, die sie ziehen müssen, um den Teufelskreis zu durchbrechen.

Der beste Weg, den ich kenne, um den Teufelskreis zu durchbrechen, besteht darin, einen Weg zu finden, die Erwartungen zurückzusetzen und den Entwicklern ein erreichbares Ziel zu geben. Ich habe einmal eine Situation wie diese geerbt, und wir waren uns einig, dass wir, anstatt uns über den gesamten 18-monatigen Projektumfang Gedanken zu machen, einen Zeithorizont von 3 Monaten wählen und uns darauf einigen, was wir in diesem Zeitrahmen tun könnten. Wir haben zwischen dem Management und den Entwicklern ein „Muss/Soll/Werde nicht“-Set von Ergebnissen ausgehandelt und vereinbart, wie die von den Entwicklern angesprochenen Probleme gelöst werden können („Die Anforderungen sind nicht gut genug“, „Wir bekommen nie nützliches Feedback“, „Das Büro ist zu laut“) usw. Wir haben dieses 3-monatige Miniprojekt genutzt, um die Kultur neu zu setzen und ein bisschen Vertrauen wieder aufzubauen.