A harmadik részben megígértem, hogy ezentúl rendszeresen visszamegyek a gépházba, és nagyjából ezt is teszem: van egy state machine, amit a csapattal együtt hibakerestem végig egy péntek délután, és van egy migráció, amelyben már nem csak jóváhagytam a tervet, hanem ott ültem a telepítésnél is, amikor kiderült, hogy a terv téves feltételezésre épült. Csak közben feltűnt, hogy a lift le-fel járása nem old meg egy másik, kellemetlenebb kérdést, amelyet eddig sikeresen elkerültem: amikor valaki papírt tesz elém, amelyen az áll, hogy most már hivatalosan is architekt vagyok, mit válaszoljak, amikor pontosan tudom, hogy a papír kiállítása előtti és utáni napom semmiben nem különbözik?
A helyzet, amelyben ezt a kérdést megkaptam, ismerős lesz mindenkinek, aki dolgozott már nagyobb szervezetben: volt egy éves értékelő beszélgetés, volt benne egy mondat arról, hogy a szerepkörömet formalizálják, és volt egy pillanat, amikor rájöttem, hogy örülnöm kellene, csak épp nem tudtam eldönteni, minek is örüljek pontosan.
Amikor a szerepből tantárgy lesz
Amíg én ezen a mondaton rágódtam, a piac egy másik, sokkal konkrétabb választ adott ugyanarra a kérdésre: intézményesítette. Az evosoft, a Valoro Consulting és a BME HSDSLab közösen indított egy tizenkét napos, több hónapon át tartó képzést azoknak, akik szoftver-, teszt- vagy szolgáltatásarchitekt szerepre készülnek, és a program alapja pontosan az, amit egy jó képzéstől várni lehet: hét nap architektúra és technológiai döntéshozás, négy nap csapatvezetés és döntési folyamatok, egy nap arról, mire jó és mire nem jó a mesterséges intelligencia ebben a szerepben.
Az érdekes nem is a tanterv, hanem az előtörténete. Az evosoft közel tíz éve futtat hasonló képzést házon belül, eddig több mint kétszáz kollégájuk végezte el, és a NextARCH nem más, mint ennek a belső tapasztalatnak a piacra vitt, moduláris, harmadik felekkel kibővített változata. Tíz év alatt tehát egy dolog, amit korábban csak úgy lehetett megszerezni, hogy valaki évekig ráment egy rendszerre, most napra pontosan megtervezett kurzussá vált, alapszinttel, specializációval és három választható iránnyal.
Ebben nincs semmi rossz, sőt: pontosan azt teszi láthatóvá, amit egyénileg nehéz megfogalmazni, mégpedig hogy az architekti munka külön, tanítható készségekből áll össze. A Valoro cégvezetője, Csősz Ildikó, ezt egy mondatban is összefoglalta: egy architekt nem önmagában dolgozik, csapatot irányít, tehát rendelkeznie kell vezetői képességekkel, még ha formálisan esetleg nem is vezető. Ez a mondat pontosan a saját problémámra mutat rá, csak fordítva: van egy funkció, amelyet vezetői képességek nélkül nem lehet betölteni, és van egy titulus, amelyet a legtöbb helyen csak azután osztanak ki, hogy a funkciót már egy ideje elláttad.
Nem cím, hanem metszet
Will Larson négy staff-szintű mintát ír le — Tech Lead, Architect, Solver, Right Hand —, de a lényeg nála nem a négy kategórián van, hanem azon a mondaton, amelyet szeretnék minden falra kifüggeszteni, ahol architekti kinevezésekről döntenek: „Being a Staff-engineer is not just a role. It’s the intersection of the role, your behaviors, your impact, and the organization’s recognition of all those things." — azaz a szint nem egy szerepkör, hanem a szerepkör, a viselkedésed, a hatásod és a szervezet ezekre adott elismerésének metszete.
Sean Goedecke pontosan ezért nem szereti, ha ezeket az archetípusokat célként adják oda junior staff-jelölteknek, mert szerinte az archetípusok csak azt írják le, mire lehet használni valakit, aki már kiépítette a bizalmat a vezetéssel, nem pedig azt, hogyan lehet staff szintre kerülni. Ahogy ő fogalmaz: „trust and influence accumulate over time. You can’t aim for those archetypes directly." — a bizalom és a befolyás idővel gyűlik össze, ezeket az archetípusokat nem lehet közvetlenül megcélozni.
Ez a két mondat együtt magyarázza meg, miért érzem furcsának a papírt az asztalon. A NextARCH-hoz hasonló képzés kiválóan alkalmas arra, hogy felgyorsítsa a tanulást, méghozzá azt a tanulást, amelyet korábban csak évek alatt, munka közben lehetett megszerezni; abban azonban nem segít, hogy a szervezet elismerése — Larson mondatának utolsó tagja — bármivel is korábban érkezzen, mint amennyi idő alatt valóban kiderül, hogy a viselkedésed és a hatásod indokolja-e a bizalmat. A cím tehát megelőzheti magát a funkciót, csak épp akkor egy időre üresen kong.
Miért fáj ez ennyire
Az őszinte válasz az, hogy azért izgat ennyire egy egyszerű HR-mondat, mert nem a fizetésről van szó, hanem arról, amit a szakirodalom identitásfenyegetésnek hív. Jennifer Petriglieri meghatározása szerint az identitásfenyegetés olyan tapasztalat, amelyet az egyén úgy értékel, hogy az kárt tehet valamelyik identitása értékében, jelentésében vagy megélésében, és a modellje szerint erre alapvetően kétféleképpen reagálhatunk: vagy megvédjük a fenyegetett identitást olyan eszközökkel, mint az elhallgatás vagy a fenyegetés forrásának leértékelése, vagy átalakítjuk az identitást magát, és beépítjük az új információt.
Az első részben bevallott momentum — hogy nem tudtam megmondani, melyik Angular-verziót használjuk, és ehelyett inkább körbebeszéltem a kérdést — pontosan az első típusú válasz tankönyvi esete: nem a tudásom hiányát rejtettem el, hanem azt védtem, amit az a tudáshiány fenyegetett, az „ilyen vagyok, aki ismeri a rendszert" identitást. A négyrészes sorozat, amit írok, végig ennek a második útnak a gyakorlása: nem letagadom a hiányosságot, hanem újraírom, mihez kötöm az architekt-identitásomat — nem a fejben tartott számokhoz, hanem a Hohpe-féle liftjáráshoz, a visszafordítható döntésekhez, most pedig ahhoz, hogy a cím ne előzze meg a munkát.
A csapat is tud hazudni magának
Ha egy ember identitásfenyegetésre elhallgatással válaszol, egy csapat erre azt a szervezeti mintát adja, amelyet Connelly, Zweig, Webster és Trougakos tudáselrejtésnek nevez: amikor valaki szándékosan visszatart olyan információt, amelyet tőle kértek. A szerzők három formát különítenek el, és mind a három ijesztően ismerős egy olyan architekttől, aki inkább a penthouse-ban marad: a playing dumb, amikor egyszerűen letagadjuk, hogy lenne érdemi tudásunk a kérdésről; az evasive hiding, amikor ígéretet teszünk egy későbbi, teljes válaszra, amely aztán soha nem érkezik meg; és a rationalized hiding, amikor a visszatartást alapos, szakmailag jól csomagolt indokkal magyarázzuk.
Ez a három forma pontosan azoknak a helyzeteknek felel meg, amelyeket a második részben a felszínen tartott döntésekről írtam: a „majd a dokumentációban részletezem" az evasive hiding archetípusa, a „most nincs idő végigmenni rajta, bízzatok bennem" a rationalized hiding, és az, amikor egy architekt azt válaszolja egy konkrét technikai kérdésre, hogy „ez már túl mélyen van a részletekben", nagyon gyakran nem szakmai határ, hanem playing dumb — csak épp fordítva, hiszen itt nem a tudás hiányát, hanem a tudás elavulását rejtjük el. A tudáselrejtés tehát nem egyéni gonoszság, hanem ugyanaz az identitásvédelem, amit Petriglieri leír, csak szervezeti méretben és görbe tükörben.
Az ízlés, ami hónapok alatt avul
Mindezt egy külső tényező is felgyorsítja, amelyet eddig szándékosan nem hoztam szóba: az, hogy amit az architekt cím valójában igazol — az ízlést, azt az összegyűjtött tapasztalatot, amely alapján valaki megérzi, melyik megoldás fog fájni két év múlva —, most éppen egy olyan eszköz kezdi el olcsón és tömegesen előállítani, amelynek nincs identitása, amit védenie kellene.
Shrivu Shankar erről ír pontosan a Taste Is Not a Moat című esszéjében: szerinte az ízlés nem védőárok, hanem alfa — olyan előny, amely csak a jelenlegi alapszinthez viszonyítva ér valamit, és ez az alapszint néhány hónap alatt feljebb kúszik. Ahogy megfogalmazza, „my judgment is only valuable relative to what AI can do by default, and that default resets every few months" — a saját ítéletem csak annyit ér, amennyivel többet tud annál, amit az AI alapból tud, ez az alapszint pedig néhány havonta újraindul, és amit korábban előnynek gondoltam, egyszerűen az új alapértelmezés részévé válik.
Ez a legkényelmetlenebb mondat az egész sorozatban, mert pontosan azt a tulajdonságot fenyegeti, amelyre az architekti cím intézményesítése — a NextARCH-hoz hasonló képzések — épül: hogy az évek alatt felszedett ízlés stabil, átadható, vizsgázható tudás. Ha viszont az ízlés fele annak, amit egy generikus modell alapból tud, akkor egy fix tanterv gyorsabban avul, mint egy verziószám, és pont ez teszi értelmetlenné azt a kérdést, hogy melyik Angular-verziót használjuk: a válasz attól lesz kevésbé fontos, hogy nem tudom, és attól, hogy holnapra egy más kérdés lesz a lényeg. Amiben viszont a Hohpe-féle visszajárás mégis véd: a saját rendszerünkről szerzett, friss, helyi tapasztalat nem az általános ízlés része, ezt egy modell nem tudja alapból kitalálni, mert ehhez nála kellene lennie a hozzáférés, ami minden lemenő úttal frissül.
Titulus vagy funkció
Vissza a papírhoz az asztalon. Végül aláírtam, de előtte feltettem egy kérdést, amelyre már tudtam a választ, csak ki akartam mondani: ha holnaptól nem mennék vissza a gépházba, változna-e valami a papíron? A válasz nem, és pontosan ez a lényeg, amit ez a négyrészes sorozat körbejárt, anélkül hogy egyetlen mondatba akartam volna belesűríteni.
A cím tehát nem választás a titulus és a funkció között, mert a kettő nem egy súlyú dolog: a funkció az, amit nap mint nap csinálok, a titulus az a késleltetett visszajelzés, amelyet a szervezet ráragaszt, amikor már eleget látott ebből a funkcióból. A veszély sosem az, hogy valaki megkapja a címet — ez Larson mondatának természetes vége, a szervezet elismerése —, hanem az, ha a cím megelőzi a munkát, és onnantól a megvédése helyettesíti a folytatását, mert pontosan ez az a pillanat, amikor beindul az identitásfenyegetés, az elhallgatás és a tudáselrejtés spirálja, amit ez a cikk körbeírt. Az egyetlen dolog, amit ígérni tudok — magamnak is, nem csak az olvasónak —, hogy a papír aláírása után is ugyanannyit megyek le a gépházba, mint előtte, mert ha ez változna, akkor tényleg csak egy papír maradt volna a négy cikkből.
Források
- Will Larson: Staff archetypes — Staff Engineer: Leadership Beyond the Management Track
- Sean Goedecke: Why I don’t like the "staff engineer archetypes" — 2025
- Schopp Attila: Három cég, egy közös képzés — ITBUSINESS, 2025.09.08
- Architekt szerep 2025-ben — ITBUSINESS, 2025.10.25
- Jennifer L. Petriglieri: Under Threat: Responses to and the Consequences of Threats to Individuals’ Identities — Academy of Management Review, 2011 (idézve: Frontiers in Psychology, 2023)
- Catherine E. Connelly, David Zweig, Jane Webster, John P. Trougakos: Knowledge hiding in organizations — Journal of Organizational Behavior, 2012 (idézve: PMC8823662)
- Shrivu Shankar: Taste Is Not a Moat — 2026