Jestem zrzędliwym administratorem Linuksa, który wykonuje dużo skryptów i zauważyłem, że mam słabe umiejętności komunikacyjne. Bardzo przypominam twojego faceta. W rzeczywistości jest to jedyny obszar, w którym zagłębiam się w recenzjach wydajności. Z drugiej strony stale przewodzę mojemu zespołowi w zakresie innowacji i rozwiązywania problemów oraz stworzyłem i poprowadziłem drogę do nowej platformy, którą wdrażamy, i zaoszczędziłem zespołowi dużo czasu, a mojej firmie dużo pieniędzy, ponieważ mogę być sobą.
Poproszono mojego byłego szefa, jego rodzinę / żonę ORAZ kierownictwo naszej firmy o opuszczenie stanowiska .... jednocześnie. Pracował niestrudzenie, aby sprawiedliwie zrównoważyć obowiązki i sam wziął na siebie spory ciężar. Jeśli podczas jakiejkolwiek interakcji z kimkolwiek spoza wydziału, doszło do nieporozumienia w komunikacji, szybko je naprawił, karno. Był kiepski w „zarządzaniu w górę”, więc nasz zespół jako ostatni pozyskiwał zasoby, dopóki nie było to nagłe zagrożenie, a następnie firma przepłaciła sprzedawców zręcznymi planami sprzedaży niesprawdzonego sprzętu bez konsultacji z zespołem, który będzie korzystał z tych narzędzi. Starając się stworzyć „dobrze wyważony” zespół, zarządzał mikromanizacją naszych list zadań i próbował wyrównywać zadania, aby członkowie zespołu mogli doskonalić swoje umiejętności w obszarach, w których nie byli świetni, co spowodowało DUŻO zepsutego kodu lub źle zaprojektowanych implementacji. Podczas gdy osobom innym niż autor przypisano zadania wsparcia dla tego zepsutego kodu, aby mogli się „nauczyć” - źle zaprojektowane implementacje, kod i testy stworzyły wiele złej dobrej woli między członkami zespołu i faktycznieczęstsze występowanie „gry obwinianej”, która jest szybką drogą do toksycznego stanu drużyny.
Mój obecny szef jest spokojną, zebraną osobą, która przyszła z roli młodszego administratora i wspięła się. Podejmuje dobre decyzje i w dużym stopniu polega na członkach zespołu, którzy ustalają własne priorytety. Jest doskonałym komunikatorem i reaguje spokojnie i w porozumieniu ze swoim przełożonym na wszelkie problemy komunikacyjne, pomysły lub potrzeby wyrażone przez mój zespół. „Pracuje w górę” niestrudzenie. Powoli wprowadza poważne zmiany w architekturze i konsultuje się dokładnie z całym zespołem, zanim wprowadzi zmiany w naszym otoczeniu, i czuje się komfortowo, polegając na specjalnościach członków naszego zespołu.
Pod nowym menedżerem przestoje spadły prawie do zera (co również zmniejszyło procent czasu, który spędzamy na zadaniach wsparcia z około 40% do około 10%), zadowolenie naszego zespołu poszło na marne i jesteśmy na dobrej drodze do przejścia od „rozbicia banku na nowym sprzęcie co trzy do pięciu lat” na ciągły plan przejęć, który powinien zaoszczędzić firmie około fajnego miliona rocznie przez pięć lat. Ten plan był oddolnym programem, który nigdy by się nie wydarzył za poprzedniego menedżera, ale został aktywnie skierowany do wyższej kadry kierowniczej przez nowego menedżera i polegał na znalezieniu DUŻEJ synergii w zestawach umiejętności zespołu. CIO poinformowało nas nieformalnie, że jesteśmy teraz jedynym zespołem w firmie, który naprawdę „ma swoje gówno razem” i że „ zamierzamy w jak najmniejszym stopniu ingerować w nasze środowisko pracy i kierować jak najwięcej zasobów w kierunku obszarów problemowych, które zidentyfikujemy w możliwie największym stopniu. Utrzymało się to prawdą i powoduje, że nasz koszt wsparcia jest jeszcze niższy, chociaż zakłócił obciążenia niektórych innych zespołów - ale obniżył również „koszt” wsparcia tych zespołów.
Spójrz, miejsce, w którym programiści mogą doskonalić swoje umiejętności, znajduje się w szkole lub w ich własnym czasie. Miejsce, w którym mogą produkować różne rzeczy, to czas twojej firmy. Najlepszym sposobem na wytwarzanie rzeczy jest wytwarzanie tego, co wiedzą najlepiej. Pracując w obszarach, w których jeden programista nie czuje się komfortowo, powinien przyciągnąć drugiego programistę, który jest wyspecjalizowany i pracuje jako zespół, lub specjalista programista powinien napisać kod oraz opracować dokumentację i diagramy. Kieruj zadania pomocy technicznej do osób, które napisały kod. Tak, zwiększa to, co nazywamy „czynnikiem autobusowym” - prawdopodobieństwo, że Twój oddział uderzy w próg zwalniający, jeśli autobus zostanie potrącony przez specjalistę. (Lub zwolnij się, albo zmień pracę, albo ...) Prawda jest taka, że Twoja strata produktywności z tego strachu jest o rząd wielkości większa niż faktyczna strata, gdy „zdarzenie autobusowe” dzieje się. To, co zwykle dzieje się podczas „wydarzenia autobusowego”, polega na tym, że spadkobierca pracy specjalisty przekształca go na swój własny obraz, aby mógł jak najskuteczniej go wesprzeć, na ogół rozwiązując wiele problemów i skracając czas poświęcany na wsparcie jeszcze bardziej, a życie toczy się dalej. na.
Przypisuj rzeczy osobom, które potrafią to najlepiej. Niech wspierają i dokumentują swoją pracę. Wspieraj ich kreatywność i pozwól im się skupić bez rozpraszania uwagi i mikrozarządzania. Cała reszta to szkoła zarządzania BS, co niestety brzmi jak Twoja firma. Nie oznacza to, że Twój zespół też musi w niej pływać.
Z punktu widzenia firmy dobry menedżer promuje wartości firmy podczas wykonywania zadań zgodnie z tymi wartościami. Z punktu widzenia pracownika IT dobry menedżer pozwala zespołowi robić to, co należy, tak szybko i czysto, jak to możliwe, i działa jak bariera kałowa przeciwko kierownictwu wyższego szczebla, wypychając wartości, których nauczyli się podczas weekendowych zajęć MBA w gardle podwładnych. Jesteś pracownikiem firmy, co może nie być najlepsze dla twojego zespołu. Osoby z „dobrymi” umiejętnościami komunikacyjnymi są zbyt grzeczne, by to powiedzieć.