Skiftet til DevOps-tankesett: Ledelseslærdommer fra en teknologidirektør

Jeremy Freeman

Jeremy Freeman startet sin karriere i programvarebransjen gjennom et bachelorprogram i informatikk. Han var så heldig å få delta i et lite entreprenørskapsprogram innen ingeniørfag ved North Carolina State University. Mens han studerte i programmet, møtte han sin nåværende medgründer, Hersh Tapadia, og dette møtet endret karriereretningen hans.

 

Én «ordentlig» jobb og tre oppstartsbedrifter senere leder han et ingeniørteam hos Allstacks, og han gleder seg over utfordringene ved ikke bare å utforme et godt produkt, men også å bygge et godt team og et sterkt selskap.

Spørsmål: Har du en mentor som har inspirert eller hjulpet deg på karriereveien så langt?

Det er så mange. Det har vært fantastisk å være en del av oppstartsmiljøet i Raleigh i North Carolina, og det finnes dusinvis av mennesker som har hjulpet meg på måter de kanskje ikke engang er klar over. Selv om jeg kunne ha trukket frem bestemte navn, er det noen avgjørende historier som har formet synet mitt på verden. 

En av historiene kommer fra en salgsleder som holdt et innlegg i en av entreprenørskapsklassene mine på universitetet. Som ingeniørstudent med fokus på å skrive kode og utvikle tekniske ferdigheter var salg både fremmed og uinteressant for meg. Denne personen fortalte imidlertid en historie som hjalp meg å se ting på en annen måte.

Han fortalte om en samtale med en av sine tekniske kolleger. Kollegan sa: «Jeg skjønner ikke hvordan du gjør det.» Selgeren svarte: «Gjør hva da?» Kollegan svarte: «Har et salgsmål. Det må være så stressende å bli tvunget til å selge for å kunne spise.» Han tenkte over dette et øyeblikk og svarte ganske enkelt: «Det er det, men hvis jeg ikke selger, får ikke du spise heller.»

Denne historien hjalp meg virkelig med å sette ingeniørarbeid i perspektiv.

En annen person som hjalp meg, var en mentor som hadde ledet ingeniørselskaper og -divisjoner, og som senere endret karriere for å hjelpe folk med å finne ut av ideene sine og finne roller i ulike oppstartsbedrifter. Han veiledet meg gjennom mange utfordringer, men en av de viktigste innsiktene han ga meg, var at de fleste ledere i tekniske organisasjoner utmerker seg på ett av tre områder:

«Nerdesjefen», stjernelederen eller den sentrale produktpersonen. Han fortsatte med å si at et vellykket selskap trenger alle tre, og at en god leder må identifisere hvem de selv er, og deretter ansette personer med de andre ferdighetene. Dette har hjulpet meg med å forstå utviklingen min som ingeniørleder og hvor jeg bør engasjere meg mer eller mindre.

Spørsmål: Kan du nevne tre styrker eller ferdigheter som har vært viktige på reisen din?

Et motto jeg følger, er: «Pass inn først, og skil deg deretter ut.» Selv om det er litt fyndig, minner det meg på at når jeg begynner å jobbe med et nytt team, må jeg først lære teamet å kjenne. Det er avgjørende å forstå hvorfor ting er som de er, for å bygge tillit.

Hvis jeg for eksempel møter opp den første dagen og forsøker å innføre eller argumentere for en stor endring, vil standardreaksjonen være motstand, og jeg har gjort jobben min vanskeligere fremover. Det er viktig å se etter likheter og områder med enighet i et nytt team før man prøver å utfordre status quo eller gjøre store endringer. Denne tilnærmingen gjelder også når man bygger nye relasjoner på alle livets områder.

En annen leveregel som veileder meg, er: «Det folk sier og gjør, samsvarer bare delvis med det de tenker og føler.» Selv om det kan høres pessimistisk ut, liker jeg tanken på at mennesker ofte handler under et enormt press for å opptre eller snakke på en bestemt måte.

Når du for eksempel spør noen hvordan dagen deres går, svarer de nesten alltid «Bra» i stedet for å åpne seg og virkelig fortelle hvordan de har det. Når man jobber med team og grupper, er det viktig å være oppmerksom på dette presset for å kunne forstå og vise empati. Hvis noen rapporterer til deg, kan det for eksempel være vanskelig for dem å ta ansvar for en feil dersom de frykter konsekvenser.

Som leder er det avgjørende å bygge opp og kontinuerlig evaluere miljøet vårt for å fremme åpenhet. Ellers kan vi utilsiktet skape en kultur der ting får ulme i teamet uten å bli tatt opp.

Når det gjelder å lede team, må man være vedvarende selvreflekterende og evaluere tidligere arbeid for å utvikle sterke ferdigheter. Selv om det å «se innover» fungerer for meg, fungerer det kanskje ikke like godt for alle, og en god leder må forstå de ulike måtene mennesker lærer og utvikler seg på.

S: Hvilke ferdigheter prøver du fortsatt å utvikle?

