Entwickler können nicht sehen, was sie falsch machen

Ich möchte, dass sie verstehen, warum ich etwas tun möchte. [...] Irgendein Rat?

Theoretisieren Sie nicht, zeigen Sie es ihnen.

Ihre derzeitige Geisteshaltung ist, dass sie wissen, was sie tun, funktioniert . Und Sie kommen rüber und sagen ihnen, dass das theoretisch schlecht ist. Sie werden niemals jemanden überzeugen, indem Sie sagen, dass er einen schlechten Job macht , während Sie einen viel besseren machen könnten . Das kann jeder sagen. Es ist, als würden Leute auf ihrer Couch vor dem Fernseher sitzen und Profisportler anschreien, dass sie dieses Spiel hätten besser machen können.

Wenn Sie möchten, dass sie Ihnen folgen, gehen Sie mit gutem Beispiel voran. Wenn Sie etwas sehen, das verbessert werden muss, zeigen Sie ihnen, woran es scheitert. Bieten Sie ihnen eine praktische Lösung aus der realen Welt.

Sie möchten einen Kodex, der mehr von den SOLID-Prinzipien einhält? Geben Sie ihnen dann ein praktisches Beispiel, warum der aktuelle Code nicht optimal ist („Wenn ich das mache, geht er kaputt“) und schlagen Sie dann eine echte Alternative vor („Ich habe es so geändert, jetzt kann es nicht mehr passieren“).

Sie haben viele Regressionsfehler, die bei besseren Tests nicht auftreten würden? Nun, stellen Sie eine Liste zusammen und lassen Sie sie jeden einzelnen von ihnen mit jeder Veröffentlichung testen. Das ist, was für das Geschäft notwendig ist. Und dann schreiben Sie einen davon als Unit-Test, zeigen Sie ihnen, wie einfach ihr Leben sein könnte, und lassen Sie sie entscheiden, ob sie ihre Zeit damit verbringen wollen, stundenlang manuell eine Liste von Tests durchzugehen, oder ob sie es automatisiert haben wollen Testsuite, die sie ausführen können, indem sie einfach mit den Fingern schnippen.

Der Punkt hier ist, ihnen nicht zu sagen, was besser sein könnte . Theoretisch könnte alles besser für sie sein, wenn sie nur im Lotto gewinnen würden. Wählen Sie einen bestimmten Fall aus, zeigen Sie ihm, warum er schlecht ist, und bieten Sie dann eine funktionierende Lösung an. Kein Schlagwort oder eine Theorie, sondern ein praktischer erster Schritt, den sie jetzt machen können.

Ihren Untergebenen einfach zu sagen, dass sie etwas tun sollen, von dem sie keinen Nutzen sehen, ist ein Rezept für eine Katastrophe, die Sie bereits anerkennen, also machen Sie ihnen Spaß. Gamification ist für Sie vielleicht nicht einfach, kann aber dazu beitragen, andere, rauere Stellen auszugleichen.

In einer Studie von Sharp et al. (2009) gehen die Forscher davon aus, dass der einflussreichste Faktor für die Motivation der Entwickler die Fähigkeit war, sich mit ihrer Arbeit zu identifizieren. Das bedeutet, dass die meisten Entwickler einen Sinn in ihrer Arbeit finden müssen, sonst sinkt ihre Motivation, weiterzuarbeiten.

https://medium.com/gameful-design/does-gamification-work-in-the-software-development-process-76780e49e545

Vielleicht möchten Sie auch etwas Zeit einplanen, um ihnen nicht nur zu zeigen, wie man etwas macht, sondern auch, wie es ihren Code verbessert, ihre Fähigkeit, ihn zu warten, und wie es ihren Entwicklungsprozess beschleunigen kann. Eine andere Antwort von nvoigt spricht darüber, aber ich sage es etwas anders: Show, don't tell.

Sie müssen wahrscheinlich langsam anfangen, z. B. 2-3 Stunden an einem Tag in der Woche. Beginnen Sie mit etwas, das ein komplettes Durcheinander ist oder einfach zu kompliziert und schwer zu verstehen ist. Vielleicht ist es etwas, an dem sie alle nur ungern arbeiten, aber zeigen Sie ihnen noch nicht, wie sie es beheben können. Verwenden Sie es einfach als Beispiel und zeigen Sie ihnen dann mit etwas anderem, etwas Einfacherem, wie kleine Verbesserungen am Code große Auswirkungen haben können. Wenn Sie in ein paar Wochen vielleicht 2-4 dieser kleinen Verbesserungen durchgearbeitet haben, bringen Sie es zurück zum "Monster-Chaos" und verwenden Sie die gleichen Techniken, die Sie ihnen zuvor gezeigt haben, um den Spaghetti-Code zu reduzieren, wiederzuverwenden und im Allgemeinen zu vereinfachen zeigte ihnen.

