Frage:
Wie kann ich als Teamleiter Änderungen in das Team einbringen, ohne dass das Team Widerstand leistet?
Babu
2013-02-14 00:02:25 UTC
view on stackexchange narkive permalink

Ich bin als Teamleiter einem neuen Team und einem neuen Projekt beigetreten. Diese Position ist das erste Mal für mich. Ich führe 3 Module. Ich bin über den 3 Modulleitern. Ich habe nur wenige Bereiche identifiziert, in denen Verbesserungen im Team erforderlich sind, einschließlich Codierungspraktiken. Ich möchte einige Änderungen in das Team einbringen, die dem Team zugute kommen und die Produktivität des Teams verbessern. Ich habe Schwierigkeiten, diese Modulleiter von meinen neuen Praktiken und Veränderungen zu überzeugen. Manchmal kommt es zu Meinungskonflikten und damit zu heftigen Auseinandersetzungen. Ich möchte diese nicht mit Gewalt durchsetzen, indem ich meine Autorität und Macht einsetze. Meine spezielle Frage lautet:

Wie kann ich Modulleiter überzeugen, ohne Konflikte zu führen, und die gewünschten Änderungen ohne Widerstand in das Team einbringen?

Forschung, die ich durchgeführt habe :
Ich habe im Arbeitsbereich gesucht. Ich habe jedoch festgestellt, dass der Beitrag Umgang mit einem älteren Teammitglied, das sich einem Teamleiter widersetzt für mich relevant erscheint. Es handelt sich jedoch hauptsächlich um eine bestimmte Person mit einer anderen Einstellung. Hier habe ich mehrere Teammitglieder, die sich weigern, Änderungen einzuladen. Daher glaube ich, dass mein Beitrag anders ist als der angegebene

Warum widersetzen sie sich? Erkennen sie das Problem, das Sie lösen möchten, nicht oder glauben sie nicht, dass Ihre Lösung das Problem lösen wird?
Es scheint mir, dass diese Antwort auf Ihre Situation zutrifft: http://workplace.stackexchange.com/questions/9603/how-to-deal-with-an-older-team-member-resisting-a-team-leader/ 9608 # 9608
@Sign: Ich versuche, neue Codierungspraktiken einzuführen und Praktiken zu organisieren, die für das, was sie tun, neu sind. Jedes Mal, wenn ich von ihnen höre, ist es schwierig, diese ins Team zu holen, und ich habe das Gefühl, dass dies die zusätzliche Belastung für sie erhöht.
Haben Sie darüber nachgedacht, die Einführung dieser Praktiken zu ändern? Haben Sie die Vorteile Ihrer Vorschläge formuliert? Haben Sie ihnen erlaubt, mitzureden, wie es für das Team gemacht wird, damit es nicht nur so ist, weil Sie gesagt haben, dass es so gemacht werden soll, wie es gemacht wird?
Erhöhen Sie die Anzahl der Schläge, bis sich die Moral verbessert!
Widerstand gegen Veränderungen tritt zu 100% auf. Sei dir bewusst, dass du es niemals los wirst, du überwindest es.
Ein gewisser Widerstand ist gesund und kein Grund zur Sorge.
Fünf antworten:
#1
+10
atconway
2013-02-14 00:32:08 UTC
view on stackexchange narkive permalink

Änderungen in einer neu implementierten Rolle sofort vorzunehmen, kommt nicht immer gut an. Ändern Sie sich von selbst schwer für die Menschen zu verdauen, aber noch schwerer von denen, denen nicht vertraut wird.

Ich habe im Laufe der Jahre immer neue Management (Leads, was auch immer) respektiert, die die Landschaft 1. in ihre neue Rolle (unabhängig davon, ob sie neu im Unternehmen oder ein Veteran sind), um die aktuelle Situation zu beurteilen, bevor Änderungen empfohlen werden.

