Führe ich ein Team, bin ich überheblich?

Ich bin in einer für mich sehr seltsamen Position. Ich bin "Teamleiter" in der Rolle für ein bestimmtes Projekt, Sr. Software Engineer in der Berufsbezeichnung. In meinem Team habe ich 4 Entwickler, von denen einer eine ähnliche Rolle in einem anderen Projekt spielt, aber jetzt hat meiner Priorität eingeräumt, und er arbeitet an meinem. Ich habe auch 2 Tester, von denen einer Manager ist. Ein weiteres Mitglied des Teams ist der "Customer Representative", der Teil einer völlig unabhängigen Abteilung ist. Ich habe auch einen Manager, der direkt über mir steht, und ich glaube auch über dem Manager of Test, der Teil meines Teams ist ... da bin ich mir allerdings nicht so sicher.

Ich habe versucht zu klären, warum meine Rolle genau mehrere Male ist. Es war schwer für mich herauszufinden, wo meine Autorität beginnt und endet, wenn ich überhaupt welche habe. Die Antwort, mit der ich gerade arbeite, ist, dass ich "technischer Leiter" des Teams bin. Dies scheint zu bedeuten, dass meine Autorität über technische Entscheidungen in Bezug auf Architektur, Design und Prozess- / Codierungsstandards liegt, da diese sich auf den Produktcode selbst beziehen.

Heute ist etwas passiert und die Ergebnisse des Codes, die ich an eines der Mitglieder meines Teams delegiert habe, wurden dem Rest des Unternehmens in unserem Scrum-Show-it-All-Off-Meeting gezeigt. Die Person, die den Kunden vertritt, macht das Vorführen. Heute wurde etwas vorgeführt, mit dem ich nicht einverstanden war, und niemand hatte mich jemals gefragt, ob ich mitreden möchte, was passiert ist. Kurz gesagt, um einem Benutzer die Möglichkeit zu geben, einen Wert in einem Bericht auf folgende Weise anzuzeigen ("doc" -Einheiten, Design-Einheiten, gerundet, nicht gerundet), stellten sie Zugriffsfelder für jede Permutation bereit. Daher haben wir den Wert in gerundeten Dokumenteinheiten, gerundeten Designeinheiten, ungerundeten Dokumenteinheiten und ungerundeten Designeinheiten. Jeder Datensatz, mit dem der Benutzer arbeiten möchte, hat viele solche Werte, und jeder wird auf diese Weise permutiert.

Ich hasse das wirklich.

Die Leute, denen wir dies gezeigt haben, möchten sicherstellen, dass die API, die wir für Berichte verwenden, mit der Art und Weise übereinstimmt, wie wir Daten nach Excel exportieren. Leider gewinnen wir jetzt diesen Schwung in eine Richtung, die ich für sehr, sehr schlecht halte.

Beim nächsten Treffen war ich ein wenig verärgert und fragte die beiden, die das getan hatten: "Warum war ich nicht an dieser Entscheidung beteiligt?" Es ist ein Thema, das immer wieder auftaucht, und es fällt mir schwer, Leute in das Team zu holen, das ich führen soll, um mich zu fragen, ob ich mitmachen möchte. Manchmal tue ich das nicht und ich denke, was immer sie sich einfallen lassen, wird in Ordnung sein. Andere Male tue ich. Es sei denn, die Leute fragen mich, obwohl es schwer zu wissen ist, dass etwas los ist, das meinen Input benötigt, und sie geben mir diese Gelegenheit nicht.

Leider erstreckt sich meine Autorität nicht darauf, den Leuten zu sagen: "Wenn Sie das nächste Mal auf eigene Faust so etwas tun, ohne überhaupt mit mir zu sprechen, werden Sie diszipliniert." Das ist eine PR-Frage, die ganz offensichtlich nicht in meinem Zuständigkeitsbereich liegt. Das ist in Ordnung für mich, denn ich möchte mich nicht mit so einem Mist auseinandersetzen müssen, wenn jemand anderes dazu bereit ist.

