Jeremy Freeman
Jeremy Freeman fik sin start i softwarebranchen gennem en bacheloruddannelse i datalogi. Han var så heldig at blive involveret i et lille iværksætterprogram inden for ingeniørfaget gennem North Carolina State University. Mens han studerede på programmet, mødte han sin nuværende medstifter, Hersh Tapadia, og denne introduktion ændrede retningen for hans karriere.
Efter ét “rigtigt” job og tre startups driver han nu et ingeniørteam hos Allstacks og motiveres af udfordringerne ved ikke blot at designe et fantastisk produkt, men også at opbygge et fantastisk team og en stærk virksomhed.
Spørgsmål: Har du en mentor, som indtil videre har inspireret dig eller hjulpet dig på din karrierevej?
Der er så mange. Det har været fantastisk at være en del af startupmiljøet i Raleigh, North Carolina, og der er snesevis af mennesker, som har hjulpet mig på måder, de måske ikke engang selv er klar over. Selvom jeg kunne nævne specifikke navne, har nogle afgørende historier formet mit syn på verden.
En af historierne kommer fra en salgsleder, som talte på et af mine iværksætterkurser på universitetet. Som ingeniørstuderende med fokus på at skrive kode og udvikle tekniske færdigheder var salg både fremmed og uinteressant for mig. Personen fortalte imidlertid en historie, som hjalp mig med at se tingene anderledes.
Han fortalte om en samtale med en af sine tekniske kolleger. Kollegeren sagde: “Jeg forstår ikke, hvordan du gør det.” Sælgeren svarede: “Gør hvad?” Kollegeren svarede: “At have et salgsmål. Det må være så stressende at være tvunget til at sælge for at kunne spise.” Han tænkte over det et øjeblik og svarede ganske enkelt: “Det er det, men hvis jeg ikke sælger, får du heller ikke noget at spise.”
Denne historie hjalp mig virkelig med at sætte ingeniørarbejde i perspektiv.
Du kan bygge det sejeste produkt eller den bedste service, men hvis du ikke kan vise værdien for de mennesker, det vil hjælpe, arbejder du bare med ingeniørarbejde i et vakuum.
En anden person, der hjalp mig, var en mentor, som havde ledet ingeniørvirksomheder og -afdelinger og derefter skiftede karriere for at hjælpe folk med at få styr på deres idéer og finde roller i forskellige startups. Han vejledte mig gennem mange udfordringer, men en af de vigtigste indsigter, han gav mig, var, at de fleste ledere i tekniske organisationer excellerer inden for et af tre områder:
Den “førende nørd”, den fremragende leder eller den centrale produktperson. Han fortsatte med at sige, at en succesfuld virksomhed har brug for alle tre, og at en god leder skal identificere, hvem de selv er, og derefter ansætte folk med de øvrige kompetencer. Det har hjulpet mig med at forstå min udvikling som ingeniørleder, og hvornår jeg skal engagere mig mere eller træde lidt tilbage.
Spørgsmål: Kan du nævne tre styrker eller færdigheder, som har været vigtige for din rejse?
Et motto, jeg følger, er: “Fald ind, og skil dig så ud.” Selvom det er lidt smart i en fart, minder det mig om, at jeg først skal lære teamet at kende, når jeg arbejder med et nyt team. Det er afgørende at forstå, hvorfor tingene er, som de er, når man skal opbygge tillid.
Hvis jeg for eksempel møder op på dag ét og forsøger at gennemføre eller argumentere for en større ændring, vil standardreaktionen være modstand, og jeg har gjort mit arbejde sværere fremover. Det er vigtigt at lede efter ligheder og områder, hvor man er enige, i et nyt team, før man forsøger at udfordre status quo eller gennemføre store ændringer. Denne tilgang gælder også for opbygning af nye relationer inden for alle dele af livet.
En anden leveregel, der guider mig, er: “Det, folk siger og gør, korrelerer kun med det, de tænker og føler.” Selvom det måske lyder pessimistisk, kan jeg godt lide tanken om, at mennesker ofte handler under et stort pres for at handle eller tale på en bestemt måde.
Når man for eksempel spørger nogen, hvordan deres dag går, svarer de næsten altid: “Godt,” i stedet for at åbne op og virkelig fortælle, hvordan de har det. Når man arbejder med teams og grupper, er det vigtigt at være opmærksom på det pres for virkelig at forstå og udvise empati. Hvis en person for eksempel refererer til dig, kan det være svært for vedkommende at tage ansvar for en fejl, hvis han eller hun frygter konsekvenserne.
Som leder er det afgørende at opbygge og konstant evaluere vores miljø for at fremme åbenhed. Ellers risikerer vi utilsigtet at skabe en kultur, hvor problemer kan ulme i teamet uden at blive taget op.
Når det handler om at lede teams, er det nødvendigt, at folk vedvarende reflekterer over sig selv og evaluerer deres arbejde for at udvikle stærke færdigheder. Selvom det fungerer for mig at “se indad”, fungerer det måske ikke godt for alle, og en god leder skal kunne genkende de forskellige måder, som mennesker lærer og udvikler sig på.
En effektiv leder fokuserer på at skabe balance mellem resultater og empati og reflekterer konstant over sine egne styrker og svagheder samt det bredere teams.
Have an account? Log In
Spørgsmål: Hvilke færdigheder forsøger du stadig at udvikle nu?
Hvis jeg vender tilbage til rådet fra en af mine mentorer, arbejder jeg konstant på ledelsessøjlen blandt de tre roller som teknisk leder. Jeg har været så heldig at arbejde sammen med en kollega, der er fantastisk på det område, og som har vist mig nogle vigtige måder at udvikle og forbedre mig på.
Som medstifter af en teknologisk startup har jeg fokuseret meget på teknologi og produkter og arbejdet med små teams. Nu hvor vores organisation vokser, er jeg nødt til at vokse sammen med den. Ledelse er lige så meget en færdighed som softwareudvikling.
Spørgsmål: Lad os tale om at have et succesfuldt DevOps-team. Hvilke centrale mål kan et DevOps-team identificere på en digital transformationsrejse?
En af de vigtigste ting, jeg hører fra andre ledere, er behovet for en fælles forståelse af, hvad DevOps betyder for jeres organisation. Jeg har set organisationer, hvor "DevOps" betyder at ansætte en SRE, kalde vedkommende en DevOps-ingeniør og fejre det.
Det er et vigtigt sted at starte at tage udgangspunkt i kernekomponenterne i DevOps-cyklussen og identificere, hvordan arbejde og idéer bevæger sig gennem jeres udviklingsproces. Tag en enkelt udviklingsopgave fra begyndelsen, og følg den, indtil den skaber den næste opgave, så kan I måske identificere nogle vigtige mangler.
Det kan for eksempel være, at jeres QA-team er adskilt fra resten, og at I har en “kaster det over muren”-mentalitet, som påvirker jeres evne til at bevæge jer hurtigt. Når I først begynder at definere dette procesflow i organisationen, kan I se på værktøjer, der kan hjælpe.
Mange organisationer begynder med værktøjer og driver langsomt og smertefuldt organisatoriske forandringer derfra. Det er en bagvendt måde at komme i gang på.
Spørgsmål: Er der udfordringer eller almindelige faldgruber, som DevOps-teams bør tage højde for?
DevOps er en måde at arbejde på. På mange måder er det efterfølgeren til den agile omstilling, der fejede gennem softwareudviklingsbranchen for årtier siden. Det er vigtigt at tænke på det på den måde. Mange organisationer havde problemer med agil omstilling på grund af manglende forståelse og opbakning fra ledelsen. Ledere troede, at vi bare skulle begynde at holde daglige statusmøder og få 50 procent flere opgaver færdige. Set i bakspejlet var det naturligvis forkert.
På samme måde tror ledere i dag, at vi bare har brug for en CI/CD-pipeline for at overgå DORA-målingerne, og at vi vil se en produktivitet på 50 procent. Det er afgørende at ændre tankegangen. DevOps muliggør fuldt ejerskab over hele livscyklussen for softwarelevering, hvilket gør det muligt for teams at bygge bedre systemer. DevOps giver teams mulighed for at identificere, hvordan de kan blive bedre, og implementere det, så lederne er nødt til at skabe plads og støtte for virkelig at se de organisatoriske effekter.
Spørgsmål: Hvordan kan effektivt samarbejde og kommunikation mellem teammedlemmer øge et DevOps-teams produktivitet og succes, og hvilke praksisser kan understøtte dette?
Kommunikation er afgørende inden for ingeniørarbejde. Næsten alle problemer kan føres tilbage til dårlig kommunikation, og DevOps er ingen undtagelse. Hvis vi vender tilbage til behovet for en fælles forståelse af, hvad DevOps betyder for jeres organisation, er I nødt til virkelig at forstå, hvor I er på vej hen, og have en fælles vision for at have en chance for at få succes.
Nogle af de vigtigste praksisser, jeg har set, er at definere enkle kontrolpunkter i processen. De skal handle om arbejdet og ikke om de personer, der udfører det. Når I har definerede processer for, hvordan opgaver og information bevæger sig gennem teamet, kan I arbejde effektivt med at skifte mellem opgaver, især når der opstår afbrydelser i arbejdet, og I kan skalere forskellige dele af teamet uafhængigt af hinanden.
Hvert team og hvert produkt har lidt forskellige behov, og ved at definere disse kontrolpunkter og hvad der skal ske ved hvert af dem bliver det lettere at se, hvor jeres ineffektiviteter er.
Spørgsmål: Hvilken rolle spiller CI/CD i DevOps, og hvad er bedste praksis for implementering af CI/CD-pipelines for at sikre en problemfri og pålidelig softwareudgivelsesproces?
Det er afgørende at få softwareændringer fra idé til produktion så hurtigt som muligt. Manuelle processer er ekstremt langsomme og afhænger af mennesker. Mennesker er ganske vist gode til ting som problemløsning og kreativitet, men de er ofte dårlige til udtømmende at gennemgå tjeklister hundredvis af gange om dagen. Automatisering af det kedelige arbejde gør det virkelig muligt for dit team at fokusere på det, de er bedst til. Derudover er computere exceptionelt hurtige og kan skaleres hurtigt. At oprette en pipeline, der udnytter disse muligheder, er den største fordel ved at indføre en CI/CD-proces.
En vigtig ting at huske, når man opbygger en proces som denne, er at afveje hastighed mod sikkerhed. Selvom du kan automatisere enhver commit fuldstændigt, så den går direkte fra en udvikler til produktion, giver det ingen sikkerhed. Hvis du opbygger din pipeline, så den muliggør dette hastighedsniveau, og langsomt tilføjer kontrolforanstaltninger, kan det hjælpe dig i fremtiden. Måske skal alt i begyndelsen godkendes eksplicit af en QA-ingeniør og en udgivelsesingeniør, men selve processen kræver måske blot et tryk på en knap.
Når du har fået automatiserede tests på plads, kan du måske fjerne QA-godkendelsen.
Spørgsmål: Hvordan bidrager fremme af en DevOps-kultur og -tankegang til et DevOps-teams samlede succes, og hvilke strategier kan organisationer bruge til at fremme denne kultur blandt deres udviklings- og driftsteams?
Den største udfordring i denne transformation er at bekæmpe “kast det over muren“-tankegangen. Hvis du er ny på denne rejse, har du måske fem eller seks teams, der skal arbejde med hvert enkelt stykke arbejde, før det kommer i produktion. Når du bevæger dig over i DevOps, fremmer du et fælles ejerskab for hele produktets livscyklus.
Det kan kræve betydelige ændringer i den måde, du designer, bygger og implementerer din løsning på. Selvom mange er fortrolige med at skabe software, der er lettere at teste, kræver indførelse af en DevOps-kultur, at man bygger systemer og platforme, som små teams ejer fra start til slut.
Spørgsmål: Hvad er de “5 væsentlige komponenter i et succesfuldt DevOps-team”? Del venligst en historie eller et eksempel på hver.
1. En fælles forståelse af, hvad DevOps betyder for din organisation. – Et af de mest kontraproduktive DevOps-initiativer opstår, hvis ledelsen og teamet ikke er enige om resultaterne. DevOps handler om langt mere end blot at ansætte “DevOps”-ingeniører og købe et CI/CD-værktøj. Når I er enige om, at det er et skift i tankegang, giver I teams mulighed for virkelig at eje leveringen af kundeværdi fra start til slut
2. Plads og støtte til at identificere og implementere forandringer – DevOps-teams identificerer ofte mange måder at forbedre leveringen og teamets effektivitet på. Hvis der ikke gives plads til denne udforskning, begrænses den indflydelse, dit team kan have på at skabe forandring, i høj grad.
3. Måder at måle og identificere succes gennem data – Alle kender DORA-målingerne og de fire nøglemålinger, som bruges til at vurdere modenheden i din udviklingsorganisation med henblik på at vurdere DevOps-modenhed. Selvom dette er et godt udgangspunkt, skal du identificere, hvad det betyder for din virksomhed at være en DevOps-organisation – og det bør du gøre gennem data.
4. Et produkt bygget til at understøtte ejerskab og udvikling af denne filosofi – DevOps er en fremragende filosofi for mange organisationer, men virksomheder er ofte ikke klar til at omfavne transformationen. Du skal sikre dig, at dit produkt kan understøttes af et samlet drifts- og udviklingsteam. Produkter, der er installeret lokalt, produkter med faste udgivelsescyklusser og produkter, der ganske enkelt ikke har den nødvendige modenhed til at understøtte et sådant team, er måske ikke gode kandidater. Du vil se nogle fordele, når dit team tilegner sig en mere driftsorienteret tankegang, men virkningerne er begrænsede.
5. Automatisering og værktøjer - Sørg for, at ting sker konsekvent og hurtigt, og sørg for ansvarlighed i forbindelse med arbejdsaftaler. En af de centrale ændringer i en DevOps-organisation er de arbejdsaftaler, du indgår med dit team og mellem dine teams. Hvis du etablerer en testproces, der kræver, at al kode regressionstestes før implementering, bør du automatisere den. Du bør etablere automatiserede kontroller og godkendelsesporte for at sikre dette. Når du har etableret disse værktøjer og praksisser, opdager du ofte, at ambitiøse mål som kontinuerlig implementering kun er få skridt væk.
Sørg for, at testningen ikke bare kører, men også lever op til dine kvalitetsstandarder.
More Articles
Spørgsmål: Hvilke nye tendenser ser du, som i væsentlig grad kan påvirke strategier for digital transformation i fremtiden?
Mange af de store løfter ved ting som overgangen til DevOps er baseret på data på højt niveau og brede resultater. Ofte er disse overskriftsagtige tal, som f.eks. “din organisation er 50 procent mere effektiv”, næsten umulige at måle, og det kan være svært at verificere, at man opnår den slags resultater.
Jeg forventer at se en mere målrettet indsats for at identificere specifikke resultater for hver organisation, før man begynder på en flerårig rejse inden for digital transformation. Det stemmer ikke kun overens med det øgede fokus på virksomheders effektivitet i de seneste år, men sikrer også succes. I stedet for brede mål som de nævnte er specifikke (men betydningsfulde) mål som “Vi løser kundeproblemer 25 procent hurtigere” mere målrettede.
Fremme af vækst gennem mentorordninger
Mentorordningers og åben kommunikations kraft er tydelig i Jeremy Freemans rejse. Ved aktivt at lære af andre og fremme et samarbejdende miljø kan ledere give deres DevOps-teams mulighed for at opnå store resultater.
Abonnér på The CTO Clubs nyhedsbrev for flere interviews, DevOps-indsigter og tips om mentorordninger!
