F: Har du någon mentor som hittills har inspirerat eller hjälpt dig på din karriärresa?
Det finns så många. Att vara en del av startupgemenskapen i Raleigh i North Carolina har varit fantastiskt, och det finns dussintals personer som har hjälpt mig på sätt som de kanske inte ens inser. Även om jag skulle kunna nämna specifika namn har vissa avgörande berättelser format min syn på världen.
En berättelse kommer från en försäljningschef som talade på en av mina universitetskurser i entreprenörskap. Som ingenjörsstudent med fokus på att skriva kod och utveckla tekniska färdigheter var försäljning både främmande och ointressant för mig. Den här personen berättade dock en historia som hjälpte mig att se saker på ett annat sätt.
Han återberättade ett samtal med en av sina tekniska kollegor. Kollegan sa: ”Jag förstår inte hur du gör det.” Säljaren svarade: ”Gör vad?” Kollegan svarade: ”Uppfyller en försäljningskvot. Det måste vara så stressigt att tvingas sälja för att kunna äta.” Han tänkte på saken en stund och svarade kort: ”Det är det, men om jag inte säljer kan inte du heller äta.”
Den här berättelsen hjälpte mig verkligen att sätta ingenjörsarbete i ett sammanhang.
Du kan bygga den häftigaste produkten eller tjänsten, men om du inte kan visa värdet för de människor som den kommer att hjälpa, så arbetar du bara med teknik i ett vakuum.
En annan person som hjälpte mig var en mentor som hade lett ingenjörsföretag och ingenjörsavdelningar och sedan ändrade inriktning på sin karriär för att hjälpa människor att utveckla sina idéer och hitta roller på olika startups. Han coachade mig genom många utmaningar, men en av de viktigaste insikterna han gav mig var att de flesta ledare för tekniska organisationer utmärker sig inom ett av tre områden:
”Teknikgurun”, stjärnchefen eller den centrala produktpersonen. Han fortsatte med att säga att ett framgångsrikt företag behöver alla tre, och att en bra ledare måste identifiera vilken av dem han eller hon är och sedan anställa personer med de andra färdigheterna. Det har hjälpt mig att förstå min utveckling som ingenjörsledare och var jag bör engagera mig mer eller mindre.
F: Kan du nämna tre styrkor eller färdigheter som har varit viktiga för din resa?
Ett motto jag följer är: ”Passa in först, stick sedan ut.” Även om det låter lite fyndigt påminner det mig om att jag först måste lära känna teamet när jag arbetar med ett nytt team. Att förstå varför saker är som de är är avgörande för att bygga förtroende.
Om jag till exempel dyker upp första dagen och försöker genomföra eller förespråka en stor förändring kommer den spontana reaktionen att vara motstånd, och jag har gjort mitt jobb svårare framöver. Det är viktigt att leta efter likheter och områden där man är överens i ett nytt team innan man försöker utmana status quo eller genomföra stora förändringar. Detta förhållningssätt gäller när man bygger nya relationer inom alla delar av livet.
En annan princip som vägleder mig är: ”Det människor säger och gör korrelerar endast med vad de tänker och känner.” Även om det kan låta pessimistiskt tycker jag om tanken att människor ofta agerar under ett enormt tryck att handla eller tala på ett visst sätt.
När man till exempel frågar någon hur dagen går svarar personen nästan alltid ”Bra” i stället för att öppna sig och verkligen berätta hur han eller hon mår. När man arbetar med team och grupper är det viktigt att uppmärksamma den typen av påtryckningar för att verkligen förstå och känna empati. Om någon rapporterar till dig kan det till exempel vara svårt för personen att ta ansvar för ett misstag om han eller hon är rädd för konsekvenserna.
Som ledare är det viktigt att bygga upp och ständigt utvärdera vår miljö för att främja öppenhet. Annars kan vi oavsiktligt skapa en kultur där saker får ligga och gro inom teamet utan att tas upp.
När det gäller att leda team behöver människor kontinuerligt granska sig själva och reflektera över tidigare arbete för att utveckla starka färdigheter. Även om det fungerar för mig att ”blicka inåt” kanske det inte fungerar lika bra för alla, och en bra ledare måste förstå de olika sätt på vilka individer lär sig och utvecklas.
En effektiv ledare fokuserar på att balansera prestation och empati och reflekterar ständigt över sina egna styrkor och svagheter samt över det bredare teamets.
F: Vilka färdigheter försöker du fortfarande utveckla?
Om jag återgår till rådet från en av mina mentorer arbetar jag ständigt med ledarskapets managementdel, som är en av den tekniska ledarens tre roller. Jag har haft turen att arbeta med en kollega som är fantastisk på det området och som har visat mig några viktiga sätt att utvecklas och bli bättre på.
Som medgrundare av en teknikstartup har jag fokuserat mycket på teknik och produkter och arbetat med små team. Nu när vår organisation växer måste jag växa tillsammans med den. Att behärska management är en färdighet som är precis lika viktig som mjukvaruutveckling.
F: Låt oss prata om att ha ett framgångsrikt DevOps-team. Vilka är de viktigaste målen som ett DevOps-team kan identifiera under en digital transformationsresa?
En av de viktigaste sakerna jag hör från andra ledare är att ha en gemensam förståelse för vad DevOps innebär för organisationen. Jag har sett organisationer där ”DevOps” innebär att anställa en SRE, kalla personen för en DevOps-ingenjör och sedan fira.
En viktig utgångspunkt är att ta de centrala delarna av DevOps-cykeln och identifiera hur arbete och idéer flödar genom utvecklingsprocessen. Ta ett enskilt utvecklingsärende från det att det skapas och följ det tills det leder till nästa ärende, så kan du identifiera några viktiga brister.
Du kanske till exempel upptäcker att QA-teamet är avskilt och att ni har en ”kasta det över muren”-mentalitet som påverkar er förmåga att arbeta snabbt. När du väl börjar definiera det processflödet i organisationen kan du undersöka verktyg som kan vara till hjälp.
Många organisationer börjar med verktygen och driver därefter organisatorisk förändring långsamt och smärtsamt. Det är ett bakvänt sätt att komma igång.
F: Finns det några utmaningar eller vanliga fallgropar som DevOps-team bör ta hänsyn till?
DevOps är ett sätt att arbeta. På många sätt är det uppföljaren till den agila omställning som svepte genom mjukvaruutvecklingsbranschen för flera decennier sedan. Det är viktigt att tänka på det på det sättet. Många organisationer hade problem med agil omställning på grund av bristande förståelse och förankring hos ledningen. Ledare trodde att vi skulle börja ha dagliga ståmöten och få 50 procent fler ärenden gjorda. I efterhand var det uppenbart fel.
På samma sätt tror ledare i dag att vi bara behöver en CI/CD-pipeline för att överträffa Dora-måtten och uppnå 50 procents produktivitet. Förändringen av tankesättet är avgörande. DevOps möjliggör ett fullständigt ägarskap av mjukvaruleveransens livscykel, vilket gör det möjligt för team att bygga bättre system. DevOps ger teamen möjlighet att identifiera hur de kan bli bättre och genomföra det, så ledare måste skapa utrymme och ge stöd för att organisationen verkligen ska märka effekterna.
F: Hur kan ett effektivt samarbete och en effektiv kommunikation mellan teammedlemmarna förbättra produktiviteten och framgången för ett DevOps-team, och vilka arbetssätt kan underlätta detta?
Kommunikation är avgörande inom teknik. Nästan alla problem kan i grunden härledas till bristande kommunikation, och DevOps är inget undantag. Om vi återgår till att ha en gemensam förståelse för vad DevOps innebär för organisationen måste ni verkligen förstå vart ni är på väg och ha en gemensam vision för att ha en chans att lyckas.
Några av de viktigaste arbetssätten jag har sett är att definiera enkla kontrollpunkter i processen. Dessa måste handla om arbetet, inte om personerna som utför det. Genom att ha definierade processer för hur uppgifter och information flödar genom teamet kan ni arbeta effektivt vid växlingar, särskilt när avbrott i arbetet uppstår, och skala olika delar av teamet oberoende av varandra.
Varje team och produkt har något olika behov, och genom att definiera dessa kontrollpunkter och vad som behöver hända vid varje punkt blir det lättare att se var ineffektiviteten finns.
F: Vilken roll spelar CI/CD i DevOps, och vilka är de bästa metoderna för att implementera CI/CD-pipelines för att säkerställa en smidig och tillförlitlig programvaruutgivningsprocess?
Det är avgörande att få programvaruändringar från idé till produktion så snabbt som möjligt. Manuella processer är extremt långsamma och beroende av människor. Människor är visserligen bra på saker som problemlösning och kreativitet, men är ofta dåliga på att uttömmande gå igenom checklistor hundratals gånger om dagen. Genom att automatisera det monotona arbetet kan ditt team verkligen fokusera på det de är bäst på. Dessutom är datorer exceptionellt snabba och kan skalas snabbt. Att skapa en pipeline som drar nytta av dessa möjligheter är den främsta fördelen med att införa en CI/CD-process.
En viktig sak att komma ihåg när man bygger en sådan process är att balansera snabbhet med säkerhet. Även om du kan automatisera varje incheckning från en utvecklare direkt till produktion innebär det ingen säkerhet. Att bygga din pipeline så att den tillåter den hastighetsnivån och sedan gradvis lägga till kontroller kan hjälpa dig i framtiden. Till en början kanske allt måste godkännas uttryckligen av en QA-ingenjör och en releaseingenjör, men själva processen kan i praktiken bara bestå av ett knapptryck.
När du väl har infört automatiserade tester kanske du kan ta bort QA-godkännandet.
F: Hur bidrar främjandet av en DevOps-kultur och ett DevOps-tankesätt till den övergripande framgången för ett DevOps-team, och vilka strategier kan organisationer använda för att främja denna kultur bland sina utvecklings- och driftteam?
Den främsta utmaningen i denna omvandling är att bekämpa mentaliteten att “kasta det över muren“. Om du är ny på den här resan kanske du har fem eller sex team som måste hantera varje arbetsuppgift innan den når produktion. När du går över till DevOps främjar du ett gemensamt ägarskap för produktens hela livscykel.
Det kan kräva betydande förändringar i hur du utformar, bygger och distribuerar din lösning. Även om många är vana vid att skapa programvara som är lättare att testa, kräver införandet av en DevOps-kultur att man bygger system och plattformar som ägs från början till slut av små team.
F: Vilka är de ”5 viktiga komponenterna i ett framgångsrikt DevOps-team”? Dela gärna en berättelse eller ett exempel för varje punkt.
1. En gemensam förståelse av vad DevOps betyder för din organisation. – Ett av de mest kontraproduktiva DevOps-initiativen uppstår när ledningen och teamet inte är samordnade kring resultaten. DevOps handlar om mycket mer än att bara anställa ”DevOps”-ingenjörer och köpa ett CI/CD-verktyg. När ni väl är överens om att det handlar om ett förändrat tankesätt ger ni teamen möjlighet att verkligen ta ansvar för leveransen av kundvärde från början till slut
2. Utrymme och stöd för att identifiera och genomföra förändringar – DevOps-team identifierar ofta många sätt att förbättra leveransen och teamets effektivitet. Om man inte ger utrymme för denna utforskning begränsas verkligen den påverkan teamet kan ha när det gäller att driva förändringar.
3. Sätt att mäta och identifiera framgång genom data – Alla känner till DORA-mätvärdena och de fyra centrala måtten som används för att bedöma mognaden hos utvecklingsorganisationen inom DevOps. Även om dessa är en bra utgångspunkt behöver du identifiera vad det innebär för ditt företag att vara en DevOps-organisation – och det bör du göra genom data.
4. En produkt som är byggd för att stödja ägarskap och utveckling av denna filosofi – DevOps är en utmärkt filosofi för många organisationer, men företag är ofta inte redo att omfamna omvandlingen. Du måste säkerställa att din produkt kan stödjas av ett kombinerat drift- och utvecklingsteam. Produkter som körs lokalt, produkter med rigida releasecykler och produkter som helt enkelt inte har nått den mognadsnivå som krävs för att stödja ett sådant team kanske inte passar bra. Du kommer att se vissa fördelar när teamet antar ett mer driftorienterat tankesätt, men effekterna är begränsade.
5. Automatisering och verktyg – Se till att saker sker konsekvent och snabbt och säkerställ ansvar för arbetsöverenskommelser. En av de centrala förändringarna i en DevOps-organisation är de arbetsöverenskommelser som ni upprättar inom teamet och mellan teamen. Om ni etablerar en testprocess som kräver att all kod regressionstestas före driftsättning bör ni automatisera den. Ni bör införa automatiserade kontroller och spärrar för att säkerställa detta. När ni väl har etablerat dessa verktyg och metoder upptäcker ni ofta att ambitiösa mål som kontinuerlig driftsättning bara ligger några få steg bort.
Se till att testningen inte bara körs utan också uppfyller dina kvalitetsstandarder.
Fråga: Vilka framväxande trender ser du som skulle kunna påverka strategier för digital transformation avsevärt i framtiden?
Många av de storslagna löftena med sådant som att övergå till DevOps bygger på data på hög nivå och breda resultat. Ofta är dessa rubriksiffror, som ”din organisation är 50 procent effektivare”, nästan omöjliga att mäta, och det kan vara svårt att verifiera att man uppnår den typen av resultat.
Jag förväntar mig att se en mer fokuserad insats för att identifiera specifika resultat för varje organisation innan man påbörjar en flerårig digital transformationsresa. Detta ligger inte bara i linje med det ökade fokuset på affärseffektivitet under de senaste åren, utan säkerställer också framgång. I stället för breda mål som de som nämndes är specifika (men betydelsefulla) mål som ”Vi löser kundproblem 25 procent snabbare” mer fokuserade.
Främja tillväxt genom mentorskap
Mentorskapets och den öppna kommunikationens kraft är tydlig i Jeremy Freemans resa. Genom att aktivt lära av andra och främja en samarbetsinriktad miljö kan ledare ge sina DevOps-team möjlighet att åstadkomma fantastiska saker.
Prenumerera på The CTO Clubs nyhetsbrev för fler intervjuer, DevOps-insikter och tips om mentorskap!