Heute sagte mir mein Vorgesetzter vor allen (was vermutlich auch meine Schuld ist), dass ich nicht in jede Entscheidung involviert sein kann und delegieren muss.

Ich denke natürlich, dass ich Recht habe ... das tue ich immer. Ich sage keine Dinge, die ich für BS halte. Ich denke, ich hätte wegen dieses Problems angesprochen werden sollen und gefragt, ob ich eine bessere Idee hätte. Eigentlich hätte ich mich dazu entschlossen, nur EINEN Wert für den Augenblick festzulegen, da dies eigentlich der Anfang einer neuen Funktion war, und Optionen zu erörtern, um auf Wunsch in Zukunft weiteren Zugriff zu gewähren. Ich hätte die aktuelle Implementierung niemals gebilligt oder empfohlen, und ich denke wirklich nicht, dass sie das Licht der Welt erblicken sollte.

Die Frage ist, bin ich derjenige, der unvernünftig ist?

Nun, wir sprachen beide darüber und waren uns einig, dass wir beide "den Ball fallen ließen" und uns auf derselben Seite zu befinden scheinen. Montagmorgen ... Wir werden versuchen, sicherzustellen, dass meine Rolle im Team klar ist und dass ich entscheiden kann, wann ein Entwurf oder eine Aufgabenänderung stattfinden muss. Ich werde vorgeschlagen und stimme entweder zu oder entscheide, dass ich tiefer schauen muss. Dann gibt es noch ein paar andere Dinge, an denen ich arbeiten kann, um sicherzustellen, dass sie zu mir kommen können.

Klingt so, als müssten Sie Source Commits überwachen. Perforce hat diese Fähigkeit nativ, Git hat sie durch Hooks, andere haben sicher ihre eigenen Methoden. Sie müssen nicht jedes Commit einzeln auswählen, aber wenn Sie eine Benachrichtigung haben und diese vergleichen, erhalten Sie einen kurzen Einblick in alles, was in Ihr Projekt einfließt.

Was Ihren Manager betrifft, der sagt, dass Sie delegieren müssen, bin ich mir nicht sicher, ob ich dem zustimmen würde - mit einem Team von vier Entwicklern sollten Sie in der Lage sein, damit umzugehen. Mehr könnte ich mit ihm (oder ihr) auf der Seite stehen. Selbstverständlich sollten Sie auch bei delegierten Aufgaben nach Statusaktualisierungen oder Anleitungen zu Entwurfsänderungen usw. fragen.

Nichts negativ sollte immer in Sitzungen gebracht werden - klingt wie Sie und Ihr Manager den Ball auf diesem gesunken. Das absolut Schlimmste, was Sie jemals einem Kollegen antun könnten , ist, ihn in Verlegenheit zu bringen. Als Führungskraft (wie bei Ihrem Vorgesetzten) müssen Sie ansprechbar und vertrauenswürdig sein. Wenn Sie jemanden herabsetzen, wird dies zu Ressentiments führen, die Ihre Fähigkeit beeinträchtigen, Ihr Team zu führen (und auch zu verärgerten Mitarbeitern).

Ich hasse es , das Wort "Disziplin" von jemandem in einer Hauptrolle zu hören. Disziplinierung (zumindest in diesem Zusammenhang) ist negativ und nicht produktiv. Arbeiten mit jemandem (persönlich und nicht in einer Sitzung Einstellung), herauszufinden , warum sie etwas tat und Alternativen bieten , wenn Sie mit ihnen vorgeschlagenen Lösungen nicht einverstanden ist , was getan werden soll. Manchmal werden Sie feststellen, dass die Person, mit der Sie arbeiten, richtig und Ihr Bauchgefühl falsch ist. Warum? Sie haben mehr Zeit mit diesem speziellen Problem verbracht als Sie.