Ich habe auch für die Umgekehrt, wo neu ernannte Machthaber Änderungen vornehmen, um etwas zu beweisen, und es sich als krass, klebrig und arrogant herausstellt. Die halbe Zeit würde ich nicht sehen, wie sie wissen könnten, welche Änderungen sie vorschlagen sollten, ohne zuerst die spezifische Umgebung zu verstehen, in der sie jetzt arbeiten. Wenden sie nur blind Richtlinien und Praktiken aus der Branche an, ohne zu wissen, wie das aktuelle Team arbeitet? (dh "Wir alle werden von nun an eine agile Methodik mit täglichen Scrum-Meetings, diesen Codestandards und diesen beiden Architekturen anwenden!")

Ein guter Leiter wird in den Hintergrund treten und das lernen Neue Umgebung, Team, und Rolle (Sie sagten, Sie sind neu in der Rolle), bevor Sie Änderungen vornehmen. Die einzige Ausnahme hiervon könnte der Fall sein, dass das obere Management Sie mit der Einführung von "Bob wurde in diese neue Position gebracht, um sie zu ändern und die Mängel von Person x zu beseitigen" in diese Rolle gebracht hat. Ich denke jedoch, dass dies die Ausnahme ist im Gegensatz zur Regel.

Lernen Sie Ihre neue Rolle, Ihr Team und Ihre Umgebung kennen, bevor Sie das Boot rocken. Sie werden auf lange Sicht mehr Respekt und Erfolg mit Ihrem Team gewinnen.

* Änderungen in einer neu implementierten Rolle sofort vorzunehmen, kommt nicht immer gut an * - zu 100% vereinbart. Es macht es für jeden, der von den Änderungen nicht beeindruckt ist, sehr einfach, einfach zu sagen: "Dieser Typ versteht unsere Arbeit / Situation / Team / etc. Nicht." Sie müssen glauben, dass Sie die aktuelle Situation verstehen.
+1 Und fragen Sie Ihr Team, was Ihrer Meinung nach verbessert werden muss. Sie könnten Dinge sehen, die Sie nicht sehen.
+1, gute Antwort. Zuerst gewinnen Sie das Vertrauen Ihrer Teams, dann können Sie Änderungen vornehmen.
#2
+9
bethlakshmi
2013-02-14 04:13:36 UTC
view on stackexchange narkive permalink

Hier ist mein bester Prozess, um die Verantwortlichen für Unterkomponenten dazu zu bringen, mir zuzustimmen. Ich musste in meinem ersten Managementjob dasselbe tun:

Kennen Sie das Problem & Es hat Priorität

Als Führungskraft ist dies wirklich Ihr Zuhause. Als oberster Punkt dieses Abschnitts des Organigramms müssen Sie entscheiden, wie die gesamten Ressourcen ausgegeben werden sollen und was am dringendsten verbessert werden muss. Nehmen Sie die Position ein, dass die Teamleiter Sie davon überzeugen müssen, dass ein anderes Problem dringlicher ist, aber seien Sie offen für Überzeugungsarbeit, da dies ein wechselseitiges Gespräch ist. Sie sehen Dinge, die Sie nicht sehen ... Sie sehen Dinge, die sie nicht sehen ... also müssen Sie zusammenarbeiten, um die wirklich höchsten Prioritäten herauszufinden.

Aber am Ende der Aufruf an das, was Sie tun tun und wie es sich auf die Verpflichtungen Ihres Teams auswirkt, ist Ihr Anruf. Sie müssen also wissen:

  • das Problem - was ist wirklich falsch an dem Code, wie er ist?

  • die Auswirkungen - warum und wie verlangsamt es die Produktivität? Was bringt Sie zu diesem Grad an Sicherheit?

  • die relative Priorität - wie dringend ist dies? Ist es wichtig genug, eine Verzögerung zu verursachen? Ist es wichtig, dass die Änderung konsistent ist - in welchem ​​Fall findet die Reha bestehender Arbeiten statt und was wird gemischt, um dies zu ermöglichen? Untergebene bewegen sich möglicherweise nicht vorwärts, wenn Sie diesbezüglich keine klare Richtung angeben können.

  • das Ultimatim - Ist dies ein Fall, der in das "Wenn" passt wir nicht ... dann können wir nicht ... "Modell - dann gibt es ein Ultimatim. Es ist unglaublich mächtig, dies mit Dingen zu verknüpfen, die Ihre Leads wollen tun. Zum Beispiel möchten die meisten Softwareentwickler ein erfolgreiches Stück Software veröffentlichen, wenn Sie es nicht ohne angemessene Codierungsstandards veröffentlichen oder verkaufen können - das ist eine starke Motivation.

