Beste svaret
Forstå først at hvis du snakker om programvareteknikk, så består alle bedriftstitler mer eller mindre av
“Principal” -ingeniør er vanligvis en som er en individuell bidragsyter, og er mer erfaren enn en senior programvareingeniør. Han / hun er vanligvis tildelt ett prosjekt om gangen, og bidrar ikke til flere team
I programvareteknikk er det to spor, teknisk spor og styringsspor. Vanligvis varierer spor etter senior programvareingeniør. Hvis du er på et ledelsesspor, vil du sannsynligvis gå
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 programvareingeniør → Programvareingeniør → Senior programvareingeniør → Rektor programvareingeniør → Arkitekt → Seniorarkitekt → Bedriftsarkitekt
Inntil du er hovedprogramvareingeniør, er du fokusert på ett prosjekt. Det forventes at du gir noen tekniske veiledninger til medlemmene i teamet ditt. Når du går inn i å være en «arkitekt», forventes det at du hjelper til i flere prosjekter
Igjen, titler i programvareingeniørjobber er mer eller mindre tullete. En rektor kalles rektor bare slik at alle i teamet vet at fyren vet tingene sine. Også ganger dette skjer. Det er 2 gutter, A & B som startet i selskapet sammen. A er mer teknisk kompetent. B er mer kompetent med mennesker. Begge går frem til Sneior programvareingeniør sammen. Siden A er mer teknisk kompetent, blir han stadig mer interessant, noe som holder ham lykkelig. Til slutt forfremmes B til «Team Lead». Nå er A ikke fornøyd, fordi det virker som om A ikke ble promotert, selv om A er teknisk kompetent. Han får fremdeles de interessante prosjektene og alt, men han har ikke en ny tittel å følge med. Så selskaper kommer med en ny tulltittel: “Principal Software Engineer. Her blir du forfremmet. glad nå? Å ja, btw, nå som du er «rektor» går du litt ut av kuben din og hjelper andre mennesker også «
Svar
Jeg har jobbet i selskaper der titler brukes for å indikere progresjon og også i selskaper der faktiske ingeniørnivåer (for det meste) ikke blir publisert.
Jeg ser begge situasjonene fungere forutsatt at du får folk som er mer fokusert på å gjøre ting og mindre fokusert på titlene deres. Du får feil folk, og de vil finne en måte å sutre over noe annet – det er ikke titler, det kan være rolle eller kompensasjon eller noe annet.
Så lenge du gir folk en vei for å vokse både profesjonelt og økonomisk, og du er rettferdig mot dem, tilstedeværelsen av fravær av titler er ikke veldig stor avtale.
For hva det er verdt, selv om du antar at du hadde en person som bytter jobb, du må bare vurdere hvor de passer inn fra sak til sak, selv om titlene er eller ikke er de samme.
En god tommelfingerregel er å spørre folk om rollen til prosjektet deres og granske andre faktorer som teknisk kompleksitet og teamstørrelse for å finne ut hvor de ligger så langt som dine egne bedriftsnivåer (enten publisert eller ikke).
- Er de en individuell bidragsyter eller leder de 10 personer eller 50 personer?
- Hva gjør de på daglig basis – skriver de kode eller administrerer folk?
- Hvis de ikke skriver kode, er de ea manager eller er de en teknisk person?
Hvis du mener at en kandidat kanskje ikke passer for bedriften din på det nivået de er på for øyeblikket, men fortsatt kan bidra på et lavere nivå, vær åpen og ærlig med dem. Noen mennesker er kanskje ikke opptatt av å ta en redusert rolle, mens andre kan ha det bra hvis de tror at de fremdeles kan vokse på andre måter.
Jeg har sett flere tilfeller hos forskjellige selskaper av personer ansatt hos et nivå under deres forrige tittel med den forståelse at hvis de beviste seg, ville de bli forfremmet raskt, og i nesten alle de tilfellene da ansettelsen ble gjort riktig, gikk det virkelig bra.
Kortversjon: Å bekymre seg for tilstedeværelsen av fravær av titler i et utviklingsteam er som å krangle om faner eller mellomrom. Velg en, vær konsistent med den og fokuser på å gjøre ting og bygge et team og andre reelle problemer.