Actualmente, solo aproximadamente 1 de cada 4 empleados en la industria tecnológica se identifica como mujer. Entonces, ¿qué se necesita para construir una carrera exitosa como mujer en tecnología? En esta serie de entrevistas llamada Mujeres en Tecnología, hablamos con líderes exitosas de la industria tecnológica para compartir historias y perspectivas sobre lo que hicieron para llevar una carrera próspera. También hablamos sobre los pasos necesarios para crear un gran producto tecnológico. Como parte de esta serie, tuve el placer de entrevistar a Samantha Carow.
¡Muchas gracias por acompañarnos en esta serie de entrevistas! Antes de empezar, a nuestros lectores les encantaría saber más sobre ti. ¿Puedes compartirnos una historia sobre lo que te llevó a este camino profesional?
Comencé mi carrera como vendedora de seguros de vida. Básicamente fue el primer trabajo que pude conseguir al salir de la universidad, pero rápidamente me di cuenta de lo exigente que era, y renuncié después de 9 meses. Me sentía muy avergonzada de haber "fracasado" en mi primer trabajo corporativo. Conseguí un empleo como mesera para pagar el alquiler y comencé a investigar nuevas trayectorias profesionales.
Mientras intentaba encontrar un plan, un amigo me habló sobre un programa llamado Dev Bootcamp; en ese entonces, los bootcamps eran un concepto completamente nuevo. Lo siguiente que supe es que estaba en San Francisco, en un hostal diminuto, para un programa de 3 meses. Lloraba todos los días por lo difícil que era, y aprendí muchísimo.
Antes del bootcamp, nunca se me había ocurrido que la industria tecnológica pudiera ser algo de lo que yo formara parte. Es más, ni siquiera había escuchado sobre muchos conceptos de la industria tecnológica. Por ejemplo, ¿qué es un product manager? ¿Cuál es la diferencia entre un sitio web estático y una aplicación web? ¿Qué es una startup? ¿Qué significa recaudar fondos? ¿Qué es una API? Literalmente, no sabía nada. Eso me hacía sentir aún más perdida.
Me gradué por los pelos y comencé la búsqueda de trabajo. Mi currículum se veía así: 9 meses de experiencia en ventas, 1 año de experiencia como mesera, y eso era todo. Sabía que no iba a conseguir un trabajo por mi historial, así que tuve que pensar en una estrategia más ingeniosa. Mi única salvación era que me sentía inmune al rechazo: ya había sido rechazada día tras día vendiendo seguros de vida, así que un poco de vergüenza no me asustaba. Empecé a revisar las páginas de inicio de startups, buscando pequeños errores de implementación. Una vez que encontraba un error, intentaba adivinar el correo electrónico del fundador (usualmente firstname@startupname.io, en ese entonces) y les enviaba un correo en frío con mi propuesta de solución. Milagrosamente, esta estrategia funcionó y conseguí un trabajo en menos de un mes.
Estuve 2,5 años en esa startup, y miro ese tiempo con mucho cariño. En ese momento me sentía un desastre andante, pero las dudas, las dificultades, el compañerismo, la mentoría y las amistades que experimenté durante esos años marcaron la base de quien soy hoy. Recibí una mentoría, autonomía y confianza desproporcionadas. Descubrí que la ingeniería no es algo binario que simplemente puedes o no puedes hacer —es una habilidad que se perfecciona durante años, a fuerza de prueba y error y equivocaciones. El mayor secreto de todos es que nadie sabe realmente lo que está haciendo. Fue un alivio enorme llegar a esa conclusión.
Esa startup después fue adquirida por Spotify.
¿Puedes compartir una historia sobre el error más gracioso que cometiste cuando recién comenzabas? ¿Qué lección aprendiste de eso?
¡Dios mío, cometí muchísimos errores! El primero que se me viene a la mente fue durante mis 5 años en Reddit. En mis primeros tres meses, me confié demasiado durante un despliegue de código y decidí subir mis cambios en el aeropuerto mientras esperaba el vuelo. Por supuesto, el sitio se cayó inmediatamente. Tuve que averiguar cómo revertir mi código, algo que nunca había hecho antes, usando el hotspot de mi teléfono mientras veía —no exagero— miles de errores llenar nuestros registros. Esa fue la primera y última vez que traté un despliegue de código con tanta ligereza.
Me sentí fatal por ese error, pero me sorprendió que no me reprendieran. De hecho, hacer caer el sitio era casi como un ‘rito de iniciación’ en Reddit. Esta experiencia cambió la forma en que veo los errores: suceden. De hecho, son de esperarse. Y cuando ocurre un error, tu rol como líder es apoyar a tu equipo durante ese error. Una vez superada la crisis, entonces implementas procesos para evitar que errores similares se repitan en el futuro.
¿Cuál sientes que ha sido el momento que definió tu carrera?
Cada etapa de mi carrera ha sido definitoria de alguna manera. Sin duda, mi rol actual como cofundadora y CTO me ha abierto puertas que nunca supe que existían. Sin embargo, creo que no habría tenido la confianza para fundar una startup si no hubiera pasado años creciendo como Engineering Manager en Reddit.
Pasé 5 años en Reddit, la mitad de ellos como ingeniera. Recuerdo sentirme frustrada porque mi carrera no crecía tan rápido como quería. Mi mentalidad hasta ese momento había sido "si haces un buen trabajo, te notarán" y "es trabajo de mi jefe ascenderme". No entendía cuánta agencia realmente tenía para acelerar mi propio crecimiento profesional. Tropecé con un crecimiento acelerado casi por accidente: descubrí una fuga de memoria en nuestra aplicación front-end. La arreglé y pudimos reducir a la mitad nuestro grupo de servidores. De repente empecé a recibir atención por mi trabajo, así que me pregunté: ¿hay alguna forma de reproducir esta "suerte"? Resulta que sí la hay. Desarrollé el siguiente marco para que otros puedan reproducir mis resultados:
El marco es el siguiente:
- Identifica un punto de dolor para tu organización en general.
- Encuentra una Solución Mínima Valiosa.
- Háblalo.
- Crea un marco que permita a otros involucrarse y ayudar.
Luego de implementar este marco para mí, fui invitada a importantes nuevas reuniones. Me colocaron en la categoría de “Mejores Desempeños”; me convertí en líder técnica; luego en gerente de un equipo, después de dos. Tal vez lo más importante, mi salario subió un 30%.
Tuve tanto éxito con esta fórmula que inicié un programa en Reddit específicamente enfocado en enseñar esta fórmula a otros. Mi programa tuvo 30 participantes a lo largo de un año, de los cuales el 70% pudo utilizar el programa para obtener un ascenso o un aumento de sueldo.
He escrito sobre mi marco con mayor profundidad aquí, si este concepto te resulta interesante.
¿Puedes contarnos una historia sobre los momentos difíciles que enfrentaste al comenzar tu camino? ¿Alguna vez pensaste en rendirte? ¿De dónde sacaste las ganas de continuar a pesar de que era tan difícil?
Mientras me preparaba para mi bootcamp de programación, algunas personas literalmente se rieron en mi cara cuando les conté lo que estaba haciendo. “¿Tú?? ¿Una ingeniera?” era una respuesta muy, muy común. Sin embargo, me criaron con mucha perseverancia. Cada reacción negativa solo me hacía aferrarme más a mi objetivo: iba a demostrarles a todas esas personas que estaban equivocadas. Me gusta llamarlo “desarrollo impulsado por el despecho”. ¡Ja!
Además de la perseverancia innata, fue extremadamente importante rodearme de personas que hacían lo mismo que yo. Esta es una de las mejores cosas de un bootcamp: estás rodeada de personas que están fracasando juntas. Hace que los fracasos sean más fáciles de soportar y te recuerda que no estás sola.
Por último, había hecho una gran apuesta por mí misma al asistir al bootcamp (del orden de $10,000). No iba a tirar ese dinero por el desagüe por miedo. Apostar por ti misma—ya sea en lo financiero, social, lo que sea—te obliga a superar las dudas porque es el único camino hacia adelante.
Nos encantaría saber un poco sobre tu empresa. ¿Cuál es el problema que tu compañía ayuda a resolver? ¿Cómo ayuda tu empresa a las personas?
¡DwellWell existe porque comprar una casa es horrible! Los compradores de vivienda son arrastrados a través de un proceso opaco, desinformados y confundidos, por un montón de proveedores que bien podrían hablar otro idioma. Hipotecas, preaprobaciones, depósito de garantía, depósitos de buena fe—¡ahh! Es todo demasiado. DwellWell educa a los compradores de vivienda sobre lo que necesitan saber antes de comenzar su búsqueda y los acompaña durante todo su proceso. Explicamos todo lo complicado y te damos una ventanilla única personalizada para la compra de vivienda. Según tus necesidades y preferencias, podemos conectarte con los mejores expertos en compra de vivienda de tu zona y eliminar la agonía de tu experiencia.
Si alguien quiere liderar una gran empresa y crear grandes productos, ¿cuál es la cualidad más importante que esa persona debería tener y qué hábitos o comportamientos sugieres para perfeccionar esa cualidad?
Debes aceptar que vas a sentir dolor durante al menos los próximos 5 años. Crear productos complicados, recibir comentarios duros, desechar cosas que no funcionan, ser rechazado por los fondos de capital de riesgo, dar noticias difíciles y crecer como líder—¡todo duele! ¿Vale la pena? Sí. ¿Eso significa que es fácil? ¡No!
Para sobrevivir, tienes que dejar tu ego de lado. Practica recibir retroalimentación sin tomarla como algo personal. Trata cada decisión como un experimento y no te apegues emocionalmente al resultado—mira los datos en su lugar. No te tomes tan en serio que no puedas ver el lado divertido de tus fracasos.
Ahora, hablemos de equipos. ¿Cuál es una estrategia o marco de gestión de equipos que te ha sido excepcionalmente útil para el desarrollo de productos?
Me encanta un equipo ágil y vertical. Mi estructura de equipo ideal es un par de ingenieros, un diseñador, un PM, y quizá un gerente de ingeniería. Tu PM es el encargado de desarrollar nuevos productos, evolucionar los existentes y priorizar lo más importante. Los marcos de priorización son ideales para esto. En DwellWell, nuestro marco de priorización es así:
- Financiero
- Impacto
- Alcance
- Urgencia
- Facilidad
Cada uno de estos factores tiene un peso. Cuando se proponen nuevos proyectos, utilizamos este marco para organizar el trabajo. Esto asegura que siempre estamos trabajando en lo más importante.
Nuestro diseñador y nuestro PM trabajan juntos para desarrollar una especificación del producto junto con algunos bocetos básicos. Una vez entregados estos dos elementos, nuestros ingenieros toman el relevo y planifican el proyecto, desarrollan un cronograma y gestionan sus propios tickets y plazos. Mantenemos una comunicación muy fluida para poder avanzar rápidamente. Mientras se desarrolla la arquitectura básica, nuestro diseñador crea los diseños reales, y nuestros ingenieros finalizan el proyecto añadiendo estas mejoras visuales.
Este proceso nos permite avanzar rápidamente y tener menos cuellos de botella.
Cuando piensas en el equipo más fuerte con el que has trabajado, ¿por qué crees que el equipo funcionaba tan bien en conjunto y puedes recordar una anécdota que ilustre la dinámica?
El equipo de ingeniería que hemos formado en DwellWell es muy sólido (¡y además, un 75 % femenino!). Trabajamos bien porque confiamos los unos en los otros. Somos muy exigentes en las revisiones de código. Nos mantenemos a estándares muy altos, no hay espacio para los egos y nos ayudamos cuando algo sale mal. Fomentamos una cultura de aprendizaje.
Recientemente lanzamos un rediseño del producto, lo cual fue un proyecto gigantesco. El trabajo se dividió entre los ingenieros, todos nos manteníamos en contacto, asegurándonos de no duplicar tareas y sincronizando nuestro trabajo para entregarlo de la forma más óptima. Fue como ver una orquesta, con mi ingeniera principal como directora. ¡Fue precioso! Logramos cumplir el plazo ambicioso de manera tan fluida que sospeché—rara vez las cosas funcionan tan bien. Pero un equipo pequeño y dedicado puede lograr resultados fuera de lo común.
Si solo pudieras tener una herramienta de software en tu arsenal, ¿cuál sería, por qué y qué otras herramientas (de software o físicas) consideras fundamentales?
Como ingeniera, diría que nuestra herramienta más crítica es GitHub. Es una respuesta muy mundana, pero muchas veces el software más crítico es totalmente aburrido—fiable, fácil y aburrido. El control de versiones es incuestionable para construir una organización de ingeniería exitosa.
Hablemos del tiempo libre. ¿Cuál es tu práctica o ritual preferido para prevenir el agotamiento?
Desafortunadamente, hacer ejercicio es realmente la mejor manera de despejar la mente. Odio hacer ejercicio, pero te hace sentir mejor—no hay forma de evitarlo. También tomo Lexapro, que realmente ayuda con mi ansiedad. Mi ansiedad se manifiesta como una irritabilidad extrema, que es una emoción totalmente inútil al dirigir una startup. Me permite ser una mejor compañera de equipo, en vez de una adversaria.
Según tu experiencia, ¿cuáles son tus “5 Pasos necesarios para crear grandes productos tecnológicos"?
1 . Lo primero que construyas probablemente será malo—lánzalo de todas formas. Como dijo Reid Hoffman—“Si no te avergüenza la primera versión de tu producto, lo has lanzado demasiado tarde.” Lo primero que publiques debe darte una señal—¿vas por el camino correcto? ¿A los usuarios les importa el problema que estás resolviendo? No pierdas tiempo valioso buscando la perfección cuando necesitas validación temprana. El primer producto que creamos en DwellWell fue un simple PDF titulado “10 pasos para comprar una casa”, donde el usuario tenía que tomar la iniciativa y enviarme un email si quería que le pusiera en contacto con uno de nuestros agentes inmobiliarios recomendados. En los dos primeros días tras el lanzamiento, tuvimos nuestro primer cliente. Fue una locura—no podía creer que algo que nos llevó dos semanas crear había resultado en un usuario real. A este producto le llamábamos cariñosamente nuestro “shitty MVP” y nos dio suficiente señal para conseguir algo de capital.
2 . Observa a los usuarios interactuar con tu producto. Te sorprenderá cómo las personas usan tu producto en comparación con lo que habías imaginado. Recuerdo que cuando empezamos DwellWell, teníamos un botón que el usuario debía pulsar para alternar entre ‘completo’ e ‘incompleto’ al terminar una tarea. Era la acción principal que tenía que realizar en la página. Lo construimos y pensamos “hermoso, elegante, intuitivo”. Pues te diré una cosa: los usuarios no tenían ni idea de para qué servía el botón. Organizamos más de 10 horas de entrevistas con usuarios y todas las personas dijeron “me confunde este botón”. Eliminamos el botón y nunca miramos atrás.
3 . Muévete rápido cuando la decisión sea reversible, más despacio cuando no lo sea. La velocidad lo es todo en las startups. No deberías agonizar por cada decisión, pero puede ser difícil saber cuáles valen la pena tomarse con calma. De hecho, es bastante raro encontrar una decisión irreversible, por lo que la mayoría de las veces actúo rápido. Sin embargo, con el reciente rediseño de DwellWell, tomamos decisiones lentamente durante dos meses para asegurarnos de ofrecer un producto más intuitivo. Íbamos a abandonar completamente la arquitectura anterior, así que era importante avanzar con cuidado hacia el futuro.
4 . Fomenta una cultura de mejora continua. Puede ser muy tentador crear una función, darla por terminada y no volver a iterar nunca más. Esto genera productos estancados y también sienta un mal precedente para los equipos de producto e ingeniería. Cada miembro debe buscar formas de mejorar continuamente el producto existente o sugerir experimentos que puedan mejorar los indicadores clave. Recientemente hicimos un experimento en DwellWell para probar diferentes experiencias de registro y ver cuál era la más intuitiva. No habíamos cambiado la experiencia de registro en un año y descubrimos que nuestro grupo de control (el flujo habitual) era el que tenía peor rendimiento entre tres variantes. Desde entonces, hemos desarrollado una matriz de priorización de experimentos y desafiamos el producto existente tan a menudo como podemos.
5 . Un usuario frustrado es mejor que un usuario desinteresado. Los usuarios frustrados son personas a las que les importa tu producto o el problema que tu empresa busca resolver. Aunque puede dar miedo interactuar con alguien que ha tenido una mala experiencia, son infinitamente más útiles que alguien que no se involucra y se va. Aprendí esta lección en Reddit, que posiblemente tenga la base de usuarios más apasionada del mundo. Los usuarios frustrados nos dieron tantas ideas sobre cómo mejorar y qué aspectos de la plataforma no estaban cubriendo sus necesidades. Es una de las lecciones más importantes que he aprendido hasta ahora.
¿Está usted actualmente satisfecha con la situación actual de las mujeres en tecnología? ¿Qué cambios específicos cree que son necesarios para cambiar esta situación?
No—definitivamente no estoy satisfecha. Esta es una pregunta muy compleja porque las desigualdades de género en tecnología son perpetuadas por todos, incluso por quienes intentan ayudar. Una de las mejores cosas que podemos hacer como líderes es formar a mujeres para que ocupen puestos de alto nivel con el mismo ímpetu con el que formamos a los hombres para esos cargos. A menudo veo que las empresas contratan a muchas mujeres junior para que sus métricas de contratación se vean bien. Pero esto solo perpetúa la idea incorrecta de que las empleadas suelen ser de menor experiencia que los empleados hombres. ¡Es casi una contradicción, porque para que las mujeres lleguen a puestos senior tienen que empezar en algún sitio! Creo que si contratas mujeres junior, debes subirlas de nivel a la misma velocidad que ascendemos a los hombres. Forma a tus colaboradoras, brinda retroalimentación crítica para ayudarlas a crecer, tracen juntas un camino de ascenso y permíteles cometer errores.
¿Hay alguna persona en el mundo con la que le encantaría tener un desayuno o almuerzo privado, y por qué?
¿Justin Bieber? Es broma (más o menos). Me encanta el pódcast de Guy Raz, Cómo lo construí, y me encantaría conocerlo. Sus entrevistas son completamente cautivadoras.
Para más contenido como este, suscríbete al newsletter de The CPO Club.