Haben ein skizzenhafter Plan

Die Skizzenhaftigkeit ist genauso wichtig wie der Plan ... hier ist der Grund:

  • Eine Anforderung des Managements, an die nicht gedacht wurde, scheint unmöglich. Es ist frustrierend zu glauben, dass Ihr Management nur zufällige Anforderungen stellt und sich keine Gedanken darüber gemacht hat, ob dies wirklich machbar ist oder wie dies erreicht werden könnte. Ein Plan zeigt, dass Sie versucht haben, einen Weg zum Erfolg zu finden.

  • Es muss lückenhaft sein - Sie werden sich nicht nur in den Details irren - weil Sie nicht wissen, was Ihr Team weiß es - aber es ist demoralisierend, bis ins kleinste Detail zu erfahren, wie man etwas macht. Diese Leute sind in Führungspositionen, weil sie in der Lage sind, große Teile der Arbeit abzubauen und zu erledigen - lassen Sie sie ihre Fähigkeiten nutzen. Wenn dies nicht möglich ist, haben Sie ein Problem mit den Teamfähigkeiten und kein Problem mit den folgenden Befehlen.

Die Chancen stehen gut, dass Sie den Plan falsch verstehen. Sie werden an Stellen zu spezifisch sein, an denen Sie dachten, Sie hätten eine Ahnung und nicht spezifisch genug in einem Bereich, den jemand im Team als "absolut wichtig" bezeichnen wird. OK - dann besteht die Aufgabe Ihrer Leads darin, Ihnen bei der Verfeinerung des Plans zu helfen.

Verfeinern Sie den Plan gemeinsam

Wenn sie es nicht einmal versuchen - fragen Sie warum? Warum ist das so verrückt? Warum ist es unmöglich? Warum gibt es hier keinen Wert? Kehren Sie immer wieder zu dem Problem zurück, das Sie sehen, und fragen Sie nach besseren Ideen. Vielleicht sind Codierungsstandards NICHT der Weg, um dieses Problem zu lösen, oder sie sind zu teuer, um durchführbar zu sein. Fordern Sie sie heraus, um das Problem zu beheben. Ich hatte nur sehr wenige Fälle, in denen sich Leute weigerten zuzugeben, dass es ein Problem gab. Ich wurde jedoch (viele, viele Male) korrigiert, weil das Problem nicht die Grundursache hatte, an die ich glaubte. Ein weiterer Grund dafür, dass dieser Plan skizzenhaft ist - es gibt Ihnen die Möglichkeit, ihn ohne großen Zeitaufwand aus dem Fenster zu werfen.

Die Herausforderung besteht darin, dass sie Sie überzeugen müssen . Akzeptieren Sie keinen Vorschlag, nur um Konflikte zu vermeiden. Stellen Sie Fragen und lassen Sie sich über alternative Lösungen informieren. Seien Sie überzeugt, dass Ihr Team Recht hat, bevor Sie zustimmen.

Sobald Sie eine Lösung gefunden haben, können Sie den tatsächlichen Plan ausarbeiten - möglicherweise wird der Plan festgelegt, mit dem Sie in die Besprechung gegangen sind. Vielleicht erstellt es gemeinsam einen ganz neuen Plan ...

