Attualmente, solo circa 1 dipendente su 4 nel settore tecnologico si identifica come donna. Quindi, cosa serve per costruire una carriera di successo come donna nella tecnologia? In questa serie di interviste intitolata Donne nella Tecnologia, abbiamo parlato con leader di successo nel settore tecnologico per condividere storie e intuizioni su ciò che hanno fatto per intraprendere carriere fiorenti. Discutiamo anche i passi necessari per creare un ottimo prodotto tecnologico. Come parte di questa serie, ho avuto il piacere di intervistare Samantha Carow.
Grazie mille per averci raggiunto in questa serie di interviste! Prima di iniziare, i nostri lettori sarebbero felici di conoscerti meglio. Puoi raccontarci una storia su cosa ti ha portato a intraprendere proprio questo percorso professionale?
Ho iniziato la mia carriera come venditrice di assicurazioni sulla vita. Era praticamente il primo lavoro che sono riuscita a trovare dopo l’università, ma ho capito rapidamente quanto fosse dura come carriera, e dopo 9 mesi mi sono licenziata. Ero molto imbarazzata di aver "fallito" nel mio lavoro aziendale. Ho trovato un impiego come cameriera per poter pagare l’affitto e ho iniziato a cercare nuove possibilità lavorative.
Mentre cercavo di farmi un’idea e trovare un piano, un mio amico mi parlò di un programma chiamato Dev Bootcamp; i bootcamp erano un concetto totalmente nuovo all’epoca. Nel giro di poco, mi sono ritrovata a San Francisco in un minuscolo ostello per seguire il programma di 3 mesi. Ho pianto ogni giorno per quanto fosse difficile, ma ho imparato molto.
Prima del bootcamp, non avevo mai nemmeno considerato che il settore tech potesse essere un mondo di cui fare parte. Anzi, non avevo mai sentito parlare di molti concetti dell’industria tecnologica. Ad esempio, cos’è un product manager? Qual è la differenza tra un sito web statico e una web app? Cos’è una startup? Cosa significa raccogliere fondi? Cos’è un API? Letteralmente, non sapevo nulla. Questo mi faceva sentire ancor più persa.
Mi sono diplomata per il rotto della cuffia e ho iniziato a cercare lavoro. Il mio curriculum era questo: 9 mesi di esperienza nelle vendite, 1 anno come cameriera, e basta. Sapevo che non avrei trovato un lavoro grazie al mio percorso precedente, quindi dovevo pensare a un approccio più "di fortuna." Il mio unico vero punto di forza era che mi sentivo immune al rifiuto — dopo i continui rifiuti ricevuti vendendo assicurazioni sulla vita, un po’ d’imbarazzo non mi spaventava più. Ho iniziato a spulciare le landing page delle startup cercando piccoli bug di implementazione. Una volta trovato il bug, cercavo di indovinare l’indirizzo email del fondatore (di solito firstname@startupname.io, all’epoca), e gli inviavo un’email a freddo con la mia soluzione proposta. Miracolosamente, questo metodo ha funzionato, e sono riuscita a trovare lavoro entro un mese.
Ho trascorso 2 anni e mezzo in quella startup, e ricordo ancora con affetto quel periodo. All’epoca mi sentivo un disastro ambulante, ma il dubbio, la fatica, la solidarietà, il mentorship e le amicizie vissute in quegli anni hanno posto le basi di ciò che sono oggi. Ho ricevuto tanto supporto, autonomia e fiducia. Ho scoperto che l’ingegneria non è una cosa in cui o sei portato o non lo sei—è una competenza che viene affinata anno dopo anno, attraverso tentativi, errori e sbagli. Il più grande segreto di tutti è che nessuno sa davvero cosa sta facendo. È stato un enorme sollievo arrivare a questa conclusione.
Quella startup è stata poi acquisita da Spotify.
Ci puoi raccontare un episodio che rappresenta l'errore più divertente che hai fatto all’inizio? Che lezione ne hai tratto?
Oh mio dio—ho fatto tantissimi errori! Il primo che mi viene in mente è durante i miei 5 anni a Reddit. Nei primi tre mesi sono diventata un po’ troppo sicura di me e ho deciso di lanciare una modifica al codice direttamente dall’aeroporto, mentre aspettavo il volo. Ovviamente, il sito è subito andato down. Ho dovuto capire come fare il rollback del mio codice, cosa che non avevo mai fatto prima, usando l’hotspot del telefono e assistendo—non esagero—a migliaia di errori che invadono i nostri log. Quella è stata la prima e ultima volta in cui ho gestito un rilascio di codice con così tanta leggerezza.
Mi sono sentita a dir poco mortificata, ma sono rimasta sorpresa dal fatto che non sono stata rimproverata. Anzi, far crashare il sito era una sorta di "rito di iniziazione" a Reddit. Questa esperienza ha influenzato la mia visione degli errori—succedono, e bisogna aspettarseli. E quando si verifica un errore, il tuo ruolo di leader è supportare il tuo team attraverso quell’errore. Una volta superata la crisi, allora si implementano processi per prevenire problemi simili in futuro.
Qual è stato, secondo te, il momento che ha definito la tua carriera?
Ogni fase della mia carriera è stata formativa a modo suo. Certamente il ruolo attuale di co-fondatrice e CTO mi ha aperto opportunità che non sapevo nemmeno esistessero. Tuttavia, credo che non avrei mai avuto la sicurezza di fondare una startup, se prima non avessi passato anni a crescere come Engineering Manager a Reddit.
Ho lavorato per 5 anni in Reddit, metà dei quali come ingegnere. Ricordo di essermi sentita frustrata perché la mia carriera non cresceva velocemente come avrei voluto. Fino a quel momento la mia mentalità era stata "se fai un buon lavoro, verrai notato" e "spetta al mio manager promuovermi". Non capivo quanta autonomia avessi realmente per accelerare la mia carriera. Mi sono imbattuta quasi per caso in una crescita incredibilmente rapida—ho scoperto una perdita di memoria nella nostra applicazione front-end. L'ho risolta, e siamo riusciti a dimezzare il nostro pool di server. Improvvisamente ho iniziato a ricevere attenzione per il mio lavoro, quindi mi sono chiesta—esiste un modo per riprodurre questa "fortuna"? In realtà sì. Ho sviluppato il seguente framework per permettere anche ad altri di riprodurre i miei risultati:
Il framework è il seguente:
- Individua un punto dolente per l’organizzazione nel suo complesso.
- Trova una Soluzione Minima di Valore.
- Parlane.
- Crea un framework che consenta ad altri di partecipare e aiutare.
Dopo aver applicato questo framework su me stessa, sono stata invitata a riunioni importanti. Sono stata inserita nella fascia “Top Performer”; sono diventata una tech lead; poi responsabile di un team, poi di due. Forse la cosa più importante: il mio stipendio è aumentato del 30%.
Ho avuto così tanto successo con questa formula che ho avviato un programma in Reddit specificamente pensato per insegnarla agli altri. Il mio programma ha visto la partecipazione di 30 persone in un anno, il 70% delle quali è riuscito a sfruttare il programma per una promozione o un aumento.
Ho scritto nel dettaglio del mio framework qui, se questo concetto ti incuriosisce!
Puoi raccontarci un episodio difficile che hai affrontato quando hai iniziato il tuo percorso? Hai mai pensato di mollare? Da dove hai trovato la forza di andare avanti anche nei momenti più duri?
Mentre mi preparavo per il bootcamp di coding, alcune persone mi hanno letteralmente riso in faccia quando ho detto cosa stavo facendo. “Tu?? Un’ingegnere?” era una risposta molto, molto frequente. Tuttavia, sono cresciuta con un sacco di tenacia. Ogni reazione negativa mi faceva solo insistere ancora di più—volevo dimostrare a tutti loro che si sbagliavano. Mi piace chiamarlo “sviluppo guidato dal dispetto”. Ah!
Oltre alla forza di volontà innata, è stato fondamentale circondarmi di persone che stavano facendo il mio stesso percorso. È una delle cose migliori di un bootcamp—sei circondato da persone che stanno tutte fallendo insieme. Rende i fallimenti più facili da digerire e ti ricorda che non sei solo.
Infine, avevo scommesso molto su me stessa decidendo di frequentare il bootcamp (al costo di $10.000). Non avevo intenzione di buttare quei soldi per paura. Scommettere su se stessi—che sia a livello finanziario, sociale, o altro—ti costringe a superare i dubbi perché è l’unico modo per andare avanti.
Ci piacerebbe conoscere un po’ la tua azienda. Qual è il problema che la tua azienda aiuta a risolvere? In che modo la tua azienda aiuta le persone?
DwellWell esiste perché comprare casa è un’esperienza terribile! Gli acquirenti vengono trascinati attraverso un processo opaco, poco chiaro e confuso, da una serie di fornitori che potrebbero parlare una lingua diversa. Mutui, pre-approvazioni, deposito a garanzia, caparra—ahh! È davvero troppo. DwellWell istruisce gli acquirenti su ciò che devono sapere prima di iniziare la ricerca e li supporta durante tutto il percorso di acquisto. Spieghiamo tutte le cose complesse e offriamo un punto di riferimento personalizzato unico per l’acquisto di casa. In base alle tue esigenze e preferenze, possiamo metterti in contatto con i migliori esperti immobiliari della tua zona e toglierti l’angoscia dall’esperienza.
Se qualcuno vuole guidare una grande azienda e creare prodotti eccellenti, qual è la qualità più importante che dovrebbe avere e quale abitudine o comportamento suggeriresti per sviluppare quella qualità?
Bisogna accettare il fatto che sentirai dolore per almeno i prossimi 5 anni. Costruire prodotti complessi, ricevere feedback sgradevoli, scartare quello che non funziona, essere rigettato dai VC, dare cattive notizie, crescere come leader—è tutto doloroso! Ne vale la pena? Sì. Significa che è facile? No!
Per sopravvivere bisogna liberarsi dell’ego. Impara a ricevere feedback senza prenderli sul personale. Considera ogni decisione come un esperimento e non rimanere emotivamente legato al risultato—guarda i dati. Non prenderti così sul serio da perdere la capacità di trovare l’umorismo nei tuoi fallimenti.
Parliamo adesso di team. Qual è una strategia o un framework di gestione del team che hai trovato particolarmente utile nello sviluppo di prodotti?
Adoro un team verticale e agile. La mia struttura di team ideale prevede un paio di ingegneri, un designer, un PM e magari un engineering manager. Il PM è responsabile dello sviluppo dei nuovi prodotti, dell’evoluzione di quelli esistenti e della definizione delle priorità. I framework di prioritizzazione sono fondamentali per questo. In DwellWell, il nostro framework di prioritizzazione è così strutturato:
- Impatto finanziario
- Impatto
- Portata
- Urgenza
- Facilità
Ognuno di questi fattori ha un peso specifico. Quando vengono proposti nuovi progetti, utilizziamo questo framework per inserirli nel piano di lavoro. Così siamo sicuri di lavorare sempre sulla cosa più importante.
Il nostro designer e il nostro project manager collaborano per sviluppare una specifica di prodotto insieme a dei wireframe di base. Una volta consegnati questi due elementi, i nostri ingegneri prendono in mano il progetto: lo suddividono in fasi, sviluppano una timeline e gestiscono in autonomia i propri ticket e scadenze. Manteniamo una comunicazione molto stretta per poterci muovere rapidamente. Mentre si sviluppa l’architettura di base, il nostro designer realizza i design definitivi e i nostri ingegneri completano il progetto aggiungendo questi miglioramenti visivi.
Questo processo ci permette di muoverci velocemente e di avere meno colli di bottiglia.
Quando pensi al team più forte con cui tu abbia mai lavorato, perché credi che funzionasse così bene? Ricordi un aneddoto che ne illustra la dinamica?
Il team di ingegneri che abbiamo costruito in DwellWell è davvero forte (senza contare che è composto al 75% da donne!). Lavoriamo bene insieme perché ci fidiamo l’uno dell’altro. Siamo esigenti nelle revisioni del codice. Ci poniamo standard molto alti, non c’è spazio per l’ego, e interveniamo subito se qualcosa va storto. Alimentiamo una cultura dell’apprendimento continuo.
Recentemente abbiamo lanciato un restyling del prodotto, un progetto enorme. Il lavoro è stato suddiviso tra gli ingegneri, ognuno di noi si confrontava spesso per assicurarci di non duplicare gli sforzi e sincronizzare le nostre attività affinché la consegna fosse la più efficiente possibile. Era come assistere a un’orchestra, con la mia ingegnera principale nel ruolo di direttrice. Uno spettacolo! Raggiungemmo la scadenza ambiziosa con tale fluidità da insospettirmi—raramente le cose procedono così lisce. Ma un team piccolo e dedicato può ottenere risultati eccezionali.
Se potessi avere solo uno strumento software nella tua "cassetta degli attrezzi", quale sarebbe e perché? Quali altri strumenti (software o oggetti concreti) ritieni fondamentali per la missione?
Come ingegnere, devo dire che il nostro strumento più importante è GitHub. È una risposta banale, ma spesso il software più fondamentale è anche il più noioso—affidabile, semplice e noioso. Il controllo di versione è imprescindibile per costruire una squadra di ingegneri di successo.
Parliamo di downtime. Qual è la tua pratica o rituale preferito per prevenire il burnout?
Sfortunatamente l’attività fisica è veramente il modo migliore per schiarirsi le idee. Odio allenarmi, ma poi ci si sente meglio—non c’è via di scampo. Prendo anche Lexapro, che mi aiuta molto con l’ansia. La mia ansia si manifesta come estrema irritabilità, che è un’emozione assolutamente inutile quando si gestisce una startup. Mi permette di essere una compagna di squadra migliore, invece di un’avversaria.
In base alla tua esperienza, quali sono i “5 Passi per Creare Grandi Prodotti Tech”?
1 . La prima cosa che costruisci probabilmente sarà pessima—lanciala comunque. Come ha detto Reid Hoffman—“Se non provi imbarazzo per la prima versione del tuo prodotto, sei uscito troppo tardi.” La prima versione che rilasci dovrebbe darti un segnale—sei sulla strada giusta? Gli utenti si interessano al problema che stai risolvendo? Non sprecare tempo prezioso alla ricerca della perfezione quando sei in cerca di validazione iniziale. Il primo prodotto che abbiamo creato in DwellWell era un semplice PDF intitolato “10 passi per comprare casa”, in cui un utente doveva prendere l’iniziativa e scrivermi una mail se voleva essere messo in contatto con uno dei nostri agenti immobiliari consigliati. Nei primi due giorni dal lancio abbiamo avuto già il nostro primo cliente. È stato pazzesco—non potevo credere che qualcosa a cui avevamo lavorato solo due settimane avesse portato a un vero utente. Abbiamo soprannominato con affetto questo prodotto il nostro “MVP schifoso” e ci ha dato lo slancio per raccogliere capitali.
2 . Guarda gli utenti mentre interagiscono con il tuo prodotto. Ti sorprenderà scoprire come le persone lo usano davvero, rispetto a come te lo immaginavi. Ricordo quando abbiamo iniziato DwellWell: c’era un pulsante che l’utente doveva cliccare per passare da ‘completato’ a ‘incompleto’ una volta terminata una task. Era l’azione principale che si doveva svolgere sulla pagina. Lo abbiamo creato pensando “bello, intuitivo, funzionale”. Ebbene, ti dico subito: gli utenti non avevano la minima idea di cosa dovesse fare quel pulsante. Abbiamo organizzato più di 10 ore di interviste agli utenti e tutti, nessuno escluso, dicevano “questo bottone mi confonde”. Lo abbiamo eliminato e non ci siamo più guardati indietro.
3 . Muoviti velocemente quando una decisione si può cambiare, più lentamente quando è irreversibile. La velocità nelle startup è vitale. Non bisogna tormentarsi per ogni scelta, ma può essere difficile capire quali decisioni meritino di essere ponderate più a lungo. In realtà sono poche le decisioni davvero irreversibili, quindi di solito mi muovo rapidamente. Tuttavia, con il recente restyling di DwellWell, abbiamo dedicato due mesi a riflettere su alcune decisioni per garantire che il prodotto risultasse più intuitivo. Stavamo abbandonando del tutto la vecchia architettura, quindi era importante procedere con cautela verso il futuro.
4 . Promuovi una cultura del miglioramento continuo. È molto facile cadere nella tentazione di rilasciare una funzionalità, segnarla come fatta e non intervenire più su di essa. Questo però crea prodotti stagnanti e dà un brutto segnale a chi lavora in prodotto e ingegneria. Ogni membro del team dovrebbe cercare modi per migliorare costantemente il prodotto esistente o proporre esperimenti che possano migliorarne i parametri chiave. Di recente abbiamo sperimentato, in DwellWell, diverse esperienze di registrazione per capire quale fosse la più intuitiva. Non cambiavamo il nostro flusso di iscrizione da un anno e abbiamo scoperto che il gruppo di controllo (il flusso classico) era quello con le performance peggiori rispetto alle altre tre varianti! Ora abbiamo sviluppato una matrice di priorità per gli esperimenti e mettiamo regolarmente in discussione il prodotto esistente.
5 . Un utente frustrato è meglio di un utente disinteressato. Un utente frustrato è una persona che tiene al tuo prodotto o al problema che la tua azienda cerca di risolvere. Può fare paura interagire con chi ha avuto un’esperienza negativa, ma è infinitamente più utile di chi abbandona subito il servizio. Ho imparato questa lezione su Reddit, che probabilmente ha la community di utenti più appassionata al mondo. Gli utenti frustrati ci hanno fornito tantissime idee su come migliorare e su dove la piattaforma non rispondeva ai loro bisogni. È una delle lezioni più importanti che abbia mai imparato.
Sei attualmente soddisfatta dello status quo riguardo le donne nel settore tecnologico? Quali cambiamenti specifici pensi siano necessari per cambiare lo status quo?
No—decisamente non sono soddisfatta. Questa è una domanda molto complessa perché le disparità di genere nella tecnologia sono perpetuate da tutti—anche da chi cerca di aiutare. Una delle cose migliori che possiamo fare come leader è formare le donne nei ruoli senior con la stessa energia con cui formiamo gli uomini per ruoli senior. Spesso vedo aziende che assumono molte donne junior solo per migliorare le metriche di assunzione. Ma questo perpetua semplicemente l’idea sbagliata che le dipendenti donne siano tipicamente più junior rispetto agli uomini. È quasi un circolo vizioso, però: perché per diventare senior, le donne devono pur iniziare da qualche parte! Penso che, se assumi donne junior, devi necessariamente promuoverle allo stesso ritmo con cui promuoviamo gli uomini. Allena le tue collaboratrici, dai loro feedback critici per aiutarle a crescere, lavora insieme a loro su un percorso di promozione e permetti che commettano errori.
C’è una persona al mondo con cui ti piacerebbe fare una colazione o un pranzo privato, e perché?
Justin Bieber? Scherzo (in parte). Adoro il podcast di Guy Raz, How I Built This, e mi piacerebbe davvero conoscerlo. Le sue interviste sono totalmente coinvolgenti.
Per altri contenuti come questo, iscriviti alla newsletter di The CPO Club.