Hvis jeg går tilbake til rådene fra en av mentorene mine, jobber jeg hele tiden med ledelsesdelen av de tre rollene til en teknisk leder. Jeg har vært så heldig å jobbe med en kollega som er fantastisk på dette området, og som har vist meg noen viktige måter å utvikle og forbedre meg på.

Som medgrunnlegger av en teknologisk oppstartsbedrift har jeg hatt stort fokus på teknologi og produkter, og jobbet med små team. Nå som organisasjonen vår vokser, må jeg vokse sammen med den. Ledelse er en ferdighet som er like viktig som programvareutvikling.

S: La oss snakke om å ha et vellykket DevOps-team. Hva er de viktigste målene et DevOps-team kan identifisere for en digital transformasjonsreise?

Noe av det viktigste jeg hører fra andre ledere, er behovet for en felles forståelse av hva DevOps betyr for organisasjonen. Jeg har sett organisasjoner der «DevOps» betyr å ansette en SRE, kalle vedkommende en DevOps-ingeniør og feire.

Et viktig sted å begynne er å ta for seg kjernekomponentene i DevOps-syklusen og identifisere hvordan arbeid og ideer flyter gjennom utviklingsprosessen. Ta utgangspunkt i én enkelt utviklingsoppgave, følg den fra oppstart til den fører til neste oppgave, så kan du oppdage noen viktige mangler.

Du kan for eksempel oppdage at QA-teamet ditt er adskilt, og at dere har en «kast det over muren»-mentalitet som påvirker evnen til å jobbe raskt. Når du først har definert denne prosessflyten i organisasjonen, kan du se på verktøy som kan hjelpe.

S: Finnes det utfordringer eller vanlige fallgruver som DevOps-team bør ta hensyn til?

DevOps er en måte å jobbe på. På mange måter er det oppfølgeren til den smidige transformasjonen som feide gjennom programvareutviklingsbransjen for flere tiår siden. Det er viktig å tenke på det på denne måten. Mange organisasjoner slet med smidig transformasjon på grunn av manglende forståelse og oppslutning fra ledelsen. Ledere trodde at vi bare skulle begynne med daglige ståmøter og få gjort 50 prosent flere oppgaver. I ettertid var det åpenbart feil.

På samme måte tror ledere i dag at vi bare trenger en CI/CD-pipeline for å overgå Dora-målingene, og at vi vil se 50 prosent produktivitet. Endringen i tankesett er avgjørende. DevOps muliggjør fullt eierskap til programvareleveransens livssyklus, noe som gjør det mulig for team å bygge bedre systemer. DevOps gir team mulighet til å identifisere hvordan de kan bli bedre og gjennomføre forbedringene, så ledere må skape rom for og støtte dette for virkelig å se effekten på organisasjonen.

S: Hvordan kan effektivt samarbeid og god kommunikasjon mellom teammedlemmer øke produktiviteten og suksessen til et DevOps-team, og hvilke praksiser kan legge til rette for dette?

Kommunikasjon er avgjørende innen teknologisk utvikling. Nesten alle problemer kan spores tilbake til dårlig kommunikasjon, og DevOps er ikke noe unntak. Hvis vi går tilbake til behovet for en felles forståelse av hva DevOps betyr for organisasjonen, må dere virkelig forstå hvor dere skal, og ha en felles visjon for å ha mulighet til å lykkes.

Noen av de viktigste praksisene jeg har sett, er å definere enkle kontrollpunkter i prosessen. Disse må handle om arbeidet, ikke personene som utfører det. Når dere har definerte prosesser for hvordan oppgaver og informasjon flyter gjennom teamet, blir dere mer effektive når dere må bytte mellom oppgaver, særlig når avbrytelser oppstår, og dere kan skalere ulike deler av teamet uavhengig av hverandre.

Hvert team og produkt har litt ulike behov, og ved å definere disse kontrollpunktene og hva som må skje ved hvert av dem, blir det lettere å se hvor ineffektivitet oppstår.

Spørsmål: Hvilken rolle spiller CI/CD i DevOps, og hva er beste praksis for implementering av CI/CD-pipelines for å sikre en sømløs og pålitelig prosess for programvareutgivelser?

Det er avgjørende å få programvareendringer fra idé til produksjon så raskt som mulig. Manuelle prosesser er ekstremt trege og prisgitt mennesker. Mennesker er riktignok gode på ting som problemløsning og kreativitet, men er ofte dårlige til å gå uttømmende gjennom sjekklister hundrevis av ganger om dagen. Automatisering av det kjedelige arbeidet gjør det virkelig mulig for teamet ditt å fokusere på det de er best på. I tillegg er datamaskiner eksepsjonelt raske og kan skaleres raskt. Å opprette en pipeline som utnytter disse egenskapene, er den største fordelen ved å ta i bruk en CI/CD-prosess.

Én viktig ting å huske på når du bygger en slik prosess, er å balansere hastighet med sikkerhet. Selv om du kan automatisere hver commit fra en utvikler direkte til produksjon, gir det ingen sikkerhet. Ved å bygge pipelinen slik at den tillater dette hastighetsnivået, og gradvis legge til kontroller, kan du hjelpe deg selv i fremtiden. Kanskje må alt i begynnelsen godkjennes uttrykkelig av en QA-ingeniør og en releaseingeniør, men selve prosessen kan i praksis bare bestå av et knappetrykk.

