Charity Majors Image
Charity Majors, CTO of Honeycomb.io

First Line of Code: Charity Majors of Honeycomb – Part 2

November 30, 2021 in FLOC, Founders

In our First Line of Code series, Commit co-founder Beier Cai talks to prominent tech founders and tech leads building the next generation of companies, to hear experiences and lessons learned from their early days.

Charity Majors is the CTO of Honeycomb.io, a San Francisco-based software company. Honeycomb provides full stack observability—designed for high cardinality data and collaborative problem solving, enabling engineers to deeply understand and debug production software together.

Commit co-founder Beier Cai sat down with Charity to talk about the early days of Honeycomb and what it was like writing the first lines of code.

This is part two of this interview. See part one here.

Beier: What was your hiring strategy in the early days of your company? What type of people did you look for, what worked and what didn’t work?

Charity: For the first couple years it was just me, Christine and two or three people, so in those stages we optimized for people we knew. We knew what they could deliver and that they were amazing and fast. One of the people we hired was my first manager from 20 years ago. Another was my ex-boyfriend from 20 years ago. It’s like family when it’s that small. 

But we were aware that this is not how you should build a team when you’re trying to grow. So when we started hiring in earnest, Christine and I knew we couldn’t keep hiring our friends, or people who had worked at Facebook or Google. We were very mindful about reaching out to people from non-traditional backgrounds in particular. Part of me was snobby and resisted at first, but I soon realized that was the wrong approach, because this team is the best team I’ve ever worked with. 

That’s because we’ve created a system where we optimize for people’s ability to communicate clearly about technical things. I believe that if you can talk me through how you’re going to solve a problem, you can write the code. But the reverse is not necessarily true. There are many people out there who can write code but can’t explain to you how they did it or the trade-offs they were thinking of. This is how you build a great team: by having people who can talk to each other and who are humble and who will learn from each other. 

We’ve iterated a lot on our interview process and come up with one where Emily always gives a small take home exercise to do. Usually it’s extending code or refactoring something or adding a small feature—and you only have an hour. We don’t want people to work on it for hours and hours. We make it very clear that you’re not expected to finish it, you’re supposed to make a bit of progress and then turn it in. 

The actual interview part is the code-review process the next day, where we talk through it. ‘What did you decide? What did you think about here? What would you do with more time?’ Because code is never finished. We’re looking for people who think clearly about the problems. 

Beier: That’s really smart, because it means you’re hiring people who can explain what they do. They can explain Honeycomb and they become a natural salesperson for it.

Charity: And they make really good coaches when they’re teaching each other or teaching new hires about the systems.

One of the hardest parts of onboarding engineers bringing them up to speed without taking six months or a year. When you have a team that is accustomed to talking through problems and explaining things out loud, it shortens the process. 

Beier: Have you ever had a bad hire? How do you deal with firing and the other hard decisions that come with that?

Charity: We have made a couple of hires that weren’t great for us. I think we take a little too long to fire, which is better than taking too little time, I guess.

There’s got to be a process where you first try to coach them through the thing that isn’t working. The main sign for us is usually if the person is not receiving that information. You’re coaching them, they’re nodding like they hear it, but then they do the same exact thing over and over, and it starts to become a burden on the team, and there starts to be friction. 

If it’s causing a lot of friction, that’s where we’ve let people go. It usually seems to come from people who either lack confidence or people who were promoted too quickly and their view of themselves is way more senior than they actually are.

Not receiving feedback well is also a big one. People who are not able to receive feedback because in their mind it gets translated into, ‘I am bad.’ They just can’t handle it. Giving them feedback seems to affect their self-image. Accepting the feedback would be like accepting that they’re a bad person. You just can’t do that with code. It can be a little brutal sometimes to hear people’s feedback about it. But you have to remember, ‘it’s not about me, it’s about the code.’

Beier: Many technical founders I know struggle with the transition from being the primary person building the product to spending time educating others and getting more people to help. How did you make that transition?

Charity: The transition happened pretty early for me, around when I had to become CEO, which was three or four months in. 

It was brutal. I had nightmares every night for two years. Nightmares that no one would ever hire me again, that I’d be pigeonholed as a project manager, that I’d be written out of the technical story of the company’s founding. 

