Arbeitsplatzhierarchie: Aufbau von Respekt mit reifen Kollegen

Vermutlich aufgrund des Altersunterschieds mag er es nicht, wenn er von jemandem, der halb so alt ist wie er seine Arbeit zu erledigen hat, erklärt wird. Ich habe keine Angst vor Konflikten, aber ich möchte, dass er mir zuhört, ohne ihm das Gefühl zu geben, dass ich zu groß für meine Stiefel bin oder dass ich ihn herabsetze. Ich möchte, dass seine Beiträge begrüßt werden.

Meine persönliche Erfahrung mit einem Alters- (oder Erfahrungs-) Unterschied war, meine Erfahrung mit dem aktuellen Unternehmen zu betonen, die zutreffender sein wird als ihre Außenerfahrung. Leider musste ich viele beruhigende Komplimente einwerfen und bestimmte Dinge über mich selbst abwertend behandeln. Ich finde, wenn ich erkläre, dass ich überlegene Kenntnisse darüber habe, wie DIESES Unternehmen arbeitet, aber versichere ihnen, dass ich nicht so viel Erfahrung habe wie sie außerhalb, oder dass dies möglicherweise nicht der RICHTIGE Weg ist, Dinge zu tun, so wie wir Dinge tun. Ich betone meine bescheideneren früheren Karrierepositionen und versuche sicherzustellen, dass ich so rüberkomme, als wollte ich nur helfen.

Sie müssen auch zeigen, dass Sie wirklich gut in Ihrem Job sind und ihm helfen könnten. Wenn er das nicht durch Taten gesehen hat, wird er Ihren Worten nicht glauben. Es könnte nur einige Zeit dauern, bis er Ihren beruflichen Wert erkennt.

Dinge, die Sie bei Ihrem Ansatz berücksichtigen sollten

Müssen Sie seinen Code prüfen? Wer ist der Chef von Ihnen beiden? Wenn Sie keine offizielle Verantwortung für seine Arbeit haben (vielleicht nur eine persönliche/ethische, dass Sie möchten, dass „Ihr“ Projekt richtig ausgeführt wird), würde ich die Regel übernehmen, ihm nur einmal zu sagen, wie er eine bestimmte Sache zu tun hat. Nachdem Sie ihm spezifisches Feedback zu einem bestimmten Problem gegeben haben, wenn Sie nicht sein Chef sind und nicht beschuldigt werden, wenn sein Code nicht gut ist, erwähnen Sie es nicht noch einmal.

Zweitens, versuchen Sie, auf andere Weise hilfreich zu sein? Wenn Sie ihn nur an seinem Code kritisieren, aber nicht erklären, wie die 401k des Unternehmens funktionieren, wenn er fragt, kann ich verstehen, warum er Ihnen nicht zuhören will.

Stellen Sie drittens sicher, dass Sie ihm Anerkennung zollen, wenn er schnell etwas verstanden hat oder wenn er eine gute Idee hat. Oder wenn er etwas vorschlägt, das sinnvoll ist, aber für Ihr Projekt nicht funktioniert, stellen Sie sicher, dass Sie ihm die gute Idee anerkennen, während Sie anerkennen, dass dies dort leider nicht so ist.

Zu guter Letzt – gehen Sie nicht zum Projektmanager (insbesondere nicht, es sei denn, diese Person ist sein oder Ihr Vorgesetzter) mit Beschwerden, dass er nicht kooperiert. Stattdessen schlagen Sie entweder vor, dass Richtlinien festgelegt werden müssen, damit der Kodex gut ist und sich alle daran halten. Geben Sie freiwillig an, dass Sie das einrichten möchten, weil das Projekt für Sie wichtig ist und Sie sicherstellen möchten, dass alle auf derselben Seite sind. Wenn sie Ihnen jedoch keine Autorität über andere Programmierer oder die Verantwortung für seine Arbeitsergebnisse auf lange Sicht übertragen, können Sie sehr wenig tun. Wenn sein Zeug durchkommt und falsch ist, hat Ihr Unternehmen offensichtlich nicht entschieden, dass es in Ihrer Verantwortung liegt, sich darum zu kümmern. Das ist eine angemessene Frage für Ihren Chef oder den PM, aber versuchen Sie, sie als Organisations-/Schulungsproblem und nicht als Persönlichkeitsproblem einzuordnen.

Kurze Antwort: Einfach gesagt, Respekt muss verdient und gegenseitig sein .

Ich sehe in Ihrer Frage, dass Sie eine Reihe von Fällen hatten, in denen Sie Ihrem Kollegen Empfehlungen gegeben haben, Dinge zu ändern. Haben Sie jedoch die guten Dinge anerkannt, die er tut? Wenn Sie möchten, dass jemand zuhört, müssen Sie ihm entgegenkommen.

