Charity: I think diverse teams are more resilient teams. I think a small group of folks who all come from the same background, have the same cultural touch points, they can move hella fast until something happens or until someone gets sick, someone gets pregnant, somebody from another culture joins and suddenly it’s like — ugh — and throws them off the record. Why not just build that in from the beginning?

Rebecca: I’m Rebecca Murphey, and this is Engineering Unblocked. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform that’s trusted by some of the best software companies in the world, including startups like Superhuman, scaleups like Miro and Honeycomb, and companies from the Fortune 500.

On today’s show, I’m talking to Charity Majors. If you haven’t heard of Charity Majors, that’s impressive. She’s the CTO and co-founder at Honeycomb — and generally a person who generates some really valuable takes. They’re just true. She’s well known as being willing to say what’s on her mind.

I’m so excited to have you on the podcast today, Charity.

Charity: I’m so excited to be here.

Rebecca: One of the things that you’re really well known for is the content that you put out into the world about the world of software engineering and building products using software.

First, I thought it was really interesting, the talk that you gave at LDX 3, the lead dev extravaganza. Does the X stand for extravaganza? That would be perfect. So you gave a talk at LDX 3 in London called “In Praise of ‘Normal’ Engineers” about the value of being able to incorporate normal engineers and new grads into your software development process.

So I’m curious: where has the obsession come from? To not optimize for normal engineers, but to optimize for, and to try to find these 10x engineers.

Charity: I mean, it’s very human to be looking for shortcuts, right? It’s very human, it’s very capitalist. And if you could get something done with one person, then why wouldn’t you? Why wouldn’t you try, you know? And in fact, another one of my personal favorite blog posts that I wrote is called something like Every Achievement Has a Denominator. And it’s about how if you have a thousand people and you do something great, that’s good for you. But if you could do the same thing with a hundred or 10, even better. I feel like leaders are so often measured by how many people, but I honestly feel like it’s really exciting to be able to do things with fewer people.

The problem is... There are many problems, but whenever I see a company saying “we want to hire the top 1% or 10%”, my immediate reaction is: “Are you going to pay them the top 1% or 10% of salaries?” I know Netflix does, but most of us can’t afford to do that.

And if you can’t afford to do that, there’s something disingenuous about that. I’m a big believer in doing work that has meaning, but I understand there’s a real movement these days to think that work is ‘just a paycheck’, which is being driven by the fact that so many people have had jobs where the employer wanted everything from them and thought that they owed them nothing in return.

There’s some symmetry here, right? If you can afford to pay people normal salaries, you need to be able to make your job function with normal engineers, right? Most of us are normal and even the people who seem like magicians, when they’re in their sweet spot, when they’re one of the best in the world at what they do — that is rare and it’s temporary.

Being exceptional is very specific. You’re a very exceptional one specific thing, and as soon as you change teams or change companies, or adopt a new framework, you’re right back to being pretty normal again.

And I would like to de-stigmatize that.

Rebecca: Yeah, I really got into this productivity space, and I imagine this is why you also got into this dev tool space, is because I was really inspired by the idea of making normal engineers able to succeed within a system.

But I also think that leaders don’t always understand the work that needs to be done to make it possible for normal engineers to succeed within a system.

Charity: Sociologists call this the ‘fundamental attribution error’, where we’re constantly looking at individuals instead of the structures around them. You can’t just drop everyone in the deep end with a pile of shell scripts and be like ‘go figure it out, be exceptional’ right?

Part of making normal engineers able to do great work is about building a system that makes it so that it’s easy to do great work.

Rebecca: You for the first time, you were the first one to say capitalism. I usually say capitalism first. And this goes to something else I’d love to talk about, which is what (and I’m talking about senior leadership, senior non-technical leadership, especially that your CEO or your company’s CFO, even the head of sales or marketing) could be lacking in understanding of what it takes.

And get specific here: what is the work to make it possible for a normal engineer to succeed? What needs to be in place?