Etwas anderes, das mich beunruhigt, ist "Ich denke immer, ich habe Recht". IMO, das ist die schlechtestmögliche Einstellung von jedem Lead. Sie sollten sich natürlich auf Ihre Fähigkeiten verlassen können, aber Sie sollten sich darüber im Klaren sein, dass Ihre Vorschläge mehrmals aus Ihrem Hinterkopf kommen (egal wie viel Erfahrung Sie haben), wenn Sie sich nicht auf ein bestimmtes Problem einlassen der Beste sein. Wenn jemand, der sich auf ein bestimmtes Problem konzentriert sich eine Alternative bietet, dann ist es Ihre Aufgabe (na ja, sowie ihre Abhängigkeit von ihrer eigenen Erfahrung Ebene) zu beweisen , warum Ihr besser ist, nicht nur sagen , „Ich bin der Leitung und Ich denke immer, dass ich Recht habe ", das ist es, was mich zu deinem Satz veranlasst, zu glauben.

Zum einpacken

Ja, Sie sind in einigen Punkten unvernünftig, in anderen jedoch nicht. Als Hinweis würde ich erwarten, dass wenn es Feature- oder Architekturänderungen gibt, diese zumindest von Ihnen bestanden werden.

Es ist jedoch auch Ihre Aufgabe, die Gesamtsystem- und Codequalität sicherzustellen, die Sie selbst erledigen müssen. Beschäftigt Ihr Unternehmen Code Reviews? Entwerfen Ihre Programmierer, woran sie arbeiten, bevor Sie mit dem Code beginnen? Wenn nicht, sollten Sie sich mit dem Einsatz solcher Qualitätskontrollmechanismen befassen.

Möglicherweise werden Sie für das Management überprüft, und wenn ja, scheitern Sie (was möglicherweise keine schlechte Sache ist; viele von uns sind gute Entwickler und wären schlechte Manager, und ich würde es vorziehen, Programmierer zu programmieren, anstatt Programmierer zu verwalten).

Manager haben häufig nicht die Autorität für alles, was sie tun sollen. Trotzdem Dinge zu erledigen ist ein Zeichen für einen guten Manager. Sie müssen Wege finden, Menschen dazu zu bringen, Dinge zu tun, ohne Disziplinarmaßnahmen zu ergreifen. (Hinweis: Menschen in der Öffentlichkeit herabsetzen, oder?)

Manager müssen auch delegieren, wenn es weh tut. Sie werden wahrscheinlich mehr Zeit mit diesem Problem verbringen, als Sie selbst damit verbracht hätten, es zu schreiben, und das ist in Ordnung. Sobald Sie damit fertig sind, sollten die Leute, die das getan haben, etwas gelernt haben, und es ist weniger wahrscheinlich, dass sie die Dinge in Zukunft falsch machen.

Der richtige Weg, mit so etwas umzugehen, ist privat. Fragen Sie zuerst die Entwickler, warum sie die Anzeige so gemacht haben. Nicht in einer Besprechung und nicht durch die Annahme, dass Sie Recht und Unrecht haben (auch wenn Sie Recht und Unrecht haben). Gib ihnen die Chance, es zu erklären. Das bedeutet nicht, dass Sie mit ihrer Entscheidung gehen müssen; Sie sind schließlich der technische Leiter. Es bedeutet, dass Sie ihnen Gründe geben müssen, um es auf Ihre Weise zu tun, und Sie sollten sich mit allen grundlegenden Problemen befassen, die während dieses privaten Meetings auftreten.