Ich würde vorschlagen, einige positive Elemente der Arbeitsleistung Ihres Kollegen zu finden und sie nicht zu loben , sondern einfach zu sagen, dass Sie das für eine gute Möglichkeit halten, etwas zu tun. Dann können Sie vorschlagen, dass etwas anderes auf diese Weise besser bedient werden könnte .

Rapport erfordert Geben und Nehmen. Wenn Sie nur auf das Nehmen drängen und das Geben ignorieren, ist es kein Wunder, dass Ihr Kollege seinen Rücken aufrichtet. Gib ein bisschen und schau was passiert :)

Fragen Sie nach dem Titel

Mit dem Titel sind Sie sein Vorgesetzter und haben jedes Recht, ihm zu sagen, was er tun soll/Vorschläge zu machen und zu erwarten, dass sie befolgt werden. Ohne den Titel bist du nur ein anderer Typ auf seinem Niveau ohne Autorität, der ihn herumkommandiert.

Als er anfing, waren Sie erfahrener im Unternehmen und er war der Neue, also nahm er Ihre Anleitung natürlich gerne an: Jetzt hat er sich zurechtgefunden und verspürt nicht das Bedürfnis, der Anleitung von jemandem zu folgen, der dies getan hat keine Autoritätsstellung über ihn.

Möglicherweise gehen Sie davon aus, dass Sie der Senior sind oder die Führungsrolle übernommen haben, aber er weiß das möglicherweise nicht oder versteht nicht, wie es im Unternehmen funktionieren soll. Das bedeutet, dass Sie entweder den formellen Titel benötigen oder dass das Management deutlich machen muss, dass Sie bei diesem Projekt der Lead sind.

Wenn Sie den Titel nicht haben (fest oder nur offiziell, befristet, projektspezifisch), sind Sie nicht sein Vorgesetzter und es gibt keine Hierarchie, also können Sie keinen hierarchischen Respekt herstellen: so einfach ist das.

Nun, zuerst denke ich, dass Sie davon ausgehen, dass dies ein Altersproblem ist. Das kann sein, aber Sie gehen davon aus. Es könnte nur ein Problem mit dir sein, da er dich entweder nicht mag oder deine Meinung nicht schätzt.

Sehen Sie, das verstehe ich nicht - warum versuchen Sie ihm zu sagen, was er tun soll? Sie sind weder der leitende Entwickler noch sein Chef noch der PM. Sie werden nicht einmal als technischer Leiter des Projekts anerkannt.

Sie und er sind gleich. Also zieh dich zurück. Es ist in Ordnung, eine knappe Kritik abzugeben, aber Sie haben ihn erschöpft. Wenn Sie fortfahren möchten, müssen Sie mit Ihren Anliegen zu Ihrem Chef oder dem echten Lead Developer gehen, und diese Person kann mit seinem Chef zusammenarbeiten. Dann können Sie sich darauf einigen, wie Sie arbeiten/codieren/was auch immer.

Wie baut man Hierarchie auf? Zeigen Sie, dass Sie gut genug sind, um den eigentlichen Titel zu bekommen, um aufzusteigen, und hören Sie auf zu glauben, Sie seien besser als Ihre aktuelle Position.

Diese Antwort geht davon aus, dass Sie der leitende Entwickler SIND. Nicht, dass Sie "in der Praxis" oder eine Art leitender Entwickler sind. Aber dass Sie für PM wirklich der leitende Entwickler für dieses Team sind.

Indirekt und zögerlich zu sein, untergräbt tatsächlich die Autorität, die Sie aufbauen möchten. Sie müssen Ihre Autorität formell bekräftigen und dann die Arbeit des Neuankömmlings von dieser höheren Ebene aus leiten.

Bitten Sie dazu Ihren PM, in einer Teambesprechung formell allen gegenüber zu betonen, dass Ihre Rolle bei Projekt X die eines leitenden Entwicklers ist und dass Sie mit der Verwaltung der Arbeit der Personen A und B beauftragt sind. Der PM sollte auch sagen, dass A und B Ihrem Beispiel folgen sollen/werden, fragen, ob das allen klar ist, und ein zustimmendes Nicken oder ein „Ja“ erhalten, und Fragen oder Kommentare äußern.

Dokumentieren Sie auch Ihre Interaktion mit A und B. Versuchen Sie, den Großteil Ihres Feedbacks auf Papier und nicht mündlich zu erhalten. Mündliche Vorschläge sind nicht überprüfbar und daher nicht durchsetzbar. E-Mail bietet eine spezifische und mit Zeitstempel versehene Aufzeichnung der Interaktion, die bei Bedarf als Beweismittel verwendet werden kann, um einen Fall von Ungehorsam oder Gründen für Produkte von geringerer Qualität von A und B vorzubringen.