Når du har fått på plass automatisert testing, kan det hende du kan fjerne QA-godkjenningen.  

Spørsmål: Hvordan bidrar det å fremme en DevOps-kultur og -tankegang til den samlede suksessen til et DevOps-team, og hvilke strategier kan organisasjoner bruke for å fremme denne kulturen blant utviklings- og driftsteamene sine?

Den viktigste kampen i denne transformasjonen er å bekjempe  «kast det over veggen»-tankegangen. Hvis du er ny på denne reisen, kan det hende du har fem eller seks team som må berøre hvert enkelt arbeidselement før det kommer i produksjon. Når du går over til DevOps, fremmer du et felles eierskap til hele livssyklusen til dette produktet.

Det kan kreve betydelige endringer i hvordan du utformer, bygger og distribuerer løsningen din. Selv om mange kjenner til å lage programvare som er enklere å teste, krever det å ta i bruk en DevOps-kultur at man bygger systemer og plattformer som eies fra ende til annen av små team.

Spørsmål: Hva er de «5 viktigste komponentene i et vellykket DevOps-team»? Del en historie eller et eksempel for hver av dem.

1. En felles forståelse av hva DevOps betyr for organisasjonen din. – Et av de mest kontraproduktive DevOps-initiativene oppstår når ledelsen og teamet ikke er samkjørte om resultatene. DevOps handler om langt mer enn bare å ansette «DevOps»-ingeniører og kjøpe et CI/CD-verktøy.  Når dere er enige om at det dreier seg om et skifte i tankegang, gir dere teamene myndighet til å ta fullt eierskap til leveringen av kundeverdi fra ende til annen

2. Rom og støtte til å identifisere og gjennomføre endringer – DevOps-team identifiserer ofte mange måter å forbedre leveringen og teamets effektivitet på.  Hvis man ikke gir rom for denne utforskingen, begrenser det i stor grad hvilken innvirkning teamet ditt kan ha på å drive endringer.

3. Måter å måle og identifisere suksess gjennom data – Alle kjenner til DORA-målingene og de fire nøkkelmålingene du gjør av utviklingsorganisasjonen din for å vurdere DevOps-modenhet.  Selv om dette er en god start, må du identifisere hva det betyr for virksomheten din å være en DevOps-organisasjon – og det bør du gjøre gjennom data.

4. Et produkt som er bygget for å støtte eierskap til og utvikling av denne filosofien – DevOps er en god filosofi for mange organisasjoner, men selskaper er ofte ikke klare til å omfavne transformasjonen. Du må være sikker på at produktet ditt kan støttes av et kombinert drifts- og utviklingsteam.  Produkter som driftes lokalt, produkter med rigide utgivelsessykluser og produkter som ganske enkelt ikke har tilstrekkelig modenhet til å støtte et slikt team, passer kanskje ikke godt.  Du vil se enkelte fordeler når teamet ditt tar i bruk en mer driftsorientert tankegang, men effekten er begrenset.

5. Automatisering og verktøy – Sørg for at ting skjer konsekvent og raskt, og sørg for ansvarlighet når det gjelder arbeidsavtaler. En av de sentrale endringene i en DevOps-organisasjon er arbeidsavtalene du etablerer med teamet ditt og mellom teamene dine. Hvis du etablerer en testprosess som krever at all kode gjennomgår regresjonstesting før distribusjon, bør du automatisere den. Du bør etablere automatiserte kontroller og sperrer for å sikre dette. Når du har etablert disse verktøyene og praksisene, oppdager du ofte at ambisiøse mål som kontinuerlig distribusjon bare er noen få trinn unna.

S: Hvilke nye trender ser du som kan få betydelig innvirkning på strategier for digital transformasjon i fremtiden?

Mange av de store løftene knyttet til ting som overgang til DevOps, bygger på data på høyt nivå og brede resultater. Ofte er disse overskriftsbaserte tallene, som «organisasjonen din er 50 prosent mer effektiv», nesten umulige å måle, og det kan være vanskelig å bekrefte at man oppnår denne typen resultater.

Jeg forventer å se en mer målrettet innsats for å identifisere konkrete resultater for hver organisasjon før man starter på en flerårig reise innen digital transformasjon. Dette samsvarer ikke bare med det økte fokuset på forretningseffektivitet de siste årene, men sikrer også suksess. I stedet for brede mål som de nevnte, er spesifikke (men betydningsfulle) mål som «Vi løser kundeproblemer 25 prosent raskere» mer målrettede.

Fremme vekst gjennom veiledning

Betydningen av veiledning og åpen kommunikasjon kommer tydelig frem i Jeremy Freemans reise. Ved å aktivt lære av andre og fremme et samarbeidsorientert miljø kan ledere sette DevOps-teamene sine i stand til å oppnå gode resultater.

Abonner på nyhetsbrevet fra The CTO Club for flere intervjuer, innsikt i DevOps og tips om veiledning!