Momenteel identificeert slechts ongeveer 1 op de 4 werknemers in de technologiesector zich als vrouw. Dus wat is ervoor nodig om als vrouw in de technologiesector een succesvolle carrière op te bouwen? In deze interviewreeks met de naam Women in Tech spraken we met succesvolle leiders in de technologiesector om verhalen en inzichten te delen over wat zij hebben gedaan om een bloeiende carrière op te bouwen. We bespreken ook de stappen die nodig zijn om een geweldig technologieproduct te creëren. Als onderdeel van deze reeks had ik het genoegen om Elizabeth Lawler te interviewen.
Elizabeth Lawler
Elizabeth Lawler is medeoprichter en CEO van AppMap, het eerste platform voor observeerbaarheid voor ontwikkelaars dat dynamische softwareprestaties, beveiligingsanalyse en uitvoeringsinzichten aan ontwikkelaars in de code-editor levert. Daarvoor was Elizabeth vicepresident voor DevOps-beveiliging bij CyberArk, waar ze de open-source marktintroductiestrategie van het bedrijf voor ontwikkelaarsgerichte tools en technologieën lanceerde. Voorafgaand aan CyberArk richtte Elizabeth Conjur op (overgenomen door CyberArk), dat het eerste product leverde om tekortkomingen op het gebied van beveiliging van geprivilegieerde accounts voor DevOps-, cloud- en container-native software aan te pakken. Elizabeth was ook directeur gegevensbeheer van Generation Health (overgenomen door CVS Caremark) en bekleedde landelijke leidinggevende functies bij het Department of Veterans Affairs. Ze heeft een doctoraat en is opgeleid als datawetenschapper.
Hartelijk dank dat je met ons wilt deelnemen aan deze interviewreeks! Voordat we erin duiken, zouden onze lezers graag meer over je te weten komen. Kun je ons een verhaal vertellen over wat je ertoe bracht juist dit carrièrepad te kiezen?
AppMap is mijn tweede techstartup op het gebied van ontwikkelaarstools waar nog weinig aanbod voor was. Ik begon mijn carrière met het geven van onderwijs in statistische computing, werd vervolgens datawetenschapper en daarna IT-leider als Chief Data Officer en Chief Security Officer. Uiteindelijk begon ik technologiebedrijven op te richten om nieuwe producten te bouwen die voorzagen in productbehoeften die ik had, maar die nog niet op de markt waren.
Toen ik complexe softwarearchitecturen probeerde uit te leggen aan nieuwe mensen, werknemers en belanghebbenden, besefte ik dat er duidelijke misverstanden en verkeerde opvattingen bestonden over codearchitectuur, hoe software zich gedraagt wanneer deze wordt uitgevoerd, en over kwaliteit, prestaties, beveiliging enzovoort. Zoveel van wat we moeten begrijpen is ondoorzichtig of gebaseerd op mentale modellen. Maar de software beschrijft zelf haar eigen gedrag, en de code is bij uitstek geschikt om uit te leggen hoe de software werkt wanneer deze wordt uitgevoerd. Dat was voor mij het aha-moment en vormde de drijfveer voor mij en enkele van de eerste teamleden om AppMap te bouwen.
Er wordt gezegd dat onze fouten soms onze beste leermeesters kunnen zijn. Kun je een verhaal vertellen over de grappigste fout die je maakte toen je net begon? Kun je ons vertellen welke les je daaruit hebt geleerd?
Ik weet niet of dit een grappig voorbeeld is, maar het is wel een voorbeeld uit de praktijk. Ze zeggen dat je je eigen fouten niet moet herhalen, maar dat deden wij dus wel. Toen we AppMap begonnen te bedenken als een product voor runtime-codeanalyse, begonnen we het te bouwen als SaaS. Dat was een van de eenvoudigste manieren om een prototype te bouwen en de testgegevens te verzamelen die we nodig hadden uit opensourceprojecten om onze technologie te valideren.
Gezien onze achtergrond in cybersecurity wisten we vanaf het begin dat er veel gevoeligheid bestond rond dynamische analyse en het opslaan van gevoelige codegegevens. Softwareontwikkelingspijplijnen kunnen worden gebruikt om kwaadaardige code te injecteren en mensen kunnen via allerlei geïntegreerde tools van derden toegang krijgen tot gevoelige code en pijplijnen, zoals blijkt uit recente inbreuken op CI-systemen.
Als we AppMap volledig naar de code-editor verplaatsten en ons dataplatform verkleinden zodat het dichter bij de code kwam, konden we het risico voor de gegevensbeveiliging verminderen. Mensen konden AppMap gebruiken en wij konden de gebruiker verzekeren dat “jouw code is jouw code”. We verminderden het risico van software van derden en de toepassing ervan nam een vlucht.
Maar toen besloten we dat we analyses wilden bouwen. Daarom begonnen we op een server te bouwen met opensourceprojecten als testgegevens. Opnieuw zeiden de gebruikers: “Ik wil het daar niet hebben. Zet het in mijn IDE.” We verplaatsten al die functies en functionaliteit dus opnieuw naar de codebasis, waar je de analysemogelijkheden vandaag de dag vindt.
De les hiervan: twee keer dezelfde fout maken is de tweede keer net zo pijnlijk als de eerste keer.
Wat beschouw je als jouw bepalende carrièremoment?
Afgelopen oktober nam AppMap deel aan TechCrunch Disrupt en dat was behoorlijk fenomenaal. Het was een ervaring zoals ik die nog nooit eerder had meegemaakt: op die manier concurreren met het publiek en het bereik van dat evenement. Ik denk dat AppMap er baat bij heeft gehad dat we ons verhaal op dat platform konden delen.
Ik denk echter niet dat mijn bepalende carrièremoment al heeft plaatsgevonden; er wacht altijd een nieuwe en grotere uitdaging. Ik zie grote dingen in het verschiet voor dit team en dit product.
Kun je ons een verhaal vertellen over de moeilijke tijden waarmee je te maken kreeg toen je net aan je reis begon? Heb je ooit overwogen om op te geven? Waar haalde je de motivatie vandaan om door te gaan, ook al waren de omstandigheden zo moeilijk?
Besluiten om een witruimteproduct te bouwen is geen eenvoudige taak. Je moet de verbeelding van mensen kunnen prikkelen, zodat ze iets gaan gebruiken of uitproberen waarvan ze niet wisten dat het kon bestaan en waarvan ze het voordeel niet intuïtief begrijpen. Hoewel het ontzettend leuk is om iets te creëren en je iets te kunnen voorstellen dat nog niet bestaat, kan het ook ontzettend frustrerend zijn. Witruimteproducten zijn een uitdaging om nauwkeurig onder woorden te brengen en soms vraag je je af: “kan ik hiermee doorgaan?” omdat het zo moeilijk is. Het is het moeilijkste soort probleem om als ondernemer op te lossen.
We gingen naar Google, Meta en bedrijven met eersteklas tools voor ontwikkelaarservaring, en zij hadden niets dat leek op wat wij aan het maken waren. We valideerden onze aannames over wat er ontbrak, maar ik denk niet dat mensen dachten dat het mogelijk was. We moesten echt in onze visie en in ons vermogen om dit product te creëren geloven. Ik heb enorm veel geluk dat ik werk met een team dat technisch ongelooflijk diepgaande en uitdagende producten kan bouwen.
Het is opwindend en beangstigend om een kans te zien die anderen niet zien. Wanneer je wat momentum begint te krijgen, ziet dat het bij mensen begint te landen en ze beginnen te versterken wat je hebt gebouwd, besef je waarom je het hebt gedaan. Je hoort hoe enthousiast de gebruiker is. Dan wil je nog verder gaan en hen nog meer verrassen.
We zouden graag wat meer over jullie bedrijf leren. Welk pijnpunt helpt jullie bedrijf oplossen? Hoe helpt jullie bedrijf mensen?
AppMap biedt het allereerste platform voor observeerbaarheid voor ontwikkelaars dat dynamische softwareanalyse levert, waaronder prestatie- en beveiligingsanalyses, rechtstreeks aan ontwikkelaars in de code-editor.
Tot nu toe was dit een enorme leemte in de markt, omdat ontwikkelaars en softwareteams gedwongen waren te vertrouwen op statische analysetools en niet in staat waren complexe ontwerpkwesties in code te identificeren of problemen van klanten op te lossen voordat deze werden uitgebracht. Dit leidde tot uren herwerk die creativiteit en innovatie tot stilstand brachten. Werkdruk door softwareonderhoud is een van de belangrijkste oorzaken dat ontwikkelaars stilletjes afhaken.
AppMap doorbreekt traditionele benaderingen van de ontwikkelaarservaring door zijn opensourcehulpmiddel voor runtime-codeanalyse naadloos rechtstreeks in de code-editor te integreren. Hierdoor kunnen gebruikers niet alleen het gedrag van code zien, maar ook eventuele voorgestelde wijzigingen op het gebied van prestaties, beveiliging en stabiliteit terwijl de code wordt ontwikkeld. Dit tilt de ontwikkelaarservaring naar een hoger niveau door voorspellende en bruikbare inzichten te bieden op het moment dat wijzigingen eenvoudig kunnen worden aangebracht.
Als iemand een geweldig bedrijf wil leiden en geweldige producten wil creëren, wat is dan de belangrijkste eigenschap die die persoon moet hebben, en welke gewoonten of gedragingen zou je aanraden om die specifieke eigenschap verder te ontwikkelen?
Je moet absoluut empathie hebben voor je gebruiker. Als ontwikkelaarstool in de code-editor bevind je je in de meest intieme creatieve ruimte van je gebruiker. Je bent aanwezig op hun bureaublad, op hun creatieve ontwikkelmoment dat bepaalt wat ontwikkelaars doen. Om behulpzaam te zijn, moet je veel medeleven hebben en zorgvuldig afwegen hoe je helpt. Dat is een zeer delicate balans.
Het doel is iets te creëren waar mensen van houden en waar ze niet meer zonder willen werken. Dat is een zeer steile opgave op het gebied van productontwerp en ontwikkeling. Om ervoor te zorgen dat je de gebruiker altijd op de eerste plaats zet, moet je je gebruiker leren kennen en een community en gesprekken rond benaderingen opbouwen.
Bij AppMap weten we dat ideeën overal vandaan komen. We brengen het profiel van veel ontwikkelaars en onze communitypagina's in kaart. In onze community zijn mensen van over de hele wereld vertegenwoordigd: uit alle 50 staten van de Verenigde Staten en uit honderden landen. Dit geeft ons de mogelijkheid om de behoeften van iedereen te weerspiegelen en te begrijpen. Dat is de krachtigste manier waarop we onze missie vooruithelpen.
Laten we het over teams hebben. Welke strategie of welk raamwerk voor teammanagement heb je bijzonder nuttig gevonden voor het productontwikkelingsproces?
Van ons product tot de manier waarop ons team werkt: transparantie is essentieel. Met AppMap begonnen we eerst met opensource, omdat iedereen die ons product kan lezen en begrijpen ons input en feedback kan geven. Door ervoor te kiezen open te zijn, creëerden we de mogelijkheid om productgesprekken te voeren met de groep gebruikers die we proberen te bedienen. Openheid is iets waar ons team echt in gelooft.
Als je denkt aan het sterkste team waarmee je ooit hebt gewerkt, waarom denk je dan dat het team zo goed samenwerkte, en kun je je een anekdote herinneren die de dynamiek illustreert?
Het AppMap-team bestaat eigenlijk uit veel leden van mijn voormalige team bij Conjur. We zijn als groep van bedrijf naar bedrijf gegaan en hebben samen opeenvolgende witruimteprojecten uitgevoerd.
Wat de meeste indruk op me maakt bij dit team, is dat we niet alleen goed samenwerken, maar ook goed samenwerken wanneer we tegenslag ondervinden. We gaan de problemen aan en werken eraan om ze op te lossen – we omarmen feedback, ongeacht wie er in de ruimte aanwezig is. Zo werken we allemaal samen.
Als team komen we regelmatig samen om voor afstemming te zorgen. We zijn erin geslaagd een cultuur van radicale transparantie te bevorderen. Iedereen kan vanuit elke hoek van de organisatie ideeën aandragen. We zorgen voor elkaar en doen dat echt goed.
Als je maar één softwaretool in je arsenaal mocht hebben, welke zou dat dan zijn, waarom, en welke andere tools beschouw je als bedrijfskritisch?
Ik denk dat code-editors, zoals VS Code en JetBrains, echt fenomenale plekken zijn om werk te doen. We zien deze niet alleen als een plek waarvoor we onszelf als leden van het ecosysteem beschouwen, maar je ziet ook alle tools en technologieën die op ontwikkelaars zijn gericht naar die omgeving verschuiven – waardoor ze absoluut onmisbaar worden. Als je wilt begrijpen hoe softwareproducten worden gebouwd, moet je begrijpen wat er in de code-editor gebeurt. Kijk naar Co-pilot en andere generatieve tools die de grenzen in de code-editor verleggen.
Als bedrijfsleider is software voor tijdbeheer een ander bedrijfskritisch hulpmiddel. Zonder een oplossing voor tijdbeheer zou het gemakkelijk zijn om je dag in te delen zoals je wilt en je door de traagheid van de dag te laten meeslepen. Mijn dagen zijn productiever wanneer ik tijd voor focus inplan om belangrijke dingen gedaan te krijgen.
Laten we het hebben over rusttijd. Wat is jouw favoriete gewoonte of ritueel om een burn-out te voorkomen?
Mijn kinderen zijn waarschijnlijk het beste middel tegen een burn-out. Kinderen laten je niet werken wanneer je bij hen bent. Ze zullen in je kantoor zijn en je vertellen dat je je werk moet wegleggen of dat ze je tijd en aandacht nodig hebben. Kinderen dwingen je om aanwezig te zijn en je werk neer te leggen. Ik koester elk moment met hen en ben blij dat ze ervoor zorgen dat ik de technologie wegleg.
Wat zijn volgens jouw ervaring de “5 stappen die nodig zijn om geweldige technologieproducten te creëren”?
1. Bepaal je POV en durf anders te zijn: voeg die vervolgens toe aan de markt en kijk of deze aanslaat. Bij AppMap geloven we dat de code-editor de enige bron van waarheid is en dat je alle hulpmiddelen die je nodig hebt direct moet hebben op de plek waar je werkt. Gebruik van daaruit zowel de kwantitatieve als kwalitatieve terugkoppeling van je gebruikers om nieuwe functies aan te sturen. Wanneer dingen goed werken, duik er dan in en blijf je eraan committeren, maar wees niet bang om gebieden te verlaten die niet worden gebruikt.
2. Duik er meteen in: en kom zo dicht mogelijk bij de gebruiker. Sta open voor het leren van je team en klanten, en netwerk om terugkoppeling uit de markt te krijgen. Een tactiek die AppMap toepast, is uitgebreid lesmateriaal op tutorialniveau te bloggen op onze pagina van de ontwikkelaarscommunity. Dit helpt ons te begrijpen in welke gebieden we meer moeten investeren wanneer we veel betrokkenheid bij een bepaalde functie zien. Elk bedrijf dat een geweldig product wil creëren, moet zijn MVP-ideeën nemen, ze breed delen en de betrokkenheidsgegevens gebruiken om de mate van investering te bepalen.
3. Begin en bouw vervolgens voortdurend verder: Reid Hoffman zei beroemd: “Als je je niet schaamt voor de eerste versie van je product, heb je het te laat gelanceerd” – en dat zou je mantra voor productontwikkeling moeten worden. Het is ook belangrijk om te beseffen dat je geen loze beloften doet en geen functionaliteitenfabriek bent. Streef bij vroege productreleases naar een goede middenweg tussen volledigheid van gedachte en ruimte voor verbetering. De realiteit is dat mensen je product zullen gebruiken om hun problemen op te lossen als je product een klein gebruiksscenario oplost, ondanks een onhandige gebruikerservaring of kleine bugs.
4. Breng het uit en meet, meet, meet: Verwacht niet dat gebruikers je enorm veel kwalitatieve terugkoppeling over je product geven – vooral niet wanneer je bouwt voor een technisch publiek. Deze gebruikers zijn druk en worden overladen met ander werk. Ze hebben geen tijd om je gedetailleerde terugkoppeling te geven. De beste manier om je gebruikers te begrijpen, is hun interacties met je product te meten, als dat mogelijk is.
Als je gebruiksvolume hoog genoeg is, probeer dan snel te itereren op basis van de gegevens die je ontvangt, en als je een groot gebruikersbestand hebt, segmenteer dit dan zo goed mogelijk om de verschillen tussen intensieve gebruikers en beginners beter te begrijpen. Deze gebruikerstypen hebben verschillende functies nodig en het bouwen van functies voor de ene doelgroep kan problemen veroorzaken voor andere doelgroepen.
5. Itereer en evolueer: Focus is de belangrijkste eigenschap van elk bedrijf, en vooral van start-ups. Start-ups hebben simpelweg niet de tijd of het geld om in meerdere gebieden te investeren. Besteed geen tijd aan zorgen over de opportuniteitskosten van het niet werken aan “alles”. Richt je in plaats daarvan op de onderdelen met de grootste impact en deel het werk op in kleine stukken. Door opleveringen op te delen in kleinere eenheden, kun je sneller reageren op terugkoppeling van gebruikers of gebruiksgegevens en je product voortdurend verder ontwikkelen om je gebruikers blij te maken.
Ben je momenteel tevreden met de status quo rond vrouwen in de technologiesector? Welke specifieke veranderingen zijn volgens jou nodig om de status quo te veranderen?
Vrouwen die technologiebedrijven leiden en machtsposities bekleden, blijven de uitzondering en niet de regel. Bedrijven die door vrouwen worden geleid in de B2B-bedrijfsomgeving vormen nog altijd slechts 2% van de door durfkapitaal gefinancierde bedrijven. Er zijn vrouwelijke leiders in deze sector die enorm veel talent hebben, maar nog niet zijn gesponsord. Dit is een passie van mij. Ik geloof dat er nog steeds gelijkheid moet worden opgebouwd. Ik hoop dat ik een sterk voorbeeld kan zijn en andere vrouwen kan helpen hun ideeën van de grond te krijgen, want het is moeilijk. De cijfers liegen niet – van salaris en waardering tot het aandeel dat vrouwen van de investeringskoek hebben. Ik vind dat mensen op de lange termijn beter moeten kijken naar B2B-bedrijven die door vrouwen zijn opgericht. Zij leveren dollar voor dollar de beste waarde.
Is er iemand ter wereld met wie je graag privé zou willen ontbijten of lunchen, en waarom?
Ik bewonder Diane Greene en haar loopbaanontwikkeling enorm. Ze begon als scheepsbouwkundig ingenieur voordat ze overstapte naar de technologiesector. Ze was oprichter en CEO van VMware, bestuurslid van Google en CEO van Google Cloud, en medeoprichter en CEO van twee start-ups die door Google en Microsoft werden overgenomen.
Abonneer je voor meer inhoud zoals deze op de nieuwsbrief van The CPO Club.