Vielleicht möchten Sie diesen Ansatz sogar wiederholen. Bringen Sie ihnen ein paar Dinge bei und wenden Sie es dann auf das "Monster-Chaos" an. Bringe ihnen noch ein paar Dinge bei und verwende es dann, um das Monster weiter zu verbessern. Aufschäumen, ausspülen, wiederholen.

Und machen Sie nicht alles selbst. Fragen Sie nach Möglichkeiten, den Code zu verbessern. Es ist nur teilweise ein Vortrag, Sie müssen Ihre Leute in den Prozess einbeziehen. Für richtige Antworten oder sogar enge Konzepte verteilen Sie Mini-Schokoriegel , wie Halloween-Süßigkeiten (das gute Zeug, nicht der billige Schrott). Dies gibt ihnen auch einen zusätzlichen Zuckerschub, damit das Gehirn besser arbeiten kann.

Möglicherweise stellen Sie fest, dass einige von ihnen bereits wissen, was Sie verwenden möchten, aber den Eindruck haben, dass dies nicht der Fall ist. Ich bin größtenteils ein autodidaktischer Programmierer. Ich habe im Laufe der Jahre viel recherchiert und verstehe alle möglichen Konzepte, aber ich kenne nicht unbedingt die Begriffe für diese Konzepte. (Aus diesem Grund habe ich kürzlich ein Interview bombardiert.) Sie verwenden die Konzepte möglicherweise bereits und denken, dass Sie sie nicht dafür erkennen. Oder sie verwenden sie falsch und benötigen nur geringfügige Anpassungen, um sie korrekt auszuführen, anstatt ihren Prozess zu überarbeiten. Es gibt viele verschiedene soziale oder kulturelle Probleme, auf die Sie möglicherweise stoßen, die die Ursache für die Reibung sind, anstatt dass es irgendetwas mit der Technologie zu tun hat.

Hilfe von außen

Es gibt auch viele Websites, die sich auf die spielerische Codierung konzentrieren, auch wenn sie nicht unbedingt SOLID oder die anderen Prinzipien lehren, die Sie zu implementieren versuchen. Sie müssen nur recherchieren, um einen zu finden, der dies tut. Ich habe CodinGame verwendet, um meine Programmierfähigkeiten zu verbessern, aber ich erinnere mich nicht genau, welche Prinzipien, wenn überhaupt, die Herausforderungen gelehrt haben. Es gibt viele Herausforderungen auf der Seite und die meisten werden von Mitgliedern gemacht, also werden sie ständig ergänzt, also könnte es etwas geben, das Sie verwenden können. Stellen Sie einfach sicher, dass Sie zuerst die Genehmigung erhalten, dies während der Firmenzeit zu tun. Und ja, es muss in der Firmenzeit erledigt werden, sonst werden es „Hausaufgaben“, die wahrscheinlich nicht gemacht werden.

Die Implementierung von Peer-Programmierung kann ebenfalls hilfreich sein. Wenn Sie einen Senior und einen Junior für die Arbeit an einer Aufgabe zusammenstellen, können beide neue Dinge lernen. Es kann ihnen auch helfen, eine Hürde beim Lernen zu überwinden. Dies kann dem 1-zu-1-Unterricht entsprechen, ohne dass Sie den Unterricht durchführen müssen. Außerdem ist eine der besten Arten zu lernen, zu lehren. Wenn Sie es jemand anderem erklären können, verstehen Sie es. Und je einfacher Sie es jemand anderem erklären können, desto wahrscheinlicher verstehen Sie es wirklich und wiederholen nicht nur, was ein Buch oder Artikel sagt.

Erzwingen Sie es nicht

Ganz gleich, was Sie tun, während Sie versuchen, Ihr Team dazu zu bringen, diese „neuen“ Prinzipien umzusetzen, machen Sie es als Entwickler überzeugend. Verwenden Sie keinen Performance Improvement Plan (PIP), wie eine andere Antwort vorschlägt. Die Arbeitsplätze von Menschen aufs Spiel zu setzen, ist fast ein garantierter Weg, sie dazu zu bringen, zu gehen, unabhängig davon, ob sie den PIP abschließen. Und wenn sie bleiben, werden sie Ihnen nicht vertrauen, dass Sie versuchen, weitere Änderungen und einen weiteren PIP zu implementieren. Genau wie jeder andere Teil des Lebens funktionieren Ultimaten selten und verbessern fast nie das Vertrauen.