Verwenden Sie gutes Urteilsvermögen, um zu entscheiden, wann es sich lohnt, Ihre PM in Ihren E-Mails an A und B zu cc setzen und wann es ausreicht, sie einfach per E-Mail zu senden (z B, aber nicht bei der Beantwortung kleinerer Fragen per E-Mail, die dazu führen könnten, dass sich A und B bevormundet und verunsichert fühlen).

Sprechen Sie bei Ihren Statusprüfungen mit PM von den Fakten und berichten Sie über alle Hinweise, die Sie dem Team gegeben haben, welcher Teil davon aufgegriffen und implementiert wurde und welcher Teil ignoriert oder falsch implementiert wurde, was eine Nacharbeit und Verlängerung des Zeitrahmens oder eine Beeinträchtigung erfordert Qualität. Sprechen Sie nicht mit dem Ziel, zu sagen, warum die Arbeit von A scheiße ist, sondern von objektiven Prinzipien: Dies ist sinnvoll, weil es später schneller/klarer/effektiver wird, aber trotz wiederholter Vorschläge spiegelt sich dies derzeit nicht wider A-Code, Punkt. Der PM kann sich seine eigene Meinung über die Schwere der von Ihnen angesprochenen Probleme bilden und entsprechend handeln.

Ein großer Vorbehalt zu den obigen Ratschlägen ist die Annahme, dass Ihre Vorschläge tatsächlich besser sind und effektivere / effizientere Vorgehensweisen darstellen als das, was A und B mit ihren eigenen Arbeitsstilen und -praktiken getan hätten. Dies ist eine ziemlich große Einschränkung. Was Ihnen wie der richtige Weg erscheinen mag, wird von älteren/erfahreneren Entwicklern möglicherweise absichtlich nicht praktiziert, aus Gründen, die sie schwer erklären können, auf deren Grundlage sie jedoch ihre Programmiergewohnheiten im Laufe der Jahre entwickelt haben.

Manchmal überschattet die Wahrnehmung, richtig zu liegen, den eigenen Mangel an Erfahrung und Bereitschaft, alternative Ansätze in Betracht zu ziehen.

Mein erster und wichtigster Ratschlag wäre also, die Probleme, die zwischen Ihnen und dem älteren Entwickler auftreten, als Gelegenheiten zum Nachdenken über Ihre eigene Praxis zu nutzen, die Gründe und Beweise dafür, dass diese Praxis tatsächlich überlegen ist, und ob die schrittweise Qualitätsänderung oder Effizienz ist die Mühe wert, sie dem Kerl aufzuzwingen, der in seinen Gewohnheiten vielleicht ein wenig sesshaft ist. Viel Glück!

Ich habe nicht den offiziellen Titel des leitenden Entwicklers erhalten, aber für dieses Projekt ist es eine Rolle, die ich selbstverständlich in der Praxis ausgefüllt und anerkannt habe.

Du bist also der Klügste hier, aber wer hat dir das gesagt, oder hast du dich gerade selbst entschieden? Es ist dasselbe, als würde man auf das Deck eines zufälligen Schiffes steigen und sich beschweren, dass kein Matrose einen als Kapitän erkennt. Warum sollten sie? Du bist nicht. Das Schiff mag für Sie schmutzig aussehen und vielleicht völlig falsch fahren, aber das macht Sie nicht automatisch zum Kapitän.

Damit andere Ihnen folgen, müssen Sie sich entweder den verdienten Respekt verdienen oder der offizielle Vorgesetzte sein. Wenn keiner von beiden, erwarten Sie nicht, dass andere Sie als Führungskraft nehmen.

Um andere Antworten zu ergänzen:

1) Kritisieren Sie nicht, wenn Sie die bessere Antwort nicht parat haben und/oder nicht bereit sind, die nötige Arbeit zu leisten, um sie anzuwenden.

2) Überhaupt nicht kritisieren. Fragen. „Hey, ich sehe, du hast es so geschrieben. Ich glaube, ich hätte es so geschrieben. Was habe ich übersehen, oder spielt es eine Rolle?“ Gehen Sie davon aus, dass Sie genauso wahrscheinlich falsch liegen oder es zumindest so darstellen, und hören Sie sich die Antwort genau an. Diskutieren, nicht behaupten und nicht streiten. Vielleicht haben Sie tatsächlich etwas übersehen. Oder es kann alte Gründe geben, dass es nicht so gemacht werden kann, wie Sie es bevorzugen. Oder es ist eine Frage des Stils und in diesem Fall wirklich egal. Oder er sagt eines davon, aber nachdem er den Vorschlag gehört hat, könnte er es das nächste Mal auf Ihre Weise versuchen. Hören Sie auf, zu versuchen, zu gewinnen, und konzentrieren Sie sich darauf, Ideen auszutauschen. so gewinnen alle .