Charity: That’s a different question than I thought you were going to ask. I’ll answer the question I thought you were going to ask: If you’re a company that recognizes the value generated by software engineers, what do those senior leaders need to understand?

We know that as an engineering leader becomes a manager, director, or VP, they need to understand how businesses run. But I don’t think there’s a mirror image expectation for sales, marketing, and CEOs to understand engineering. Many things that go into doing high-performance engineering work actually sound completely counterintuitive, especially to those from a financial background.

There’s a well-known finance rule: the same person shouldn’t both submit and approve receipts. This logic somehow got ported to technology as a rule that the same person can’t write and commit code, which is SO stupid. It sounds right, but it’s so stupid.

My recommendation to engineering leaders is simple: if you do nothing else, every single executive at a tech company should read ‘Accelerate’ so they don’t accidentally crack down and make it impossible for engineers to do good work.

Rebecca: What are the ingredients that need to be in place?

Charity: You need to have CICD. You need to have tests. You need to have documentation. You need to have people whose job it is to work on internal tooling: making it easy to use and intuitive. You need to have good observability.

In fact, I really feel like the state of the art in observability has come so far over the past decade. It’s kind of a prerequisite for a high-performing engineering team. The level of excellence you are able to achieve will be defined by the quality of your observability. If you have shitty observability, you can only get so good. The better your observability, it doesn’t mean you will absolutely then get high-performing teams, but it is a gate.

And if you care about having a meritocracy (I do), you have to care about inclusion first, or else you are just replicating all of society’s existing advantages and preferences and enshrining them again in your own company.

So I think diverse teams are more resilient teams. A small group of folks who all come from the same background can move hella fast until something happens — someone gets sick, someone gets pregnant, somebody from another culture joins — and suddenly it throws them off. Why not just build that diversity in from the beginning? Why not just make it so that everyone feels normal?

And there’s plenty of research about how these teams consistently perform better over the long run.

Rebecca: What creates that magical 10x leverage, if not the mythical 10x developer?

Charity: 10x is not a thing. I mean, I’m not offended by the idea that some people out there can write 10 times as much code as others. I just didn’t think it matters, because ultimately individuals don’t own software. Engineering teams own software. That’s the whole apparatus that lets people get sick, people take time off, go on vacation, get pregnant — it’s about resiliency, it’s redundancy in human form.

Writing software has always been the easiest part of the software development lifecycle and is only becoming more so. So if there’s any person, team, or company out there that can consistently — not just episodically, but consistently — perform 10x greater than their peers, I’ve never seen it. I think it’s not helpful.

Rebecca: Yeah, I agree. And I think we talk a lot about continuous improvement. It’s not like ‘go hire five 10x developers and now you have 50 developers’. But it’s about getting better every week, which is so much more powerful than trying to hire that 1%.

So this kind of leads into another piece of content that you created way back in 2020, which is kind of wild to think this was like early pandemic time, possibly, right? So 10% of the 50 years that we have been building software. Think of it that way. Don’t freak out.

But yeah, way back in 2020, early pandemic, before we entered this post ZIRP period — so after people completely stopped hiring, people started hiring again like crazy. And a lot of those people don’t have jobs now.

But I thought it’s actually really prescient that you were talking about this in 2020, because I think it was very common in 2020 for very large engineering organizations to be having conversations about developer productivity.

Certainly, like if you had more than a thousand engineers, this was obviously on your radar. Maybe it started earlier than that, but it wasn’t on the radar necessarily for the companies that had 100 engineers or 50 engineers. And suddenly everybody cares about developer productivity.

Not literally everybody, but you know, we are in business because suddenly everybody hears a little bit more about developer productivity than they did. But even back then, you wrote about how if you take the word developer productivity or the words developer productivity, as literally the productivity of a developer, then you reduce the job to a set of metrics, and that job could be automated away.

If we could measure this, we’d have a computer doing it.

Charity: The only thing that actually matters is impact to the business. And there are both upsides and downsides.