Erklären Sie ihnen, wie es ihre Arbeit und ihr Privatleben verbessern wird. Ein offengelegtes/unverschlüsseltes Passwort kann zu Sicherheitsverletzungen führen, die dazu führen, dass sie rund um die Uhr daran arbeiten, alles zu patchen und wiederherzustellen, was durch den Hack verstümmelt wurde. Überlassen Sie dies nicht dem Zufall oder einem imaginären/unbestimmten fernen Zeitpunkt in der Zukunft, fragen Sie sie, wie sie reagieren würden, wenn dies während einer wichtigen Zeit in ihrem Leben passieren würde, wie einer Hochzeit, einem Urlaub, einem Kindersportspiel oder was auch immer. Machen Sie es zu einem praktischen Beispiel, das für sie relevant ist. Erinnern Sie sie dann daran, dass eine Reparatur jetzt diese Art von Katastrophe verhindert.

Erklären Sie, wie die Vereinfachung der Dinge ihre mentale Belastung bei zukünftigen Änderungen verringert. Erklären Sie, wie die Wiederverwendung derselben Methoden nicht nur den Code vereinfachen, sondern auch das Auffinden des gesuchten Codes erleichtern kann. Erklären Sie, wie Polymorphismus Codezeilen reduzieren kann und warum dies manchmal nicht angemessen ist. Ja, erklären Sie, dass einige der Konzepte, die Sie implementieren möchten, nicht immer notwendig sind oder die Dinge manchmal unnötig verkomplizieren. Erklären Sie auch, dass die meisten dieser Änderungen iterativ nach Bedarf vorgenommen werden können, nicht „nur weil ich es gesagt habe“. Die meisten dieser Konzepte sind nur „Faustregeln“ und nicht festgeschrieben, was wahrscheinlich das ist, wogegen sie sich wirklich wehren.

Sicher, das lässt die Tür offen für langsamere Veränderungen, aber das wird wahrscheinlich dafür sorgen, dass es besser funktioniert. Genau wie bei einer Diät, wenn Sie zu plötzlich zu viele Änderungen vornehmen, werden Sie die Diät schneller verlassen, als Sie sie begonnen haben, und Sie werden nie wieder auf die Diät kommen können.

Vorbehalt

Versuchen Sie nicht, zu viel auf einmal zu tun. Ich hatte einen Manager, der meiner Abteilung ein mehrere hundert Seiten umfassendes Buch über SOLID-Prinzipien gab und uns alle dazu brachte, es zu lesen. Es war so langweilig, dass ich es nicht einmal 5 Seiten geschafft habe, ohne einzunicken. Das war, während der Manager versuchte, uns dazu zu bringen, fast über Nacht einen sehr großen Teil unseres Codes zu ändern. Ja, wir mussten diese Änderungen vornehmen, aber es gab so viele Änderungen, dass wir nicht mit allen Schritt halten konnten. Und es war alles ein Befehl, ohne Raum für Fragen oder gar Erklärungen, was oder warum die Änderungen notwendig waren. Zusammen mit anderen bedeutenden Änderungen in der Einstellung des Managements führte dies dazu, dass ich nach 4 Jahren dort eine andere Stelle suchte.

Ihre Leute haben sich wahrscheinlich in ihren Positionen wohlgefühlt. Das ist nicht unbedingt eine schlechte Sache, aber die Änderungen, die Sie anstreben, machen sie unangenehm. Unbequem zu sein ist im Allgemeinen, wenn Leute Dinge lernen, aber machen Sie es nicht zu unbequem oder Sie werden Leute verlieren. Und Sie können sie verlieren, ohne dass sie tatsächlich einen anderen Job finden. Arbeiten Sie mit ihnen zusammen, wenn sie Probleme haben, und seien Sie verständnisvoll, wenn sie Vorbehalte haben.

Ich sage nicht, sie zu babysitten oder zu verhätscheln, sei einfach keine Mauer, an der alles abprallt und sie keine Antworten bekommen können.

Es hört sich so an, als ob Sie deswegen gestresst sind. Sie müssen diesen Stress aus sich herausholen. Hier ist, was ich empfehlen würde:

