Vrouwen in de technologie: Elizabeth Lawler van AppMap over de 5 stappen die nodig zijn om geweldige technologieproducten te creëren

Toen ik complexe softwarearchitecturen probeerde uit te leggen aan nieuwe mensen, werknemers en belanghebbenden, realiseerde ik me dat er duidelijke misverstanden en verkeerde opvattingen bestonden over codearchitectuur, de manier waarop software zich gedraagt wanneer deze wordt uitgevoerd, en over kwaliteit, prestaties, beveiliging enzovoort. Veel 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 deze werkt wanneer ze 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. Kunt u een verhaal vertellen over de grappigste fout die u maakte toen u net begon? Kunt u ons vertellen welke les u daaruit heeft geleerd?

Ik weet niet of dit een grappig voorbeeld is, maar het is wel een voorbeeld uit de praktijk. Men zegt dat je je eigen fouten niet moet herhalen, maar dat hebben wij dus wel gedaan. Toen we AppMap begonnen te bedenken als een product voor codeanalyse tijdens de uitvoering, begonnen we het te bouwen als SaaS. Dat was een van de gemakkelijkste manieren om een prototype te bouwen en de testgegevens te verzamelen die we nodig hadden uit open-sourceprojecten 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 codedata. Softwareontwikkelingspijplijnen kunnen worden gebruikt voor het invoegen van schadelijke code, 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 zouden verplaatsen en ons dataplatform zouden verkleinen zodat het dichter bij de code kwam, konden we het risico voor de gegevensbeveiliging beperken. Mensen konden AppMap gebruiken en wij konden de gebruiker verzekeren: “jouw code blijft jouw code”.  We verkleinden het risico van software van derden en de adoptie nam een hoge vlucht. 

Maar toen besloten we dat we analyses wilden bouwen. Daarom begonnen we op een server te bouwen met open-sourceprojecten als testgegevens.  Opnieuw zeiden de gebruikers: “Ik wil het daar niet hebben. Zet het in mijn IDE.” We hebben al die functies en functionaliteiten opnieuw naar de codebasis verplaatst, waar u de analysemogelijkheden vandaag de dag aantreft. 

De les hieruit: dezelfde fout twee keer maken is de tweede keer net zo pijnlijk als de eerste.

Wat beschouwt u als uw bepalende carrièremoment?

Afgelopen oktober nam AppMap deel aan TechCrunch Disrupt en dat was werkelijk 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 had om onze boodschap op dat platform te kunnen delen. 

Toch denk ik niet dat mijn bepalende carrièremoment al heeft plaatsgevonden; er ligt altijd een nieuwe en grotere uitdaging in het verschiet. Ik zie grote dingen voor dit team en dit product.

Kunt u ons vertellen over de moeilijke tijden waarmee u te maken kreeg toen u net aan uw reis begon? Heeft u ooit overwogen om op te geven? Waar haalde u de motivatie vandaan om door te gaan, ook al waren de dingen zo moeilijk?

Besluiten om een product in een onbenutte marktruimte te bouwen, is geen eenvoudige taak. Je moet de verbeelding van mensen kunnen aanspreken, 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 creëren van iets dat nog niet bestaat en het vermogen om het voor je te zien ontzettend leuk is, kan het ook bijzonder frustrerend zijn. Producten voor onbenutte marktruimtes zijn moeilijk nauwkeurig onder woorden te brengen en soms vraag je je af: “kan ik hiermee doorgaan?” omdat het zo ontzettend moeilijk is. Het is als ondernemer het moeilijkste soort probleem om op te lossen. 

We gingen naar Google, Meta en bedrijven met ontwikkeltools van topniveau, en zij hadden niets dat leek op wat wij aan het creëren waren. We bevestigden 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 samenwerk met een team dat technisch zeer uitdagende producten met grote diepgang kan bouwen.

Het is opwindend en beangstigend om een kans te zien die anderen niet zien. Wanneer je een beetje vaart begint te krijgen en ziet dat het bij mensen begint te landen en dat zij verder uitdragen wat je hebt gebouwd, besef je waarom je het hebt gedaan. Je hoort hoe blij de gebruiker is. Dan wil je nog verder gaan en hen nog meer verrassen.

We zouden graag wat meer over jullie bedrijf te weten komen. Welk pijnpunt helpt jullie bedrijf op te lossen? Hoe helpt jullie bedrijf mensen? 

AppMap biedt het allereerste platform voor observeerbaarheid voor ontwikkelaars, dat dynamische softwareanalyse, waaronder prestatie- en beveiligingsanalyse, rechtstreeks in de code-editor aan ontwikkelaars levert. 

Tot nu toe was dit een enorme leemte in de markt, omdat ontwikkelaars en softwareteams gedwongen waren te vertrouwen op statische analysetools en complexe ontwerpproblemen in code niet konden identificeren of problemen van klanten konden oplossen voordat software werd uitgebracht. Dit leidde tot uren herwerk die creativiteit en innovatie afremden. Werk dat vooral uit sleur bestaat, is een van de belangrijkste oorzaken dat ontwikkelaars stilletjes ontslag nemen.

AppMap doorbreekt traditionele benaderingen van de ontwikkelaarservaring door de opensource-analysetool voor runtime-code rechtstreeks in de code-editor te integreren. Hierdoor kunnen gebruikers niet alleen het gedrag van code zien, maar ook eventuele voorgestelde wijzigingen in 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 te ontwikkelen?

