Vrouwen in de tech: Sam Carow van DwellWell over de 5 stappen die nodig zijn om geweldige techproducten te creëren

Terwijl ik maar wat aanmodderde en een plan probeerde te bedenken, vertelde een vriend me over een programma genaamd Dev Bootcamp; bootcamps waren toen een volledig nieuw concept. Voor ik het wist, zat ik in San Francisco in een piepklein hostel voor het programma van 3 maanden. Ik huilde elke dag omdat het zo zwaar was en heb er veel geleerd.

Vóór de bootcamp had ik er nooit aan gedacht dat de techindustrie iets was waar ik deel van kon uitmaken. Bovendien had ik nog nooit gehoord van veel concepten uit de techindustrie. Wat is bijvoorbeeld een productmanager? Wat is het verschil tussen een statische website en een webapp? Wat is een startup? Wat betekent fondsenwerving? Wat is een API? Letterlijk, ik wist niets. Daardoor voelde ik me nog meer verloren.

Ik studeerde met de hakken over de sloot af en begon aan mijn zoektocht naar een baan. Mijn cv zag er als volgt uit: 9 maanden verkoopervaring, 1 jaar ervaring als serveerster en verder niets. Ik wist dat ik geen baan zou krijgen op basis van mijn cv, dus moest ik een inventievere aanpak bedenken. Mijn enige redding was dat ik me immuun voelde voor afwijzing -- ik was dag na dag afgewezen bij de verkoop van levensverzekeringen, dus een beetje schaamte joeg me geen angst aan. Ik begon de landingspagina’s van startups nauwkeurig te doorzoeken, op zoek naar kleine implementatiefouten. Zodra ik de fout had gevonden, gokte ik het e-mailadres van de oprichter (meestal firstname@startupname.io in die tijd) en stuurde ik diegene een ongevraagde e-mail met mijn voorgestelde oplossing. Wonder boven wonder werkte deze aanpak en had ik binnen een maand een baan.

Ik heb 2,5 jaar bij deze startup gewerkt en kijk met veel genegenheid terug op die periode. Destijds voelde ik me als een wandelende ramp, maar de twijfel, ontberingen, kameraadschap, begeleiding en vriendschap die ik in die jaren heb ervaren, vormden de basis voor wie ik vandaag ben. Ik kreeg buitengewoon veel begeleiding, autonomie en vertrouwen. Ik ontdekte dat softwareontwikkeling geen kwestie van wel of niet kunnen is—het is een vaardigheid die je in de loop van vele jaren aanscherpt, door te proberen, fouten te maken en daarvan te leren. Het grootste geheim is dat eigenlijk niemand echt weet wat die aan het doen is. Het was zo’n opluchting om tot die conclusie te komen.

Die startup werd later overgenomen door Spotify.

Kun je vertellen over de grappigste fout die je maakte toen je net begon? Kun je ons vertellen welke les je daaruit hebt geleerd?

O mijn god—zoveel fouten! De eerste die bij me opkomt, maakte ik tijdens mijn 5 jaar bij Reddit. In mijn eerste drie maanden werd ik iets te overmoedig over het implementeren van code en besloot ik mijn wijzigingen uit te rollen op het vliegveld terwijl ik op mijn vlucht wachtte. Natuurlijk crashte de site onmiddellijk. Ik moest uitzoeken hoe ik mijn code kon terugdraaien, wat ik nog nooit eerder had gedaan, via de hotspot van mijn telefoon, terwijl ik—ik overdrijf niet—duizenden fouten onze logboeken zag binnenstromen. Dat was de eerste en laatste keer dat ik het implementeren van code zo onzorgvuldig behandelde.

Ik schaamde me kapot voor deze fout, maar was verbaasd dat ik niet berispt werd. Sterker nog, de site laten crashen was bij Reddit een soort ‘initiatie­ritueel’. Deze ervaring heeft de manier gevormd waarop ik nu naar fouten kijk—ze gebeuren. Sterker nog, je moet ze verwachten. En wanneer er een fout optreedt, is het jouw rol als leider om je team door die fout heen te helpen. Zodra de crisis voorbij is, implementeer je processen om soortgelijke fouten in de toekomst te voorkomen.