Es hört sich so an, als wüsste das Team nicht, wie wichtig all die technischen Probleme sind, auf die Sie hingewiesen haben. Es gibt zwei Möglichkeiten, Menschen verständlich zu machen:

1. Lassen Sie sie diese Probleme beheben und verfolgen Sie dann die Ergebnisse
2. Sie kümmern sich um diese Korrekturen und präsentieren die Ergebnisse

Letzteres hat bei mir immer funktioniert. Wenn Sie dies richtig machen und wenn das Team den Wert Ihrer Arbeit sieht. Sie sind natürlich gezwungen, sich in Zukunft darum zu kümmern.

Sie können einfach eines dieser technischen Probleme auswählen, mit denen Sie vertraut sind und bei denen Sie denken, dass Sie etwas bewirken können.

Legen Sie los und halten Sie uns auf dem Laufenden...

Sie müssen dieses Problem an mehreren Fronten angehen:

Bieten Sie zunächst an, für Kurse zu bezahlen, in denen die Praktiken und Gründe für deren Anwendung vermittelt werden. Bieten Sie jedem von ihnen, der Zertifikate verdient, einen Bonus und/oder eine Gehaltserhöhung an. Geben Sie dem nicht mehr als zwei Monate Zeit, um etwas Traktion zu bekommen. Sie werden vielleicht feststellen, dass einige von ihnen bereit sind, sich zumindest etwas Mühe zu geben.

Verschließen Sie die Datenlöcher. Sie brauchen Beweise, um Ihre Behauptungen zu untermauern. Alle Code-Check-Ins sollten einem Fehler, einer Funktion oder einer User Story zugeordnet werden. Fangen Sie an, die Zeit zu messen, die Sie für die Arbeit an diesen Fehlern und Funktionen aufgewendet haben. Fügen Sie häufige Post-Mortems hinzu. Sie alle müssen genau wissen, wie viel Aufwand für das Umschreiben von Code im Vergleich zum Hinzufügen von neuem Code für jede Aufgabe erforderlich ist. Gehen Sie zurück und analysieren Sie alte Fehler. Was war die eigentliche Ursache? War es ein Day-Zero-Bug oder wurde es eingeführt, weil „funktionierender Code“ verbogen wurde, um etwas Neues hinzuzufügen?

Beauftragen Sie einen Berater, um Ihre Codebasis und Ihre Entwicklungspraktiken zu überprüfen, und erstellen Sie eine Top-Ten-Liste der Dinge, die das Unternehmen beheben sollte.

Fangen Sie an, sich darauf vorzubereiten, Leute zu feuern. Bringen Sie zunächst einen leitenden Ingenieur auf Zeitbasis hinzu (vorzugsweise einen mit den genannten Zertifizierungen) und beginnen Sie mit ihm zusammenzuarbeiten, um einige der ungeheuerlicheren Probleme zu beheben. Nach ein paar Monaten, wenn die Aushilfe die Codebasis im Griff hat, stellen Sie sie ein und bringen Sie die nächste Aushilfe, dann feuern Sie den Entwickler, der am härtesten gearbeitet hat, um Ihre Bemühungen zu blockieren. Spülen und wiederholen.

Auf die eine oder andere Weise müssen Sie das richtige Team für den Job haben. Wenn es nicht die aktuellen Hacks sind, dann müssen Sie sie ersetzen. Während Sie ein Mentor sein und lebenslanges Lernen und kontinuierliche Verbesserung fördern können, ist es nicht Ihre Aufgabe, sie zu erziehen, da dies einfach nicht Ihre Fähigkeiten sind.

Vorwort

Da diese Frage auf Project Management Stack Exchange und nicht auf The Workplace oder einer anderen relevanten Website gepostet wurde, besteht die einzig gültige Möglichkeit, sie aus Sicht des Projektmanagements zu beantworten, darin, sich auf die Verantwortlichkeiten des Organisations- und Projektmanagements zu konzentrieren. Das bedeutet, viele der unwesentlichen Teile Ihrer Frage wegzuschneiden und sich auf die Kernaspekte des Projektmanagements zu konzentrieren, die entweder kanonische Antworten oder zumindest allgemein anerkannte Best Practices haben.

TL;DR

