Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Jeg er det eneste udenforstående menneske, der nogensinde har fået lov til at deltage i en julefrokost hos et specialkorps her i landet. Det var en stor oplevelse.
Hvert team havde forberedt et festligt indslag for de andre, og de havde brugt tid, kræfter, materiel og kreativitet på det.
Tidligere på året var der kommet en masse ekstra penge til special-folkene fra Folketinget (noget med terror, selvfølgelig), men også et krav om, at de - på magisk vis - skulle få mange flere til at gennemføre optagelsesprøven end hidtil.
Jeg sagde ved en anden lejlighed til chefen, at så skulle de jo bare sænke adgangskravene, hvilket han klart og tydeligt fortalte mig ikke kom til at ske.
Nå, men tilbage til julefrokosten: Et af holdene havde lavet en sketch om de kommende adgangskrav, hvor det eneste krav var, at man selv kunne fiske en baret frem fra en Legoborg og sætte den på hovedet. Det grinede vi meget af det år.
Hvorfor lykkes projekterne hos AWS, men ikke Skat?
Jeg har i to tidligere klummer skrevet lidt om min forundring over, hvorfor store projekter lykkes hos AWS, Azure, med flere, og hvorfor de ikke lykkes i Skat, Nets, NetCompany, med flere.
Den første klumme om emnet argumenterede for, at alle, der er involveret i projektet, skal forstå teknologistakken:
Den anden handlede faktisk ikke så meget om at få projekter til at lykkes, men var mere nogle udgydelser om Statens IT-råd, en eventuel it-havarikommission og en nedadvendt tommelfinger til SKI:
Så nu tager vi fat på det tredje, eller reelt kun det andet, afsnit i serien om, hvorfor projekter (mis)lykkes her, dér og allevegne.
Den gode måde at hyre på
Lad mig begynde med at beskrive en radikal måde at sikre sig, at projekter lykkes i højere grad: Amazon Web Services' (AWS') måde at hyre folk på:
Hvis man vil have et opslået job i AWS, sker der følgende:
Man indsender et resumé, som er en blanding af et rent CV og lidt "Jeg lærte dette og hint...".
Hvis det ser interessant ud bliver man inviteret til en screening, hvor en senior- udspørger én i en time med nogle såkaldte behavioural questions (dem vender jeg tilbage til).
Hvis hun synes godt om én, indstilles man til at gå videre.
Først får man en halv til en hel times møde med en recruiter, der giver gode råd til, hvordan man kan forberede sig bedst muligt til forløbet.
Så bliver man bedt om at skrive et par sider om et givet emne, for eksempel "What is your greatest invention?".
Det skyldes, at man ikke ansætter folk, der er dårlige til at formulere sig skriftligt.
Det skyldes, at man har forbudt PowerPoint i hele Amazon. De siger, at "deres PowerPoint er dokumenter".
Hvert møde i projekter indledes typisk ved, at alle rundt om bordet i tavshed læser et dokument igennem, der er relevant for mødet. PowerPoint er forbudt. Punktum. Imagine.
Seks interviews
Sideløbende med den skriftlige opgave inviteres man til seks interviews, hver af dem en time langt med seks forskellige personer (med forskellige funktioner) og med hvert sit fokus omkring to eller tre såkaldte ledelsesprincipper.
På den måde sikrer man sig, at ansøgeren også kan formulere sig mundtligt.
Amazon har i mange år haft 14 ledelsesprincipper (LP'er). Dem er de meget stolte af. De er også gode, synes jeg. Se selv:
Først en lege-let-version:
amazon leadership principles – Google Søgning
Og her en kedelig, skriftlig version:
Amazon's Leadership Principles (aboutamazon.com)
De har tilføjet to LP'er mere, der handler om LGBTQAPIK og noget med at være god ved planeten, men disse indgår ikke i pensum.
Man opfordres til at sætte sig grundigt ind i LP'erne, se en masse videoer på YouTube om den type spørgsmål man bliver stillet desangående, osv.
Spørgsmålene er af typen "Fortæl om et tidspunkt, hvor du skulle træffe en beslutning uden at have tilstrækkelig med data - hvad gjorde du?", osv. Det kaldes behavioural questions.
Man opfordres til at svare i STAR-formatet (Situation, Task, Action, Result), gerne med én linie til S, to linier til A og tre linier til R ... og man opfordres til at tænke over eksempler i forhold til alle LP'erne.
Bar-raiser
Der stilles virtuelle redskaber til rådighed for de af interviewene, der har at gøre med praktiske eksempler på system design og/eller kodning.
Og dem, der interviewer, er folk, der både er meget dybt inde i materien og har fået en masse træning i at spørge på en pæn, men dybdegående, måde.
Ved ét, muligvis to, af de seks interviews er der også en såkaldt bar-raiser med.
Det er ikke en person, der kan løfte bardisken nede på den lokale bodega.
Bar-raiserens opgave er at sikre, at ansøgeren er bedre end 50 procent af de mennesker, som man har ansat, allerede i tilsvarende funktioner i organisationen. På den måde sikrer de, at organisationen bliver bedre og bedre. Alle medarbejdere trænes i øvrigt i at afholde interviews.
Til sidst samles de seks interviewere og bar-raiseren og afgiver deres stemmer ("Inclined" eller "Not inclined"), og de diskuterer frem og tilbage i en time eller to, og hvis der er tvivl er det bar-raiseren, der har vetoret.
Fantastisk miljø
Folk, der arbejder der, siger, at det er et fantastisk miljø at arbejde i. Folk er dygtige, vil gerne blive dygtigere og tager LP'erne alvorligt, inklusive det at være gode team-medlemmer, have rygrad til at sige fra, og alt det andet.
Man laver, med mine fattige ord, en elite-agtig organisation af dygtige folk, der ikke tror, at de er bedre end de andre, og som virkelig kan deres håndværk.
Og alder, etnicitet, S&M-tilbøjeligheder, og så videre betyder intet. Det kunne PET-chefen lære noget af.
Jeff Bezos har udtalt, at om han så kun bliver husket for én ting, så håber han, at det bliver Amazons ledelsesprincipper.
Han tror, at andre kunne have fornøjelse af dem, og han er meget stolt af dem. Ét af de mange spørgsmål, man kan blive stillet, er i øvrigt: "Hvilket ledelsesprincip føler du, at Amazon mangler?".
I projekterne kan man gøre karriere som udvikler, arkitekt, product manager, osv. - mens dem, der tager sig af management-ting kører i en parallel organisationssøjle uden indflydelse på, hvad der sker i projektet.
Der er prestige og karriere i at være i projekterne. De sætter sig høje mål, de hyrer de bedste de kan, de VIL bare lykkes, og der er nedtur, hvis de ikke lykkes.
Dem i management-søjlen er også OK, såmænd, de er gode mod dyr og varmt klædt på, og alt det dér. Men dem, der skal få det vilde projekt til at lykkes og gøre verden til et bedre sted, har altid fortrinsret og ledelsens fulde opmærksomhed. Der er forskel på det danske militær i 80'erne og det Ukrainske militær i dag.
Skal godkendes af alle
Product Manageren (PM'en) har i øvrigt en meget anderledes rolle i AWS-projekter end sådan én har i andre bikse.
Hun skal skrive pressemeddelelsen og en omfattende Q&A om det kommende produkt på forhånd, og begge dele skal godkendes af alle, helt op til de fem-seks folk, der sidder lige under Jeff Bezos.
Og de fem-seks folk ved, hvad det handler om.
Check for eksempel min bekendte James Hamilton ud (på LinkedIn eller andre steder), som jeg mødte i 2004, da jeg - på en bryllupsrejse - holdt et foredrag for 140 SQL Server-udviklere i Redmond om nogle af Oracles fordele - han kan noget, og han er lidt svær at løbe om hjørner med, hvad angår teknologi, projekter, mv.
PM'ens pressemeddelelse plus spørgsmål/svar kan tage flere måneder at udarbejde, fordi hun skal hente input fra alle parter og få alle til at være enige om scope, features, osv. osv.
Først når pressemeddelelse plus Q&A er godkendt af alle, høj og lav, engineering, business, leadership, tager man fat på selve projektet.
Der kræves ledelseserfaring, diplomatiske evner, teknisk viden, beslutningskraft, osv. af en PM, og de nyder meget høj agtelse i organisationen. De er edderkoppen i midten, og nok den vigtigste person i projektet.
Tilbage til Andedammen: Alt det hurlumhej med at ansætte nye folk har vi heldigvis forstået at forenkle og effektivisere her i Danmark. Godt nok tager processen længere tid, men den omfatter langt, langt færre trin og folk.
Herhjemme skal man indsende en ansøgning og et CV, dokumentere at man har en videregående uddannelse (ekstremt vigtigt!), og derefter tage en uvidenskabelig hokuspokustest på nettet, der jo - som det så rigtigt siges - er et godt udgangspunkt for en åben snak... og så kommer man til samtale, HVIS man ligner dem, der arbejder i HR, HVIS CV'en indeholdt nogle nøgleord, som forekom i jobannoncen, og selvfølgelig HVIS man er under 50...
Jeg har ansat folk på udseendet
Jeg sagde ofte i min Miracle-tid, at jeg ansatte folk på udseendet.
Med dét mente jeg ikke, at de var smukke og unge, men at det var afgørende, om der var en god kemi med dem, de skulle arbejde sammen med - udover, at det faglige skulle være på plads.
Jeg er bange for, at der nu om dage nogle gange er tale om lidt mere konkrete eksempler på det gode udseende.
Hvis I kan huske min historie i begyndelsen af klummen om julefrokosten hos nogle af de hårde folk, så gør AWS det, som chefen for enheden sagde til mig, nemlig holder fast i høje adgangskrav uanset et skrigende behov for flere folk, mens mange danske bikse bruger metoden med baretten i Legoborgen.
Er det ikke interessant? Kunne man bruge AWS-lignende metoder i Danmark?
Eller er vi - også på dét punkt - meget klogere og bedre uddannede end alle andre? Er der nogen, der gør noget lignende herhjemme? Mangler Amazon nogle ledelsesprincipper? Skriv, gerne uden brug af PowerPoint, til mig på mogensxy@gmail.com!
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.