Das Ziel hier ist, gerade flexibel genug zu sein, um die Arbeit zu erledigen. Wissen Sie, was Sie interessiert und was Sie nicht interessiert. Wissen Sie, wofür Sie bereit sind, Geld und Zeit auszugeben, und was nicht zumutbar ist.

Verwenden Sie eines als Backup

Es gibt Zeiten, in denen die Leute ohne offensichtlichen Grund streiten. Sie können übermäßig emotional, unlogisch oder einfach unsinnig sein. Dies ist der Fall, wenn Einzelgespräche ein gutes Backup sind. Menschen werden Ängste und Bedenken anders äußern, wenn sie privat mit Ihnen sprechen. Und manchmal äußern kluge Leute mit guten Ideen sie nicht in Besprechungen.

Wenn Sie wirklich unerklärlichen Widerstand erhalten, beseitigen Sie das Chaos der Gruppenkommunikation und führen Sie es zu einem Einzelgespräch. Außerdem können Sie Feedback erzwingen. Es gibt nichts Schöneres, als eine provokative Frage zu stellen und dann in unangenehmer Stille zu warten, bis Ihre Person auftaucht und etwas sagt - zumal Ihre "unangenehme Stille" der "Moment der gesegneten Erleichterung" Ihrer Person sein kann, während sie ihre Gedanken sammelt und sich etwas einfallen lässt wirklich aufschlussreich. Es ist schwierig, dies in einer Teamumgebung durchzuziehen, da alle Teammitglieder die Mischung ergänzen.

#3
+4
JB King
2013-02-14 00:37:29 UTC
view on stackexchange narkive permalink

Wie man Freunde gewinnt und Menschen beeinflusst hätte folgende Vorschläge, die eine Überlegung wert sein könnten:

Zwölf Möglichkeiten, Menschen für Ihre Denkweise zu gewinnen

  1. Der einzige Weg, das Beste aus einem Argument herauszuholen, besteht darin, es zu vermeiden.
  2. Zeigen Sie Respekt für die Meinungen der anderen Person. Sagen Sie niemals "Sie liegen falsch".
  3. Wenn Sie sich irren, geben Sie es schnell und nachdrücklich zu.
  4. Beginnen Sie freundlich.
  5. Beginnen Sie mit Fragen, auf die die andere Person mit Ja antworten wird.
  6. Lassen Sie die andere Person viel reden.
  7. Lassen Sie die andere Person das Gefühl haben, dass die Idee ihre oder ihre ist.
  8. Versuchen Sie ehrlich, die Dinge aus der Sicht der anderen Person zu sehen.
  9. Seien Sie mit den Ideen und Wünschen der anderen Person sympathisch.
  10. Appellieren Sie an die edleren Motive.
  11. Dramatisieren Sie Ihre Ideen.
  12. Stellen Sie sich einer Herausforderung.
  13. ol>

    Seien Sie führend: So ändern Sie Menschen, ohne Beleidigungen zu erregen oder Ressentiments zu erregen

    1. Beginnen Sie mit Lob und ehrlicher Wertschätzung.
    2. Machen Sie indirekt auf die Fehler der Menschen aufmerksam.
    3. Sprechen Sie über Ihre eigenen Fehler, bevor Sie die andere Person kritisieren.
    4. Stellen Sie Fragen, anstatt direkte Befehle zu erteilen.
    5. Lassen Sie die andere Person das Gesicht wahren.
    6. Loben Sie jede Verbesserung.
    7. Geben Sie der anderen Person einen guten Ruf, dem sie gerecht werden kann.
    8. Verwenden Sie Ermutigung. Lassen Sie den Fehler leicht zu beheben erscheinen.
    9. Machen Sie die andere Person glücklich darüber, was Sie vorschlagen.
    10. ol>

