Dere trenger ikke flere søknader når dere skal ansette en skyarkitekt. Dere trenger bedre svar. Denne skyarkitekt rekrutteringsguide for bedrifter handler derfor ikke om å skrive en penere annonse. Den handler om å finne ut hva dere faktisk trenger, hva markedet krever, og om kandidaten kan ta ansvar for valgene som blir dyre å gjøre feil.
En skyarkitekt er sjelden bare personen som kan mest om AWS, Azure eller Google Cloud. Rollen ligger i skjæringspunktet mellom teknologi, sikkerhet, kostnad, drift og forretning. Ansetter dere feil, får dere ikke bare en kompetansegap. Dere kan få en plattform som er vanskelig å skalere, en skyregning ingen forstår eller et team som mister fart fordi arkitekturen ikke tåler virkeligheten.
Start med oppdraget, ikke teknologistacken
Mange stillingsbeskrivelser for skyarkitekter er kopiert fra en annen stillingsannonse. Resultatet er en ønskeliste med tre skyleverandører, ti sertifiseringer, Kubernetes, sikkerhet, DevOps, data og ledererfaring. Da leter dere ikke etter en person. Dere leter etter et helt fagmiljø i én CV.
Begynn heller med hvilket problem rollen skal løse de neste 12 til 18 månedene. Skal dere flytte en gammel applikasjonsportefølje til skyen? Bygge en plattform som flere produktteam kan bruke? Få kontroll på sikkerhet og tilgangsstyring? Eller redusere kostnader etter en periode med rask vekst?
Svarene avgjør hvilken skyarkitekt dere trenger. En kandidat som er sterk på migrering fra on-premise, er ikke automatisk rett person for å etablere en moderne utviklerplattform. En arkitekt med tung erfaring fra regulerte miljøer kan være uvurderlig i finans eller helse, men overdimensjonert for et mindre selskap som først og fremst trenger fart og gode tekniske prioriteringer.
Skriv derfor oppdraget i klart språk: Hva skal være annerledes når personen har vært i jobb i ett år? Hvis dere ikke kan svare på det, kan ingen kandidat treffe presist.
Skyarkitekt rekrutteringsguide for bedrifter: Skill krav fra signaler
Teknologier er lette å telle. Dømmekraft er vanskeligere å se. Likevel er det dømmekraften som ofte skiller en god skyarkitekt fra en kandidat som bare kjenner verktøyene.
En erfaren skyarkitekt skal kunne forklare hvorfor en løsning passer, ikke bare hvordan den settes opp. Be kandidaten beskrive avveiningene de har gjort. Når valgte de en enklere løsning fremfor den teknisk mest avanserte? Når sa de nei til en tjeneste eller en migrering fordi risikoen var for høy? Hvordan håndterte de konflikt mellom sikkerhet, utviklingshastighet og kostnad?
Se særlig etter fire signaler i vurderingen:
- Evnen til å oversette tekniske valg til konsekvenser ledelsen og produktteamene forstår.
- Erfaring med å etablere prinsipper som andre kan bygge etter, uten å bli en flaskehals.
- Forståelse for sikkerhet, identitet, logging og beredskap som en del av arkitekturen, ikke som kontrollarbeid til slutt.
- Dokumenterte valg i miljøer som ligner deres i kompleksitet, tempo og ansvar.
Sertifiseringer kan støtte en vurdering, men de kan ikke bære den. En sertifisert kandidat uten erfaring fra reelle prioriteringer kan trenge langt mer oppfølging enn dere har sett for dere. Samtidig kan en kandidat med færre formelle bevis ha bygget akkurat den typen plattform dere trenger. Det avhenger av oppdraget.
Ikke gjør erfaring med én leverandør til et absolutt krav
Hvis dere bruker Azure, er Azure-erfaring relevant. Det betyr ikke alltid at dere må avvise kandidater med hovedvekt på AWS eller Google Cloud. De grunnleggende problemene er ofte de samme: identitet, nettverk, automatisering, observability, kostnadsstyring og styring av tilgang.
Men det finnes grenser. Dersom dere trenger noen som skal rydde opp i et komplekst Azure-miljø fra første arbeidsdag, må dyp Azure-erfaring veie tungt. Dersom dere bygger et nytt team og trenger arkitekturkompetanse mer enn leverandørspesifikke snarveier, kan en kandidat fra en annen plattform være et bedre langsiktig valg.
Vær ærlige om hvilken av disse situasjonene dere faktisk står i. Det sparer både dere og kandidaten for en prosess som aldri kunne endt godt.
Test for arbeid, ikke for presentasjon
Et intervju blir svakt når kandidaten bare blir bedt om å fortelle om seg selv. De mest overbevisende kandidatene er ikke nødvendigvis de som tar mest plass i rommet. Gi heller kandidaten et realistisk scenario fra deres hverdag.
Det kan være en applikasjon med ustabile kostnader, uklare tilgangsmodeller og utviklere som opplever at produksjonssetting tar for lang tid. Spør hva kandidaten vil undersøke først, hvem de vil involvere, hvilke beslutninger som ikke kan vente, og hva de ville utsatt til dere vet mer.
Dere trenger ikke en perfekt løsningsskisse. Dere ser etter rekkefølge, resonnering og evne til å håndtere usikkerhet. En dyktig arkitekt kan si «jeg vet ikke ennå» uten å bli vag. Deretter forklarer personen hva som må avklares før et ansvarlig valg kan tas.
La også de riktige menneskene møte kandidaten. En CTO ser andre ting enn en produktleder. En sikkerhetsansvarlig vil utfordre andre antakelser enn en utvikler. Men ikke la seks personer stille de samme generelle spørsmålene. Avtal på forhånd hva hver intervjuer skal vurdere, og bruk en felles scorecard etterpå. Magefølelse blir ikke mindre upålitelig av at flere har den samtidig.
Sjekk markedet før dere låser lønn og senioritet
Dere kan ha et godt definert behov og fortsatt miste kandidatene fordi premissene ikke holder. Skyarkitekter med erfaring fra komplekse miljøer er sjelden aktive søkere. De har ofte en jobb de mestrer, gode kolleger og flere henvendelser i innboksen. En annonse alene forteller dere mest om hvem som er tilgjengelig akkurat nå, ikke nødvendigvis hvem som er best.
Før dere bestemmer lønn, tittel og krav, bør dere vite hvor mange sammenlignbare selskaper som søker samme profil. Dere bør også vite hvordan dere fremstår som arbeidsgiver. Er teknologivalgene interessante? Har rollen reell påvirkning? Er lederansvaret tydelig? Og er lønnsnivået i nærheten av det markedet betaler?
Det kan være ubehagelig å oppdage at budsjettet ligger under medianen, eller at rollen dere kaller «skyarkitekt» i praksis er en senior plattformingeniør med ansvar ingen andre vil eie. Men det er bedre å vite det før prosessen starter enn etter at tre kandidater har takket nei.
I Mandag Match får dere fem anonyme kandidater, relevante lønnstall og en måling av arbeidsgiverattraktivitet før stillingen publiseres. Poenget er ikke å late som data velger kandidaten for dere. Poenget er at dere kan ta et valg på noe mer enn håp.
Vurder kandidaten som et menneske med alternativer
Når dere har funnet en aktuell kandidat, er ikke jobben gjort. De beste kandidatene vurderer dere like grundig som dere vurderer dem. De vil vite hvem de skal samarbeide med, hva de får mandat til å endre, og hva som skjer når tekniske hensyn kolliderer med korte frister.
Vær konkrete. Ikke lov «stor påvirkning» dersom arkitekturbeslutninger allerede tas av en ekstern leverandør eller av en ledergruppe uten teknisk innsikt. Ikke selg fleksibilitet dersom rollen krever kontinuerlig tilgjengelighet. En ærlig ramme tiltrekker færre feil kandidater og flere riktige.
Gi også raske svar. Stillhet etter et intervju er ikke nøytral. Den forteller kandidaten noe om hvordan dere tar beslutninger når presset øker. Dere trenger ikke ha bestemt dere samme dag, men dere skal kunne si hvor dere er i prosessen og når kandidaten får et reelt svar.
Den riktige skyarkitekten skal ikke bare passe inn i dagens miljø. Personen skal gjøre dere bedre rustet for det som kommer. Derfor bør dere gå inn i prosessen med et tydelig oppdrag, et ærlig bilde av markedet og respekt for at kandidaten velger dere også.
