Mitől senior egy senior? Ki mit ért seniorság alatt? A válasz sok tényezőből áll össze, függ a cégtől és embertől is. Nincs egységes mérce vagy abszolút igazság a kérdésben. A kép gazdagítása végett én is szeretném megosztani veletek a gondolataimat a témáról. Valamint szeretnék bemutatni egy lehetséges eszközt, amivel cégen belül tisztázhatjuk a kérdést és termékeny párbeszédeket indíthatunk el a témában.

A dimenziók és szerepkörök

A véleménykülönbségek alapja, hogy a seniorság legtöbbször valamilyen kompetencia mix a fejünkben, amiről azt gondoljuk, hogy mindenkinél azonos formában fordul elő. Holott ez nagyon nincs így.

Első körben fontosnak tartom a különböző szerepkörök szétválasztását, megfogalmazását, még akkor is, ha egy kisebb cégnél például ezek a szerepkörök keverednek és egy ember több, akár egymással nehezen összeegyeztethető szerepet is visz. Gondoljunk bele egy egyéni vállalkozó helyzetébe, ahol egy személyben van jelen az elsősorban a külső elvárásoknak megfelelni vágyó vezető és a szakmai kiválóságra maximálisan törekvő fejlesztő.

Természetesen a két tétel (külső elvárások, szakmai követelmények) mindkettőjük fontossági listáján szerepel, csak más-más súllyal.

Csapatvezető

A seniort és a csapatvezetőt én például két külön szerepnek tartom és nem gondolom jó ötletnek egy seniortól a csapatvezetést mint skill-t feltétlenül elvárni.

Egy senior sose lesz csapatvezető, ha nem szed magára az emberekkel való foglalkozáshoz szükséges kompetenciákat. Ugyanakkor egy adott szakmaterületen való elmélyülés nem feltétlenül fogja magával hozni egyéb kompetenciák kiépülését. Számomra a seniorság mint dimenzió, az adott szakmai kompetenciában való elmélyülésnek a mértéke. A csapatvezető pedig több kompetencia megfelelő egyvelege, szinergiája.

Félreértés ne essék: nem gond, ha munkaadóként elvárjuk ezeket a kompetenciákat mindenkitől, akit seniornak hívunk, csak legyenek egyértelműek ezek az elvárások. Ezek az elvárások, ugyanis nagyon gyakran csak cégen belül tekinthető evidenciának.

Ugyanígy a munkavállalói oldalról ne akadjunk fenn azon, ha egy seniortól, a saját seniorság definíciódon túli kompetencia együttest várnak el egy álláshirdetésben.

Teljesen jogosnak gondolom azt az elvárást, hogy csapatban dolgozva egy idő után az igény megszülessen a különböző egyéb kompetenciák kiépítésére. Én is úgy gondolom, hogy e kettő együtt kellene, hogy járjon. A tapasztalatom viszont az, hogy számos esetben ez nem történik meg és nem is feltétlenül baj, ha van a csapatban egy olyan senior fejlesztő aki soha nem is akar majd egy csapat vezetője lenni.

Személy szerint én a megfelelő kommunikációs kompetenciákat várom el egy seniortól, de ez mindig külön sorban szerepel, ha álláshirdetés rakok össze.

Az időfaktor

Ha azt kérdezed, hogy hány év kell, hogy valakiből senior lehessen, akkor 3-5 évet fogok mondani. Ha azt kérdezed, hogy valaki hány év után válik senior-rá, akkor viszont nem fogok tudni neked válaszolni. Mert a 3-5 év az egy szükséges, de nem elégséges feltétel.

Amennyiben nem töltesz el három-öt évet az adott területen akkor nem leszel senior, mert nem lesz elég gyakorlatod, de attól nem leszel senior, ha eltöltesz három-öt évet, de közben az adott időt nem a szakmai kiválóságra való törekvéssel töltöd el, hanem a munkahelyi minimum elvárásoknak való megfeleléssel.

Gondolj bele, ha éveken át azt az egy lehetséges megoldást tudod nyújtani, amit egy junior két perc keresés után megtalál a neten, akkor ugyanaz a junior vagy, mint aki annak idején ezt megkereste. Fejlődésed azért nem látják és te azért nem tudod azt megmutatni, mert nincs. Feladatonként tudsz nyerni konstans 2 percet, amit egy másik senior minimum két-háromszoros vagy akár százszoros sebesség növekedésével kell összevetni, hasonló minőségi mutatók mellett. Ha ennek ellenére is emelkedő fizetésed volt és most annyit keresel mint egy senior, akkor becsüld meg a helyet ahol vagy és ne akarj váltani.

Architekt és a komplexitás

Sokszor az architectet gondolják a senior utáni lépésnek. Ez igaz is lehet, azonban azzal, hogy valaki évek alatt megtanult villámsebesen összerakni egy adott üzleti domainben lévő alkalmazást, még nem jelenti azt, hogy architect lesz. Attól senki nem lesz képes nagy és komplex rendszereket összerakni, ha sok száz kis komplexitású rendszert pattintott össze. Ettől inkább egy igen értékes senior lesz, aki az adott business domain-ben hasonlóan kis komplexitású rendszereket villámsebesen fog elkészíteni.