I’ve been meaning to write a new piece about this, because I think when I say impact to the business, I think a lot of people feel like their work is unseen there because they’re in security or something that isn’t moving the business materially forward.

But it’s absolutely about contributing to business stability, staying in business, and not having terrible things happen. One of the biggest shifts in the past 10 years is that teams used to do a lot of cost-center work — keeping the lights on, supportive infrastructure, monitoring, operations.

We’ve really tried to minimize those, and most companies outsource it. Up to a certain size, you really want most of your teams moving the business forward every day in a product-ended way. And I think this is neither good nor bad, it just is.

And it doesn’t mean that the people who do that are less-than. Like, I come from the side of the infrastructure, doing the protecting from downside work, the enabling work, right? So I get it. It’s a painful adjustment, but it’s real.

But I think the number one productivity tip is to be working on the right things. This is not something engineers can do alone. You have to be plugged into the business.

This is why I hate the whole ’shit umbrella‘ school of management: like, no, no, no. Your job IS to keep your engineers connected to the business, right? To make sure they have the context and understand what they’re doing so you guys can push back.

The most devastating work is when the work that you do doesn’t actually get used or wasn’t worth doing. It’s one of the most depressing, debilitating experiences I’ve ever had.

You have to be working on the right things and be plugged into the business.

In this blog post I told the story of one of my early jobs in tech, which is basically a kind of Unix tech support, right? And I got so good at closing tickets. My boss thought I was amazing. I gamed the f*ck outta those metrics, right? And I wasn’t doing things sinister. I was just like, ’well, this is what they’re judging me on, so crank, crank, crank, crank, crank.‘

And so I think developer productivity metrics do really matter, but you can’t reduce it to some predictable set. They’re there to help you understand what’s happening, not to distort your behavior.

Rebecca: There are a set of conditions required for success in developer productivity. They’re very much the same things as the set of things required for success for a normal engineer. But it’s interesting, like some of them are technical, like you listed, but also some of them are super cultural.

If a team is being loaded to 110%, the main leverage an individual has is to quit. They don’t have a lot of agency over interruptions or changes in priorities. Talking about Honeycomb in particular, how do you create the space for productivity to happen?

Charity: Oh God. It’s such a good question and it always makes me wince a little because I’m immediately thinking about all the ways we do this imperfectly or have stumbled or failed in the past.

But I will say that engineering managers are an undersung component of making this all work. In the early 2020s, it was all the rage to be like, ’Well, we have engineering managers to do the people work, and tech leads to do the technical leadership.‘

If you became an engineering manager, you were told to stop writing code. That’s not your job anymore. Don’t get involved. And I’m like, this is a tricky minefield. When a new engineering manager wants to go back to their safe place of writing code, you need to forcibly yank them out of there so they can learn new skills.

But like, I actually think that if you try to separate the ’people work‘ from the ’technical work‘ in a sociotechnical system, you’re really knee-capping both parties.

What I see when you’ve got a tech lead manager pair and that manager is not connected to the technical stuff at all is that they have to outsource a lot of their judgment about people to someone else’s judgment.

And ultimately, that does not give me confidence in that manager’s judgment, you know? And if I was someone reporting to that manager, I’d be like, ’well, now I have two bosses’. And if the tech lead isn’t in lockstep with that manager at all times…

I think engineering managers being deeply technical and knowing what it feels like is important. They should at least do a ticket every now and then. They should write code. They should know what it feels like to ship. They should know where the friction is. They should be able to go to bat for the engineers who are pillars of their team, whose work is not showing up in the metrics.

They should be able to not just say they’re awesome, but explain how and why they couldn’t have gotten across the finish line without those awesome engineers and why the metrics are wrong, right? Or how you should iterate and evolve the metrics to better capture certain kinds of work.

There’s this chain of leadership at every level, right from the CTO, VP, Director to the manager — and the manager is the part of the management chain that’s closest to the ground. And they need to be able to trust those managers’ technical judgment.

