8 min read
When I first met with my soon-to-be co-founder Tammy at the South Park Commons back in October 2016, I thought I was signing up for another freelance gig. Instead, the part-time gig at Carrot Fertility turned into a co-founder role. Five years later, the idea I helped build has become a team hundreds strong, serving hundreds of thousands of people across the globe.
Two months ago, I left Carrot to rest and focus on my physical and mental wellbeing. As I reflect on those five years, the following lessons stand out.
Another startup in Palo Alto told me that they heard from a mutual investor that Carrot was looking for a designer. Tammy and I had a 45-minute chat about a small initial project the following week. Over the next few months, my projects with Carrot drowned out my other freelance work, and I signed on full-time as a founder.
Similarly, most of our early hires came through personal connections. I’ve seen this be the norm for early companies. They often don’t have the resources for hiring like larger companies. This means that some of the best opportunities never appear on public job boards and the like.
Five years ago, I was still struggling with imposter syndrome. Like most of us, I had a voice inside telling me I didn’t belong or couldn’t make it. I let that voice control me.
At Carrot, that behavior manifested as self-censorship. I didn’t say anything unless I was 100% sure. This wasn’t a rational choice but a natural behavior stemming from my self-doubt. In time, I started to get feedback that either people thought I didn’t care or I didn’t have opinions. I realized that when people were looking to me for leadership, I let them down.
As I observed the other leaders around me, I saw that even though they weren’t certain about everything, they acted. I learned that for many decisions, it’s better to make an educated guess and correct it later.
The hardest-learned lesson was the need to differentiate from working inside the machine to working on the machine.
In 2018 and 2019, I had the feeling that we needed to improve design at Carrot. I knew we could do better. I also hungered to improve as a designer. I combined both problems and thought that the only way forward was to grow myself to fit the company’s needs.
Fortunately, Tammy saw the risks in that idea. She instead brought in a team of seasoned pros from All Turtles to supplement our team. This decision allowed us to skip obstacles we would have faced if we had tried to grow a design team independently. We all learned how to do design well and how design fits into the greater organization.
In the end, we not only solved the problem of leveling up design at Carrot. I also found myself surrounded by peers and mentors that helped me learn at a pace far faster than on my own.
I’ve seen multiple situations where stakeholders in a project all agree to undertake the project. However, when I listen to each of them speak about it, there appears disagreement on the specific problem to be solved, the desired outcome, potential next steps, etc. I also observe that some teammates are quieter than others. Hence, ideas may be biased towards the loudest or senior-most. If left unchecked, these misalignments can lead to big problems later.
This is the perfect chance to do a listening tour. We come up with a list of questions to probe the significant areas of the project, especially points of disagreement. Then, a teammate and I will interview each stakeholder and compile all feedback.
When we look at each answer side-by-side, we can compile where everyone agrees and disagrees into a report. By surfacing the breadth of everyone’s feedback, we force ourselves to resolve our conflicts and acknowledge details we may have overlooked.
If we don’t have the time for a listening tour, we rely on a clear decision-maker to resolve conflicts and allow the team to continue.
Whatever method we choose, resolving conflicts as they arrive has been paramount as it prevents further divergence in expectations.
When I reviewed candidate portfolios, I saw a pattern among many designers. They described a step-by-step design process they follow with every project — frameworks like the Double Diamond.
When I was getting started in design, those frameworks were alluring. They brought structure to problems that seemed difficult to untangle.
In practice, no one design process will work every time. Design problems tend to be wicked, meaning that they can have multiple solutions and changing or contradictory requirements. Therefore there cannot be one process that works every time.
In practice, I’ve seen that the most effective design process requires interatively understanding the problem, deciding what to do, getting feedback, and adjusting the plan.
For example, if I’m working on an invariant part of most products like a sign-in flow, I use industry best practices as a starting point. On the other hand, if I’m designing something new, something core to what makes our product unique, I do more research and exploration.
Of course, since we work with teammates, we do need some standardization when it comes to communications, documentation, timelines, etc.
In my time on the engineering team at Carrot, we avoided the usual whiteboarding and algorithms questions in interviews. Instead, we used challenges that closely mirrored our actual day-to-day work.
First, we found that our process favored not preparation for algorithms interviews but people who had experience working on a team.
Second, we found that some of our best engineers came from non-engineering backgrounds. They either taught themselves programming or did a boot camp after pursuing another career. These individuals were professional, ambitious, and self-managing. Their resumes didn’t fit the standard mold, and their strength was in projects and the real world, not interview prep.
Patrick Collison, co-founder, and CEO of Stripe mentioned experimentation with organizational structures and methodologies on the Tim Ferris Show podcast. The gist of his comment is that experimenting with org charts and corporate governance is quite risky. It’s best to stick to industry best practices and accept their inherent deficiencies.
At Carrot, we initially tried to enable our engineers to work beyond the normal boundaries of the discipline. We envisioned engineers as hybrids that could do product management, design, etc. This worked at the beginning, given our team was formed of generalists.
As we scaled, it started to fall apart. Our mistake was trying to hold on to this too long, thereby implicitly reinventing how a larger company’s org chart looks. We ended up fixing this mistake and building out a more traditional structure.
We should have followed the tried and true playbooks when expanding our team. This would have reduced confusion and notably increased the quality of our output.
A crucial part of Carrot’s culture is intellectual safety. We created a space where team members could provide each other feedback and have difficult conversations.
This culture was created through the confluence of ongoing work by everyone at the company.
First, we were cautious with who we hired. Of course, the teammates I worked with were professional and intelligent but also came from diverse backgrounds. We avoided toxic individuals, like those driven by their ego or those out to make a quick buck.
Second, we create structured forms of discussion for difficult conversations. Periodic retrospectives were especially effective. Team members could write nearly anything on their minds with the trust that the team would listen to them and try their best to understand the problem without blaming anyone.
Lastly, leaders and managers in the company worked very hard to prevent their subordinates from being put in difficult situations. An example is the misalignment of roles and responsibilities across multiple teams. Sometimes this can lead to two teams overlapping and feeling like the other team is stepping on their toes. It’s here that leaders and managers can step in to remind everyone that we are working towards the same mission. They can then approach the situation as a problem of process. The solution is to create more explicit contracts between the teams.
Many of these lessons were challenging to learn. They arose from repeated iterations of trial and error. I hope that they serve you as well as they serve me.
Note: All photos in this post are from my time at Carrot
Thanks to Q for reading drafts of this.