Ostatnio poproszono mnie o radę – „Czy powinienem ubiegać się o rolę lidera otwartego zespołu, jeśli nie jestem techniczny?”
W tym przypadku dowiedziałem się, że „techniczny” znaczy „jest inżynierem oprogramowania”.
Jeśli jesteś już zatrudniony w organizacji zajmującej się tworzeniem oprogramowania, krótka odpowiedź brzmi „tak”, zdecydowanie powinieneś.
Jeśli pochodzisz spoza branży technologii, możesz mieć trudnośći, ponieważ branża ta jest nieco dziwna, ale nadal rozważ ją, jeśli masz doświadczenie w kierowaniu zespołem.
Absolutnie nie musisz być byłym inżynierem oprogramowania, aby osiągnąć ten wynik.
Posiadanie pokory, by zadawać właściwe pytania, takie jak to, jest znaczącym wskaźnikiem, że będziesz świetnym liderem zespołu. Zadawanie właściwych pytań jest ważną częścią pracy.
Bardziej szczegółowa odpowiedź obejmuje zdefiniowanie niektórych warunków i rozbicie rzeczy, które mogą się zdarzyć, jeśli nie jesteś byłym ani obecnym inżynierem oprogramowania.
Określenie roli
W niektórych organizacjach rola team leadera jest skoncentrowana na ludziach, a w innych zarówno na ludziach jak i na technicznych aspektach.
Powinieneś porozmawiać z kierownikiem HR’u , aby zrozumieć, jaka to rola.
Oto niektóre obowiązki kierowników zespołów i liderów technicznych.
Obowiązki skoncentrowane na ludziach
- Potrafi dobrze zarządzać czasem swoim i innych
- Musi być pozytywny i skoncentrowany na rozwiązaniu
- Naprawdę dba o dobre samopoczucie swojego zespołu
- Identyfikowanie i ograniczanie ryzyka
- Spokojnie radzenie sobie z kryzysem
- Planowanie przyszłych prac i planowanie zdolności
- Zatrudnianie i budowanie wizerunku pracodawcy
- Promowanie samoorganizacji dla zespołu
- Ułatwienie komunikacji, ceremonii i spotkań
Techniczne obowiązki
- Definiowanie i wykonywanie architektury rozwiązania
- Bezpośredni coaching i mentoring ról technicznych
- Projektowanie i wdrażanie praktyk rozwoju oprogramowania
- Badania i wybór technologii i narzędzi
- Przywództwo poprzez stosowanie standardów
Inne
- Oszacowanie i dostawa zgodnie z harmonogramem
- Ułatwienie szkolenia i wsparcia klienta
Chodzi o to, że organizacje często potrzebują osoby bardziej skoncentrowanej na ludziach niż na kwestiach technicznych. Zespół jest już pełen starszych inżynierów, którzy lubią skupiać się na kwestiach technicznych.
Zazwyczaj możesz zidentyfikować i współpracować z innymi członkami swojego zespołu i organizacji, aby objąć część roli związaną z architekturą oprogramowania.
Nie pracowałem w organizacji, w której starsi inżynierowie i kierownicy zespołów nie byliby chętni do pomocy.
W rzeczywistości większość starszych inżynierów, z którymi współpracowałem, prawdopodobnie wolałaby pracować z liderem zespołu, który wspierał ich we wszystkich rzeczach ludzi i zostawił ich, aby mogli zająć się projektowaniem i budowaniem fajnych rzeczy bez ingerencji.
Zobacz również: Nauka programowania zajmuje 500h
Jesteś “techniczny”
Z zawodu możesz nie być inżynierem oprogramowania, ale fakt, że pracujesz w organizacji zajmującej się programowaniem produktów, oznacza, że prawie na pewno jesteś już techniczny.
Nie sprzedawaj się krótko.
Wykonanie UX i projektowanie produktu jest techniczne, testowanie produktu jest techniczne, oprogramowanie marketingowe w 2020 roku jest super techniczne, wszystkie analizy są techniczne. Pracujemy w branży, w której wszyscy musimy dobrze rozumieć, w jaki sposób każda rola wpływa na wyniki produktu – wszyscy jesteśmy techniczni.
Jestem dość techniczny, ale podkreślam dla mojego zespołu, że chociaż cieszę się, że mogę pomóc w technicznym ukierunkowaniu, skupiam się na dobrym samopoczuciu zespołu.
Dbam o to, kto i dlaczego w naszej pracy. Z przyjemnością zostawiam to zespołowi, chyba że poprosi (lub widzę ryzyko).
Zrozum ryzyko i ogranicz je
Porozmawiaj z kierownikiem ds. Rekrutacji i wysłuchaj wszelkich wątpliwości. Nie próbuj ich tam rozwiązywać. Zanotuj je i daj sobie czas na ich przemyślenie i odpowiedź później.
Zrozum, że prawie nikt nie zaznaczy wszystkich pól w danym opisie stanowiska. Menedżer ds. Rekrutacji będzie miał priorytety dotyczące wszystkich wymagań, które musi spełnić kandydat, i pójdzie na kompromis w przypadku dobrego kandydata.
W roli lidera zespołu rzeczy ludzi są zwykle ważniejsze. Nie zawsze, ale zwykle.
Różnorodność wiedzy
Jeśli wszyscy kierownicy zespołu w Twojej organizacji to byli inżynierowie oprogramowania, istnieje problem z różnorodnością.
Różnorodność w pierwszym zespole kierowników zespołów jest taka sama, jak różnorodność wiedzy w zespole ds. Rozwoju produktu. Różne perspektywy są tak samo ważne w całej organizacji, jak w jednym zespole indywidualnych współpracowników.
Zobacz również: Cienie i blaski mentoringu
Pomoc w zakresie architektury i oprogramowania
Powinieneś porozmawiać z innymi członkami zespołu i przewodnikami, którym ufasz. W razie potrzeby będą wspierać Cię w zakresie pomocy związanej z architekturą oprogramowania.
Jeśli dostaniesz pracę, a są członkowie zespołu, którzy sprawiają, że trudno jest nie być inżynierem oprogramowania, po prostu zrozum, że prawie na pewno to oni, a nie Ty, mają problem. Istnieją różne sposoby rozwiązania konfliktu i powinieneś o tym przeczytać i ciężko nad tym pracować.
Ogólnie rzecz biorąc, po prostu wyjaśnij, że kwestie techniczne należy do zespołu, aby wspólnie rozwiązać. Zrobisz wszystko, co możliwe, aby pomóc im współpracować, aby uzyskać najlepszy wynik. To rola lidera zespołu.
Szacowanie i ryzyko w oprogramowaniu
Menedżer ds. Zatrudnienia może martwić się o twoją zdolność do dokładnego oszacowania i zidentyfikowania ryzyka, jeśli wcześniej nie pisałeś oprogramowania.
Chodzi o to, że musisz tylko ułatwić i upewnić się, że te rzeczy regularnie się zdarzają. Istnieją dobrze znane techniki ułatwiania oceny grupy i zachęcania do komunikacji w zespole, w tym ryzyka. Opisz, w jaki sposób się nauczysz i zastosuj je do menedżera ds. Zatrudnienia.
Po pewnym czasie pracy nad produktem szybko dowiadujesz się, jakie obszary są ryzykowne lub w jaki sposób praca nad złym starszym kodem w porównaniu z dobrym starszym kodem w porównaniu z greenfieldem może wpłynąć na harmonogram.
Te rzeczy i tak będą specyficzne dla twojej organizacji, więc doświadczony inżynier oprogramowania / kierownik zespołu spoza organizacji zaczynałby od podobnej lub nawet gorszej pozycji do kogoś, kto nie kodował, ale znał system, biznes i klientów bardzo dobrze.
Dla deweloperów
A jeśli jesteś programistą, który kieruje zespołem bez doświadczenia w inżynierii oprogramowania, nie bądź dla nich dupkiem. Wspierają cię w sposób, którego nawet nie widzisz, wspierają ich, jeśli chodzi o wiedzę związaną z inżynierią oprogramowania! 🙂
Ich zadaniem jest zwiększenie efektywności zespołu i stworzenie lepszego miejsca do pracy, jeśli to robią.
Ciesz się swobodą techniczną!
Wersja angielska artykułu na dev.tu : https://dev.to/darraghor/should-you-apply-for-a-team-lead-role-if-you-re-not-technical-4fio
Darragh ORiordan
Hi! I’m Darragh ORiordan. I live and work in Auckland, New Zealand enjoying the mountains and the ocean. I build and support happy teams that create high quality software for the web!