Manager haben auch die Verantwortung für das, was aus ihren Mitarbeitern herauskommt. Sie sollten versuchen, sich von nichts blind zu zeigen, was sie tun, insbesondere vor den Augen eines Kunden. Dies kann bedeuten, dass Sie den Überblick über Code-Check-Ins behalten oder kurze Minikonferenzen mit Ihren Entwicklern abhalten müssen (obwohl Sie darauf achten müssen, dass Sie sie nicht unterbrechen möchten, wenn sie sich in der Zone befinden). Möglicherweise sollten Sie am Nachmittag vor dem Treffen mit dem Kundenvertreter mit allen Entwicklern sprechen.

Nimm es nicht persönlich

Es ist eine Teamleistung. Sie sind der technische Leiter, nicht der einzige, der an dem Projekt beteiligt ist. Sie sollten sich darauf konzentrieren, dass das Team aus Fehlern lernt oder den Prozess ändert.

Führen und lernen

Teil jeder Führungsposition, einschließlich eines technischen Vorsprungs, ist es, zu verstehen, dass Sie mit den Menschen, die Sie haben, das Beste aus Ihnen machen. Je mehr das Team zusammenarbeitet, desto mehr wissen sie, wann sie Dinge ansprechen müssen und wann nicht. Stellen Sie nur sicher, dass Sie nicht in die Falle tappen, Ihrem Team zu diktieren. Überprüfen Sie wöchentlich, was schief gelaufen ist und was gut gelaufen ist . Kommunizieren Sie mit Ihrem Team, wenn Sie möchten, dass es die Dinge anders macht. Strafmaßnahme sollte immer ein letzter Ausweg sein und bedeutet normalerweise, dass Sie entweder jemanden entlassen müssen oder Ihre Rolle nicht bestanden haben.

Überprüfung vor Kundenpräsentation

Wenn Sie der Projektleiter sind, warum haben Sie das Feature und die Implementierung nicht überprüft, bevor es vorgestellt wurde?

Wenn es falsch ist, beheben Sie es

Erklären Sie klar, warum etwas nicht stimmt, und ändern Sie es. Es ist teurer, aber wenn es tatsächlich falsch ist, beheben Sie es. Wenn es nicht falsch ist, nur anders, als Sie es wollten, dann noch einmal; Verstehe, dass du nicht der einzige bist, der an dem Projekt arbeitet.

Gab es eine Spezifikation, die dokumentierte, was implementiert werden soll? Angesichts einer zu offenen Anforderung füllen Entwickler häufig die Lücken (oder erfordern Mikromanagement) mit dem, was sie für angemessen halten.

Am Ende erhalten Sie von Ihrem Manager folgende Informationen: "Anstatt an den Spezifikationen zu arbeiten, haben sie beschlossen, stattdessen die Funktion [feature] auszuführen. Jetzt sind wir aufgrund einer Funktion im Rückstand, die von Anfang an nicht genehmigt wurde."

Anschließend können Sie mit dem Scrubben der Funktion beginnen, nachdem die Entwickler neu zugewiesen wurden.

Bearbeiten> Und nein, ich glaube nicht, dass du überheblich bist. Ihre Arbeit endet als dein Arsch.

Ich befinde mich oft in der gleichen Position und meine Ausführungen in Besprechungen und Diskussionen scheinen nichts zu bringen. Manchmal sende ich als letztes Mittel, bevor ich mich damit abfinde, die getroffene Entscheidung zu treffen (albiet not mine), eine E-Mail an die relevanten Parteien, in der ich die Gründe dafür in Schwarzweiß wiedergebe.

Dann würde ich diese E-Mail archivieren, um sicherzustellen, dass ich sie für zukünftige Referenzzwecke habe, falls sie später benötigt wird, wenn ein Manager oder Kunde fragt, warum etwas auf diese Weise getan wurde oder warum es so viel kostet, eine Änderung zu beheben.