Rebecca: So this is another interesting topic to me because I was never going to be a manager because that sounded absolutely terrible. Um, like really awful. Absolutely not. I was gonna write code for the rest of my life. And then I got a new job and I saw that there was a deep need for an organization centered around frontend infrastructure because they didn’t have one and it was a mess, and frontend was my thing, and that’s why they hired me.

So I had this moment of like: I can either try to find a manager I want to work for, or I could just be that manager. So I decided to just be that manager.

That means I also grew up in the late 2010s, 2020 time, and a lot of managers were growing up out of necessity. And you know, my experience is that I’ve only had so many jobs, so my personal experience is only so valuable. But I know I saw a lot of people kind of being pressed into management because we were hiring so many new ICs that we needed more managers.

Charity: And a lot of people became managers in reaction to the long string of bad managers we had ever had.

Rebecca: Yes, and I also love to tell new managers: the only one-on-one you’ve ever been in is your own, up until this moment. I guess I look back on that time and there wasn’t necessarily a lot of enablement for the stuff that you’re talking about: teaching these managers to do this stuff.

And now, you know, some of these managers are directors. And, you know, I loved Camille’s book about the manager’s path and that was really, like, a seminal book for me as I went down that path, but I think that, like… nobody made you read that book. If you didn’t read that book, you still got to be a manager.

Charity: Mm-hmm.

Rebecca: So I think that’s an interesting component of where we are in technology today, that we’re kind of paying for the choices that we made. And they were, you know, all choices were good at the time.

Charity: We were all doing the best we could. I think that’s really interesting. I think that like the best managers that I’ve seen from like a decade ago were the ones who were lucky enough to work under someone who they really admired and looked up to. And those people are few and far between.

Most of us became managers out of reaction or a desire to protect people, a desire to be that ‘sht umbrella’. I became a manager when we all just arrived at Facebook, and I was like “ah, fck these people, I’ll be the manager, I’ll protect my team from all this horrendous Facebook thing”. And that’s terrible, right? Which is why I don’t judge anyone for the reasons they got into management.

If it’s selfish ambition, if you topped out, you’re a ladder climber, it doesn’t really matter why you got power, what matters is what you do with it, right? But I do feel like a lot of us who got into management kind of in a reactionary way. Then I think we often had this, “well, I’m never gonna do all these things that I’ve hated from all my managers”.

And so then, of course, we made the opposite mistakes. Those of us who went through this Silicon Valley era of sleeping under your desk and burning the candle at both ends came out being like telling everyone: take breaks, pace yourself, take time off.

And it took a while for me to realize that some people really don’t need to hear this. Some people actually really need to hear that they’re not actually putting in enough time. You just can’t manage from place of reaction. You really have to be connected to the reality of what’s going on.

Rebecca: And I think it’s also interesting that with late recent layoffs, we’ve also seen that [IC] level is getting eliminated, or is being given such a large portfolio that it’s not the job that it used to be. Charity: You know, whenever people talk to me about their careers and how to stay employed over the long haul, I really emphasize that management will be the first to be eliminated because engineers create value. Nobody else can do that, right?

I still think that if you want to be employed over the long haul, invest in your technical depth and don’t get too far away from knowing how to go back and do that — because I think that’s the surest bet to a long career. I think it’s great to diversify your skill sets, it can only make you a more powerful technologist, to spend time on the other side of the device.

And, frankly, it is so valuable to have people who used to be managers in your pool of ICs, because some of the hardest times in your life as a senior leader are times when you can’t tell everyone the full story.

And, there are other people out there straight up lying about what happened. And most ICs, they’re still closer to the other ICs, right? There’s this sort of oppositional relationship with their management, which I get, but it’s so valuable to be able to have people who have been managers before who can be like: “all right, kids, but here’s what might be going on. Here’s something that if it was going on, they couldn’t tell you.”

I just want to rain blessings down upon all of the former managers who are now ICs because it’s such a valuable part of the ecosystem.

Rebecca: Yeah. As a manager to have that person on your team who can be that voice, it’s huge.