Wat beschouw je als je ‘carrièrebepalende’ moment?

Elke fase van mijn carrière is op de een of andere manier bepalend geweest. Zeker mijn huidige rol als medeoprichter en CTO heeft deuren geopend waarvan ik niet eens wist dat ze bestonden. Toch denk ik niet dat ik het vertrouwen zou hebben gehad om een startup op te richten als ik niet jarenlang was gegroeid naar de rol van engineeringmanager bij Reddit.

Ik heb 5 jaar bij Reddit gewerkt, waarvan de helft als softwareontwikkelaar. Ik herinner me dat ik gefrustreerd was omdat mijn carrière niet zo snel groeide als ik wilde. Tot dat moment was mijn instelling geweest: “als je goed werk levert, word je opgemerkt” en “het is de taak van mijn manager om mij promotie te geven”. Ik begreep niet hoeveel invloed ik zelf daadwerkelijk had om mijn carrière te versnellen. Bijna per ongeluk maakte ik een enorm versnelde groei door: ik ontdekte een geheugenlek in onze front-endapplicatie. Ik loste het op, waardoor we onze serverpool konden halveren. Plotseling kreeg ik aandacht voor mijn werk, dus vroeg ik me af: is er een manier waarop ik dit “geluk” kan reproduceren? Het blijkt van wel. Ik ontwikkelde het volgende raamwerk om anderen in staat te stellen mijn resultaten te reproduceren:

Het raamwerk is als volgt:

1. Identificeer een pijnpunt voor je organisatie als geheel.
2. Vind een minimaal waardevolle oplossing.
3. Praat erover.
4. Creëer een raamwerk waarmee anderen kunnen instappen en helpen.

Nadat ik dit raamwerk voor mezelf had geïmplementeerd, werd ik uitgenodigd voor nieuwe belangrijke vergaderingen. Ik werd ingedeeld in de categorie “Toppresteerders”; ik werd technisch leider; vervolgens manager van één team en daarna van twee. Misschien wel het belangrijkste: mijn salaris steeg met 30%.

Ik had zoveel succes met deze formule dat ik bij Reddit een programma startte dat specifiek gericht was op het aanleren van deze formule aan anderen. Gedurende een jaar namen 30 deelnemers deel aan mijn programma, van wie 70% het programma kon benutten voor een promotie of salarisverhoging.

Ik heb hier uitgebreid over mijn raamwerk geschreven, als dit concept je interesseert!

Kun je ons een verhaal vertellen over de moeilijke tijden die je meemaakte 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 dingen zo moeilijk?

Toen ik me voorbereidde op mijn programmeerbootcamp, lachten sommige mensen me letterlijk uit toen ik vertelde wat ik ging doen. “Jij?? Een softwareontwikkelaar?” was een heel, heel gebruikelijke reactie. Ik ben echter opgevoed met ontzettend veel doorzettingsvermogen. Elke negatieve reactie zorgde er alleen maar voor dat ik vastberadener werd—ik zou al deze mensen het tegendeel bewijzen. Ik noem het graag “door wrok gedreven ontwikkeling”. Ha!

Naast aangeboren doorzettingsvermogen was het ontzettend belangrijk om mezelf te omringen met mensen die hetzelfde deden als ik. Dat is een van de beste dingen aan een bootcamp: je wordt omringd door mensen die allemaal samen falen. Dat maakt de mislukkingen gemakkelijker te verdragen en herinnert je eraan dat je er niet alleen voor staat.

Tot slot had ik een grote gok op mezelf genomen door aan de bootcamp deel te nemen (ter waarde van $10,000). Ik zou dat geld niet door angst door de gootsteen spoelen. Op jezelf wedden—of het nu financieel, sociaal of wat dan ook is—dwingt je om door twijfel heen te breken, omdat het de enige weg vooruit is.

