Currently, only about 1 in 4 employees in the tech industry identifies as a woman. So what does it take to create a successful career as a woman in tech? In this interview series called Women in Tech, we spoke to successful leaders in the tech industry to share stories and insights about what they did to lead flourishing careers. We also discuss the steps needed to create a great tech product. As part of this series, I had the pleasure of interviewing Samantha Carow.
Thank you so much for joining us in this interview series! Before diving in, our readers would love to learn more about you. Can you tell us a story about what brought you to this specific career path?
I started my career off as a life insurance salesperson. It was pretty much the first job I could get out of college, but I quickly realized how grueling of a career it is, and quit after 9 months. I was super embarrassed that I had “failed” in my corporate job. I picked up a waitressing gig to pay my rent, and started researching new career paths.
As I was bumbling along, trying to come up with a plan, a friend of mine told me about a program called Dev Bootcamp; boot camps were a totally new concept back then. Next thing I knew, I was in San Francisco in a teeny tiny hostel for the 3 month program. I cried every day because of how hard it was, and learned a lot.
Before bootcamp, I had never even considered that the tech industry was something I could be a part of. Further, I had never even heard of many tech industry concepts. Like, what is a product manager? What’s the difference between a static website and a web app? What is a startup? What does it mean to fundraise? What is an API? Literally, I knew nothing. It made me feel even more lost.
I graduated by the skin of my teeth and started my job hunt. My resume looked like this: 9 months of sales experience, 1 year of waitressing experience, and that’s it. I knew I wouldn’t be landing a job based on my pedigree, so I had to think of a scrappier approach. My single saving grace was that I felt immune to rejection -- I had been rejected day after day selling life insurance, so a little embarrassment didn’t scare me. I began scouring the landing pages of startups, looking for tiny implementation bugs. Once I found the bug, I would guess the email address of the founder (usually firstname@startupname.io, at the time), and cold-email them with my proposed solution. Miraculously, this approach worked, and I landed a job within the month.
I spent 2.5 years at this startup, and look back on this time so fondly. At the time I felt like a walking disaster, but the doubt, hardship, camaraderie, mentorship, and friendship I experienced during these years set the baseline for who I am today. I received outsized mentorship, autonomy, and trust. I discovered that engineering is not a boolean thing that you either can or can’t do—it’s a skill that gets honed over years and years, through trial and error and mistakes. The biggest secret of all is that no one really knows what they’re doing. It was such a relief to arrive at this conclusion.
That startup later went on to get acquired by Spotify.
Can you share a story about the funniest mistake you made when you were first starting? Can you tell us what lesson you learned from that?
Oh my god—so many mistakes! The first one that comes to mind was during my 5 years at Reddit. In my first three months, I got a little too cocky about a code deploy, and decided to roll out my changes at the airport while waiting for my flight. Of course, the site immediately crashed. I had to figure out how to roll back my code, which I had never done before, over my phone’s hotspot while watching—I am not exaggerating—thousands of errors flood our logs. That was the first and last time I ever treated a code deploy so callously.
I was mortified by this mistake, but was amazed that I did not get reprimanded. In fact, crashing the site was a sort of ‘rite of passage’ at Reddit. This experience shaped the way I now view mistakes—they happen. In fact, they are to be expected. And when a mistake does happen, your role as a leader is to support your team through that mistake. Once the crisis is over, you then implement processes to prevent similar mistakes in the future.
What do you feel has been your ‘career-defining’ moment?
Every stage of my career has been defining in some way. Certainly my current role, co-founder and CTO, has opened doors I never even knew existed. However, I don’t think I would have had the confidence to found a startup had I not spent years growing into an Engineering Manager at Reddit.
I spent 5 years at Reddit, half of it as an engineer. I remember feeling frustrated that my career wasn’t growing as quickly as I wanted. My mindset up until this point had been “if you do good work, you will be noticed” and “it’s my manager’s job to promote me”. I didn’t understand how much agency I actually had to accelerate my own career. I stumbled into crazy accelerated growth almost by accident—I discovered a memory leak in our front-end application. I fixed it, and we were able to cut our server pool in half. I suddenly started getting attention for my work, so I wondered—is there a way I can reproduce this “luck”? Turns out, yes there is. I developed the following framework to allow others to reproduce my results:
The framework is as follows:
- Identify a pain point for your organization as a whole.
- Find a Minimum Valuable Fix.
- Talk about it.
- Create a framework to allow others to jump in and help.
After implementing this framework for myself, I was invited to new important meetings. I was put in the “Top Performers” tier; I became a tech lead; then a manager of one team, then two. Maybe most importantly, my salary jumped by 30%.
I had so much success with this formula that I started a program at Reddit specifically geared towards teaching others this formula. My program saw 30 participants over the course of a year, 70% of which were able to leverage the program for a promotion or raise.
I’ve written about my framework in depth here, if this concept is interesting to you!
Can you tell us a story about the hard times that you faced when you first started your journey? Did you ever consider giving up? Where did you get the drive to continue even though things were so hard?
While preparing for my coding bootcamp, some people literally laughed in my face when I told them what I was doing. “You?? An engineer?” was a very, very common response. However, I was raised with a ton of grit. Every negative reaction only made me dig my heels deeper—I was going to prove all of these people wrong. I like to call it “spite-driven development”. Ha!
Aside from innate grit, it was extremely important to surround myself with people doing the same thing as me. This is one of the best things about a bootcamp—you’re surrounded by people who are all failing together. It makes the failures easier to stomach, and it reminds you that you’re not alone.
Finally, I had taken a big bet on myself in attending the bootcamp (to the tune of $10,000). I wasn’t going to flush that money down the drain because of fear. Taking a bet on yourself—whether it’s financial, social, whatever—forces you to push through doubt because it’s the only way forward.
We’d love to learn a bit about your company. What is the pain point that your company is helping to address? How does your company help people?
DwellWell exists because buying a house sucks! Homebuyers are dragged through an opaque process, uneducated and confused, by a bunch of vendors who might as well speak a different language. Mortgages, pre-approvals, escrow, earnest money deposits—ahh! It’s all too much. DwellWell educates homebuyers on what they need to know before they get started with their home search and supports them throughout their home buying journey. We explain all the hard stuff and deliver your own personalized one-stop-shop for home buying. Based on your needs and preferences, we can connect you to the best home buying experts in your area and remove the agony from your experience.
If someone wants to lead a great company and create great products, what is the most important quality that person should have, and what habits or behaviors would you suggest for honing that particular quality?
You need to come to terms with the fact that you will be in pain for the next 5 years, minimum. Building complicated products, soliciting harsh feedback, scrapping things that don’t work, getting rejected by VCs, delivering tough news, and growing into yourself as a leader—it’s all painful! Is it worth it? Yes. Does that mean it’s easy? No!
In order to survive, you need to release your ego. Practice receiving feedback without taking it personally. Treat every decision like an experiment, and don’t be emotionally invested in the outcome—look at the data instead. Don’t take yourself so seriously that you can’t see the humor in your failures.
Next, let’s talk about teams. What’s a team management strategy or framework that you’ve found to be exceptionally useful for the product development process?
I love a scrappy, vertical team. My ideal team structure is a couple engineers, one designer, one PM, and maybe an engineering manager. Your PM is in charge of developing new products, evolving existing products, and prioritizing what’s most important. Prioritization frameworks are great for this. At DwellWell, our prioritization framework looks like this:
- Financial
- Impact
- Reach
- Urgency
- Ease
Each of these is weighted. When new projects are proposed, we use this framework to slot in the work. This ensures we’re working on the most important thing at all times.
Our designer and PM work together to develop a product spec alongside some basic wireframes. Once these two items are delivered, our engineers take over and scope the project, develop a timeline, and manage their own tickets and deadlines. We keep our communication very tight so we can move quickly. While the basic architecture is developed, our designer develops the real designs, and our engineers finish up the project by adding these visual enhancements.
This process allows us to move quickly and have fewer bottlenecks.
When you think of the strongest team you’ve ever worked with, why do you think the team worked so well together, and can you recall an anecdote that illustrates the dynamic?
The engineering team we’ve put together at DwellWell is so strong (not to mention, 75% female!). We work well together because we trust each other. We’re picky in our code review. We hold each other to very high standards, there is no room for ego, and we jump in to help when something goes wrong. We foster a culture of learning.
Recently we launched a product redesign, which was a gigantic project. The work was divided between engineers, each of us checking in, ensuring we weren’t duplicating work, and synchronizing our work to be delivered in the most optimal way. It was like watching an orchestra, with my lead engineer as the conductor. It was beautiful! We hit the ambitious deadline so seamlessly that I was suspicious—things rarely run this smoothly. But a small, devoted team can deliver outsized results.
If you had only one software tool in your arsenal, what would it be, why, and what other tools (software or tangible items) do you consider to be mission-critical?
As an engineer, I would have to say our most critical tool is GitHub. This is such a mundane answer, but oftentimes the most critical software is totally boring—reliable, easy, and boring. Version control is a non-negotiable in building a successful engineering org.
Let’s talk about downtime. What’s your go-to practice or ritual for preventing burnout?
Unfortunately, exercise is really the best way to get your head on straight. I hate working out, but you just feel better—there’s no way around it. I also take Lexapro, which really helps my anxiety. My anxiety manifests as extreme irritability, which is a completely useless emotion while running a startup. It allows me to be a better teammate, rather than an adversary.
Based on your experience, what are your “5 Steps Needed to Create Great Tech Products"?
1 . The first thing you build will probably be bad—launch it anyways. As Reid Hoffman said—“If you are not embarrassed by the first version of your product, you've launched too late.” The first thing you release should give you signal—are you on the right track? Do users care about the problem you’re solving? Don’t waste precious time on perfection when you’re looking for early validation. The first product we created at DwellWell was a simple PDF titled “10 Steps to Homebuying”, where a user had to take the initiative and email me if they wanted to get set up with one of our recommended real estate agents. Within the first two days of launching, we had our first customer. It was crazy—I couldn’t believe something that had taken us 2 weeks to make had resulted in a real user. We lovingly called this product our “shitty MVP” and it gave us enough signal to raise some capital.
2 . Watch users interact with your product. It will amaze you how people use your product compared to how you imagined they would use it. I remember when we first started DwellWell, we had this button that a user was meant to click to toggle between ‘complete’ and ‘incomplete’ when they finished a task. It was the main action a user was supposed to take on the page. We built it and we were like “beautiful, gorgeous, intuitive”. I’ll tell you what—users had no freakin’ idea what this button was supposed to do. We hosted over 10 hours of user interviews and every single person was like “I am confused about this button”. We ripped the button out and never looked back.
3 . Move fast when the decision can be reversed, move slower when it can’t be reversed. Speed is life in startups. You should not agonize over every decision, but it can be tough to know which decisions are worth slowing down for. It’s actually pretty rare to find an irreversible decision, so most of the time I’m moving fast. However, with DwellWell’s recent redesign, we made decisions slowly over two months to ensure we would be delivering a more intuitive product. We’d be completely abandoning the old architecture, so it was important to move carefully into our future.
4 . Foster a culture of continuous improvement. It can be very tempting to build a feature, call it done, and never iterate on it again. This will create stagnant products, and also sets a poor precedence for product and engineering teams. Every member on the team should seek out ways to continuously improve existing product, or suggest experiments that may increase core metrics. We recently ran an experiment at DwellWell to test various signup experiences to see which was the most intuitive. We hadn’t changed our signup experience in a year, and discovered that our control group (our normal signup flow) was the worst performing out of three variants! We’ve since developed an experiment prioritization matrix and challenge existing product as often as possible.
5 . A frustrated user is better than a disengaged user. Frustrated users are people who care about your product, or care about the problem your company is trying to solve. Though it can be scary to interact with someone who has had a bad experience, they are infinitely more helpful than a user who is disengaged and bounces. I learned this lesson at Reddit, which potentially has the most passionate user base in the world. Frustrated users gave us so many ideas on how to improve and where the platform was failing to meet their needs. It’s one of the most important lessons I’ve learned thus far.
Are you currently satisfied with the status quo regarding women in Tech? What specific changes do you think are needed to change the status quo?
No—I am definitely not satisfied. This is such a complicated question because the gender disparities in tech are perpetuated by everyone—even those who are trying to help. One of the best things we can do as leaders is train women into senior roles with the same vigor that we train men for senior roles. I often see companies hire tons of junior women so their hiring metrics look good. But this just perpetuates the incorrect idea that female employees are typically junior to male employees. It’s almost a catch 22 though, because for women to become senior, they have to start somewhere! I think that If you are hiring junior women, you must forcibly uplevel them at the same rate as we uplevel men. Coach your women, give critical feedback to help them grow, work together on a promotion path, and allow them to make mistakes.
Is there a person in the world with whom you would love to have a private breakfast or lunch, and why?
Justin Bieber? Just kidding (kind of). I love Guy Raz’s podcast, How I Built This, and would love to meet him. His interviews are completely captivating.
For more content like this, subscribe to The Product Manager newsletter.