Ich glaube, Sie haben sich geirrt, wie Sie zugegeben haben. Sie sind nicht falsch zu sagen, dass Sie auf dieser Ebene einen gewissen Einfluss auf das Design haben sollten, aber ich bin mir nicht sicher, wie Sie erwarten, dass dies vernünftig ist. Die Leute werden ein Design nicht von Ihnen führen, wenn sie es für unkompliziert halten. Da sie sich genauso leicht irren können wie das Design selbst, werden Sie keine Menschen finden, die sich freiwillig erbieten, Ihnen all ihre falschen Designs zu zeigen. An diesem Punkt bin ich meistens neugierig auf Ihre Arbeitsgewohnheiten und Kommunikationsmuster, aber egal wie das alles gemacht wird, manchmal werden Sie einfach blind von diesen Dingen. Ich bin mir nicht sicher, wie Sie dagegen vorgehen sollen, wenn Sie nicht jedes Commit sorgfältig prüfen.

Ich fühle mich zu oft emotional so:

 I of course think I'm right....I always do. 

aber ich habe den intellektuellen Sinn zu wissen, dass ich gelegentlich falsch liege. Ich weiß auch, wann man einen Kampf auswählt - man kann nicht über alles streiten, und manchmal kann eine unerwartete Einigung von Ihrer Seite Wunder wirken.

Was ist ein wahrer Anführer?

Ist jemand, der einen Untergebenen feuern kann , jeden Untergebenen. (muss aber nicht neu eingestellt werden)

Manchmal werden die meisten Leute als Leiter eines Projekts "getaggt", aber ohne die Kraft des Feuers ist es eher eine "Anleitung" / "Lehrerin" als ein echter Leiter.

Es kann aber auch vorkommen, dass Sie ein Teamleiter sind, Ihr aktuelles Projekt jedoch nicht leiten. Der schlimmste Fall ist, wenn der Kunde das Projekt leitet. An diesem Punkt liegt es nicht in Ihrer Verantwortung, wenn das Projekt fehlschlägt (und es wird fehlschlagen).

Und der schlimmste Fall ist, wenn zwei Projektleiter existieren.

Als Militär sind Befehlsketten alles (nicht so radikal wie "für ein Projekt sterben", aber nah genug). In dieser Angelegenheit hat Ihr Manager Ihren Status gebrochen, die Moral von "Ihren" Leuten herabgesetzt und hat überhaupt nicht geholfen.

Ja, Ihr Chef hat Recht - Sie können nicht in jede Entscheidung einbezogen werden . In der Tat ist es unmöglich, alles so zu fangen, es sei denn, Sie tun alles selbst. Ich denke, da kommen Sie her - Sie haben das Gefühl, dass Sie das gesamte Projekt nicht gut im Griff haben können, wenn Sie nicht in jedes Detail involviert sind, aber Sie können nicht in jedes Detail involviert sein, ohne Sie zu überwältigen (was das gesamte Projekt demoralisieren wird) Team und wahrscheinlich brennen Sie aus).

Die Antwort ist, sich keine Sorgen zu machen über Dinge, die schief gehen - sie tun es immer -, statt sich darum zu sorgen, dass sie später auf konstruktive Weise repariert werden.

Wenn Sie mit der Kommunikation auf dem Laufenden bleiben, können Sie nicht nur delegieren, sondern auch Ihre älteren Mitarbeiter entlassen und das tun, was sie wissen, ohne sie immer mit Bewertungen, Diskussionen und fehlgeleiteten Versuchen, sie zu kontrollieren, zurückhalten zu müssen. Vertraue darauf, dass sie das Richtige tun und darüber 'plaudern', was los ist, damit du auf dem Laufenden bleibst (und deine Nase hineinsteckst, wenn du das Gefühl hast, dass es wirklich nötig ist).