We zouden graag wat meer over je bedrijf leren. Wat is het pijnpunt dat je bedrijf helpt aanpakken? Hoe helpt je bedrijf mensen?

DwellWell bestaat omdat een huis kopen vreselijk is! Huizenkopers worden door een ondoorzichtig proces gesleept, onwetend en verward, door allerlei dienstverleners die net zo goed een andere taal kunnen spreken. Hypotheken, voorlopige goedkeuringen, derdenrekeningen, waarborgsommen—ahh! Het is allemaal te veel. DwellWell informeert huizenkopers over wat ze moeten weten voordat ze aan hun zoektocht naar een huis beginnen en begeleidt hen tijdens hun hele aankooptraject. We leggen alle moeilijke zaken uit en bieden je een gepersonaliseerde alles-in-éénoplossing voor het kopen van een huis. Op basis van je behoeften en voorkeuren kunnen we je in contact brengen met de beste experts op het gebied van huizen kopen in jouw omgeving en de ellende uit je ervaring wegnemen.

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 accepteren dat je de komende 5 jaar, minimaal, pijn zult lijden. Gecompliceerde producten bouwen, harde feedback vragen, dingen schrappen die niet werken, afgewezen worden door VC’s, moeilijk nieuws brengen en uitgroeien tot de leider die je bent—het is allemaal pijnlijk! Is het de moeite waard? Ja. Betekent dat dat het makkelijk is? Nee!

Om te overleven, moet je je ego loslaten. Oefen met het ontvangen van feedback zonder het persoonlijk op te vatten. Behandel elke beslissing als een experiment en raak niet emotioneel geïnvesteerd in de uitkomst—kijk in plaats daarvan naar de gegevens. Neem jezelf niet zo serieus dat je de humor in je mislukkingen niet meer kunt zien.

Laten we het nu over teams hebben. Welke strategie of welk raamwerk voor teammanagement heb je gevonden dat uitzonderlijk nuttig is voor het productontwikkelingsproces?

Ik houd van een pragmatisch, verticaal team. Mijn ideale teamstructuur bestaat uit een paar ontwikkelaars, één ontwerper, één PM en misschien een technisch manager. Je PM is verantwoordelijk voor het ontwikkelen van nieuwe producten, het doorontwikkelen van bestaande producten en het prioriteren van wat het belangrijkst is. Prioriteringsraamwerken zijn hiervoor geweldig. Bij DwellWell ziet ons prioriteringsraamwerk er als volgt uit:

1. Financieel
2. Impact
3. Bereik
4. Urgentie
5. Gemak

Elk van deze factoren krijgt een weging. Wanneer nieuwe projecten worden voorgesteld, gebruiken we dit raamwerk om het werk in te delen. Zo zorgen we ervoor dat we altijd aan het belangrijkste werken.

Onze ontwerper en projectmanager werken samen om een productspecificatie te ontwikkelen, samen met enkele eenvoudige wireframes. Zodra deze twee onderdelen zijn opgeleverd, nemen onze engineers het over: ze bepalen de omvang van het project, stellen een tijdlijn op en beheren hun eigen tickets en deadlines. We houden onze communicatie zeer strak, zodat we snel kunnen handelen. Terwijl de basisarchitectuur wordt ontwikkeld, werkt onze ontwerper de definitieve ontwerpen uit en ronden onze engineers het project af door deze visuele verbeteringen toe te voegen.

Dankzij dit proces kunnen we snel werken en hebben we minder knelpunten.

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 herinneren die de dynamiek illustreert?

Het engineeringteam dat we bij DwellWell hebben samengesteld is zo sterk (en dan heb ik het nog niet eens gehad over het feit dat 75% vrouw is!). We werken goed samen omdat we elkaar vertrouwen. We zijn kritisch bij codebeoordelingen. We stellen elkaar zeer hoge eisen, er is geen ruimte voor ego en we springen bij om te helpen wanneer er iets misgaat. We stimuleren een leercultuur.

