Jakie stopnie/tytuły obowiązują u Was w pracy?

Moja firma jest na etapie pewnych transformacji. Jedną ze zmian jest wprowadzenie dobrze określonych tytułów, z zakresem obowiązków, oczekiwanymi atrybutami takimi jak zasięg odpowiedzialności itp. Pomagam trochę w tym naszemu VP Engineering, i jestem ciekaw jak sprawa wygląda w innych firmach.

Przeglądałem oczywiście jak to robią niektórzy duzi gracze (dla zainteresowanych proponuje wygooglowac "software engineering career framework") ale chciałbym też przykłady z pierwszej ręki. Jeśli będziesz się tym dzielił, to proszę również o określenie rozmiaru firmy, np. przybliżona liczba pracowników.

Na dzień dzisiejszy u nas jest tradycyjny model, gdzie czysto techniczna ścieżka to junior, mid (po prostu Software Developer), senior. Później się lekko rozwidla bo jest Software Development Team Leader, lub w inną stronę Software Architect i Lead Architect. Plan jest taki żeby to pozmieniać, dodać jaśniejsze ścieżki rozwoju technicznego i managerskiego itp. Firma to ok 200 osób, ale jest również firma matka z ok. 1500 osób.

EDIT: Zainspirowany odpowiedzią @somekind sformułuję inaczej pytanie: jakie tytuły/ścieżki kariery obowiązują w Waszej pracy?

Proszę zauważyć że w tym wątku nie chodzi o przemyślenia i dywagacje nad tym czy dane tytuły coś w ogóle znaczą itp. chyba że macie coś do dodania w tym temacie w kontekście Waszej pracy. Samo zagadnienie problemów z tytułami było przerabiane wiele razy na tym forum.

A w sumie co za różnica jak to się nazywa? Nie jest ważniejsze to jaki jest zakres obowiązków i pensja?

No po seniorze, to trzeba jeszcze dać principala chyba.
A architektów też może być więcej rodzajów: system architect, solution architect, no i najważniejszy: enterprise architect.

We większości firm w których pracowałem była prosta hierarchia typu "Software Engineer". Każdy miał taki tytuł w papierach no matter what :P Przez takie ogólniki można praktycznie wszystko zrzucić na człowieka pod kątem obowiązków. Częsta praktyka w kontraktorniach.

Już imo nazewnictwo typu backend / frontend developer bardziej zawęża zakres obowiązków.

Przy dookreśleniu stanowisk powyżej seniora to polecam książkę: staffeng.com/book. Bardzo fajnie opisuje to jakie są typowe archetypy staff/principal inżyniera i pokazuje jak tacy ludzie pracują i jaki maja wpływ na organizacje

Jest nas trzech szeregowy, szeregowy i kapitan.

U nas jest kierownik i reszta :)

Jak dotąd we wszystkich firmach, w których byłem (z wyjątkiem jednego korpo ~2500 ludzi), podział kończył się na "developer szeregowy" oraz "team/tech leader".

Szeregowi pracownicy w stylu programiści/HR/it/TL etc i menadżerowie. Oni dopiero mają swoją rozbudowaną hierarchię. Tak to jest w dużym korpo.

Tytuły g**no znaczą.
Póki nie będzie egzaminów państwowych / branżowych, po których zdaniu można domniemywać że za tytułem idzie minimum umiejętności to co da firmie B nazwa stanowisk w firmie A?

W jednej z korp zmieniali tytuły w ciągu chyba 5 lat

• poziom developer technologia (junior dev java)
• poziom developer (senior dev)
• poziom inżynier oprogramowania (junior software engineer)

Czy to coś zmieniło?

Tytuły g**no znaczą.

Powiedz to w FAANG, gdzie często masz jasno określone obowiązki, widełki itp. Zgadzam się natomiast że często faktycznie tak jest, problem tylko w tym że ja nie pytam czy tytuły coś znaczą czy też nie, a o to jak to u Was wygląda. Konkretnie, jakie te tytuły w ogóle obowiązują.

EDIT: Po to też chcemy wprowadzić zmiany, żeby coś te tytuły jednak znaczyły i nie było niejasności.

@Aventus: chciałbym Ci jakoś pomóc, ale w sumie nie wiem jakiego efektu oczekujesz. To, żeby tytuły coś znaczyły i nie było niejasności - nie jest zbyt precyzyjne. :)

Może po porostu napiszę, jak to u mnie wygląda.
Mamy w zespole team leadera i 4 senior devów. Team lead ma pół etatu zaalokowane na programowanie, a drugie pół na spotkania.
Naszą odpowiedzialnością jako seniorów jest tworzenie i utrzymywanie softu. Jakiego konkretnie - no to zależy od zespołu, każdy ma przypisane jakieś swoje domeny, którymi się zajmuje.

W mojej obecnej firmie w ścieżce deweloperskiej jest inżynier (po amerykańsku - I, II, III), senior, principal, staff. W R&D nie widziałem architekta. Widziałem "customer experience architect", ale to nie R&D. Zespół odpowiada za swój projekt. Inicjatywa może wyjść od każdego. Mamy naprawdę doświadczony inżynierów i ludzie, którzy gdzie indziej mieliby tytuł "principal engineer" albo "architect" są często tylko seniorami, a jednak wpływ na rozwój produktów mają ogromny.
Mniej niż 500 osób na całym świecie, przy czym R&D to jakieś 130 osób.