Sie haben mehrere Probleme. Zuerst hat sich Ihr Manager Ihrem Team angeschlossen und Ihnen gesagt, Sie sollen mehr delegieren. Dies zeigt einen Mangel an Vertrauen in Ihre Fähigkeit, das Team zu führen. Es zeigt in der Tat, dass Sie zwar den Titel Tech Lead haben, aber nicht der Tech Lead sind, weil Sie keine Autorität haben. Sie müssen sich mit Ihrem Vorgesetzten zusammensetzen und diesbezüglich ein Herz fürs Herz haben. Ohne die Unterstützung seines Managers und ohne die Befugnis, vom Team getroffene Entwurfsentscheidungen ohne seine Zustimmung zu ändern, kann niemand eine technische Führungsposition übernehmen. Sie sind nicht befugt, Ihre Arbeit zu erledigen. Ihr Chef muss verstehen, dass Sie nicht gewinnen können und dass er Sie öffentlich unterstützen muss, damit es Ihnen besser geht. Verantwortung ohne Autorität ist die schlimmste Situation, in der man sich wiederfinden kann.

Als nächstes hat Ihr Team Sie blindgestellt. Sie müssen das mit ihnen besprechen. Sie sollten die Designdiskussion mit ihnen führen, bevor sie eine Entwicklung durchführen und lange bevor sie eine öffentliche Präsentation durchführen. Es ist in Ordnung, einen Teil des Entwurfs zu delegieren (obwohl Sie, nicht sie, entscheiden können, was Ihrer Meinung nach delegiert werden soll), aber es ist nicht in Ordnung, dass sie fortfahren, ohne Sie darüber zu informieren. Sie haben Ihr Vertrauen verloren, indem sie Sie blind gemacht haben. Jetzt müssen sie besseres Verhalten lernen. Sie müssen sich regelmäßig mit ihnen in Verbindung setzen, um sicherzustellen, dass sie Sie nicht wieder blind machen. Wenn dies der Fall ist, sollten Sie eine formelle Meldung des Problems an die Personalabteilung vornehmen. Leads sind keine populären Leads, wenn Entwickler sie absichtlich umgehen, nachdem sie dazu aufgefordert wurden, verdienen sie Konsequenzen. Tut es nicht' Es ist egal, ob sie dich mögen oder nicht, aber im Moment respektieren sie dich eindeutig nicht. Sie müssen Konsequenzen für ihr unangemessenes Verhalten haben, sonst wird es nur noch schlimmer. Sie können diesen Teil des Problems jedoch erst beheben, wenn Sie das Problem mit der Verwaltungsunterstützung behoben haben.

Als nächstes hast du öffentlich gesprengt, du musst dich öffentlich entschuldigen. Dies wird Ihnen helfen, Ihren Ruf wieder aufzubauen.

Dann müssen Sie die einzelnen Personen privat beiseite nehmen und ihnen die Konsequenzen für ihr anhaltendes schlechtes Benehmen mitteilen (sobald Sie von Ihrem Vorgesetzten die Zustimmung erhalten haben, dass Sie ihnen Konsequenzen geben können). Öffentliches Lob und Unterstützung, private Kritik sollte Ihre Regel sein. Möglicherweise müssen Sie auch häufiger außerhalb der Gruppentreffen bei ihnen einchecken, damit sie Sie nicht aus den Augen lassen können.

Offen gesagt, da sowohl die über als auch die unter Ihnen klar denken, dass Sie jemand sind, der ignoriert und nicht informiert werden kann, müssen Sie sich ernsthaft überlegen, was sie dazu veranlasst, Sie zu missachten. Sie müssen sich auch entscheiden, ob Sie als Technologieleiter nicht glücklicher wären oder ob Sie zu einem Ort wechseln sollten, an dem Sie die Autorität haben, die Verantwortung zu übernehmen. Wenn Sie sich dazu entschließen, in dieser Position zu bleiben, müssen Sie die Leute bitten, sich mit Ihnen abzustimmen, warum sie Sie so schlecht behandeln. Das wird schmerzhaft sein und Sie werden die Antwort wahrscheinlich nicht hören wollen, aber Sie müssen wissen, warum Sie so wahrgenommen werden, wie sie Sie klar wahrnehmen.