For øyeblikket er det bare omtrent 1 av 4 ansatte i teknologibransjen som identifiserer seg som kvinne. Så hva skal til for å skape en vellykket karriere som kvinne innen teknologi? I denne intervjuserien kalt Kvinner innen teknologi snakket vi med vellykkede ledere i teknologibransjen for å dele historier og innsikt om hva de gjorde for å skape fremgangsrike karrierer. Vi diskuterer også stegene som kreves for å skape et godt teknologiprodukt. Som en del av denne serien hadde jeg gleden av å intervjue Elizabeth Lawler.
Elizabeth Lawler
Elizabeth Lawler er medgrunnlegger og administrerende direktør i AppMap, den første plattformen for utviklerobservasjon som leverer dynamisk programvareytelse, sikkerhetsanalyse og innsikt fra kjøretid til utviklere i koderedigeringsverktøyet. Tidligere var Elizabeth visepresident for DevOps-sikkerhet hos CyberArk, hvor hun lanserte selskapets åpen kildekode-baserte markedsstrategi for utviklerfokuserte verktøy og teknologier. Før CyberArk grunnla Elizabeth Conjur (kjøpt opp av CyberArk), som leverte det første produktet som håndterte mangler innen sikkerhet for privilegerte kontoer i DevOps-, sky- og containerbasert programvare. Elizabeth har også vært datasjef i Generation Health (kjøpt opp av CVS Caremark) og hatt nasjonale lederstillinger i USAs departement for veteransaker. Hun har en doktorgrad og er utdannet dataforsker.
Tusen takk for at du vil delta i denne intervjuserien! Før vi går i gang, vil leserne våre gjerne lære mer om deg. Kan du fortelle oss en historie om hva som førte deg til akkurat denne karriereveien?
AppMap er min andre teknologistartup innen nisjen utviklerverktøy. Jeg startet karrieren min med å undervise studenter i statistisk databehandling, ble deretter dataforsker og så IT-leder, blant annet som datasjef og sikkerhetssjef. Til slutt begynte jeg å grunnlegge teknologiselskaper for å utvikle nye produkter som kunne løse behov jeg hadde for produkter som ikke fantes på markedet.
Da jeg forsøkte å kommunisere komplekse programvarearkitekturer til nye personer, ansatte og interessenter, innså jeg at det var tydelige misforståelser og feiloppfatninger rundt kodearkitektur, hvordan programvare oppfører seg når den kjører, samt misoppfatninger om kvalitet, ytelse, sikkerhet og så videre. Så mye av det vi trenger å forstå, er ugjennomsiktig eller basert på mentale modeller. Men programvaren beskriver selv sin egen atferd, og koden er best egnet til å forklare hvordan den fungerer når den kjører. Det var aha-øyeblikket for meg, og det som fikk meg og noen av de tidlige teammedlemmene til å bygge AppMap.
Det sies at feilene våre noen ganger kan være våre beste lærere. Kan du dele en historie om den morsomste feilen du gjorde da du nettopp hadde startet? Kan du fortelle oss hvilken lærdom du fikk av den?
Jeg vet ikke om dette er et morsomt eksempel, men det er et eksempel fra virkeligheten. Man sier at man ikke bør gjenta sine egne feil, men det gjorde vi. Da vi begynte å tenke ut AppMap, som var et produkt for kodeanalyse ved kjøring, begynte vi å bygge det som en SaaS-løsning. Det var en av de enkleste måtene å bygge en prototype på og samle inn testdataene vi trengte fra åpen kildekode-prosjekter for å validere teknologien vår.
Med bakgrunnen vår innen cybersikkerhet visste vi fra starten at det var stor følsomhet rundt dynamisk analyse og lagring av sensitive kodingsdata. Programvareutviklingsprosesser kan være vektorer for innsetting av ondsinnet kode, og personer kan få tilgang til sensitiv kode og prosesser gjennom alle slags integrerte tredjepartsverktøy, noe nyere brudd på CI-systemer har vist.
Hvis vi flyttet AppMap helt inn i koderedigeringsverktøyet og gjorde dataplattformen vår mindre for å komme nærmere koden, kunne vi redusere datasikkerhetsrisikoen. Folk kunne bruke AppMap, og vi kunne forsikre brukeren om at «koden din er din kode». Vi reduserte risikoen knyttet til tredjepartsprogramvare, og utbredelsen skjøt fart.
Men så bestemte vi oss for at vi ville bygge analysefunksjoner. Derfor begynte vi å bygge på en server ved å bruke åpen kildekode-prosjekter som testdata. Igjen sa brukerne: «Jeg vil ikke ha det der. Legg det inn i IDE-en min.» Nok en gang flyttet vi alle disse funksjonene tilbake inn i kodebasen, og det er der du finner analysefunksjonene i dag.
Lærdommen her er at det er like smertefullt å gjøre den samme feilen to ganger andre gang som første gang.
Hva føler du har vært ditt «karrieredefinerende» øyeblikk?
Forrige oktober deltok AppMap på TechCrunch Disrupt, og det var ganske fenomenalt. Det var en opplevelse ulik alt jeg hadde opplevd før – å konkurrere på den måten med publikum og rekkevidden til dette arrangementet. Jeg tror AppMap hadde fordel av å få dele budskapet vårt på den plattformen.
Jeg tror imidlertid ikke at mitt karrieredefinerende øyeblikk har kommet ennå. Det finnes alltid en ny og større utfordring i vente. Jeg ser store ting i vente for dette teamet og dette produktet.
Kan du fortelle oss en historie om de vanskelige tidene du møtte da du først startet reisen din? Vurderte du noen gang å gi opp? Hvor fikk du drivkraften til å fortsette, selv om ting var så vanskelige?
Det er ingen enkel oppgave å bestemme seg for å utvikle et tomromsprodukt. Du må være i stand til å fange folks fantasi slik at de tar i bruk eller prøver noe de ikke visste kunne eksistere, og som de ikke intuitivt forstår nytten av. Selv om det er utrolig morsomt å skape noe og evne å se for seg noe som ennå ikke eksisterer, kan det også være utrolig frustrerende. Tomromsprodukter er utfordrende å kommunisere presist, og noen ganger lurer du på: «Kan jeg fortsette med dette?» fordi det er så vanskelig å gjøre. Det er den vanskeligste typen problem å løse som entreprenør.
Vi gikk til Google, Meta og selskaper med verktøy for utvikleropplevelser i verdensklasse, og de hadde ikke noe som lignet på det vi skapte. Vi validerte antakelsene våre om det som manglet, men jeg tror ikke folk mente at det var mulig. Vi måtte virkelig tro på visjonen vår og evnen vår til å skape dette produktet. Jeg er så heldig å få jobbe med et team som virkelig kan bygge utrolig dyptgående, teknisk krevende produkter.
Det er både spennende og skremmende å se en mulighet som andre ikke ser. Det er når du begynner å få litt fremdrift, og ser at det begynner å gi mening for folk, og at de begynner å forsterke det du har bygget – da innser du hvorfor du gjorde det. Du hører brukerens begeistring. Nå får du lyst til å gå enda lenger og begeistre dem enda mer.
Vi vil gjerne lære litt om selskapet deres. Hvilket problem bidrar selskapet deres til å løse? Hvordan hjelper selskapet deres folk?
AppMap tilbyr den første plattformen for utviklerobservasjon noensinne, som leverer dynamisk programvareanalyse, inkludert ytelses- og sikkerhetsanalyse, til utviklere i koderedigeringsverktøyet.
Frem til nå har dette vært et stort gap i markedet, ettersom utviklere og programvareteam har vært nødt til å basere seg på verktøy for statisk analyse og ikke har kunnet identifisere komplekse designproblemer knyttet til kode eller feilsøke kundeproblemer før de ble lansert. Dette har ført til timevis med omarbeid som hemmer kreativitet og innovasjon. Arbeidskrevende programvareoppgaver er en av hoveddriverne bak at utviklere i stillhet trekker seg fra arbeidslivet.
AppMap utfordrer tradisjonelle tilnærminger til utvikleropplevelsen ved å integrere sitt åpen kildekodebaserte verktøy for kjøretidsanalyse av kode direkte i koderedigeringsverktøyet. Dette gjør det mulig for brukerne å se ikke bare hvordan koden oppfører seg, men også eventuelle foreslåtte endringer i ytelse, sikkerhet og stabilitet mens koden utvikles. Dette løfter utvikleropplevelsen ved å gi prediktiv og handlingsrettet innsikt når det er enkelt å gjøre endringer.
Hvis noen ønsker å lede et flott selskap og skape flotte produkter, hvilken egenskap er viktigst at denne personen bør ha, og hvilke vaner eller hvilken atferd vil du anbefale for å utvikle akkurat denne egenskapen?
Du må absolutt ha empati for brukeren din. Som utviklerverktøy i koderedigeringsverktøyet befinner du deg i brukerens mest intime kreative rom. Du er på skrivebordet deres, i det kreative utviklingsøyeblikket som definerer hva utviklere gjør. For å være til hjelp må du ha mye medfølelse, og du må være svært bevisst på hvordan du hjelper. Det er en hårfin balansegang.
Målet er å skape noe som folk elsker, og som de ikke ønsker å jobbe uten. Det er en svært bratt bakke når det gjelder produktdesign og utvikling. Måten du sikrer at du alltid setter brukeren først på, er å bli kjent med brukeren din og bygge et fellesskap og samtaler rundt ulike tilnærminger.
I AppMap vet vi at ideer kan komme fra hvor som helst. Vi profilerer mange utviklere og fellesskapssidene våre. Vi har mennesker fra hele verden – fra alle de 50 delstatene i USA og hundrevis av land – representert i fellesskapet vårt. Dette gir oss muligheten til å gjenspeile og forstå alles behov. Det er den mest kraftfulle måten vi driver oppdraget vårt fremover på.
La oss snakke om team. Hvilken strategi eller hvilket rammeverk for teamledelse har du funnet spesielt nyttig i produktutviklingsprosessen?
Fra produktet vårt til måten teamet vårt arbeider på er åpenhet avgjørende. Med AppMap startet vi med åpen kildekode som utgangspunkt, fordi det gjør det mulig for alle som kan lese og forstå produktet vårt, å gi oss innspill og tilbakemeldinger. Ved å velge åpenhet skapte vi en mulighet til å ha produktsamtaler med gruppen av brukere vi prøver å betjene. Åpenhet er noe teamet vårt virkelig tror på.
Når du tenker på det sterkeste teamet du noen gang har jobbet med, hvorfor tror du at teamet fungerte så godt sammen, og kan du huske en anekdote som illustrerer dynamikken?
AppMap-teamet består faktisk av mange medlemmer fra mitt tidligere team i Conjur. Vi har gått fra selskap til selskap og jobbet sammen med en rekke tomromsprosjekter.
Det som imponerer meg mest med dette teamet, er at vi ikke bare fungerer godt sammen, men at vi også fungerer godt sammen i møte med motgang. Vi går inn i problemene og arbeider med å løse dem – vi tar imot tilbakemeldinger uansett hvem som er i rommet. Det er slik vi alle arbeider sammen.
Som team samles vi ofte for å skape samordning. Vi har klart å fremme en kultur preget av radikal åpenhet. Alle kan komme med ideer fra alle deler av organisasjonen. Vi tar vare på hverandre og gjør en veldig god jobb med det.
Hvis du bare hadde hatt ett programvareverktøy i arsenalet ditt, hvilket ville det vært, hvorfor, og hvilke andre verktøy anser du som kritiske for oppdraget?
Jeg synes koderedigeringsverktøy som VS Code og JetBrains er fantastiske steder å utføre arbeid. Ikke bare omfavner vi disse som steder der vi ser på oss selv som medlemmer av økosystemet, men du kan også se at alle verktøyene og teknologiene som er rettet mot utviklere, beveger seg inn i dette miljøet – noe som gjør dem helt uunnværlige. Hvis du vil forstå hvordan programvareprodukter bygges, må du forstå hva som skjer inne i koderedigeringsverktøyet. Se på Co-pilot og andre generative verktøy som flytter grensene i koderedigeringsverktøyet.
Som bedriftsleder er et annet forretningskritisk verktøy programvare for tidsstyring. Uten en løsning for tidsstyring ville det vært lett å tilbringe dagen slik du selv ønsker og la tregheten føre deg gjennom dagen. Dagene mine er mer produktive når jeg setter av fokustid til å få gjort viktige ting.
La oss snakke om nedetid. Hva er din foretrukne praksis eller ditt ritual for å forebygge utbrenthet?
Barna mine er sannsynligvis den beste motgiften mot utbrenthet. Barn lar deg ikke jobbe når du er sammen med dem. De vil være på kontoret ditt og be deg legge bort arbeidet, eller fortelle deg at de trenger tiden og oppmerksomheten din. Barn tvinger deg til å være til stede og legge jobben til side. Jeg setter pris på hvert øyeblikk med dem, og jeg er glad for at de får meg til å legge bort teknologien.
Basert på erfaringen din, hva er dine «5 trinn som trengs for å skape gode teknologiprodukter»?
1. Finn ditt ståsted og våg å være annerledes: lanser det deretter i markedet og se om det slår an. Hos AppMap mener vi at den eneste sannhetskilden er koderedigeringsprogrammet, og at du bør ha alle verktøyene du trenger, akkurat der du utfører arbeidet ditt. Derfra kan du bruke både kvantitative og kvalitative tilbakemeldinger fra brukerne dine til å styre utviklingen av nye funksjoner. Når ting fungerer, bør du gå i dybden og fortsette å satse, men ikke være redd for å legge bort områder som ikke blir brukt.
2. Kast deg ut i det: og kom så nær brukeren som mulig. Vær åpen for å lære av teamet og kundene dine, og bygg nettverk for å få tilbakemeldinger fra markedet. En taktikk AppMap bruker, er å skrive omfattende blogginnlegg med innhold på veiledningsnivå på siden vår i utviklerfellesskapet. Dette hjelper oss med å forstå hvilke områder vi bør investere mer i, når vi ser høyt engasjement rundt en bestemt funksjon. Alle selskaper som ønsker å skape et godt produkt, bør ta ideene til MVP-en sin, dele dem bredt og bruke engasjementsdata til å styre investeringsnivået.
3. Begynn, og bygg deretter kontinuerlig: Reid Hoffman sa berømt: «Hvis du ikke skammer deg over den første versjonen av produktet ditt, har du lansert for sent» – og dette bør bli ditt mantra for produktutvikling. Det er også viktig å være klar over at du ikke er et tomt løfte, og at du ikke er en funksjonsfabrikk. Sikt mot en god mellomting mellom gjennomtenkt helhet og rom for forbedring i tidlige produktlanseringer. Realiteten er at hvis produktet ditt løser et lite bruksområde, vil folk bruke det til å løse problemene sine, selv om brukeropplevelsen er klønete eller det finnes mindre feil.
4. Lanser det og mål, mål, mål: Ikke forvent at brukerne gir deg mengder av kvalitative tilbakemeldinger på produktet ditt – særlig når du utvikler for tekniske målgrupper. Disse brukerne er travle og overlesset med annet arbeid. De har ikke tid til å gi deg detaljerte tilbakemeldinger. Den beste måten å forstå brukerne på er å måle hvordan de samhandler med produktet ditt, hvis du har mulighet til det.
Hvis bruken er høy nok, bør du prøve å gjøre raske forbedringer basert på dataene du mottar, og hvis du har en stor brukerbase, bør du segmentere den så godt du kan for å forstå forskjellene mellom avanserte brukere og nybegynnere bedre. Disse brukertypene trenger ulike funksjoner, og det å utvikle funksjoner for én målgruppe kan skape problemer for andre.
5. Gjenta og videreutvikle: Fokus er den viktigste egenskapen i ethvert selskap, særlig i oppstartsbedrifter. Oppstartsbedrifter har ganske enkelt ikke tid eller penger til å investere på flere områder. Ikke bruk tid på å bekymre deg for alternativkostnaden ved å ikke jobbe med «alt». Fokuser i stedet på tiltakene med størst effekt, og del arbeidet opp i små biter. Ved å dele leveransene opp i mindre enheter kan du reagere raskere på tilbakemeldinger fra brukerne eller bruksdata, og kontinuerlig videreutvikle produktet slik at brukerne blir fornøyde.
Er du for øyeblikket fornøyd med status quo når det gjelder kvinner i teknologibransjen? Hvilke konkrete endringer mener du trengs for å endre status quo?
Kvinner som leder teknologiselskaper og innehar maktposisjoner, er fortsatt unntaket, ikke regelen. Selskaper ledet av kvinner i B2B-markedet for bedriftsløsninger utgjør fortsatt bare 2 % av risikofinansierte selskaper. Det finnes kvinnelige ledere i denne bransjen med et enormt talent, men som ennå ikke har fått en sponsor. Dette er noe jeg brenner for. Jeg mener at det fortsatt må bygges opp mer likestilling. Jeg håper jeg kan være et godt eksempel og hjelpe andre kvinner med å få ideene sine opp og frem, fordi det er vanskelig. Tallene lyver ikke – fra lønn til verdivurdering og andelen kvinner har av investeringskaken. Jeg mener folk bør se nærmere på B2B-selskaper grunnlagt av kvinner på lang sikt. De leverer den beste verdien for hver krone.
Finnes det en person i verden du gjerne skulle ha spist en privat frokost eller lunsj med, og hvorfor?
Jeg beundrer virkelig Diane Greene og karriereutviklingen hennes. Hun begynte som skipsarkitekt før hun gikk over til teknologi. Hun var grunnlegger og administrerende direktør i VMware, styremedlem i Google og administrerende direktør for Google Cloud, samt medgrunnlegger og administrerende direktør for to oppstartsbedrifter som ble kjøpt opp av Google og Microsoft.
For mer innhold som dette kan du abonnere på nyhetsbrevet til CPO Club.