I’d have nightmares about showing up with my co-founder at a VC event and all the technical questions were directed to her instead of me. I didn’t realize how much of my identity was bound up in being seen as a highly competent technical person.

I don’t think I handled it particularly well. You have to love your job in order to do it well, and I never loved my job as CEO. I did it with gritted teeth. Because I’m good at that, at taking the pain and continuing on. But that’s not what you should do. It’s okay to grit your teeth if you can see that you’re growing to love it and it’s temporary pain, but no one should sign up for unending pain. 

You need to find a job that you love. You need to find a niche or a position in the company that you love. I didn’t do that for a very long time and it left some scars that I’m still dealing with today. 

Beier: Knowing what you know today, would you have transitioned from CEO to CTO sooner?

Charity: It’s a hard call. It was definitely necessary for a couple years. Maybe there’s a way I could have stepped down a little earlier, but probably not, because my co-founder needed to go through a certain amount of growth as well. She was able to take over from me in ways that she wouldn’t have been able to early on.

Beier: When you started Honeycomb, the last job you had was at Facebook. I assume that was a pretty high-level position and well paid. Then all of a sudden you start your own company and you lose all that. How did you manage the personal financial risk?

Charity: I grew up dirt poor, and one of the reasons I got into computers was because I realized if I stayed a music major I would continue to be dirt poor. I didn’t want that. I used to have a lot of financial anxiety.

So when I was at Facebook, my wife at the time and I had been scrimping and saving to buy our house, and I was spending no money. We were reusing plastic Ziplock bags. And I was making a million dollars a year there. I never would have thought that I would walk away from that. 

But it got to a point where I was projectile vomiting in the morning when I tried to leave and go to work. There was a whole saga. It was just wrong. My body wouldn’t let me do it anymore. 

I realized after socking away a bit of money and buying the house that enough was enough, that I wasn’t stressed anymore. If I never made giant amounts of money again and I just had a salary for the next 20 or 30 years, I could retire and I would be fine. I wasn’t rich by any means but I would be fine. That was what gave me the feeling of safety to do something on my own that was super risky.

Beier: Now you’re doing pretty well—and Honeycomb is doing pretty well. 

Charity: It’s interesting, because I’ve never once thought about what would happen if Honeycomb made it big. I assumed from the beginning we would fail, but I thought, this tool needs to exist in the world. I thought we were going to fail, but people are offering us money, so I’ll go build it. And when we fail, we’ll open-source it. 

And then we tried at not failing, just barely not failing. And you seem to be not failing, and in fact you’re doing pretty well. But in my mind I still thought, ‘we’re definitely going to fail.’ I just think it’s healthier that way for me.

Beier: Technical founders often have unique experiences outside of coding. Let’s say you’re an engineer, but all of a sudden you need to join a board meeting and you have no idea what to do. In the early days, what were some of the unique experiences you had outside of product and technology?

Charity: My number one job for the first three years was chief evangelist—just flying around and talking about the product constantly. I was painfully shy and introverted for most of my life. When I was at Parse I gave one talk, and it went so badly. I was petrified. My knees were knocking, I couldn’t talk. It was personally humiliating. 

So I decided that would never happen again and I started giving talks anywhere that would have me. Where there’s pain, I tend to lean into it. And I’m very grateful that I did that because it got me over being petrified whenever I was talking and people were looking at me. I feel very grateful that I got over that experience just a year or two before I started Honeycomb.

Beier: When you don’t agree with a CEO, what do you do? How do you handle that conflict?

Charity: Christine and I have a great partnership. In practice, if there’s something I care about, I get my way. But there aren’t that many things that I care that deeply about. Christine is much better at details and keeping up on this and that. I’m a little bit more big picture.

What I will say is that we’ve taken a lot of therapy. There have been times when our relationship was at a nadir. I think that we’re past those times, and we’ve settled into a very happy kind of married life now. But it was rocky for a long time, and I cannot stress enough the importance of communication with your co-founder, because it is everything. When you are on the rocks, everyone feels it. It’s like, ‘mom and dad are fighting again.’

Do you want to stay up-to-date with Commit news? Subscribe to our newsletters!