It’s almost like we scripted this, but like, we didn’t script this this much, but anyway...

The next topic is this pendulum, this back and forth of managers who are now ICs, and that’s something that you’ve really celebrated and championed, just like you just did now.

I’m seeing your blog post from…I don’t remember when this one was from, but I know it wasn’t yesterday. I’m seeing it making the rounds today.

Charity: That blog post was written in 2017. Can you believe it? To this day, it’s the most popular blog post I’ve ever written, which really… I love it.

Rebecca: I see it routinely in channels about searching for a job from those managers who just got laid off and are trying to figure out what their next step is.

How do you help people get over a fear that this might be ‘career limiting’ to go back?

Charity: I think it’s about investing in your career long longevity. I mean, mathematically speaking, there are an order of magnitude fewer jobs available every rung of the ladder that you go up.

Between engineers to management, there’s somewhere between 1 and 5 to 1 and 10. Then managers to directors, then there’s VPs, CTOs — there’s an order. Which is why part of this is always gonna be opportunistic, right? Some people are in the right place at the right time and they climb the ladder like nobody’s business. And good for them.

I think opportunism is honestly the best career strategy: trying to set yourself up for being in a place where there’s going to be opportunities.

But sometimes lightning doesn’t strike. And if you’ve got your heart set and you’re just gunning to climb that ladder, I really think that that is limiting. Yes, people get paid more at each run of the ladder, but I feel like those jobs are also more fragile and it could be a lot harder to find a new job the higher you go up. This is why if you’re a director and above, you only find jobs via special placement recruiter firms. Like you can’t just apply for jobs. A lot of it’s word of mouth, and very clubby — because hiring gets very conservative at those levels. They don’t wanna take risks on people.

You can take a risk on an engineer, whereas if you’re hiring a director VP, you’re crossing your fingers and praying to God and lighting a candle that this person will be the right person.

And I know because I’ve been hiring these execs, we’re also very conservative when it comes to this. You only want someone who’s done this before because the future of your company sits in their hands, right?

So I feel like people should be aware of that trade-off. And I feel like continuing to invest in being someone who has [technical skills] is not career limiting. Oh my God. It is career extending. You can always find work creating value.

Rebecca: And I’m trying to think back to 2017. Geez.

Charity: I know. You know, can I tell you a little story about how that blog post came to be? It was a letter to a friend of mine who was a director of engineering at Slack at the time. And he was just miserable. He was so unhappy. And I was meeting up for drinks with him, you know, every other week or so. We were both pretty miserable. But I was like: “Your solution is easy! Just go be a principal!” And he was like “Ah, I don’t know…”

But I wrote this blog post for him, because I was like: I see you becoming more powerful than you ever were before. If you were an IC, everyone knows you, everyone trusts you. You can write your own ticket.

And he did! He went on to be a principal engineer and he spearheaded so many of the Slack technologies that we know and love and take [for granted]. A lot of the security stuff, the multi login stuff. His career just f*cking exploded after that. So obviously I was proven right and that gives me great joy.

I feel like he was like an early canary for what a lot of people have experienced. Honestly, your career is unlikely to take off while you’re miserable.

Rebecca: Part of the reason I was trying to go back to 2017 is because, well, we were still in the throes of like “hire everybody you can and pay what you have to, and give them free lunch, too.”

The future was, the future was granted. The future was known. They would just keep doing this.

Charity: Hypergrowth, so many hypergrowth companies.

Rebecca: Again, that blog post has turned out to be really prescient today when this is not a choice that people are making ‘just’ because they’re miserable. It’s a choice that people are having to make to pay bills.

Charity: Yes!

Rebecca: You know, you said like it makes you happy to be proven right? I think part of why I was so excited to talk to you is you seem to be pretty right about a lot of things in software engineering.

Charity: I’m glad you said that and not me!