Möglicherweise sind Sie in eine dysfunktionale Organisation involviert oder auch nicht, aber Sie verstehen Ihre Rolle im Bereich des Projektmanagements sicherlich falsch und Ihnen fehlen möglicherweise die entsprechenden Fähigkeiten und die organisatorische Befähigung, um Ihre Arbeit erfolgreich zu erledigen. Ihr Hauptziel sollte es sein, sowohl mit Ihrem Führungsteam als auch mit Ihren Entwicklern zusammenzuarbeiten, um funktionale Arbeitsvereinbarungen auszubügeln, die die organisatorischen Ziele für das Projekt erfüllen, und gleichzeitig alle (einschließlich Ihnen) zu befähigen, den Prozess kontinuierlich zu verfeinern, bis er seine ergebnisbasierten Ziele erreicht .

Situationsanalyse

Ihre Frage enthält viel Material, das sich im Grunde auf einige Schlüsselelemente reduziert:

1. Möglicherweise haben Sie es mit einigen Unterschieden zwischen der in den USA ansässigen und der europäischen Arbeitskultur zu tun. Auch wenn dies kein direktes Problem ist, färbt es sicherlich einen Teil der Perspektive und des Rahmens Ihrer Situation, und Sie müssen diesen Aspekt des Problems anerkennen.
2. Der CTO übernimmt das Problem nicht und ist nicht bereit, direkte Autorität auszuüben. Wenn ein C-Level-Manager sagt, dass es den Leuten freisteht, zu kündigen (anstatt dass sie entlassen werden können), weigert sich diese Person, direkte Autorität auszuüben, und versetzt Sie in die Lage, das Problem durch Einfluss und nicht durch delegierte Autorität lösen zu müssen.
3. Ihr Entwicklungsteam widersetzt sich Ihrer empfohlenen Vorgehensweise, sei es in Form von Vorschlägen, Richtlinien, Designprinzipien oder was auch immer sonst in Frage kommt. Die Tatsache, dass sie dies auf eine Weise tun, die Sie als unhöflich empfinden, ist ein Hinweis darauf, dass Sie sich ihren Respekt weder durch delegierte Autorität noch durch Soft-Skill-Einfluss verdient haben. Das Endergebnis ist, dass Sie keine Möglichkeit haben, sinnvolle Veränderungen herbeizuführen, wenn dies überhaupt ein Unternehmensziel für Sie ist.
4. Aus Sicht des Projektmanagements spricht nichts in Ihrem Post Metriken, KPIs, Projektkontrollen oder irgendetwas anderes Messbares an. Veränderung ist hart und muss von einem Ort der Vision und durch die Anwendung aufgeklärten Eigeninteresses geführt werden. Projektmanagement als Fachmann ist oft eine schwierige Rolle, gerade weil es eine Rolle mit viel Verantwortung, aber sehr wenig direkter oder delegierter Autorität ist. Infolgedessen sind Projektmanager normalerweise am erfolgreichsten, wenn sie sich auf Projektkontrollen in Bezug auf Budget, Umfang, Zeitplan und Qualität konzentrieren und nicht auf architektonische oder technische Fragen.
5. Ihr Rollenverständnis bedarf der Klärung. Sollen Sie ein mittlerer Manager, ein Servant-Leader, ein Coach, ein Vordenker für Geschäftsprozesse oder etwas ganz anderes sein? Die Tatsache, dass Sie keine klare Vorstellung davon haben, wie Sie das Team führen sollen, und keine Anweisung von der obersten Führung, was Sie das Team führen sollen, sind immer Indikatoren für einen organisatorischen Prozess Problem.

Es gibt sicherlich viele andere Probleme, die durch Ihren Beitrag aufgeworfen werden, sowie die Art und Weise, wie Sie sie formulieren. Dennoch bin ich der festen Überzeugung, dass die obige kurze Liste die Mehrheit der umsetzbaren Probleme abdeckt und diejenigen, auf die Sie Ihre unmittelbare Energie konzentrieren sollten.

Empfehlungen

Es gibt keine vollständig kanonische Liste für Personen-und-Einfluss-Probleme, aber sie als organisatorische Probleme zu definieren, führt zu ziemlich eindeutigen Lösungen. Obwohl nicht vollständig, würde ich auf jeden Fall eine Kombination der folgenden Aktivitäten empfehlen:

