I øjeblikket identificerer kun omkring 1 ud af 4 medarbejdere i teknologibranchen sig som kvinder. Så hvad kræver det at skabe en succesfuld karriere som kvinde inden for teknologi? I denne interviewserie kaldet Kvinder i teknologi talte vi med succesfulde ledere i teknologibranchen for at dele historier og indsigter om, hvad de gjorde for at skabe blomstrende karrierer. Vi diskuterer også de skridt, der er nødvendige for at skabe et fantastisk teknologiprodukt. Som en del af denne serie havde jeg fornøjelsen af at interviewe Elizabeth Lawler.

Elizabeth Lawler
Elizabeth Lawler er medstifter og administrerende direktør for AppMap, den første platform til observerbarhed for udviklere, som leverer dynamisk softwareydeevne, sikkerhedsanalyse og indsigt i kørsel til udviklere i kodeeditoren. Tidligere var Elizabeth VP for DevOps-sikkerhed hos CyberArk, hvor hun lancerede virksomhedens open source-go-to-market-strategi for udviklerfokuserede værktøjer og teknologier. Før CyberArk grundlagde Elizabeth Conjur (opkøbt af CyberArk), som leverede det første produkt til at håndtere mangler inden for beskyttelse af privilegerede konti til DevOps-, cloud- og containerbaseret software. Elizabeth har også fungeret som Chief Data Officer hos Generation Health (opkøbt af CVS Caremark) og haft nationale lederstillinger i Department of Veterans Affairs. Hun har en doktorgrad og er uddannet dataforsker.
Mange tak, fordi du vil deltage i denne interviewserie! Før vi går i gang, vil vores læsere meget gerne lære mere om dig. Kan du fortælle os en historie om, hvad der førte dig ind på netop denne karrierevej?
AppMap er min anden teknologistartup inden for det uudnyttede område for udviklerværktøjer. Jeg begyndte min karriere med at undervise studerende i statistisk databehandling, blev derefter dataforsker og senere IT-leder, hvor jeg fungerede som dataansvarlig og sikkerhedschef. Til sidst begyndte jeg at grundlægge teknologivirksomheder for at udvikle nye produkter, der kunne opfylde nogle behov, jeg havde for produkter, som ikke fandtes på markedet.
Da jeg forsøgte at kommunikere komplekse softwarearkitekturer til nye mennesker, medarbejdere og interessenter, indså jeg, at der var tydelige misforståelser og fejlopfattelser omkring kodearkitektur, hvordan software opfører sig, når den kører, samt fejlopfattelser omkring kvalitet, ydeevne, sikkerhed osv.; så meget af det, vi har brug for at forstå, er uigennemsigtigt eller baseret på mentale modeller. Men softwaren beskriver selv sin egen adfærd, og koden er bedst placeret til at forklare, hvordan den fungerer, når den kører. Det var mit aha-øjeblik, og det var det, der fik mig og nogle af de tidlige teammedlemmer til at udvikle AppMap.
Det er blevet sagt, at vores fejl nogle gange kan være vores største læremestre. Kan du dele en historie om den sjoveste fejl, du begik, da du lige var begyndt? Kan du fortælle os, hvilken lektie du lærte af den?
Jeg ved ikke, om dette er et sjovt eksempel, men det er et eksempel fra den virkelige verden. Man siger, at man ikke bør gentage sine egne fejl, men det gjorde vi netop. Da vi begyndte at udtænke AppMap, som er et produkt til kodeanalyse under kørsel, begyndte vi at udvikle det som en SaaS-løsning. Det var en af de nemmeste måder at bygge en prototype på og indsamle de testdata, vi havde brug for fra open source-projekter, for at validere vores teknologi.
På grund af vores baggrund inden for cybersikkerhed vidste vi fra begyndelsen, at der var stor følsomhed omkring dynamisk analyse og lagring af følsomme kodedata. Softwareudviklingspipelines kan være vektorer for indsættelse af ondsindet kode, og personer kan få adgang til følsom kode og pipelines gennem alle mulige integrerede tredjepartsværktøjer, som det fremgår af de seneste brud på CI-systemer.
Hvis vi flyttede AppMap helt ind i kodeeditoren og gjorde vores dataplatform mindre for at placere den tættere på koden, kunne vi reducere datasikkerhedsrisikoen. Folk kunne bruge AppMap, og vi kunne forsikre brugeren om, at “din kode er din kode”. Vi reducerede risikoen fra tredjepartssoftware, og udbredelsen tog fart.
Men så besluttede vi, at vi ville udvikle analysefunktioner. Derfor begyndte vi at bygge på en server ved hjælp af open source-projekter som vores testdata. Igen sagde brugerne: “Jeg vil ikke have det der. Læg det i mit IDE.” Endnu en gang flyttede vi alle disse funktioner og denne funktionalitet tilbage ind i kodebasen, hvor du finder analysefunktionerne i dag.
Lektien her er: Det er lige så smertefuldt at begå den samme fejl to gange anden gang som første gang.
Hvad føler du har været det øjeblik, der har defineret din karriere?
I oktober sidste år deltog AppMap i TechCrunch Disrupt, og det var ret fantastisk. Det var en oplevelse uden sidestykke i forhold til noget, jeg havde prøvet før – at konkurrere på den måde med publikum og rækkevidden af det arrangement. Jeg tror, at AppMap havde gavn af at få mulighed for at dele vores budskab på den platform.
Jeg tror dog ikke, at det øjeblik, der har defineret min karriere, er indtruffet endnu; der venter altid en ny og større udfordring. Jeg ser store ting forude for dette team og dette produkt.
Kan du fortælle os en historie om de svære tider, du oplevede, da du først begyndte på din rejse? Overvejede du nogensinde at give op? Hvor fandt du drivkraften til at fortsætte, selv om tingene var så svære?
Det er ikke nogen nem opgave at beslutte sig for at bygge et produkt til et uudforsket område. Man skal være i stand til at fange folks fantasi, så de tager noget til sig eller prøver noget, som de ikke vidste kunne eksistere, og hvis fordel de ikke intuitivt forstår. Selvom det er utrolig sjovt at skabe noget og kunne forestille sig noget, der endnu ikke eksisterer, kan det også være utrolig frustrerende. Produkter til uudforskede områder er en udfordring at kommunikere præcist, og nogle gange spørger man sig selv: »Kan jeg blive ved med det her?«, fordi det er så svært at gøre. Det er den sværeste type problem at løse som iværksætter.
Vi henvendte os til Google, Meta og virksomheder med udviklerværktøjer til udvikleroplevelse i verdensklasse, og de havde ikke noget, der lignede det, vi skabte. Vi validerede vores antagelser om det, der manglede, men jeg tror ikke, folk mente, at det var muligt. Vi var nødt til virkelig at tro på vores vision og vores evne til at skabe dette produkt. Jeg er så heldig at arbejde sammen med et team, der virkelig kan bygge teknisk udfordrende produkter med en utrolig dybde.
Det er både fantastisk og skræmmende at få øje på en mulighed, som andre ikke ser. Det er, når man begynder at få lidt fremdrift, og man ser, at det begynder at give mening for folk, og de begynder at forstærke det, man har bygget – så indser man, hvorfor man gjorde det. Man hører brugerens begejstring. Nu får man lyst til at gå endnu længere og begejstre dem endnu mere.
Vi vil meget gerne høre lidt om jeres virksomhed. Hvilket problem hjælper jeres virksomhed med at løse? Hvordan hjælper jeres virksomhed folk?
AppMap leverer den første platform til observerbarhed for udviklere, som giver udviklere dynamisk softwareanalyse, herunder analyse af ydeevne og sikkerhed, direkte i kodeeditoren.
Indtil nu har dette været et stort hul i markedet, eftersom udviklere og softwareteams har været tvunget til at stole på værktøjer til statisk analyse og ikke har kunnet identificere komplekse designproblemer i koden eller fejlfinde kundeproblemer, før de blev udgivet. Det resulterede i timevis af omarbejde, som hæmmer kreativitet og innovation. Softwarebesvær er en af de primære årsager til, at udviklere foretager stille opsigelser.
AppMap udfordrer traditionelle tilgange til udvikleroplevelsen ved problemfrit at integrere sit værktøj med åben kildekode til analyse af kode under kørsel direkte i kodeeditoren. Det gør det muligt for brugerne ikke kun at se kodens adfærd, men også eventuelle foreslåede ændringer af ydeevne, sikkerhed og stabilitet, mens koden udvikles. Det løfter udvikleroplevelsen ved at give forudsigende og handlingsanvisende indsigt, når det er nemt at foretage ændringer.
Hvis nogen ønsker at lede en fantastisk virksomhed og skabe fantastiske produkter, hvilken egenskab er så den vigtigste, som personen bør have, og hvilke vaner eller hvilken adfærd vil du anbefale for at styrke netop denne egenskab?
Man skal absolut have empati for sin bruger. Som udviklerværktøj i kodeeditoren befinder man sig i det mest intime kreative rum sammen med sin bruger. Man er på brugerens skrivebord, i det kreative udviklingsøjeblik, der definerer, hvad udviklere gør. For at være hjælpsom skal man have stor medfølelse og være omhyggelig med, hvordan man hjælper. Det er en meget fin balance.
Målet er at skabe noget, som folk elsker og ikke ønsker at arbejde uden. Det er en meget stejl bakke, når det gælder produktdesign og udvikling. Måden at sikre, at man altid sætter brugeren først, er at lære sin bruger at kende og opbygge et fællesskab og samtaler omkring forskellige tilgange.
Hos AppMap ved vi, at idéer kan komme alle steder fra. Vi profilerer en masse udviklere og vores fællesskabssider. Vi har mennesker fra hele verden – fra alle 50 delstater i USA og hundredvis af lande – repræsenteret i vores fællesskab. Det giver os mulighed for at afspejle og forstå alles behov. Det er den mest effektive måde, vi driver vores mission fremad på.
Lad os tale om teams. Hvilken strategi eller ramme for teamledelse har du fundet særligt nyttig i produktudviklingsprocessen?
Fra vores produkt til den måde, vores team arbejder på, er gennemsigtighed afgørende. Med AppMap begyndte vi med åben kildekode, fordi det giver alle, der kan læse og forstå vores produkt, mulighed for at give os input og feedback. Ved at vælge åbenhed skabte vi en mulighed for at have produktsamtaler med den gruppe af brugere, vi forsøger at betjene. Åbenhed er noget, vores team virkelig tror på.
Når du tænker på det stærkeste team, du nogensinde har arbejdet sammen med, hvorfor tror du så, at teamet fungerede så godt sammen, og kan du huske en anekdote, der illustrerer dynamikken?
AppMap-teamet består faktisk af mange medlemmer fra mit tidligere team hos Conjur. Vi har bevæget os fra virksomhed til virksomhed og arbejdet sammen på en række projekter inden for uudforskede områder.
Det, der imponerer mig mest ved dette team, er, at vi ikke kun arbejder godt sammen, men også fungerer godt sammen, når vi møder modgang. Vi går ind i problemerne og arbejder på at løse dem – vi tager imod feedback, uanset hvem der er i rummet. Det er sådan, vi alle arbejder sammen.
Som team mødes vi ofte for at skabe fælles retning. Det er lykkedes os at fremme en kultur med radikal gennemsigtighed. Alle kan komme med idéer fra alle hjørner af organisationen. Vi passer på hinanden, og det gør vi virkelig godt.
Hvis du kun havde ét softwareværktøj i dit arsenal, hvilket skulle det så være, hvorfor, og hvilke andre værktøjer anser du for at være afgørende for jeres mission?
Jeg synes, at kodeeditorer som VS Code og JetBrains er fantastiske steder at udføre sit arbejde. Vi betragter dem ikke kun som steder, hvor vi selv er medlemmer af økosystemet, men man kan også se alle de værktøjer og teknologier, der er målrettet udviklere, bevæge sig ind i det miljø – hvilket gør dem helt uundværlige. Hvis man vil forstå, hvordan softwareprodukter bliver bygget, er man nødt til at forstå, hvad der foregår inde i kodeeditoren. Se på Co-pilot og andre generative værktøjer, der flytter grænserne i kodeeditoren.
Som virksomhedsleder er et andet missionskritisk værktøj software til tidsstyring. Uden en løsning til tidsstyring ville det være nemt at bruge dagen, som man har lyst til, og lade inertien føre en gennem dagen. Mine dage er mere produktive, når jeg planlægger fokustid til at få vigtige ting gjort.
Lad os tale om nedetid. Hvad er din foretrukne praksis eller dit ritual for at forebygge udbrændthed?
Mine børn er sandsynligvis den bedste modgift mod udbrændthed. Børn lader dig ikke arbejde, når du er sammen med dem. De vil være på dit kontor og fortælle dig, at du skal lægge arbejdet væk, eller at de har brug for din tid og opmærksomhed. Børn tvinger dig til at være nærværende og lægge arbejdet fra dig. Jeg værdsætter hvert øjeblik med dem, og jeg er glad for, at de får mig til at lægge teknologien væk.
Hvad er efter din erfaring dine ”5 trin, der er nødvendige for at skabe fantastiske teknologiprodukter”?
1. Find dit synspunkt, og tur at være anderledes: før det derefter ud på markedet, og se, om det resonerer. Hos AppMap mener vi, at den eneste sandhedskilde er kodeeditoren, og at du bør have alle de værktøjer, du har brug for, lige dér, hvor du udfører dit arbejde. Derfra skal du bruge både kvantitativ og kvalitativ feedback fra dine brugere til at udvikle nye funktioner. Når tingene fungerer, skal du dykke ned i det og fortsætte med at engagere dig, men vær ikke bange for at opgive områder, der ikke bliver brugt.
2. Kast dig ud i det: og kom så tæt på brugeren som muligt. Vær åben over for at lære af dit team og dine kunder, og skab netværk for at få feedback fra markedet. En af de taktikker, AppMap bruger, er at blogge omfattende om indhold på vejledningsniveau på vores side for udviklerfællesskabet. Det hjælper os med at forstå, hvilke områder vi bør investere mere i, når vi ser højt engagement i en bestemt funktion. Enhver virksomhed, der ønsker at skabe et fantastisk produkt, bør tage sine MVP-idéer, dele dem bredt og bruge engagementsdata til at styre investeringsniveauet.
3. Start, og byg derefter løbende videre: Reid Hoffman sagde berømt: ”Hvis du ikke er flov over den første version af dit produkt, har du lanceret for sent” – og det bør blive dit mantra for produktudvikling. Det er også vigtigt at være opmærksom på, at du hverken er vaporware eller en funktionsfabrik. Sigt efter en god mellemvej mellem gennemtænkt fuldstændighed og plads til forbedringer i de tidlige produktudgivelser. Virkeligheden er, at hvis dit produkt løser en lille anvendelsessituation, vil folk bruge det til at løse deres problemer på trods af en klodset brugeroplevelse eller mindre fejl.
4. Udgiv det, og mål, mål, mål: Forvent ikke, at brugerne giver dig masser af kvalitativ feedback på dit produkt – især ikke når du bygger til tekniske målgrupper. Disse brugere har travlt og er overbebyrdede med andet arbejde. De har ikke tid til at give dig detaljeret feedback. Den bedste måde at forstå dine brugere på er at måle deres interaktioner med dit produkt, hvis du kan.
Hvis din brug er tilstrækkelig høj, kan du forsøge at iterere hurtigt på de data, du modtager, og hvis du har en stor brugerbase, kan du segmentere den så godt som muligt for bedre at forstå forskellene mellem superbrugere og begyndere. Disse brugertyper har brug for forskellige funktioner, og udvikling af funktioner til én målgruppe kan skabe problemer for andre.
5. Iterér, og udvikl dig: Fokus er den vigtigste egenskab i enhver virksomhed, især i startups. Startups har ganske enkelt ikke tid eller penge til at investere i flere områder. Brug ikke tid på at bekymre dig om alternativomkostningen ved ikke at arbejde på ”alt det hele”. Fokuser i stedet på de områder med størst effekt, og opdel arbejdet i små bidder. Ved at opdele leverancerne i mindre enheder kan du reagere hurtigere på brugerfeedback eller brugsdata og løbende udvikle dit produkt, så dine brugere bliver begejstrede.
Er du i øjeblikket tilfreds med status quo, når det gælder kvinder i teknologibranchen? Hvilke konkrete ændringer mener du er nødvendige for at ændre status quo?
Kvinder, der leder teknologivirksomheder og sidder i magtfulde positioner, er stadig undtagelsen, ikke reglen. Virksomheder ledet af kvinder inden for B2B-enterpriseområdet udgør stadig kun 2 % af de venturefinansierede virksomheder. Der er kvindelige ledere i denne branche, som har et enormt talent, men som endnu ikke er blevet støttet gennem sponsorater. Dette er en hjertesag for mig. Jeg mener, at der stadig skal opbygges lighed. Jeg håber, at jeg kan være et stærkt eksempel og hjælpe andre kvinder med at få deres idéer fra jorden, for det er svært. Tallene lyver ikke – hverken når det gælder løn, værdiansættelse eller den andel af investeringskagen, som kvinder har. Jeg mener, at folk på lang sigt bør se nærmere på B2B-virksomheder grundlagt af kvinder. De leverer den bedste værdi for hver investeret krone.
Er der en person i verden, som du ville elske at spise privat morgenmad eller frokost med, og hvorfor?
Jeg beundrer virkelig Diane Greene og hendes karriereforløb. Hun begyndte som skibsarkitekt, før hun skiftede til teknologibranchen. Hun var grundlægger og administrerende direktør for VMware, bestyrelsesmedlem i Google samt administrerende direktør for Google Cloud og medstifter og administrerende direktør for to startups, der blev opkøbt af Google og Microsoft.
Hvis du vil have mere indhold som dette, kan du abonnere på nyhedsbrevet fra The CPO Club.