Rebecca: I’ll say it. And especially when you realize that that post was written in 2017 and it seems like a few days ago to me. I love the work that you do to speak out about these things because I do think that you’re mostly right, and I think that a lot of people know these things to be true, but saying it is scary for whatever reason.

So what is it that makes it not scary for you to speak out?

Charity: I’ve always gotten a lot of joy and pleasure out of being contrary.

Rebecca: Is it contrary if you’re right?

Charity: I mean, it doesn’t bring me any joy to say something everyone else is saying. Like, why would you say it? I think I’ve mellowed as I’ve gotten older, but I was very much in that vein.

But also I feel like those of us who come from the operations side of the house have always been a little bit more reality-tethered than the people who are starry-eyed about the future. Which is why I think it’s so unusual that I am a company founder.

Ops engineers do not start companies because you need a certain amount of reality distortion field as a founder, just a starry-eyed view of the future.

And those of us Ops software engineers are more likely to be like: “I hear your bright idea. Here’s how it’s gonna fail. Boom, boom, you’re doomed.”

That “you’re doomed” vibe runs deep in me and it is a complete accident of history that I’ve turned out where I am. And since the company doesn’t wanna hear that we’re doomed, I really try to [reign it in], but it is deeply weird and I just wanna acknowledge that.

Rebecca: I appreciate your continued corrections. We’re about to wrap up here, so my last question to you is: what’s your current hot take about the state of the software engineering industry?

Charity: How could it not be about AI? Right? That’s all everyone’s talking about.

My hot-un-hot take is (depending on where you are — if you go to SREcon, then you’re probably like: “this is obvious”) but I think 9 times out of 10 when you hear someone make a statement about AI, you could substitute the word automation for AI, and it would be just as true. A lot of the stuff that AI is bringing to the industry is not new, it’s just an acceleration.

Not 10 times out of 10, right? Like there are new things, like the introduction of non-determinism. What does it mean to have an API now? And the MCP stuff which I think is super interesting. But so much of it is just automation, right?

And so the people who are predicting that we’re not gonna need engineering, it’s like: “oh, you sweet summer child…”.

We’re generating more code, and worse code, faster than ever. So I’m confident that there will be jobs for software engineers in the future, but I do think that being tethered to reality is more important than ever. And my coworker Fred Haber and I gave a keynote at SREcon this spring where we spoke about the fact that there are people on the product side who are just off to the races saying everything’s gonna change, and then there are SREs who are like “uh, none of it’s gonna work.”

And that’s not true either. And my challenge to those people was: we want to be in the conversation. We need to be part of the conversation, but they’re not going to bring us to the conversation if we’re just doom and gloom. If we’re not acknowledging the potential, if we’re not acknowledging the amazing things that we are seeing.

So we have a responsibility to learn, and use, and try, and play around, and come along, and be in the conversation so that the warnings that we do issue, land. Everyone’s a critic these days. It’s not hard to be cynical. But what’s hard is to be a builder — but to be a builder who is grounded in reality and who retains their ideals and their sense of ethical obligations to each other.

Rebecca: I feel like you just gave a talk to my impression of a younger Charity.

Charity: I think so, I think so.

Rebecca: I love it though. And I think that’s been a big lesson to me too over the years. You can’t be contrary and also be invited to the conversation.

Charity: You can’t be contrary for the sake of being contrary. You have to be contrary while trying to move forward, and while trying to help get to the future.

Rebecca: Yes, exactly. Well, on that note: thank you so much. I cannot believe that the first time I got to talk to you was recorded for the whole world to hear, so here we are.

Charity: I feel like we could have kept talking all day!

Rebecca: Oh my gosh. I want to talk to you for another hour about all the things we didn’t talk about in the notes.

Charity: Well, we’ll have to do a part two!

Rebecca: Yes, at some point! But this was really amazing. Thank you so much for coming on.

Charity: Thanks for having me. This was really fun.

Rebecca: And that’s the show. Engineering Unblocked is brought to you by Swarmia, the engineering intelligence platform that’s trusted by some of the best software companies in the world.

See you next time!