För närvarande identifierar sig endast ungefär 1 av 4 anställda inom teknikbranschen som kvinna. Så vad krävs för att skapa en framgångsrik karriär som kvinna inom teknik? I den här intervjuserien, Kvinnor inom teknik, har vi talat med framgångsrika ledare inom teknikbranschen för att dela berättelser och insikter om vad de gjorde för att skapa blomstrande karriärer. Vi diskuterar också de steg som krävs för att skapa en fantastisk teknisk produkt. Som en del av den här serien hade jag nöjet att intervjua Elizabeth Lawler.
Elizabeth Lawler
Elizabeth Lawler är medgrundare och VD för AppMap, den första plattformen för observerbarhet för utvecklare som levererar dynamisk mjukvaruprestanda, säkerhetsanalys och insikter från körning till utvecklare i kodredigeraren. Tidigare var Elizabeth VP för DevOps-säkerhet på CyberArk, där hon lanserade företagets strategi för marknadsintroduktion med öppen källkod för utvecklarfokuserade verktyg och tekniker. Före CyberArk grundade Elizabeth Conjur (förvärvat av CyberArk), som levererade den första produkten för att åtgärda brister inom säkerhet för privilegierade konton i DevOps-, moln- och containerbaserad mjukvara. Elizabeth har även varit dataansvarig chef på Generation Health (förvärvat av CVS Caremark) och haft nationella ledarroller på USA:s departement för veteranfrågor. Hon har en doktorsexamen och är utbildad dataforskare.
Tack så mycket för att du deltar i den här intervjuserien! Innan vi börjar skulle våra läsare gärna vilja veta mer om dig. Kan du berätta om vad som ledde dig till just den här karriärvägen?
AppMap är min andra teknikstartup inom det outvecklade området för utvecklarverktyg. Jag började min karriär med att undervisa studenter i statistisk databehandling, blev sedan dataforskare och därefter IT-ledare som dataansvarig chef och säkerhetschef. Till slut började jag grunda teknikföretag för att bygga nya produkter som löste behov jag hade av produkter som inte fanns på marknaden.
När jag försökte förmedla komplexa mjukvaruarkitekturer till nya personer, anställda och intressenter insåg jag att det fanns tydliga missförstånd och felaktiga föreställningar kring kodarkitektur, hur mjukvara beter sig när den körs, missuppfattningar om kvalitet, prestanda, säkerhet och så vidare; så mycket av det vi behöver förstå är ogenomskinligt eller baserat på mentala modeller. Men mjukvaran beskriver själv sitt eget beteende, och koden är bäst lämpad att förklara hur den fungerar när den körs. Det var mitt aha-ögonblick och det som fick mig och några av de tidiga teammedlemmarna att bygga AppMap.
Det har sagts att våra misstag ibland kan vara våra bästa lärare. Kan du berätta om det roligaste misstaget du gjorde när du precis hade börjat? Kan du berätta vilken lärdom du drog av det?
Jag vet inte om det här är ett roligt exempel, men det är ett verkligt exempel. Man brukar säga att man inte ska upprepa sina egna misstag, men det var precis vad vi gjorde. När vi började tänka ut AppMap, som var en produkt för kodanalys under körning, började vi bygga den som en SaaS-tjänst. Det var ett av de enklaste sätten att bygga en prototyp och samla in de testdata vi behövde från projekt med öppen källkod för att validera vår teknik.
Med tanke på vår bakgrund inom cybersäkerhet visste vi redan från början att det fanns stor känslighet kring dynamisk analys och lagring av känsliga koddata. Programvaruutvecklingspipelines kan användas som vektorer för att införa skadlig kod, och människor kan få tillgång till känslig kod och pipelines genom alla möjliga integrerade verktyg från tredje part, vilket de senaste intrången i CI-system visar.
Om vi flyttade AppMap helt till kodredigeraren och gjorde vår dataplattform mindre för att komma närmare koden kunde vi minska datasäkerhetsrisken. Människor kunde använda AppMap och vi kunde försäkra användaren om att ”din kod är din kod”. Vi minskade risken med programvara från tredje part, och användningen tog fart.
Men sedan bestämde vi oss för att bygga analysfunktioner. Så vi började bygga på en server med projekt med öppen källkod som testdata. Än en gång sa användarna: ”Jag vill inte ha det där. Lägg det i min IDE.” Ännu en gång flyttade vi tillbaka alla dessa funktioner och all denna funktionalitet till kodbasen, vilket är där du hittar analysfunktionerna i dag.
Lärdomen här är att det gör lika ont att göra samma misstag två gånger andra gången som första gången.
Vilket ögonblick tycker du har varit avgörande för din karriär?
Förra oktober deltog AppMap i TechCrunch Disrupt, och det var ganska fantastiskt. Det var en upplevelse olik allt jag hade varit med om tidigare – att tävla på det sättet inför publiken och med räckvidden hos det evenemanget. Jag tror att AppMap gynnades av att få dela vårt budskap på den plattformen.
Jag tror dock inte att det avgörande ögonblicket i min karriär har inträffat ännu; det finns alltid en ny och större utmaning framför oss. Jag ser stora möjligheter framöver för det här teamet och den här produkten.
Kan du berätta om de svåra perioder du mötte när du först påbörjade din resa? Övervägde du någonsin att ge upp? Varifrån fick du drivkraften att fortsätta trots att saker och ting var så svåra?
Att besluta sig för att bygga en produkt inom ett outnyttjat område är ingen enkel uppgift. Man måste kunna fånga människors fantasi så att de vill ta till sig eller prova något som de inte visste kunde existera och vars fördelar de inte intuitivt förstår. Även om det är väldigt roligt att skapa något och kunna föreställa sig något som ännu inte existerar, kan det också vara oerhört frustrerande. Produkter inom outnyttjade områden är svåra att beskriva på ett träffsäkert sätt, och ibland undrar man: ”kan jag fortsätta med det här?” eftersom det är så svårt. Det är den svåraste typen av problem att lösa som entreprenör.
Vi gick till Google, Meta och företag med avancerade verktyg för utvecklarupplevelsen, och de hade inget som liknade det vi skapade. Vi validerade våra antaganden om vad som saknades, men jag tror inte att människor trodde att det var möjligt. Vi behövde verkligen tro på vår vision och vår förmåga att skapa den här produkten. Jag har sådan tur som får arbeta med ett team som verkligen kan bygga otroligt djupa och tekniskt utmanande produkter.
Det är både uppslukande och skrämmande att se en möjlighet som andra inte ser. När man börjar få lite momentum och ser hur det börjar klicka för människor och hur de börjar förstärka det man har byggt – då inser man varför man gjorde det. Man hör användarens glädje. Nu vill man gå ännu längre och glädja dem ännu mer.
Vi skulle gärna vilja veta lite mer om ert företag. Vilket problem hjälper ert företag till att lösa? Hur hjälper ert företag människor?
AppMap tillhandahåller den första plattformen någonsin för observerbarhet för utvecklare, som levererar dynamisk programanalys, inklusive prestanda- och säkerhetsanalys, till utvecklare i kodredigeraren.
Fram till nu har detta varit en stor lucka på marknaden, eftersom utvecklare och programvaruteam har tvingats förlita sig på statiska analysverktyg och inte kunnat identifiera komplexa designproblem i koden eller felsöka kundproblem innan de lanserats. Detta har lett till timmar av omarbete som hämmar kreativitet och innovation. Det monotona underhållsarbetet i programvaruutvecklingen är en av de främsta drivkrafterna bakom att utvecklare säger upp sig i tysthet.
AppMap förändrar traditionella angreppssätt för utvecklarupplevelsen genom att sömlöst integrera sitt verktyg för körningsbaserad kodanalys med öppen källkod direkt i kodredigeraren. Det gör det möjligt för användare att se inte bara kodens beteende, utan även alla föreslagna förändringar av prestanda, säkerhet och stabilitet medan koden utvecklas. Detta lyfter utvecklarupplevelsen genom att ge förutseende och handlingsbara insikter när det är enkelt att göra förändringar.
Om någon vill leda ett fantastiskt företag och skapa fantastiska produkter, vilken är då den viktigaste egenskapen som personen bör ha, och vilka vanor eller beteenden skulle du föreslå för att utveckla just den egenskapen?
Man måste absolut ha empati för sin användare. Som verktyg för utvecklare i kodredigeraren befinner man sig i det mest intima kreativa utrymmet tillsammans med användaren. Man finns på deras skrivbord, i det kreativa utvecklingsögonblick som definierar vad utvecklare gör. För att vara till hjälp måste man ha mycket medkänsla och vara omsorgsfull med hur man hjälper. Det är en mycket fin balansgång.
Målet är att skapa något som människor älskar och inte vill arbeta utan. Det är en mycket brant uppförsbacke när det gäller produktdesign och utveckling. Sättet att se till att man alltid sätter användaren främst är att lära känna sin användare och bygga en gemenskap och samtal kring olika angreppssätt.
På AppMap vet vi att idéer kan komma från alla håll. Vi presenterar många utvecklare och våra gemenskapssidor. Människor från hela världen – från alla 50 delstater i USA och hundratals länder – finns representerade i vår gemenskap. Det ger oss möjlighet att spegla och förstå allas behov. Det är det mest kraftfulla sättet vi driver vårt uppdrag framåt på.
Låt oss prata om team. Vilken strategi eller modell för teamledning har du funnit vara särskilt användbar i produktutvecklingsprocessen?
Transparens är avgörande, från vår produkt till hur vårt team arbetar. Med AppMap började vi med öppen källkod eftersom det gör det möjligt för alla som kan läsa och förstå vår produkt att ge oss synpunkter och återkoppling. Genom att välja öppenhet skapade vi en möjlighet att ha produktsamtal med den grupp användare som vi försöker hjälpa. Öppenhet är något som vårt team verkligen tror på.
När du tänker på det starkaste team du någonsin har arbetat med, varför tror du att teamet fungerade så bra tillsammans, och kan du minnas en anekdot som illustrerar dynamiken?
AppMap-teamet består faktiskt av många medlemmar från mitt tidigare team på Conjur. Vi har gått från företag till företag och arbetat tillsammans med flera projekt inom outnyttjade områden.
Det som imponerar mest på mig med det här teamet är att vi inte bara arbetar bra tillsammans, utan också gör det när vi möter motgångar. Vi tar oss an problemen och arbetar för att hantera dem – vi välkomnar återkopplingen oavsett vem som befinner sig i rummet. Det är så vi alla arbetar tillsammans.
Som team träffas vi ofta för att skapa samsyn. Vi har lyckats främja en kultur av radikal transparens. Alla kan komma med idéer från vilken del av organisationen som helst. Vi tar hand om varandra och gör det riktigt bra.
Om du bara fick ha ett programvaruverktyg i din verktygslåda, vilket skulle det vara, varför, och vilka andra verktyg anser du vara verksamhetskritiska?
Jag tycker att kodredigerare, som VS Code och JetBrains, är helt fantastiska platser att utföra arbete på. Vi ser dem inte bara som en plats där vi själva är medlemmar av ekosystemet, utan man kan också se hur alla verktyg och tekniker som riktar sig till utvecklare flyttar in i den miljön – vilket gör dem helt oumbärliga. Om man vill förstå hur programvaruprodukter byggs måste man förstå vad som händer inuti kodredigeraren. Titta på Co-pilot och andra generativa verktyg som tänjer på gränserna i kodredigeraren.
Som företagsledare är programvara för tidshantering ännu ett verksamhetskritiskt verktyg. Utan en programvarulösning för tidshantering skulle det vara lätt att tillbringa dagen på det sätt man själv vill och låta trögheten föra en genom dagen. Mina dagar blir mer produktiva när jag schemalägger fokustid för att få viktiga saker gjorda.
Låt oss prata om återhämtning. Vilken metod eller ritual brukar du använda för att förebygga utbrändhet?
Mina barn är förmodligen det bästa botemedlet mot utbrändhet. Barn låter dig inte arbeta när du är med dem. De kommer att vara på ditt kontor och säga åt dig att lägga undan arbetet, eller att de behöver din tid och uppmärksamhet. Barn tvingar dig att vara närvarande och lägga ifrån dig jobbet. Jag värdesätter varje stund med dem och är glad att de får mig att lägga undan tekniken.
Utifrån din erfarenhet, vilka är dina ”5 steg som krävs för att skapa fantastiska teknikprodukter”?
1. Fastställ din POV och våga vara annorlunda: lansera den sedan på marknaden och se om den får gensvar. På AppMap anser vi att den enda sanningskällan är kodredigeraren och att du bör ha alla verktyg du behöver precis där du utför ditt arbete. Därifrån kan du använda både kvantitativ och kvalitativ feedback från dina användare för att styra utvecklingen av nya funktioner. När saker fungerar ska du fördjupa dig och fortsätta satsa, men var inte rädd för att överge områden som inte används.
2. Sätt igång direkt: och kom så nära användaren som möjligt. Var öppen för att lära dig av ditt team och dina kunder, och nätverka för att få feedback från marknaden. En metod AppMap använder är att i stor omfattning blogga innehåll på handledningsnivå på vår Dev Community-sida. Det hjälper oss att förstå vilka områden vi bör investera mer i när vi ser ett högt engagemang för en viss funktion. Alla företag som vill skapa en fantastisk produkt bör ta sina MVP-idéer, dela dem brett och använda engagemangsdata för att styra investeringsnivån.
3. Börja och bygg sedan kontinuerligt: Reid Hoffman sa berömt: ”Om du inte skäms över den första versionen av din produkt har du lanserat för sent” – och det bör bli ditt mantra för produktutveckling. Det är också viktigt att vara medveten om att du varken är en tom produkt utan fungerande innehåll eller en funktionsfabrik. Sikta på en bra medelväg mellan genomtänkt helhet och utrymme för förbättringar i tidiga produktlanseringar. Verkligheten är att om din produkt löser ett mindre användningsfall kommer människor att använda den för att lösa sina problem trots en klumpig användarupplevelse eller mindre buggar.
4. Lansera och mät, mät, mät: Förvänta dig inte att användarna ska ge dig mängder av kvalitativ feedback om din produkt – särskilt inte när du utvecklar för tekniska målgrupper. Dessa användare är upptagna och överbelastade med annat arbete. De har inte tid att ge dig detaljerad feedback. Det bästa sättet att förstå dina användare är att mäta deras interaktioner med din produkt, om du har möjlighet.
Om användningen är tillräckligt hög kan du försöka iterera snabbt utifrån den data du får, och om du har en stor användarbas bör du segmentera den efter bästa förmåga för att bättre förstå skillnaderna mellan avancerade användare och nybörjare. Dessa användartyper behöver olika funktioner, och att bygga funktioner för en målgrupp kan orsaka problem för andra.
5. Iterera och utvecklas: Fokus är den viktigaste egenskapen hos alla företag, särskilt nystartade företag. Nystartade företag har helt enkelt inte tid eller pengar att investera i flera områden. Lägg inte tid på att oroa dig över alternativkostnaden för att inte arbeta med ”allt”. Fokusera i stället på de insatser som ger störst effekt och dela upp arbetet i små delar. Genom att dela upp leveranserna i mindre enheter kan du reagera snabbare på användarfeedback eller användningsdata och kontinuerligt utveckla din produkt för att glädja dina användare.
Är du för närvarande nöjd med status quo när det gäller kvinnor inom teknik? Vilka specifika förändringar anser du behövs för att förändra status quo?
Kvinnor som leder teknikföretag och har maktpositioner är fortfarande undantaget, inte regeln. Kvinnor leder endast 2 % av de riskkapitalfinansierade företagen inom B2B- och företagssegmentet. Det finns kvinnliga ledare i den här branschen som har en enorm talang men ännu inte har fått någon sponsor. Det här är en hjärtefråga för mig. Jag anser att jämlikhet fortfarande måste byggas. Jag hoppas att jag kan vara ett starkt föredöme och hjälpa andra kvinnor att förverkliga sina idéer, eftersom det är svårt. Siffrorna ljuger inte – från löner och värderingar till den andel av investeringskakan som kvinnor får. Jag tycker att människor bör granska kvinnligt grundade B2B-företag närmare på lång sikt. De levererar det bästa värdet per investerad krona.
Finns det någon person i världen som du gärna skulle vilja äta en privat frukost eller lunch med, och varför?
Jag beundrar verkligen Diane Greene och hennes karriärbåge. Hon började som mariningenjör innan hon gick över till teknikbranschen. Hon var grundare och vd för VMware, styrelseledamot i Google samt vd för Google Cloud, och medgrundare och vd för två nystartade företag som förvärvades av Google respektive Microsoft.
För mer innehåll av det här slaget kan du prenumerera på nyhetsbrevet från The CPO Club.