Onlangs hebben we een herontwerp van een product gelanceerd, een gigantisch project. Het werk werd verdeeld over de engineers, waarbij ieder van ons regelmatig afstemde, ervoor zorgde dat we geen werk dubbel deden en ons werk synchroniseerde om het zo optimaal mogelijk op te leveren. Het was alsof je naar een orkest keek, met mijn lead-engineer als dirigent. Het was prachtig! We haalden de ambitieuze deadline zo moeiteloos dat ik argwanend werd—zo soepel verlopen dingen zelden. Maar een klein, toegewijd team kan buitenproportionele resultaten leveren.

Als je slechts één softwaretool in je arsenaal mocht hebben, welke zou dat dan zijn, waarom, en welke andere hulpmiddelen (software of tastbare zaken) beschouw je als bedrijfskritisch?

Als engineer zou ik moeten zeggen dat onze belangrijkste tool GitHub is. Dit is zo'n alledaags antwoord, maar vaak is de meest cruciale software totaal saai—betrouwbaar, eenvoudig en saai. Versiebeheer is niet onderhandelbaar bij het opbouwen van een succesvolle engineeringorganisatie.

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

Helaas is sporten echt de beste manier om je hoofd op orde te krijgen. Ik heb een hekel aan sporten, maar je voelt je er gewoon beter door—daar kom je niet omheen. Ik gebruik ook Lexapro, wat mijn angstklachten aanzienlijk helpt verminderen. Mijn angst uit zich als extreme prikkelbaarheid, en dat is een volkomen nutteloze emotie wanneer je een startup runt. Dankzij het medicijn kan ik een betere teamgenoot zijn in plaats van een tegenstander.

Welke “5 stappen die nodig zijn om geweldige technologieproducten te creëren” volgen volgens jou uit je ervaring?

1 . Het eerste wat je bouwt zal waarschijnlijk slecht zijn—lanceer het toch. Zoals Reid Hoffman zei—“Als je je niet schaamt voor de eerste versie van je product, heb je te laat gelanceerd.” Het eerste wat je uitbrengt moet je inzicht geven—zit je op het juiste spoor? Geven gebruikers om het probleem dat je oplost? Verspil geen kostbare tijd aan perfectie wanneer je op zoek bent naar vroege validatie. Het eerste product dat we bij DwellWell creëerden was een eenvoudige pdf met de titel “10 stappen voor het kopen van een huis”, waarbij een gebruiker zelf het initiatief moest nemen en mij moest e-mailen als diegene aan de slag wilde met een van onze aanbevolen makelaars. Binnen de eerste twee dagen na de lancering hadden we onze eerste klant. Het was krankzinnig—ik kon niet geloven dat iets waar we twee weken aan hadden gewerkt, een echte gebruiker had opgeleverd. We noemden dit product liefdevol onze “waardeloze MVP” en het gaf ons voldoende inzicht om kapitaal op te halen.

2 . Bekijk hoe gebruikers met je product omgaan. Het zal je verbazen hoe mensen je product gebruiken in vergelijking met hoe jij dacht dat ze het zouden gebruiken. Ik herinner me dat we toen we net met DwellWell begonnen een knop hadden waarop een gebruiker moest klikken om tussen ‘voltooid’ en ‘onvoltooid’ te schakelen wanneer diegene een taak had afgerond. Het was de belangrijkste actie die een gebruiker op de pagina moest uitvoeren. We bouwden de knop en dachten: “prachtig, schitterend, intuïtief”. Ik zal je zeggen hoe het zat—gebruikers hadden geen flauw idee wat deze knop moest doen. We hielden meer dan 10 uur aan gebruikersinterviews en iedereen zei: “Ik snap deze knop niet”. We haalden de knop eruit en keken nooit meer achterom.