Je moet absoluut empathie voor je gebruiker hebben. Als ontwikkelaarstool in de code-editor bevind je je in de meest intieme creatieve ruimte van je gebruiker. Je zit op hun desktop, 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 heel subtiele dans.

Het doel is iets te creëren waar mensen van houden en waar ze niet meer zonder willen werken. Dat is wat betreft productontwerp en ontwikkeling een bijzonder hoge drempel. Om ervoor te zorgen dat je de gebruiker altijd op de eerste plaats zet, moet je je gebruiker leren kennen en een gemeenschap en gesprekken rond verschillende 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 honderden landen. Hierdoor krijgen we de kans 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 zijn we begonnen met opensource als uitgangspunt, omdat iedereen die ons product kan lezen en begrijpen ons input en feedback kan geven. Door voor openheid te kiezen, 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 samengewerkt, waarom denk je dan dat het team zo goed samenwerkte, en kun je een anekdote noemen die deze 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 projecten in onbenutte marktruimtes uitgevoerd. 

Wat de meeste indruk op me maakt bij dit team, is dat we niet alleen goed samenwerken, maar dat ook doen wanneer we met tegenslag te maken krijgen. We duiken in de problemen en werken eraan om ze aan te pakken – we omarmen feedback, ongeacht wie er in de ruimte is.  Zo werken we allemaal samen.

Als team komen we regelmatig samen om overeenstemming te creëren. 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 heel goed.

Als je maar één softwaretool in je arsenaal mocht hebben, welke zou dat dan zijn, waarom, en welke andere tools beschouw je als essentieel voor de missie?

Ik denk dat code-editors, zoals VS Code en JetBrains, echt fenomenale plekken zijn om werk te doen. We beschouwen deze niet alleen als een plek waarvan we onszelf als leden van het ecosysteem zien, maar je ziet ook dat 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 vullen zoals je wilt en je door de dag te laten meeslepen door inertie. Mijn dagen zijn productiever wanneer ik tijd inplan om me te concentreren en belangrijke zaken gedaan te krijgen.

Laten we het hebben over rusttijd. Wat is jouw vaste gewoonte of ritueel om een burn-out te voorkomen?

Mijn kinderen zijn waarschijnlijk het beste tegengif 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. 

Op basis van je ervaring: wat zijn jouw “5 stappen die nodig zijn om geweldige technologieproducten te creëren”?

1. Bepaal je standpunt en durf anders te zijn: breng het vervolgens op de markt en kijk of het aanslaat. Bij AppMap geloven we dat de code-editor de enige bron van waarheid is en dat je alle tools die je nodig hebt precies daar moet hebben waar je je werk doet. Gebruik van daaruit zowel de kwantitatieve als kwalitatieve feedback 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 los te laten die niet worden gebruikt. 

2. Duik er meteen in: en kom zo dicht mogelijk bij de gebruiker. Sta open om van je team en klanten te leren en leg contacten om feedback uit de markt te krijgen. Een tactiek die AppMap toepast, is uitgebreid bloggen over inhoud op handleidingniveau op onze pagina van de ontwikkelaarscommunity. Dit helpt ons te begrijpen in welke gebieden we meer moeten investeren wanneer we een hoge mate van 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 het investeringsniveau 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 je ervan bewust te zijn dat je geen loze softwarebeloften doet en geen fabriek bent die lukraak functies uitbrengt. Streef bij vroege productreleases naar een goede middenweg tussen volledigheid van gedachten en ruimte voor verbetering. De realiteit is dat als je product een kleine gebruikssituatie oplost, mensen het zullen gebruiken om hun problemen op te lossen, ondanks een omslachtige gebruikerservaring of kleine fouten. 

4. Breng het uit en meet, meet, meet: Verwacht niet dat gebruikers je bergen kwalitatieve feedback 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 feedback te geven. De beste manier om je gebruikers te begrijpen, is hun interacties met je product te meten, als dat mogelijk is. 

Als je gebruik hoog genoeg is, probeer dan snel te itereren op basis van de gegevens die je ontvangt, en als je een groot gebruikersbestand hebt, segmenteer het 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 ontwikkel: Focus is de belangrijkste eigenschap van elk bedrijf, en van start-ups in het bijzonder. Start-ups hebben eenvoudigweg niet de tijd of het geld om in meerdere gebieden te investeren. Besteed geen tijd aan zorgen over de gemiste kans van het niet werken aan “alles”. Richt je in plaats daarvan op de zaken 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 feedback van gebruikers of gebruiksgegevens en je product voortdurend ontwikkelen om je gebruikers tevreden te stellen.  

Ben je momenteel tevreden met de huidige situatie rond vrouwen in de technologiesector? Welke specifieke veranderingen zijn volgens jou nodig om de huidige situatie 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-ondernemingssector vormen nog steeds slechts 2% van de door durfkapitaal gefinancierde bedrijven. Er zijn vrouwen in deze sector met enorm veel talent, maar die nog geen steun hebben gekregen. Dit ligt mij na aan het hart. 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 tot waardering en het aandeel dat vrouwen hebben in de investeringskoek. Ik denk dat mensen op de lange termijn beter naar door vrouwen opgerichte B2B-bedrijven zouden moeten kijken.  Ze leveren de beste waarde, dollar voor dollar. 

Ik vraag me af of er iemand ter wereld is met wie je graag privé zou willen ontbijten of lunchen, en waarom?

Ik bewonder Diane Greene en haar carrièreverloop 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 op de nieuwsbrief van The CPO Club voor meer inhoud zoals deze.