Building an authentic developer brand with Charity Majors, CTO & Co-Founder of Honeycomb
Tips for building trust and authority among skeptical audiences
Anyone who has tried to rank a corporate blog post on Hacker News knows both how difficult it is and the impact it can have. There’s no gaming the system. It requires opinionated and interesting writing – and a bit of luck. The observability startup Honeycomb is the rare company I’ve seen that does this consistently.
Honeycomb has built a brand that is genuinely trusted among developers. It’s thanks in large part to the punchy voice of co-founder Charity Majors (you may know her as @MipsyTipsy on Twitter).
In this interview, we cover:
Building a developer brand that passes the BS test
Whether to create a software category or joining an existing one
Evolving your voice as you go up market
Let’s go!
To start, how would you define the Honeycomb brand?
With Honeycomb we’re trying to make clear that your job as a developer doesn’t end when you finish writing code and your tests pass; it extends through the lifecycle of your software.
We want the Honeycomb brand and personality to be friendly and deeply technical. Opinionated, but practical. People have a lot of fear and anxiety around interacting with production systems, and the last thing we want to do is contribute to that. We want people to feel like we are on your side. Like we are the friendly senior engineer who has seen this before, and just wants to help.
You write in a very vendor-neutral way. Many founders would disagree with you on this approach. Was this a conscious choice?
I talk to people the way I want to be talked to. I hate feeling sold to, but I appreciate being educated and informed. I will always trust a vendor who tells me the truth, even — especially! — if it doesn’t paint them in the best light, over a vendor that promises me the world. I think that most engineers are like me.
I think that if you can’t justify the need for your product without referring to your product, it’s a weak product. It does happen to be true that Honeycomb is the only tool available that really meets the needs we describe, but I actually deeply wish that wasn’t true. It doesn’t bug me that so many companies have copied our messaging and our marketing, but it does bug me that they’ve copied the messaging without also building a better solution. I guess I wasn’t sufficiently cynical about that.
Almost none of this was a conscious choice, by the way. We had no idea how you’re supposed to build a business, we were just fumbling around.
It also made everything soooo much harder than it had to be.
How so?
Well, the whole category creation thing. [Paige note: Honeycomb popularized the term observability and essentially created a whole new software category, which today is represented with a Gartner Magic Quadrant.]
At the time, I didn't know categories were a thing. I had never heard of APM [application monitoring tools], I had never heard the phrase “product-market fit.” I didn’t know the difference between sales and marketing. (The list goes on.)
When I look back at the first few years of Honeycomb, the hardest thing was figuring out how to talk about what we were building. Building a storage engine wasn’t easy, but the product marketing problems felt way harder than any of the deeply technical challenges we faced.
When we started trying to describe what we were building, we were reaching for words like “monitoring,” and “analysis,” “analytics,” and “data pipelines.” All of these terms were so overused, and already being used to market some other product.
How did you figure out how to explain what you were doing as a new thing, “observability”? How did you sharpen your message?
Well, for the first six or eight months, if someone asked what we were doing, we’d sit you down…and it would take half an hour to tell you.
I still have the Slack chat record from the first time I googled “observability.” The Wikipedia definition was something like, “Can you understand the state of your system just by observing its outputs?”. I had a lightbulb moment: this is what we’re trying to do!
Messaging-wise, all we did was talk constantly on Twitter. One out of every 10 things we said, people would really lean into. We’d be like, “Huh – there’s something interesting there.”
Pay attention to the caliber of people responding to your messages. As we were publicly teasing apart these questions about observability, people who were solving really hard problems – hardcore engineers who we really respected – were responding like “Yes! This is a problem I’m having!”
We had no marketing strategy other than saying “yes” to literally anyone, anywhere who invited me to give a talk, talking on Twitter and listening to what messages resonated with people.
Some founders reading this are in a similar spot you were – wondering if they should join an established category and explain why their product is different, or start their own. Any advice?
The best advice is to join one. Trying to create a category is really hard, and it’s not entirely up to you.
If there is an established category that means there’s already a budget attached to it. People already understand what it is. It’s way easier to differentiate yourself against something established versus defining something new.
You have to fight to give people a reason to pay attention to you, and the less you have to ask someone to memorize or care about, the better.
Your writing is very honest, opinionated and never salesy. How intentional was it to use your writing as a growth play for Honeycomb?
There was nothing strategic about it; I’ve always been more comfortable writing my thoughts out than speaking. It was very organic, and such smart people were engaging with it.
You could tell that they cared.
Any time you write a talk, also publish it as a blog post. At minimum. Writing is how the word spreads, more so than any other form of communication, and founders are usually the most eloquent missionaries for their ideas.
If you have a body of written work, you're also making things much easier (or even possible) for the marketing people who come along later and try to figure out how to do their jobs.
Tell me about your writing process today.
Every day I walk from home to the office. I look down at my phone, do Twitter and email, and then look back up when I get there. That’s how I do all my tweeting, and most of my good posts started out as Twitter threads.
It’s a good process because I can only go as fast as my thumb can type, so it keeps me concise. When I sit down in front of a Google doc, I may vomit out like 30 ranty pages. But if it’s a tweet thread it’s already well-organized, so I can just shine it up and publish it.
As devtools companies go up market you’re not only talking to a developer audience, but also an enterprise audience. How are you thinking about this evolution of voice and tone?
Our sales strategy relies on technical champions behind closed doors because we can’t compete from a pure marketing play.
We have been very fortunate in our champions – we tend to get a lot of very influential, senior technical people who understand what we’re saying and why it matters. Luckily we do not have the problem of over-hyping and under-delivering with the product – we have the opposite problem, which is still a problem! — so our most effective marketing is just us amplifying our users.
For a long time we didn’t want to do outbound [with SDRs], but you can’t build a business that way. It’s very hard to build trust and very easy to lose it. So any sign of spamming people, you have to stop. You should be able to give someone something that is actually valuable to them and not waste their time. If it feels icky, you shouldn’t be doing it. We hold ourselves to a very high standard there. It’s not enough to tell SDRs when things are bad, you have to actively show them what good looks like. But it’s not impossible. I used to feel like it was impossible to use SDRs to outbound to technical audiences without alienating them, and it is not. It’s just hard.
What’s also been interesting has been adapting our message to speaking to enterprise decision-makers. Converting the value of what we do into the language of what a CTO thinks about all day, and giving them the ammunition to sell it internally – these have been new and interesting muscles to build.
I still struggle with this a little, because it’s so easy for something to sound generic. If you’re saying something that literally any of your competitors could say, then it’s not a good message.
Tactically, how are you having these conversations about brand and voice with Honeycomb employees? How are you making sure it doesn’t get diluted as you grow?
We are in a period of standardization. We recently got a new head of Product Marketing who comes at things from a sales enablement perspective – it’s all about bringing it back to a message that is simple, powerful, and specific enough that people who aren’t steeped in this space can credibly talk about with prospective customers.
We were a little bit late to realize just how important this is. It’s one thing when you’re sort of doing this PLG, engineer-to-engineer motion – you can just wing it a lot. But when you’re making things programmatic, you need someone who specializes in the programmatization of messaging.
How do you see the interplay between internal culture + external brand?
I’ve been trying to draw more defined lines between my own brand and the company’s brand, because unless you do this, there’s an expectation on the part of employees that I want them to sound and look like me. That’s not the intention at all – and that feels very limiting.
I wrote a blog post called Choose Boring Culture, which is a riff off the famous Dan McKinley piece called “Choose Boring Technology.” Boring doesn’t mean bad. It means its failure conditions are well understood, so you can save those brain cells for your differentiators. I feel like tech companies try way too hard to make their cultures “fun,” when that isn’t the point. If people feel safe and supported, then they bring the fun. And it’s better fun! Forced corporate fun is so lame.
Talking about our culture has been such a huge asset and differentiator for us. We've attracted some incredible, world-class contributors, people who should really be way out of our league, because they resonated with our philosophy and approach to culture.
What specific practices have you tried to help employees understand “who Honeycomb is” as a company/brand?
During our times of fastest growth we had a lot of conversations about “gardening our culture;” what we wanted to keep and what it was time to let expire. We’d have once-per-month events where we’d talk about one of our values and do breakout groups with our entire company. It was like, “the culture is yours, what are we going to do with it?”.
We ask someone new to facilitate each All Hands, and someone else does an AMA at the end. We also make a point of asking people to present their own work instead of having it presented by their manager.
We also put an elected employee representative on our Board, as a voting member. We are the first company in the Americas to do that, as far as I know.
After every Board meeting, she presents the slides to the company and talks about what the vibe was like, what the investors were interested in.
We are a very transparent company in part because Christine and I were formerly at a startup that was not transparent at all, and we hated it. People have a right to know what’s going on at their company. It’s their lives, and they are choosing to spend them here; we have certain obligations to them in return.
One of our company values is, “we hire adults”. I feel like companies tend to infantilize their employees, like they don’t trust them to handle hard, complex realities. I don’t agree, and I definitely don’t like being treated that way. People are fully capable of understanding why you make decisions they may not agree with.
You’ve basically taken a very open sourced, employee-shaped approach to Honeycomb’s culture.
To me, it’s about ownership and agency. We all want autonomy, mastery and meaning out of our work. It’s the job of leaders to constantly look at your culture through that lens. At the end of the day, people will always do a better job when they care.
Thanks for reading. If you haven’t already, subscribe to get our next interview directly to your inbox.
Charity Majors is the co-founder and CTO of honeycomb.io. She pioneered the concept of modern Observability, drawing on her years of experience building and managing massive distributed systems at Parse (acquired by Facebook), Facebook, and Linden Lab building Second Life. She is the co-author of Observability Engineering and Database Reliability Engineering (O'Reilly). She loves free speech, free software and single malt scotch.
Great interview with someone who is an inspiration to many in the reliability space