Der andere Punkt, über den Sie hier nachdenken sollten, ist, wie gut Hören Sie sich die Probleme an, die die Modulleiter haben, was Sie tun möchten? Wenn sie Bedenken haben, die Dinge sind, die Sie über das Unternehmen nicht wussten, könnte dies gut darauf hinweisen, warum Dinge nicht so gemacht werden, wie Sie es sich vorgestellt haben. Wenn Sie relativ neu sind, würde ich die Idee in Betracht ziehen, eher Vorschläge als kraftvolle Befehle zu machen, die nur mehr Spannung erzeugen.

#4
+4
user8365
2013-02-14 01:07:35 UTC
view on stackexchange narkive permalink

Fragen Sie zunächst, was Sie tun können, um ihre Arbeit zu erleichtern. Jeder kann in ein bestehendes Team / Projekt springen und Fehler finden. Man weiß nie; Sie möchten vielleicht die einfachsten Dinge: neue Computer, ein besseres Bug-Tracking-System, Gleitzeit, Zugang zu Schulungsmaterialien, besseren Kaffee usw. Sie haben mehr Glaubwürdigkeit, wenn Sie Ihre Vorschläge machen, und sie sind empfänglicher, wenn Sie Wir haben einige ihrer Hindernisse beseitigt und eine Abstraktionsschicht bereitgestellt.

Vertrauen wird nicht dadurch gewonnen, dass Menschen um ihr Vertrauen gebeten werden, sondern indem sie ihnen Ihr Vertrauen geben.

Ich würde diese +100 wählen, wenn ich könnte. Die Leute widersetzen sich nicht der Veränderung, sie widersetzen sich der Veränderung, an die sie nicht glauben. Helfen Sie dem Team bei den Veränderungen, die sie vornehmen möchten, anstatt diejenigen zu zwingen, die Sie vornehmen möchten. Sie wissen mit ziemlicher Sicherheit besser, was sich sowieso ändern muss.
#5
+1
Simon O'Doherty
2013-02-14 00:32:01 UTC
view on stackexchange narkive permalink

Das Schlüsselwort hier ist Team.

Wenn Sie die Haltung "So werden wir es machen, Ende der Geschichte" einnehmen, werden Sie zurückgedrängt.

Andererseits ist es besser, klare Ziele für das zu haben, was Sie erreichen möchten, und dem Team zu ermöglichen, den Weg zu diesem Ziel zu bauen.

Wenn Sie also glauben, dass Prozess X fehlerhaft ist, weisen Sie auf die Fehler im Prozess und die dadurch verursachten Probleme hin. Es ist hilfreich, einige Metriken zu haben, um Ihre Punkte zu sichern. Besprechen Sie anschließend mit dem Team, wie dies am besten gelöst werden kann.

An dieser Stelle können Sie vorschlagen, wie es angegangen werden soll, aber das Problem nicht erzwingen. Wenn jemand es abschießt, bitten Sie ihn, eine bessere Option vorzuschlagen.

Schlagen Sie vor, diese Option für eine festgelegte Zeit auszuführen, um die Metriken darauf zu bestimmen. Wenn es keine wesentliche Verbesserung gegenüber dem aktuellen System gibt, werden Sie sie erneut ändern.

Wenn sie keine Lösung anbieten können, teilen Sie ihnen mit, was Sie vorgeschlagen haben, und Sie werden alle in ein paar Wochen nachverfolgen, ob der Ansatz verfeinert oder geändert werden kann.

Der Punkt, um zu vermitteln, dass das Team nach Lösungen für Probleme sucht, die Sie in den aktuellen Prozessen gesehen haben.

Wenn Sie meinungsbasierte Änderungen haben (z. B. die Formatierung des Quellcodes macht immer Spaß), lassen Sie alle ein festes Format vereinbaren, und wenn Sie es nicht festlegen können, tun Sie dies. Wenn sich jemand weigert, teilen Sie ihm mit, dass er frei im gewünschten Codierungsstil schreiben kann. Er kann jedoch erst einchecken, wenn dieser Code dem für das Projekt festgelegten Standard entspricht. Alle Check-Ins, die gegen diese Konvention verstoßen, werden nicht in den Build verschoben.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...