3 . Handel snel wanneer een beslissing kan worden teruggedraaid en langzamer wanneer dat niet kan. Snelheid is alles bij startups. Je moet niet over elke beslissing eindeloos piekeren, maar het kan lastig zijn om te weten voor welke beslissingen je gas moet terugnemen. Het komt eigenlijk maar zelden voor dat je een onomkeerbare beslissing tegenkomt, dus meestal handel ik snel. Bij het recente herontwerp van DwellWell namen we echter gedurende twee maanden langzaam beslissingen om er zeker van te zijn dat we een intuïtiever product zouden opleveren. We zouden de oude architectuur volledig achter ons laten, dus het was belangrijk om zorgvuldig onze toekomst tegemoet te gaan.

4 . Stimuleer een cultuur van voortdurende verbetering. Het kan erg verleidelijk zijn om een functie te bouwen, haar als afgerond te beschouwen en er nooit meer aan te werken. Dit leidt tot stilstaande producten en geeft product- en engineeringteams bovendien een slecht voorbeeld. Elk teamlid moet actief zoeken naar manieren om bestaande producten voortdurend te verbeteren of experimenten voorstellen die de belangrijkste statistieken kunnen verhogen. Onlangs voerden we bij DwellWell een experiment uit om verschillende registratie-ervaringen te testen en te zien welke het meest intuïtief was. We hadden onze registratie-ervaring al een jaar niet aangepast en ontdekten dat onze controlegroep (onze normale registratiestroom) het slechtst presteerde van de drie varianten! Sindsdien hebben we een matrix voor het prioriteren van experimenten ontwikkeld en dagen we het bestaande product zo vaak mogelijk uit.

5 . Een gefrustreerde gebruiker is beter dan een afgehaakte gebruiker. Gefrustreerde gebruikers zijn mensen die om je product geven of om het probleem dat je bedrijf probeert op te lossen. Hoewel het eng kan zijn om contact te hebben met iemand die een slechte ervaring heeft gehad, zijn zulke gebruikers oneindig veel behulpzamer dan een gebruiker die niet betrokken is en afhaakt. Ik leerde deze les bij Reddit, dat mogelijk de meest gepassioneerde gebruikersgroep ter wereld heeft. Gefrustreerde gebruikers gaven ons zoveel ideeën over hoe we konden verbeteren en waar het platform niet aan hun behoeften voldeed. Het is een van de belangrijkste lessen die ik tot nu toe heb geleerd.

Ben je momenteel tevreden met de status quo met betrekking tot vrouwen in de techsector? Welke specifieke veranderingen zijn volgens jou nodig om de status quo te veranderen?

Nee—ik ben absoluut niet tevreden. Dit is zo’n ingewikkelde vraag, omdat de genderongelijkheid in de technologiesector door iedereen in stand wordt gehouden—zelfs door degenen die proberen te helpen. Een van de beste dingen die we als leiders kunnen doen, is vrouwen met dezelfde inzet opleiden voor hogere functies als waarmee we mannen voor hogere functies opleiden. Ik zie vaak dat bedrijven grote aantallen junior vrouwen aannemen, zodat hun wervingscijfers er goed uitzien. Maar daarmee wordt het onjuiste idee in stand gehouden dat vrouwelijke werknemers doorgaans een lagere functie hebben dan mannelijke werknemers. Het is echter bijna een paradox, want om senior te worden, moeten vrouwen ergens beginnen! Ik denk dat als je junior vrouwen aanneemt, je hen in hetzelfde tempo als mannen actief naar een hoger niveau moet brengen. Coach je vrouwelijke medewerkers, geef kritische feedback om hen te helpen groeien, werk samen aan een promotiepad en geef hen de ruimte om fouten te maken.

Is er iemand ter wereld met wie je graag privé zou willen ontbijten of lunchen, en waarom?

Justin Bieber? Grapje (min of meer). Ik ben dol op de podcast van Guy Raz, Hoe ik dit heb gebouwd, en zou hem heel graag willen ontmoeten. Zijn interviews zijn buitengewoon boeiend.

Wil je meer inhoud zoals deze lezen? Schrijf je dan in voor de nieuwsbrief van The CPO Club.