W poprzedniej firmie było więcej pozycji, pincipal był rozbity na różne stopnie, do tego byli architekci, którzy też mogli być seniorami. Nie zauważyłem przełożenia tytułu na firmę. Byli architekci, którzy w zasadzie odgrywali rolę pryncypałka, a byli i pryncypałowie i seniorzy, którzy mieli wpływ na podejmowane decyzje i architekturę systemu nie mniejszą niż architekci. Jakieś 6000 pracowników na świecie, R&D nie pamietam jak duże, ale nie większe niż 1/4, a może i 1/5.

Na koniec dodam, że jakby firma limitowała mnie tytułem, uniemożliwiając wychodzenie z propozycjami, dyskusje z architektami i generalnie praktykowała politykę zamkniętych drzwi, to zdecydowanie nie byłaby to firma dla mnie.

@Aventus: a jaką pracę do tej pory wykonałeś? Jak to chcesz zaprojektować u siebie? Co będziesz proponował w swojej firmie?

Dla klepaczy:
Junior Software Developer,
Software Developer
Senior Software Developer
Senior Software Developer Master

Ale będąc Seniorem można awansować na Domain Architect zamiast na Master, i generalnie jest tak że tych Masterów jest b.mało bo powyżej Seniora trzeba mieć już funkcję "zarządczą" i podejmować decyzje. Można też będąc Seniorem próbować wbić na System Developera - czyli robić design na poziomie systemu a nie pojedynczych komponentów.

@Oggy2: ciekawe. Z tym master to można powiedzieć że trochę kontrowersyjnie jak na dzisiejsze czasy w świetle całej dramy z Gitem i master branch :D

Wspomniałeś że Senior może awansować na Domain Architect zamiast Master, oraz że tych drugich jest bardzo mało. A Domain Architect jest więcej? Czym się oni różnią- wydawałoby się że Domain Architect też podejmuje decyzje.

jakie tytuły/ścieżki kariery obowiązują w Waszej pracy?

Obecnie pracuję w małej firmie i w sumie nie ma żadnych jako takich tytułów. Każdy jest szeregowym developerem. Są też podziały typu junior/senior, ale one sprowadzają się głównie do doświadczenia i kasy. Nie tutaj żadnych korporacyjnych ram. Można być jeszcze liderem zespołu albo szefem firmy, ewentualnie CTO, ale to już są "polityczne" sprawy. Z mojej perspektywy zwykłego kodera, "ścieżka rozwoju" polega na tym, że mogę uczyć się nowych rzeczy, sprawdzić je na prodzie, coś zaprojektować od zera, wprowadzić swoje pomysły, podzielić się wiedzą, etc. W sensie papierologicznym praktycznie nie mam ścieżki kariery jako szeregowy koder, bo w obecnej sytuacji musiałbym kogoś wygryźć, szantażować lub bawić się w jakieś polityczne gry, aby wskoczyć wyżej w rzekomej firmowej mini-hierarchii i też nie jest powiedziane, że rzeczywiście bym coś na tym zyskał.

Czy oprócz tych tytułów i zakresów obowiązków, będziecie opracowywać ścieżki rozwoju między nimi? w sensie, co dokładnie musi spełnić kandydat, żeby przejść na tytuł wyżej/w bok, jakie nabyć kompetencje i w jaki sposób je ocenić?

@tmk3: tak, to jeden z głównych celów. Chodzi o jasne określenie zakresu obowiązków, wpływu na projekt(y), oczekiwanych umiejętności, rozwidlenie i określenie ścieżki rozwoju managerskiego i nie-managerskiego (zarządzanie ludźmi vs zarządzanie techniczne) itp.

W temacie tytułów to uwielbiam jakieś molochy rzędu Big4 czy banki i potem aby szeregowi programiści wpadali w widełki mają tytuły managerów czy vice presidentów. :D

@Aventus: dużo ludzi jest w to zaangażowanych? Bo to nie brzmi na robotę dla dwóch osób, ciężko byłoby devowi zrobić odpowiednią ścieżkę, np. managerska. Macie kogoś, kto coś takiego kiedyś wprowadzał i mógłby koordynować taką pracę? Taka wiedza nie jest tak zwyczajnie dostępna, już pomijając to, że nie da się tego skopiować między firmami :-\

@tmk3 to jest na razie wczesny etap. Będą zaangażowani chociażby wszyscy team leaderzy jak i osoby od strony nie-technicznej. To nie jest tak że mój VP mnie poprosił i my sobie we dwójkę szczęśliwe wszystko rozpisujemy jak nam się widzi- to by była nadinterpretacja moich słów. Podobnie sprawa wygląda z innymi firmami- wbrew temu co ktoś wcześniej sugerował, rzecz właśnie nie w tym żeby po prostu skopiować jakiś inny model. Nie wyklucza to jednak możliwości motywowania się tym jak to wygląa w innych miejscach, oraz uczeniu się na porażkach/sukcesach innych.

U mnie nie ma stanowisk.

A w poprzedniej pracy jak zaczęli wprowadzać stanowiska to się zwolniłem bo to jest korpo bul szit.

Ściemniacz, starszy ściemniacz, młodszy ściemniacz, lider ściemniaczy.
Plus kilka innych mniej istotnych, np. PM/SM.

U mnie większość ludzi pracuje teraz na kontraktach, czyli wg. firmowych zasad wszyscy jesteśmy "Software Developer". W projektach mamy jeszcze role, ale to nie są stanowiska. Jak mi kazali architektować, to dopisałem sobie "architekt" w stopce maila, bo wtedy jest szansa, że ktoś to przeczyta.

Z zabawnych spraw, mamy w projekcie UX Designera. Sztuk 1. Zawsze mam niezłą bekę, jak przedstawia się jako "Lead UX Designer". Zauważyłem, że Amerykanie mają dużo większe ciśnienie niż my na te wszystkie "principal master fellow engineer".

nas nazywają zasobami xD