Atualmente, apenas cerca de 1 em cada 4 profissionais do setor tecnológico se identifica como mulher. Então, o que é necessário para construir uma carreira de sucesso enquanto mulher na área da tecnologia? Nesta série de entrevistas intitulada Mulheres na Tecnologia, falámos com líderes de sucesso do setor tecnológico para partilharem histórias e perspetivas sobre o que fizeram para desenvolver carreiras prósperas. Também abordamos os passos necessários para criar um excelente produto tecnológico. Como parte desta série, tive o prazer de entrevistar Samantha Carow.
Samantha Carow
Samantha Carow é cofundadora e CTO da DwellWell. Passou a maior parte da sua carreira em startups, desde a Preact (adquirida pelo Spotify em 2016) até à Reddit, e está agora a usar os seus conhecimentos de engenharia e a sua liderança para trazer a compra de casa para o século XXI com a DwellWell. A Sam é apaixonada por diversificar o ecossistema tecnológico e esforça-se por criar uma cultura de engenharia equitativa, empática e orientada para os resultados. É uma líder no espaço das mulheres na tecnologia e já discursou na Grace Hopper Celebration e na Women in Tech Summit.
Muito obrigada por se juntar a nós nesta série de entrevistas! Antes de começarmos, os nossos leitores gostariam de saber mais sobre si. Pode contar-nos uma história sobre o que a levou a seguir esta carreira específica?
Comecei a minha carreira como vendedora de seguros de vida. Foi praticamente o primeiro emprego que consegui depois de terminar a faculdade, mas percebi rapidamente como é exigente esta carreira e saí ao fim de 9 meses. Senti-me muito envergonhada por ter “falhado” no meu emprego numa empresa. Arranjei um trabalho como empregada de mesa para pagar a renda e comecei a pesquisar novas carreiras.
Enquanto avançava sem grande rumo, a tentar elaborar um plano, uma amiga falou-me de um programa chamado Dev Bootcamp; os bootcamps eram um conceito completamente novo naquela altura. Quando dei por mim, estava em São Francisco, num hostel minúsculo, para frequentar o programa de 3 meses. Chorei todos os dias por ser tão difícil e aprendi imenso.
Antes do bootcamp, nunca tinha sequer considerado que o setor tecnológico pudesse ser algo de que eu fizesse parte. Além disso, nunca tinha sequer ouvido falar de muitos conceitos do setor tecnológico. Por exemplo, o que faz um gestor de produto? Qual é a diferença entre um site estático e uma aplicação Web? O que é uma startup? O que significa angariar financiamento? O que é uma API? Literalmente, não sabia nada. Isso fez-me sentir ainda mais perdida.
Concluí o curso por muito pouco e comecei a procurar emprego. O meu currículo tinha este aspeto: 9 meses de experiência em vendas, 1 ano de experiência como empregada de mesa e nada mais. Sabia que não conseguiria um emprego com base no meu currículo, por isso tive de pensar numa abordagem mais engenhosa. A minha única grande vantagem era sentir-me imune à rejeição — tinha sido rejeitada dia após dia ao vender seguros de vida, por isso um pouco de embaraço não me assustava. Comecei a analisar minuciosamente as páginas de destino de startups, à procura de pequenos erros de implementação. Quando encontrava o erro, tentava adivinhar o endereço de e-mail do fundador (naquela altura, normalmente firstname@startupname.io) e enviava-lhe um e-mail não solicitado com a minha proposta de solução. Milagrosamente, esta abordagem resultou e consegui um emprego no espaço de um mês.
Passei 2,5 anos nessa startup e recordo esse período com muito carinho. Na altura, sentia-me um desastre ambulante, mas a dúvida, as dificuldades, a camaradagem, a mentoria e a amizade que vivi durante esses anos estabeleceram a base da pessoa que sou hoje. Recebi uma mentoria, autonomia e confiança extraordinárias. Descobri que a engenharia não é algo binário que se consegue ou não se consegue fazer — é uma competência que se aperfeiçoa ao longo de muitos anos, através de tentativa e erro e de falhas. O maior segredo de todos é que, na realidade, ninguém sabe verdadeiramente o que está a fazer. Foi um grande alívio chegar a esta conclusão.
Mais tarde, essa startup acabou por ser adquirida pelo Spotify.
Pode partilhar uma história sobre o erro mais engraçado que cometeu quando estava a começar? Pode dizer-nos que lição aprendeu com isso?
Meu Deus — tantos erros! O primeiro que me vem à cabeça aconteceu durante os meus 5 anos na Reddit. Nos meus primeiros três meses, fiquei um pouco demasiado convencida em relação à implementação de código e decidi disponibilizar as minhas alterações no aeroporto, enquanto esperava pelo meu voo. Claro que o site ficou imediatamente indisponível. Tive de descobrir como reverter o meu código, algo que nunca tinha feito antes, através do ponto de acesso do meu telemóvel, enquanto observava — não estou a exagerar — milhares de erros a inundarem os nossos registos. Foi a primeira e última vez que tratei uma implementação de código com tamanha leviandade.
Fiquei mortificada com este erro, mas surpreendeu-me não ter sido repreendida. Na verdade, fazer o site cair era uma espécie de “rito de passagem” na Reddit. Esta experiência moldou a forma como vejo os erros atualmente — eles acontecem. Na verdade, são esperados. E quando ocorre um erro, o seu papel enquanto líder é apoiar a sua equipa durante esse erro. Quando a crise terminar, deve então implementar processos para evitar erros semelhantes no futuro.
Qual considera ter sido o momento que “definiu a sua carreira”?
Cada etapa da minha carreira foi marcante de alguma forma. Certamente, o meu cargo atual, como cofundadora e CTO, abriu portas cuja existência eu nem sequer conhecia. No entanto, não creio que tivesse tido a confiança necessária para fundar uma startup se não tivesse passado anos a crescer profissionalmente até me tornar gestora de engenharia na Reddit.
Passei 5 anos no Reddit, metade dos quais como engenheiro. Lembro-me de me sentir frustrado por a minha carreira não estar a evoluir tão rapidamente quanto queria. Até esse momento, a minha mentalidade tinha sido “se fizeres um bom trabalho, serás reconhecido” e “é responsabilidade do meu gerente promover-me”. Não compreendia quanta autonomia tinha, na realidade, para acelerar a minha própria carreira. Deparei-me com um crescimento incrivelmente acelerado quase por acaso — descobri uma fuga de memória na nossa aplicação de front-end. Corrigi-a e conseguimos reduzir o nosso conjunto de servidores para metade. De repente, comecei a receber atenção pelo meu trabalho, por isso perguntei-me: haverá alguma forma de reproduzir esta “sorte”? Afinal, sim, há. Desenvolvi a seguinte estrutura para permitir que outras pessoas reproduzissem os meus resultados:
A estrutura é a seguinte:
- Identificar um problema que afete toda a organização.
- Encontrar uma solução mínima valiosa.
- Falar sobre isso.
- Criar uma estrutura que permita a outras pessoas participar e ajudar.
Depois de implementar esta estrutura para mim, fui convidado para novas reuniões importantes. Fui colocado no escalão dos “Melhores Desempenhos”; tornei-me líder técnico; depois, gerente de uma equipa e, posteriormente, de duas. Talvez o mais importante seja que o meu salário aumentou 30%.
Tive tanto sucesso com esta fórmula que criei um programa no Reddit especificamente destinado a ensinar esta fórmula a outras pessoas. O meu programa contou com 30 participantes ao longo de um ano, 70% dos quais conseguiram tirar partido do programa para obter uma promoção ou um aumento.
Escrevi em profundidade sobre a minha estrutura aqui, caso este conceito lhe interesse!
Pode contar-nos uma história sobre os momentos difíceis que enfrentou quando iniciou o seu percurso? Chegou a considerar desistir? Onde encontrou a motivação para continuar, apesar de as coisas serem tão difíceis?
Enquanto me preparava para o meu curso intensivo de programação, algumas pessoas chegaram literalmente a rir-se na minha cara quando lhes contei o que estava a fazer. “Tu? Um engenheiro?” era uma resposta muito, muito comum. No entanto, fui educado com uma enorme dose de determinação. Cada reação negativa só me fazia fincar ainda mais os pés no chão — eu ia provar que todas aquelas pessoas estavam erradas. Gosto de lhe chamar “desenvolvimento movido pelo despeito”. Ha!
Para além da determinação inata, foi extremamente importante rodear-me de pessoas que estavam a fazer o mesmo que eu. Esta é uma das melhores coisas de um curso intensivo — está rodeado de pessoas que estão todas a falhar em conjunto. Isso torna os fracassos mais fáceis de suportar e lembra-lhe que não está sozinho.
Por fim, apostei muito em mim próprio ao frequentar o curso intensivo (no valor de $10,000). Não ia deitar esse dinheiro fora por causa do medo. Apostar em si próprio — seja uma aposta financeira, social ou de qualquer outro tipo — obriga-o a ultrapassar as dúvidas, porque é a única forma de avançar.
Gostaríamos de saber um pouco mais sobre a sua empresa. Qual é o problema que a sua empresa procura resolver? Como é que a sua empresa ajuda as pessoas?
A DwellWell existe porque comprar uma casa é um pesadelo! Os compradores de casa são arrastados por um processo pouco transparente, sem informação e confusos, por um conjunto de fornecedores que poderiam perfeitamente falar outra língua. Hipotecas, pré-aprovações, contas de garantia, depósitos de sinal — ahh! É tudo demasiado. A DwellWell informa os compradores de casa sobre o que precisam de saber antes de iniciarem a procura de uma casa e apoia-os ao longo de todo o processo de compra. Explicamos todos os aspetos complicados e disponibilizamos uma solução personalizada e completa para a compra da sua casa. Com base nas suas necessidades e preferências, podemos pô-lo em contacto com os melhores especialistas em compra de casa da sua zona e eliminar o sofrimento da sua experiência.
Se alguém quiser liderar uma grande empresa e criar excelentes produtos, qual é a qualidade mais importante que essa pessoa deve ter e que hábitos ou comportamentos sugeriria para desenvolver essa qualidade específica?
É preciso aceitar o facto de que vai sentir dor durante os próximos 5 anos, no mínimo. Criar produtos complexos, procurar feedback rigoroso, descartar o que não funciona, ser rejeitado por investidores de capital de risco, dar notícias difíceis e crescer enquanto líder — tudo isto é doloroso! Vale a pena? Sim. Isso significa que é fácil? Não!
Para sobreviver, precisa de libertar-se do ego. Pratique receber feedback sem o levar para o lado pessoal. Trate cada decisão como uma experiência e não se envolva emocionalmente no resultado — olhe antes para os dados. Não se leve tão a sério que não consiga ver o humor nos seus fracassos.
Agora, falemos de equipas. Que estratégia ou estrutura de gestão de equipas considera particularmente útil para o processo de desenvolvimento de produtos?
Adoro uma equipa vertical e desenrascada. A estrutura de equipa ideal para mim inclui alguns engenheiros, um designer, um PM e talvez um gerente de engenharia. O seu PM é responsável por desenvolver novos produtos, fazer evoluir os produtos existentes e definir as prioridades mais importantes. As estruturas de definição de prioridades são ótimas para isso. Na DwellWell, a nossa estrutura de definição de prioridades é a seguinte:
- Financeiro
- Impacto
- Alcance
- Urgência
- Facilidade
Cada um destes critérios tem uma ponderação. Quando são propostos novos projetos, utilizamos esta estrutura para enquadrar o trabalho. Isto garante que estamos sempre a trabalhar naquilo que é mais importante.
O nosso designer e o gestor de produto trabalham em conjunto para desenvolver uma especificação do produto, acompanhada de alguns wireframes básicos. Assim que estes dois elementos são entregues, os nossos engenheiros assumem o controlo, definem o âmbito do projeto, elaboram um calendário e gerem os seus próprios tickets e prazos. Mantemos a nossa comunicação muito estreita para podermos avançar rapidamente. Enquanto a arquitetura básica é desenvolvida, o nosso designer cria os designs finais e os nossos engenheiros concluem o projeto acrescentando estes melhoramentos visuais.
Este processo permite-nos avançar rapidamente e ter menos estrangulamentos.
Quando pensa na equipa mais forte com que já trabalhou, porque acha que a equipa funcionava tão bem em conjunto e consegue recordar uma história que ilustre essa dinâmica?
A equipa de engenharia que reunimos na DwellWell é extremamente forte (e, já agora, 75% são mulheres!). Trabalhamos bem em conjunto porque confiamos uns nos outros. Somos exigentes nas nossas revisões de código. Exigimos padrões muito elevados uns dos outros, não há lugar para egos e ajudamo-nos quando algo corre mal. Promovemos uma cultura de aprendizagem.
Recentemente lançámos uma reformulação do produto, que foi um projeto gigantesco. O trabalho foi dividido entre os engenheiros, cada um de nós verificando o progresso, garantindo que não duplicávamos trabalho e sincronizando o nosso trabalho para que fosse entregue da forma mais otimizada possível. Era como assistir a uma orquestra, com o meu engenheiro principal como maestro. Foi lindo! Cumprimos o prazo ambicioso com tanta facilidade que fiquei desconfiada — as coisas raramente correm assim tão bem. Mas uma equipa pequena e dedicada pode alcançar resultados extraordinários.
Se tivesse apenas uma ferramenta de software no seu arsenal, qual seria, porquê e que outras ferramentas (de software ou objetos físicos) considera essenciais para a missão?
Como engenheira, teria de dizer que a nossa ferramenta mais importante é o GitHub. É uma resposta tão banal, mas muitas vezes o software mais importante é completamente aborrecido — fiável, fácil de utilizar e aborrecido. O controlo de versões é indispensável para criar uma organização de engenharia bem-sucedida.
Falemos de tempo de descanso. Qual é a sua prática ou ritual habitual para evitar o esgotamento?
Infelizmente, o exercício é mesmo a melhor forma de pôr a cabeça em ordem. Detesto fazer exercício, mas sentimo-nos simplesmente melhor — não há volta a dar. Também tomo Lexapro, que ajuda muito com a minha ansiedade. A minha ansiedade manifesta-se como uma irritabilidade extrema, que é uma emoção completamente inútil quando se está a gerir uma startup. Permite-me ser uma colega de equipa melhor, em vez de uma adversária.
Com base na sua experiência, quais são os seus “5 passos necessários para criar excelentes produtos tecnológicos”?
1 . A primeira coisa que construir será provavelmente má — lance-a na mesma. Como disse Reid Hoffman — “Se não se sentir envergonhado com a primeira versão do seu produto, lançou-o demasiado tarde.” O primeiro produto que lançar deve fornecer-lhe informação — está no caminho certo? Os utilizadores preocupam-se com o problema que está a tentar resolver? Não desperdice tempo precioso com a perfeição quando está à procura de validação inicial. O primeiro produto que criámos na DwellWell foi um simples PDF intitulado “10 passos para comprar casa”, no qual o utilizador tinha de tomar a iniciativa e enviar-me um e-mail se quisesse ser encaminhado para um dos nossos agentes imobiliários recomendados. Nos primeiros dois dias após o lançamento, tivemos o nosso primeiro cliente. Foi incrível — não conseguia acreditar que algo que nos tinha levado 2 semanas a criar tinha resultado num utilizador real. Chamávamos carinhosamente a este produto o nosso “MVP de merda” e forneceu-nos informação suficiente para angariar algum capital.
2 . Observe os utilizadores a interagir com o seu produto. Ficará surpreendido com a forma como as pessoas utilizam o seu produto, comparativamente à forma como imaginou que o iriam utilizar. Lembro-me de que, quando começámos a DwellWell, tínhamos um botão que o utilizador deveria premir para alternar entre “concluído” e “incompleto” quando terminasse uma tarefa. Era a principal ação que o utilizador deveria realizar na página. Criámo-lo e pensámos: “bonito, maravilhoso, intuitivo”. Mas digo-vos uma coisa — os utilizadores não faziam a mínima ideia do que aquele botão deveria fazer. Realizámos mais de 10 horas de entrevistas com utilizadores e todas as pessoas diziam: “Estou confuso com este botão”. Retirámos o botão e nunca mais olhámos para trás.
3 . Avance rapidamente quando a decisão puder ser revertida e mais devagar quando não puder ser revertida. A velocidade é essencial nas startups. Não deve agonizar sobre todas as decisões, mas pode ser difícil saber quais justificam abrandar. Na verdade, é bastante raro encontrar uma decisão irreversível, por isso, na maior parte do tempo, avanço rapidamente. No entanto, com a recente reformulação da DwellWell, tomámos decisões lentamente ao longo de dois meses para garantir que iríamos disponibilizar um produto mais intuitivo. Iríamos abandonar completamente a arquitetura antiga, por isso era importante avançar com cuidado rumo ao nosso futuro.
4 . Promova uma cultura de melhoria contínua. Pode ser muito tentador criar uma funcionalidade, dá-la por concluída e nunca mais iterar sobre ela. Isto criará produtos estagnados e também estabelecerá um mau precedente para as equipas de produto e engenharia. Cada membro da equipa deve procurar formas de melhorar continuamente o produto existente ou sugerir experiências que possam aumentar as métricas principais. Recentemente, realizámos uma experiência na DwellWell para testar várias experiências de registo e descobrir qual era a mais intuitiva. Não tínhamos alterado a nossa experiência de registo há um ano e descobrimos que o nosso grupo de controlo (o nosso fluxo normal de registo) era o que apresentava pior desempenho entre três variantes! Desde então, desenvolvemos uma matriz de priorização de experiências e desafiamos o produto existente com a maior frequência possível.
5 . Um utilizador frustrado é melhor do que um utilizador desinteressado. Os utilizadores frustrados são pessoas que se preocupam com o seu produto ou com o problema que a sua empresa está a tentar resolver. Embora possa ser assustador interagir com alguém que teve uma má experiência, essas pessoas são infinitamente mais úteis do que um utilizador desinteressado que abandona o produto. Aprendi esta lição no Reddit, que tem potencialmente a base de utilizadores mais apaixonada do mundo. Os utilizadores frustrados deram-nos tantas ideias sobre como melhorar e sobre os aspetos em que a plataforma não conseguia satisfazer as suas necessidades. É uma das lições mais importantes que aprendi até agora.
Está atualmente satisfeito/a com o status quo relativamente às mulheres na tecnologia? Que mudanças específicas considera necessárias para alterar o status quo?
Não — definitivamente não estou satisfeito/a. Esta é uma questão muito complicada, porque as disparidades de género na tecnologia são perpetuadas por todos — até por aqueles que estão a tentar ajudar. Uma das melhores coisas que podemos fazer enquanto líderes é formar mulheres para cargos seniores com o mesmo empenho com que formamos homens para cargos seniores. Vejo frequentemente empresas contratarem imensas mulheres em início de carreira para que as suas métricas de contratação pareçam boas. Mas isto apenas perpetua a ideia incorreta de que as colaboradoras ocupam normalmente posições mais juniores do que os colaboradores. É quase um paradoxo, porque, para as mulheres chegarem a cargos seniores, têm de começar por algum lado! Penso que, se está a contratar mulheres em início de carreira, tem de as fazer progredir obrigatoriamente ao mesmo ritmo a que fazemos progredir os homens. Oriente as suas colaboradoras, dê-lhes feedback crítico para as ajudar a crescer, trabalhem em conjunto num plano de progressão e permita-lhes cometer erros.
Há alguma pessoa no mundo com quem adoraria tomar um pequeno-almoço ou almoçar em privado, e porquê?
Justin Bieber? Estou a brincar (mais ou menos). Adoro o podcast do Guy Raz, Como construí isto, e adoraria conhecê-lo. As entrevistas dele são completamente cativantes.
Para receber mais conteúdos como este, subscreva o boletim informativo do CPO Club.
