Bedste svar
Forstår du først, at hvis du taler om software engineering, så er alle virksomhedstitler mere eller mindre sammensat
“Principal” -ingeniør er generelt en person, der bidrager individuelt og er mere erfaren end en senior softwareingeniør. Han / hun er normalt tildelt et projekt ad gangen og bidrager ikke til flere teams
I softwareteknik er der to spor, teknisk spor og ledelsesspor. Generelt afviger spor efter senior software engineer. Hvis du er på et ledelsesspor, vil du sandsynligvis blive
Junior software engineer → Software engineer → Senior Software engineer → Team lead → Scrum master → Project / Product Manager → Director → VP
Hvis du er på et teknisk spor, går du
Junior software engineer → Software engineer → Senior Software engineer → Principal Software engineer → Architect → Senior Architect → Enterprise Architect
Indtil du er den vigtigste softwareingeniør, er du fokuseret på et projekt. Det forventes, at du giver nogle tekniske vejledninger til medlemmerne af dit team. Når du går ind i at være en “arkitekt”, forventes det, at du hjælper med i flere projekter
Igen er titler i softwareingeniørjob mere eller mindre lort. En rektor kaldes rektor bare så alle i holdet ved, at fyren kender hans / hendes ting. Også nogle gange kan dette ske. Der er 2 fyre, A & B, der startede sammen i virksomheden. A er mere teknisk kompetent. B er mere kompetent med mennesker. Begge skrider frem til Sneior softwaretekniker sammen. Da A er mere teknisk kompetent, får han stadig flere og mere interessante ting, som holder ham glad. Til sidst bliver B forfremmet til “Team Lead”. Nu er A ikke glad, fordi det ser ud til, at A ikke blev forfremmet, selvom A er teknisk kompetent. Han får stadig de interessante projekter og alt, men han har ikke en ny titel at gå med. Så virksomheder kommer med en ny bullshit-titel: “Principal Software Engineer. Her forfremmes du. glad nu? Åh ja, btw, nu hvor du er “principiel” træder du lidt ud af din terning og hjælper andre mennesker også “
Svar
Jeg har arbejdet i virksomheder, hvor titler bruges for at indikere progression og også hos virksomheder, hvor faktiske ingeniørniveauer (for det meste) ikke offentliggøres.
Jeg kan se, at begge situationer fungerer, forudsat at du får folk, der er mere fokuserede på at gøre ting og mindre fokuseret på deres titler. Du får de forkerte mennesker, og de finder en måde at klynke over noget andet – det er ikke titler, det kan være rolle eller kompensation eller noget andet.
Så længe du giver folk en vej til at vokse både professionelt og økonomisk, og du er retfærdig over for dem, tilstedeværelsen af fravær af titler er ikke en enorm aftale.
For hvad det er værd, selv hvis du antog, at du havde en person, der skiftede job, du skal bare evaluere, hvor de passer ind fra sag til sag, selv om titlerne er eller ikke er de samme.
En god tommelfingerregel er at spørge folk om deres projekts rolle og også undersøge andre faktorer såsom teknisk kompleksitet og teamstørrelse for at finde ud af, hvor de ligger så langt som dine egne virksomhedsniveauer (uanset om de er offentliggjort eller ej).
- Er de en individuel bidragsyder, eller fører de 10 mennesker eller 50 personer?
- Hvad gør de dagligt – skriver de kode eller administrerer folk?
- Hvis de ikke skriver kode, er de da ea manager eller er de en teknisk person?
Hvis du mener, at en kandidat måske ikke passer til din virksomhed på det niveau, de er i øjeblikket, men stadig kan bidrage på et mindre niveau, vær åben og ærlig over for dem. Nogle mennesker er måske ikke klar til at tage en reduceret rolle, mens andre måske har det godt, hvis de mener, at de stadig kan vokse på andre måder.
Jeg har set flere tilfælde hos forskellige virksomheder af mennesker ansat hos et niveau under deres tidligere titel med den forståelse, at hvis de beviste sig, ville de blive forfremmet hurtigt, og i næsten alle de tilfælde, hvor ansættelsen blev udført rigtigt, gik det faktisk godt ud.
Kort version: At bekymre sig om tilstedeværelsen af fravær af titler i et udviklingsteam er ligesom at diskutere om faner eller mellemrum. Vælg en, vær konsistent med den og fokuser på at gøre ting og opbygning af et team og andre reelle problemer.