1. Stellen Sie sicher, dass Sie von der Geschäftsführung klare Anweisungen zum Umfang Ihrer Befugnisse (falls vorhanden) sowie klare Erwartungen und Kennzahlen zur Bewertung Ihrer Leistung in der Rolle erhalten.
2. Jedes Problem, das nicht im Rahmen Ihrer Befugnisse oder Ihres Einflusses gelöst werden kann, sollte der Geschäftsleitung zusammen mit allen unterstützenden Kennzahlen und Empfehlungen klar mitgeteilt werden. Was sie mit diesen Informationen tun (wenn überhaupt), liegt in ihrer Verantwortung und nicht in Ihrer.
3. Denken Sie nicht in Begriffen des Änderungsmanagements, es sei denn, es wurde ausdrücklich zu Ihrem Job gemacht. Denken Sie in messbaren Ergebnissen . Arbeiten Sie mit dem Team zusammen, um die gewünschten Ergebnisse, Leistungskennzahlen, die den Fortschritt in Richtung dieser Ergebnisse messen, und alle erforderlichen Prozesskontrollen zu identifizieren, die zum Erreichen dieser Ergebnisse erforderlich sind. Mit anderen Worten, schaffen Sie eine gemeinsame Verantwortlichkeit für klar definierte Ergebnisse, anstatt zu versuchen, von oben nach unten Veränderungen herbeizuführen, die Sie ohne die aktive Zusammenarbeit des Teams nicht erreichen können.
4. Hören Sie auf, die Verantwortung für Probleme zu übernehmen, für deren Kontrolle Ihnen die Werkzeuge, Fähigkeiten, Befugnisse oder andere Mittel fehlen. Erstellen Sie gemeinsame Verantwortlichkeiten, wo immer Sie können, verweisen Sie andere Probleme auf die Organisationsebene, wo sie gelöst werden können, und stellen Sie sicher, dass alle Parteien (einschließlich Ihnen, den Entwicklern und dem CTO) absolut klar sind, wer in Ihrer bestehenden Organisation für was verantwortlich ist Kultur.
5. Denken Sie daran, dass Sie jetzt ein "Tech Project Manager" (was auch immer das in Ihrem Unternehmen eigentlich bedeutet) und kein Entwickler sind. So wie Sie ihr Vertrauen in Sie gewinnen möchten, während Sie Ihre Rolle erfüllen, müssen Sie auch das Vertrauen aufbauen und demonstrieren, das sie benötigen, um ihre Rolle zu erfüllen. Wenn das nicht passiert, ist das Teil dessen, was Sie alle gemeinsam beheben müssen.

Rollen, Verantwortlichkeiten, Vertrauen, Zusammenarbeit und Arbeitsvereinbarungen sind nie einheitlich. Dies sind Dinge, die ehrlich und offen besprochen werden müssen, insbesondere an wichtigen Wendepunkten wie Änderungen in der Teamzusammensetzung oder organisatorischen Verschiebungen von Rollen und Verantwortlichkeiten. Sie werden diese Probleme nicht über Nacht lösen, aber wenn diese Dinge nicht grundlegend für Ihren Plan sind, die von Ihnen identifizierten Probleme anzugehen, dann lösen Sie letztendlich die falschen Probleme. Transparenz, Kommunikation und Zusammenarbeit sind Ihre besten Werkzeuge, also nutzen Sie sie so oft und so effektiv wie möglich.

Aus Ihrem Beitrag geht hervor, dass nicht das gesamte Team an Bord ist. Deshalb sind sie es nicht; Sie und Ihr Management.

• Wie funktioniert das Team Pulling?
• Wie werden Schätzungen bearbeitet, von wem?
• Sind die Folgen technischer Schulden ein tatsächliches Managementanliegen?
• Wird die Neuentwicklung gestoppt, bis all diese technischen Schulden behoben sind?

Setzen Sie sie in Leistungsverbesserungspläne ein.

Sie erbringen derzeit keine angemessene Leistung, und Sie haben eine Liste von Gründen, in denen ihre Leistung unzureichend ist. Glücklicherweise gibt es ein Tool zur Leistungssteigerung, das genau solche Listen nutzt: den Performance Improvement Plan.

Motivation wird in zwei Arten eingeteilt, intrinsische und extrinsische, und da es ihnen anscheinend an intrinsischer Motivation mangelt, müssen Sie extrinsische Motivation nutzen, und diese wird durch Anreize bestimmt. Sie können dies tun, indem Sie Boni für hohe Leistung anbieten, aber es hört sich so an, als ob Ihr Hauptproblem darin besteht, dass ihre Leistung nicht einmal angemessen ist, und genau darauf soll der Leistungsverbesserungsplan eingehen. Der Leistungsverbesserungsplan legt die Anreize sehr klar dar: Erfüllen Sie die folgenden Ziele bis zum angegebenen Zeitpunkt, und Sie werden Ihren Job nicht verlieren.