Ezektől függetlenül egy ilyen seniort igen értékessé tesz az a tulajdonsága is, ha egy feladatról előre meg tudja mondani, hogy az túl van azon a komplexitási szinten amit még meg tud oldani avagy sem. Egyszóval kell-e bevonni architectet a projectbe avagy sem.

Egy architectet pedig az tesz értékessé, ha a nagy komplexitású projekteket olyan önálló kis komplexitású részekre tudja szétszedni, amit már meg lehet valósítani és az működik is.

Kompetencia mátrix készítése

Most már talán elárulhatom, hogy én a junior/senior nulldimenzióra való egyszerűsítésének nem nagyon vagyok a híve. Nem hiszem azt, hogy van értelme csak erről a két kategóriáról beszélni. Első lépésként nyisuk ki a dolgot és szélesítsük picit. Például vezessük be a gyakornok fogalmát és ne csodálkozzunk többet, hogy a juniornak nincs gyakorlata és ne csodálkozzanak a jelentkezők, hogy egy juniortól munkatapasztalatot várnak el. Legyen a gyakornok az akinek nincs munkatapasztalata és nem várnak el tőle legalább egy év gyakorlatot. Ha úgy érezzük adjuk hozzá még a mid vagy középhaladó szintet is, de első körben négynél több lépcsővel ne számoljunk.

Ezután fogalmazzuk meg azt, hogy mit is jelentenek az egyes szintek. Ehhez írjuk fel azokat a szakmai és nem szakmai kompetenciákat amiket fontosnak tartunk. A technológiai ismeretektől kezdve a softskillekig legyen ott minden.

Ebből a kettőből készítsünk táblázatot, oszlopokba legyenek a kategóriáink(gyakornok, junior, mid, senior), sorokba a kompetenciák vagy más néven szükséges ismeretek. A kettő találkozásánál a cellákban ne csak kell/nemkell értéket írjunk, hanem használjuk a “Kell-e nekem az egyetem” című cikkemben a “Hogyan mérjük a tudást” fejezetnél bevezetett négyes skálát: 1 - ismeret, 2 - megértés, 3 - alkalmazás, 4 - integráció

Ezt a táblázatot szerepkörökként (developer, techlead, manager, pm, adminisztráció stb.) készítsük el, majd töltsük ki közösen. Beszéljünk róla!

  • Mit várunk el egy új belépőtől?
  • Mikor válik a cég hasznos tagjává egy régóta itt dolgozó?
  • Mi kell egy developernek, hogy manager legyen?
  • Milyen karierutak vannak a cégben, és ezeket hogyan lehet bejárni?

Ha jól csináltuk, ezekre a kérdésekre tudunk majd gyorsan választ adni a táblázatok segítségével. Ne akadjunk fent első körben olyanokon, ha esetleg kijön, hogy a gyakornoknak ismernie kell a cég szolgáltatásait, termékeit. Nem kell talán értenie se, csak ismernie. Természetesen ezek a speciális, céghez, üzleti domainhez kapcsolódó fogalmak ismerete ne egy belépő szűrő legyen, hanem tekintsünk erre egy olyan eszközként, ami segíteni fogja a döntésünket a próbaidő végén, hogy marad-e az illető avagy elköszönünk tőle.

Készüljünk több fordulóra, iterációra, mivel egyes szerepköröket szét fogunk szedni több szerepkörre, és lesznek olyanok majd amiket összevonunk. Itt a folyamat és az, hogy párbeszédet folytatunk ezekről legalább annyira fontos, mint a végső táblázatok. Hisz lehet, hogy folytattunk már erről párbeszédet a cégen belül korábban, de ennyire célhoz kötötten és struktúráltan nem nagyon valószínű. Érdekes lesz látni majd, hogy egy frontend vagy backend fejlesztőnél mennyire nagy részt képvisel majd az azonos fejlesztői kompetenciák és milyen keveset a specifikus backend vagy frontend rész.

A puding próbája az evés, tartja a közmondás. Kérjük meg munkatársainkat, hogy töltsék ki magukra vonatkozóan a táblázatot. Természetesen folyamatosan kommunikáljunk erről az új dologról és adjunk segítséget, kivonatot, kitöltési útmutatót nekik. Kik fogják ezt látni, milyen célból gyűjtjük ezeket az adatokat stb. Ezután személyes beszélgetések keretében adjunk és kérjünk róla visszajelzést, beszélgessünk róla.

  • Könnyű volt kitölteni?
  • Voltak nehézségek?
  • Mik voltak ezek?

Ha kell pontosítsunk, javítsunk a táblázatokon.

Egy ilyen táblázat alapjául szolgálhat a személyes fejlődési terv kidolgozásához is, vagy cégen belüli karrierút tervezéséhez, de ezekről egy másik bejegyzésben írok majd.

Érdekesnek találod ezt, kipróbálnád? Keress nyugodtan, szívesen segítek. Egyetértesz, tetszik? Oszd meg, küldd el, lájkold. Kiegészítenéd, vitatkoznál? Szólj hozzá!