How to hire normal engineers and help them do great work with Charity Majors from Honeycomb

Summary

The episode features a conversation between host Rebecca Murphy and Charity Majors, CTO and co-founder of Honeycomb, focusing on the value of hiring ‘normal’ engineers over the mythical ‘10x developer’. Majors argues that most companies cannot afford to pay top-tier salaries and should instead build systems that enable regular engineers to do great work. She critiques the human tendency to seek shortcuts and the capitalist drive to achieve more with fewer people, pointing out the dissonance when companies seek the ‘top 1%’ without offering commensurate pay.

Majors outlines the technical and cultural prerequisites for enabling normal engineers to succeed. Technically, this includes CI/CD, testing, documentation, internal tooling, and good observability, which she describes as a gate to higher performance. Culturally, it requires building diverse and inclusive teams from the start, as homogeneous groups may move fast initially but lack resilience when faced with change, illness, or new members from different backgrounds. She connects this to the ‘fundamental attribution error,’ where leaders focus on individuals rather than the structures around them.

The discussion shifts to developer productivity, with Majors referencing a 2020 blog post where she argued that if a job can be reduced to a set of metrics, it can be automated. The true measure is business impact. She emphasizes that engineers must be working on the right things, which requires management to keep them connected to business context, not shielded by a ‘shit umbrella.’ The conversation also covers the role of engineering managers, advocating that they remain technically engaged to advocate for their teams effectively and judge technical work.

Finally, Majors discusses career longevity, advising engineers to maintain technical depth even if they move into management, as IC roles create tangible value and offer more job security. She celebrates the ‘pendulum swing’ of managers returning to IC roles, noting their unique perspective is invaluable. On AI, her ‘hot take’ is that most statements about AI are equally true for automation; it accelerates existing trends rather than creating wholly new ones. She urges grounded, reality-tethered builders to engage in the AI conversation to ensure their warnings about potential failures are heard.

Recommendations

Books

Accelerate — Charity Majors strongly recommends that every executive at a tech company should read this book to understand what enables high-performing engineering teams and avoid practices that make it impossible for engineers to do good work.

People

Camille Fournier — Mentioned in the context of her book ‘The Manager’s Path,’ which was a seminal resource for Rebecca Murphy as she transitioned into management.

Topic Timeline

00:00:00 — Introduction to the value of diverse and resilient teams — Charity Majors opens by stating that diverse teams are more resilient. She explains that homogeneous teams can move very fast initially but are easily disrupted by changes like someone getting sick, pregnant, or a new member from a different culture joining. She advocates for building this diversity in from the beginning to create stability.
00:01:55 — The obsession with ‘10x engineers’ and its problems — Rebecca Murphy asks about the industry’s obsession with finding ‘10x engineers.’ Charity Majors responds that it’s a human and capitalist desire for shortcuts. She points out the hypocrisy of companies wanting the ‘top 1%’ without paying top salaries and argues that most people are ‘normal.’ She emphasizes that being exceptional is rare, temporary, and context-specific.
00:04:19 — Building systems for normal engineers to succeed — Majors discusses the work required to enable normal engineers. She mentions the ‘fundamental attribution error’—focusing on individuals instead of structures. Success requires building systems where it’s easy to do great work, not just dropping people into a chaotic environment with shell scripts and expecting excellence.
00:05:42 — What senior non-technical leaders need to understand — Murphy asks what senior non-technical leaders (like CEOs, CFOs) need to understand about engineering. Majors says many high-performance engineering practices sound counterintuitive, especially from a financial background. She gives the example of segregation of duties in finance being wrongly applied to code commits. Her key recommendation is that every exec should read the book ‘Accelerate’.
00:07:25 — Technical and cultural ingredients for success — Majors lists the ingredients needed: CI/CD, tests, documentation, internal tooling, and good observability. She states that observability is a prerequisite—the level of excellence is bounded by its quality. Culturally, she stresses that caring about meritocracy requires caring about inclusion first to avoid replicating societal biases. Diverse teams consistently perform better long-term.
00:09:27 — Debunking the ‘10x leverage’ myth — Murphy asks what creates ‘10x leverage’ if not 10x developers. Majors dismisses the term, arguing that individuals don’t own software—teams do. Writing code is the easiest part of the lifecycle. She states she’s never seen a person or team consistently perform 10x better than peers and finds the concept unhelpful.
00:12:37 — Developer productivity and business impact — Referencing a 2020 blog post, Majors argues that if you can reduce a job to metrics, it can be automated. The only thing that matters is business impact. She notes a shift from ‘cost center’ engineering work to product-centric work. The number one productivity tip is ‘be working on the right things,’ which requires engineers to be plugged into the business context.
00:16:31 — Creating space for productivity at Honeycomb — Murphy asks how Honeycomb creates space for productivity. Majors says engineering managers are crucial. She critiques the trend of separating people leadership (managers) from technical leadership (tech leads), arguing it kneecaps both. Managers need technical depth to advocate for their engineers and explain their value beyond metrics.
00:23:40 — Career longevity and the value of technical depth — Majors advises that for long-term employment, engineers should invest in technical depth. Engineers create value in a way others can’t. She values former managers who become ICs because they can provide context to teams when full transparency from leadership isn’t possible, acting as a bridge.
00:28:01 — The pendulum swing from manager back to IC — They discuss a popular 2017 blog post by Majors encouraging a director friend to return to a principal engineer role. Majors argues that going back to an IC role is career-extending, not limiting. Higher-level management jobs are fewer, more fragile, and harder to find. Creating value as an engineer offers more job security.
00:32:31 — Hot take on AI and the state of software engineering — Majors’ hot take is that nine times out of ten, you can substitute ‘automation’ for ‘AI’ in industry statements. AI is an acceleration of existing trends, not entirely new. She is confident there will be jobs for software engineers, but urges reality-tethered builders (like those from ops/SRE backgrounds) to engage in the AI conversation constructively so their warnings land.

Episode Info

Podcast: Engineering Unblocked
Author: Swarmia
Category: Technology
Published: 2025-07-22T14:15:12Z
Duration: 00:36:03

References

URL PocketCasts: https://pocketcasts.com/podcast/engineering-unblocked/efb12a80-e355-013b-f4d0-0acc26574db2/how-to-hire-normal-engineers-and-help-them-do-great-work-with-charity-majors-from-honeycomb/bbef832b-9a43-4ab2-9eed-2847020fafd4
Episode UUID: bbef832b-9a43-4ab2-9eed-2847020fafd4

Podcast Info

Name: Engineering Unblocked
Type: episodic
Site: https://www.unblocked.fm
UUID: efb12a80-e355-013b-f4d0-0acc26574db2

Transcript

[00:00:00] I think diverse teams are more resilient teams.

[00:00:02] I think, you know, 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.

[00:00:13] Or until they try to, like, someone gets sick, someone gets pregnant, somebody from another culture joins, and suddenly it’s like, ugh, throws them off the rocker.

[00:00:20] Why not just build that in from the beginning?

[00:00:26] I’m Rebecca Murphy, and this is Engineering Unblocked.

[00:00:29] Engineering Unblocked is brought to you by Sformia, the engineering intelligence platform that’s trusted by some of the best software companies in the world, including startups like Supervenom, scale-ups like Miro and Honeycomb, and companies from the Fortune 500.

[00:00:41] On today’s show, I’m talking to Charity Majors.

[00:00:43] If you haven’t heard of Charity Majors, that’s impressive.

[00:00:47] But she’s the CTO and co-founder at Honeycomb, and generally a person who generates some really, really valuable, I don’t even want to call them hot takes.

[00:00:56] They’re just takes.

[00:00:56] They’re just true.

[00:00:58] She’s well-known.

[00:00:59] She’s known as being willing to say them.

[00:01:01] So, so excited to have you on the podcast today, Charity.

[00:01:04] I’m so excited to be here.

[00:01:06] Yeah, and introduce yourself better than I just did.

[00:01:09] I mean, I don’t think I can.

[00:01:10] That was fantastic.

[00:01:12] One of the things that you’re really well-known for is the content that you put out into the world about the work of software engineering and building products using software.

[00:01:21] First, I thought it was really interesting, your talk that you gave at LDX3, the lead dev extravaganza.

[00:01:29] Is that what the X stands for, maybe?

[00:01:31] I don’t know.

[00:01:33] That would be perfect.

[00:01:35] So you gave a talk at LDX3 in London called Emprisoned Normal Engineers.

[00:01:42] And when I was talking to you before we started recording, we were kind of riffing on the value of being able to incorporate normal engineers and new grads into your software development process.

[00:01:55] So I’m curious, where do you think this…

[00:01:59] Where does the obsession come from to not optimize for normal engineers, but to optimize for or try to find these 10x engineers?

[00:02:07] I mean, it’s very human to be looking for shortcuts.

[00:02:10] It’s very human.

[00:02:11] It’s very capitalist.

[00:02:13] It’s, you know, and if you could get something done with one person, then why wouldn’t you?

[00:02:19] Why wouldn’t you try, you know?

[00:02:21] And in fact, another one of my personal favorite blog posts that I wrote is called something about every achievement has a denominator.

[00:02:29] And it’s about how if you have a thousand people and you do something great, like good for you.

[00:02:34] But if you could do the same thing with 100 or 10, I feel like leaders are so often measured by how many people.

[00:02:40] But I honestly feel like it’s really exciting to be able to do things with fewer people.

[00:02:44] The problem is…

[00:02:47] There are many problems.

[00:02:52] But like whenever I see a company be like, we want to hire the top 1% or 10%, my immediate reaction is,

[00:02:59] are you going to pay them the top 1% or 10% of salaries?

[00:03:04] I know Netflix does.

[00:03:05] That’s a very coherent, but they have, most of us can’t afford to do that.

[00:03:10] And if you can’t afford to do that, something disingenuous, I, I am a big believer in doing work that has meaning that, you know, but I understand there’s a real movement these days to like workers, just a paycheck, which is, which is being driven by the fact that so many people have had jobs where the employer wouldn’t everything.

[00:03:28] Yeah.

[00:03:29] Yeah.

[00:03:30] Yeah.

[00:03:31] Yeah.

[00:03:32] Yeah.

[00:03:32] There’s some symmetry here, right?

[00:03:34] If you can afford to pay people normal salaries, I think you owe the, you need to be able to make your job function with normal engineers.

[00:03:44] Right?

[00:03:44] Most of us are normal.

[00:03:46] And even the people who are like, I think all of us have met people who just seem like magicians,

[00:03:51] right?

[00:03:51] When they’re in their sweet spot, when they’re one of the best in the world at what they do.

[00:03:55] But like, that is rare and it’s temporary, you know, except being exceptional is very

[00:04:00] specific.

[00:04:01] You’re very exceptional in one specific thing.

[00:04:03] And as soon as you change teams or change companies or change, you know, adopt a new

[00:04:08] framework, you’re right back to being pretty normal again.

[00:04:11] And I would like to de-stigmatize that.

[00:04:15] Yeah.

[00:04:15] And I think I really got into this productivity space.

[00:04:19] I imagine you also got into this, this dev tool space.

[00:04:21] Because like, I’m really inspired by the idea of making, making normal engineers able to succeed

[00:04:28] within a system.

[00:04:30] And I, but I also think that the leaders don’t always understand the work that needs to be

[00:04:36] done to make it possible for normal engineers to succeed within a system.

[00:04:40] Sociologists call this the fundamental attribution error, you know, where we’re constantly looking

[00:04:44] at individuals instead of the structures around them.

[00:04:47] And, and like, you can’t just drop everyone in the deep end.

[00:04:51] And with a pile of shell scripts and be like, go figure it out, be exceptional, right?

[00:04:56] Part of making normal engineers able to do great work is about building, building a system that make it so that it’s easy to do great work.

[00:05:06] You, for the first time, you were the first one to say capitalism.

[00:05:09] I usually say capitalism first.

[00:05:11] And this goes to something else I’d love to talk about is, is kind of how well leadership understands the, and I’m talking about senior leadership, senior non-technical leadership, especially that we’re seeing.

[00:05:21] It’s not that it’s like your CEO, not your CEO, but that could be your company’s CEO or your company’s CFO or some even the head of sales or marketing could have, could be lacking in understanding of what it takes.

[00:05:36] Get, get specific here.

[00:05:38] What is the work to make it possible for a normal engineer to succeed?

[00:05:42] What needs to be in place?

[00:05:43] Different question that I thought you were going for.

[00:05:45] So I’m going to answer the question that I thought you were going to ask, which is,

[00:05:50] uh,

[00:05:51] what is, what do they, so if you’re a company where you recognize that the value that you’re

[00:05:57] selling, that you’re marketing, that you’re, is being generated by software engineers,

[00:06:01] what do those senior leaders, what do they need to understand? Like we understand that if you are

[00:06:06] an engineering leader, you become a manager, director, VP, you need to understand things

[00:06:10] about how businesses run. I don’t know that I think that there’s this, the mirror image

[00:06:15] expectation of sales and marketing and CEOs, but they need to understand things about engineering

[00:06:22] because so many things that go into making a high, high performance engineering work actually

[00:06:29] sound completely counterintuitive. They sound wrong, especially if you come from a financial

[00:06:35] background. And like, I think a great example of this is, you know, there’s a well-known rule in

[00:06:40] finance that the same person shouldn’t be submitting the receipts and approving the receipts.

[00:06:46] Makes a lot of sense. Somehow that got ported over into technology and enshrined in law as

[00:06:52] the same person can’t write the code and commit the code, which is so stupid, right? But like,

[00:06:58] it sounds right, but it’s so stupid, right? And I feel, so I always, the recommendation I always

[00:07:05] make to engineering leaders who are like, I can’t read Accelerate. If you do nothing else,

[00:07:10] every single exec at a tech company should read Accelerate.

[00:07:15] So that they don’t accidentally crack down and make it impossible for engineers to do good work.

[00:07:23] What are the ingredients that need to be in place?

[00:07:25] You need to have, you need to have CICD. You need to have tests. You need to have

[00:07:32] documentation. You need to have people whose job it is to work on internal tooling, making it

[00:07:38] easy to use, intuitive, you know, you need to have good observability. In fact, I, I really feel like,

[00:07:45] the state of the art and observability has come so far over the past decade. And it’s, it’s kind of

[00:07:51] a prerequisite, like your ability to have a high performing engineering team, the, the, what’s the

[00:07:58] right way to put this? The, the high, the, the level of excellence you are able to achieve will

[00:08:04] be defined by, by the quality of your observability. If you have shitty observability, you can only,

[00:08:10] you can only get so good, right? The better your observability, it doesn’t mean you will absolutely

[00:08:15] then get high performing teams, but it is, it is a gate, right? And also, so those are the main

[00:08:22] technical things, I think. And then there’s also, if you care about having a meritocracy, and I do,

[00:08:29] you have to care about inclusion first, or else you are just replicating all of society’s existing

[00:08:35] advantages and preferences and enshrining them again in your own company, right? So I think

[00:08:39] diverse teams are more resilient teams. I think, you know, a group of people,

[00:08:45] a small group of folks who all come from the same background, have the same cultural touch points,

[00:08:49] they can move hella fast until something happens, or until they try to, like, someone gets sick,

[00:08:56] someone gets pregnant, somebody from another culture joins, and suddenly it’s like, ugh,

[00:09:00] throws them off the rocker. Why not just build that in from the beginning, right? Why not just

[00:09:06] have a diversity of levels, a diversity of backgrounds, a diversity of genders,

[00:09:09] a diversity of parental status, diversity of, you know, ages? Why not just make it so that

[00:09:15] everyone feels normal, right? Because you know, there’s plenty—I shouldn’t have to even, like,

[00:09:20] say this at this point, there’s so much research about how these teams consistently perform better

[00:09:26] over the long run.

[00:09:27] What does create the magical 10x leverage? Not the magical 10x developer, because I don’t think they

[00:09:33] exist, but what does create that magical 10x leverage?

[00:09:37] I think 10x is such a—I don’t like it. I mean, I don’t—I don’t—I don’t use this word, but I’m not doing it…

[00:09:43] I mean, I don’t—I don’t—I don’t—I don’t—I don’t use this word, but I’m not using this word, but I’m not using it…

[00:09:43] I don’t—I don’t—I don’t—I don’t use this word, but I’m not using this word, because I don’t want to put it out there.

[00:09:43] I’m not offended by the idea that there are some people out there who can write 10 times as much code as others.

[00:09:51] I just don’t think it matters because ultimately individuals don’t own software.

[00:09:56] Engineering teams own software.

[00:09:57] That is the whole apparatus that lets some people get sick.

[00:10:01] Some people get pregnant.

[00:10:02] Some people go on vacation.

[00:10:04] Some people have, you know, everyone have lives, right?

[00:10:05] It’s resiliency.

[00:10:06] It’s redundancy in human form, right?

[00:10:09] And writing software has always been the easiest part of the software development lifecycle.

[00:10:13] And only becoming more so, right?

[00:10:15] So, like, I think 10x is, if there’s any person or team or company out there that consistently can consistently, not just episodically, but consistently perform 10x greater than their peers, I’ve never seen it.

[00:10:32] I think it’s, I don’t think it’s helpful.

[00:10:37] Yeah, I agree.

[00:10:38] And I think, like, we talk a lot about continuous improvement.

[00:10:41] It’s not like go hire your, you know.

[00:10:43] Hire five, 10x developers like you have 50 now.

[00:10:46] Every week.

[00:10:46] Yeah.

[00:10:47] Every week.

[00:10:48] Every week.

[00:10:48] It’s so much more powerful than trying to hire that one person.

[00:10:52] So, this kind of leads into another piece of content that you created.

[00:10:58] And it’s way back in 2020, which I can’t, it’s kind of wild to think.

[00:11:01] This was, like, early pandemic time, right?

[00:11:06] 10% of the 50 years that we have been building software.

[00:11:10] God.

[00:11:12] Think of it that way.

[00:11:13] Don’t freak out.

[00:11:16] But, yeah, way back in 2020, early pandemic, before, you know, we entered this post-Zerp period.

[00:11:24] And when hiring was, that people were hiring, after people completely stopped hiring, people started hiring again, like crazy.

[00:11:33] And a lot of those people don’t have jobs now.

[00:11:36] 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.

[00:11:43] For very large engineering organizations to be having conversations about developer productivity.

[00:11:49] You know, certainly, like, if you had more than 1,000 engineers, this was obviously on your radar.

[00:11:54] Maybe it started earlier than that.

[00:11:57] But it wasn’t on the radar necessarily as a company that had 100 engineers or 50 engineers.

[00:12:03] And suddenly, everybody cares about developer productivity.

[00:12:09] Not literally everybody, but we are in business.

[00:12:12] Because.

[00:12:13] Suddenly, everybody cares a little bit more about developer productivity than they did.

[00:12:19] But even back then, you wrote about how, like, if you take the word developer productivity, or the words developer productivity, literally, the productivity of a developer, then you said, you know, to the extent you can reduce the job to a set of metrics, that job can be automated away.

[00:12:37] If we could measure this, we’d have a computer doing it.

[00:12:43] The only thing that actually matters is impact to the business.

[00:12:47] And there are both upsides and downsides, right?

[00:12:50] 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.

[00:12:57] But, like, then that’s not moving the business materially forward, which is another thing I often say.

[00:13:03] But it is absolutely, like, contributing to business stability, staying in business, not having terrible things.

[00:13:10] You know, and I think part of it, one of the biggest shifts of the past.

[00:13:13] 10 years is that there used to be a ton of teams and engineers inside businesses that were doing sort of cost center work, right?

[00:13:23] Keeping the lights on, supportive infrastructure, monitoring, you know, operations, data center.

[00:13:29] And we have really tried to, like, minimize those.

[00:13:33] We outsource those.

[00:13:34] For the most part, for most companies up to a certain size, you really want most of your teams moving the business forward every day in some way that is, you know, product-centric.

[00:13:43] And I think this is neither good nor bad.

[00:13:45] It just is, right?

[00:13:46] And it doesn’t mean that the people who do that sort of, like, I come from the side of the infrastructure, very protecting or downside, very enabling, right?

[00:13:55] So I get it.

[00:13:56] It’s painful adjustment, but it’s real.

[00:13:58] Which means that something I didn’t say in this post, which I’m so glad I had forgotten all about writing this.

[00:14:03] Sometimes I go to write it and I get through it and I’m like, this does sound familiar.

[00:14:06] Oh, shit, I didn’t write this.

[00:14:07] But I think the number one productivity tip is be working on the right.

[00:14:13] And this is not something that engineers can do alone, right?

[00:14:18] This is something that you have to be plugged in.

[00:14:21] This is why I hate the whole shit umbrella school of management.

[00:14:25] No, no, no, no, no, no, no, no.

[00:14:27] Your job is to keep your engineers connected to the business, right?

[00:14:30] To, like, make sure they have the context, understand what they’re doing so you guys can push back.

[00:14:35] The most devastating work is when the work that you do doesn’t actually get used or wasn’t.

[00:14:43] That’s one of the most depressing, debilitating experiences I’ve ever had, you know?

[00:14:49] So I feel like that’s one thing I didn’t mention, so I just wanted to throw that.

[00:14:53] You have to be working on the right things and that moving plugged into the business.

[00:14:56] But then beyond that, you know, yes, anything you can reduce to a set of metrics can be automated away.

[00:15:02] And in this blog post, I told the story of one of my early jobs in tech, which is basically kind of Unix tech support, right?

[00:15:10] And I got so good at closing tickets.

[00:15:13] My boss thought I was amazing.

[00:15:16] I gamed the fuck out of those metrics, right?

[00:15:19] I wasn’t doing anything sinister.

[00:15:21] I’m just like, well, this is what they’re judging me on, so crank, crank, crank, crank, crank.

[00:15:24] And so, like, I think developer productivity metrics really matter, but you can’t reduce it to some predictable set.

[00:15:33] They’re there to help you understand what’s happening, not to distort your behavior.

[00:15:39] There is a set of conditions required for it.

[00:15:43] And they’re very much the same set of things required for success for a normal engineer.

[00:15:52] But it’s interesting, like, some of them are technical, like you listed, but also some of them are super cultural.

[00:15:58] And so if you aren’t being, if you are, for example, a team that is being loaded to 110 percent, as a team, you don’t have a lot of, your main leverage is to quit.

[00:16:11] Right?

[00:16:13] As an individual on that team, you don’t have a lot of agency over that or over the interruptions that are coming to your team or the changes in priorities that are happening.

[00:16:24] Talking about Honeycomb in particular, like, how do you create the space for productivity to happen?

[00:16:31] Oh, God, it’s such a good question.

[00:16:33] It always makes me wince a little because I am immediately thinking about all the ways we do this imperfectly or stumbled or failed in the past.

[00:16:43] Or the things that we’ve realized belatedly, you know, but I will say that I think engineering managers are an undersung component of making this all work.

[00:16:59] You know, for a long time in the 2020s, in the early 2020s, late 2019s, I feel like it was all the rage to be like, well, we have engineering managers to do the people, people work, people leadership.

[00:17:10] We have tech leads to do the technical leadership.

[00:17:12] And, you know, and if you.

[00:17:13] You became an engineering manager, you were told to stop writing code.

[00:17:15] That’s not your job anymore.

[00:17:16] Don’t get involved.

[00:17:17] And like, this is, this is a, this is a little bit of a tricky minefield because it does make sense when a new engineering manager, like they want to go back to their safe place where they’re good at writing code.

[00:17:28] You know, and you need to like, sort of like forcibly yank them out of that.

[00:17:31] Right.

[00:17:31] Where are new skills learned?

[00:17:33] But like, I actually think that if you try to separate the people work, quote unquote, from the technical work and associate technical system, you’re making it.

[00:17:43] You’re really kneecapping both parties.

[00:17:46] I think that.

[00:17:48] And like with all the caveats that like people are complicated and flexible and lots of different configurations can work.

[00:17:55] And I’m not saying that can’t work.

[00:17:57] But like what I see when, you know, you’ve got a tech lead manager pair and the manager is not connected to the technical stuff at all.

[00:18:05] It actually just means that they have to outsource a lot of their judgment about people to someone else’s judgment.

[00:18:11] And that is ultimately.

[00:18:12] That does not give me confidence in that manager’s judgment.

[00:18:16] You know, and if I was someone reporting to that manager, I’d be like, well, now I have two buses, you know.

[00:18:20] And if the tech lead isn’t in lockstep with that manager at all time, there’s just so many.

[00:18:28] I think engineering managers being deeply technical and knowing how to knowing what it feels like.

[00:18:36] They should at least do a ticket every now and then.

[00:18:39] They should write code.

[00:18:39] They should know what it feels like to ship.

[00:18:41] You should know where the.

[00:18:42] 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.

[00:18:52] 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 without without that engineer and why the metrics are wrong.

[00:19:03] Right. Or how you should iterate and evolve the metrics to better capture certain kinds of, you know, you need there’s there’s this.

[00:19:10] Chain of leadership at every level, right from the CTO, VP, director, manager, and the manager is the part of the management chain that is closest to the ground.

[00:19:21] And they need to be able to have to be able to trust those managers, technical judgment.

[00:19:25] It’s such a big part of this.

[00:19:27] So this is another interesting topic to me because my own manager journey was like I was never going to be a manager.

[00:19:36] That sounded absolutely terrible.

[00:19:38] Like really awful.

[00:19:40] Absolutely.

[00:19:40] Not.

[00:19:41] I was going to write code for the rest of my life.

[00:19:43] And then I got a new job and I saw that there was a deep need to like they needed to like organization centered around front end infrastructure.

[00:19:54] They didn’t have one.

[00:19:55] And it was a mess.

[00:19:56] And front end was my thing.

[00:19:57] And that’s why they hired me.

[00:19:58] And so I had this moment of like, I can either try to find a manager I want to work for.

[00:20:04] Yeah.

[00:20:05] Or I can just be that manager.

[00:20:07] I decided to just be that manager.

[00:20:09] But that means I also.

[00:20:10] I grew up in the, in the 20, you know, late 2010s, 2020 time, a lot of people, a lot of managers were growing up out of necessity.

[00:20:19] And, and, you know, my, my experience is I’ve only had so many jobs.

[00:20:24] So I, my personal experience is, 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.

[00:20:39] And a lot of them became managers.

[00:20:40] In reaction to the long string of bad managers we had ever had.

[00:20:44] Yes.

[00:20:44] And I also love to tell new managers, like the only one-on-one you’ve ever been in is your own up until this moment.

[00:20:51] And so, but I, 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.

[00:21:02] And now, you know, now some of these are, are directors, like, and I think that, you know, I loved.

[00:21:10] I loved reading Camille’s book about the manager’s path, and that was really like a seminal book for me as I went down that, went down that path, but I think that nobody made you read that book.

[00:21:21] If you didn’t read that book, you’ve still got to be a manager.

[00:21:25] And if you didn’t listen to the podcast, like if you, anyway.

[00:21:29] So I think that’s an interesting component of where we are in, in technology today is that we’re kind of paying for the choices that we made.

[00:21:39] And they were, you know.

[00:21:40] All choices were good at the time.

[00:21:42] We were all doing the best we could.

[00:21:44] No, I think that’s very interesting.

[00:21:45] I think that 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.

[00:21:55] Most people are few and far between.

[00:21:58] Most of us became managers out of reaction or a desire to protect our, a desire to be that shit umbrella, right?

[00:22:03] I became a manager from like, we all just arrived at Facebook.

[00:22:08] I’m like, ah, fuck these people.

[00:22:10] I’ll be the manager.

[00:22:11] I will protect my team from horrendous Facebook.

[00:22:14] That’s terrible, right?

[00:22:15] But like, I don’t know, which is why I don’t judge anyone for the reasons they got into management.

[00:22:19] If it’s selfish ambition, you topped out your ladder.

[00:22:23] You want, like, I don’t, I don’t think it doesn’t really matter why you got power.

[00:22:26] What matters is what you do with it.

[00:22:28] Right.

[00:22:28] But I do feel like a lot of us who got into management kind of in a reactionary way, then had to, like, I think we often had this.

[00:22:39] Well, I’m never going to do.

[00:22:40] All these things that I’ve hated and all the managers, so that, of course, we made the opposite mistakes, right?

[00:22:44] Like, like we, those of us who went through the sort of like Silicon Valley, sleeping under your desk, working, you know, burning her up, came out being like telling everyone breaks, pace yourself, take time off.

[00:22:56] And it took a while for me to realize, actually, some people really don’t need to hear this.

[00:23:00] Some people actually really need to hear that they’re not actually putting in enough time or, or, you know, like, you just can’t, you can’t manage from a place of reaction.

[00:23:07] You really have to be connected to the reaction.

[00:23:10] You really have to be connected to the reality of what’s going on and you have to be able to like, yeah, uh, yeah, there’s a lot that could be said there, but yeah.

[00:23:19] Yeah.

[00:23:19] And it is, it’s also interesting that with late recently us, we’ve also seen that level is getting eliminated, um, or is being given such a large portfolio that it is, it’s not the job that it used to be.

[00:23:31] You know, whenever people talk to me about their careers and how to stay employed over the long haul, I, I really emphasize that.

[00:23:39] Management.

[00:23:40] Don’t be the first to be eliminated because engineers create value.

[00:23:44] Nobody else can do that.

[00:23:46] Right.

[00:23:47] Even with all of, I still stand, but even with all the, like, ah, coding.

[00:23:50] I still think that, like, 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.

[00:23:59] Because I think that’s the surest bet to a long career.

[00:24:02] I think it’s great to diversify your skill sets.

[00:24:04] I think it can only make you a more powerful technologist who spends time on the other side of the divide.

[00:24:09] And, frankly, I would say, if you have a job that is the longest lasting and the longest lasting opportunity to, to do that, then you are the best the most successful person in the industry you have ever met.

[00:24:09] it is so valuable to have people who used to be managers in your pool of ICs because some of the

[00:24:18] hardest times in your life as a senior leader are times when you can’t tell everyone the full story

[00:24:23] and and there are other people out there straight up lying about what happened and most ICs

[00:24:29] they’re so closer to the ICs right there’s this sort of oppositional relationship with their

[00:24:35] management which I get but you really have it’s so valuable to be able to have people who have

[00:24:41] been managers before who can be like all right kids but here’s what might be going on here’s

[00:24:46] something that if it was going on they couldn’t tell you right here is you know I just want to

[00:24:52] rain blessings down upon all of the former managers who are now ICs because it’s such a valuable part

[00:24:57] of the ecosystem yeah like as a manager to have that person on your team yes who can be be that

[00:25:04] voice yeah it’s

[00:25:05] it’s huge it’s almost like we scripted this but like we didn’t script this this much but like

[00:25:09] this leads right into our next the next topic it’s um is uh this pendulum this this like back

[00:25:17] and forth um of and that’s something you’ve really celebrated and championed um just like

[00:25:22] you just did now I’m seeing your blog post for I don’t remember when this one was from but I know

[00:25:28] it wasn’t yesterday uh like I’m seeing that blog post as well making the rounds as these managers

[00:25:34] who

[00:25:35] can you believe it to this day the most popular blog post I’ve ever written which really

[00:25:40] I love it is definitely making the rounds today I see it I see it routinely in channels about

[00:25:48] searching for a job from those managers who just got laid off um and trying to figure out um trying

[00:25:54] to figure out what is their what is their next step how do you help people get over a fear that

[00:26:03] they might have that this is like career

[00:26:05] limiting to go back I think it’s about investing in your career longevity um I mean mathematically

[00:26:14] speaking there are an order of magnitude fewer jobs available every rung of the ladder that you

[00:26:19] go up right there’s there’s about engineers to management you know somewhere between one and

[00:26:26] five to one and ten uh managers to directors you know there’s bps you know ctos you know

[00:26:31] there’s an order of your so you know and which is

[00:26:35] part of this is always going to be opportunistic right some people are in the right place at the

[00:26:40] right time and they climb the ladder like nobody’s business good for them that a lot of luck went

[00:26:45] into that you know and i think a lot of people try to put themselves in the right or they chase

[00:26:51] i i think opportunism is honestly the best career strategy trying to set yourself up for being you

[00:26:58] know in a place where there’s going to be opportunities but sometimes lightning doesn’t

[00:27:01] strike right and if you’ve got if you got your your heart set you’re just gunning to check i

[00:27:07] really think that that is it’s limiting like yes you know people get paid more and you just run

[00:27:12] the ladder but i feel like those jobs are also more fragile and it can be a lot harder to find

[00:27:18] a new job the higher you go up this is why you know if if you’re like director and above you

[00:27:24] only find jobs via like special placement recruiter firms like you can’t just apply for jobs it’s all

[00:27:30] a lot of it’s word of mouth

[00:27:31] very clubby you know a lot of like small because because hiring gets very conservative at those

[00:27:37] levels they don’t want to take risks on people you can take a risk on an engineer if you’re

[00:27:42] hiring a director vp you are crossing your fingers and praying to god and lighting a candle

[00:27:48] this person will be the right person like and i know because i’ve been hiring these execs

[00:27:52] we are also very conservative when it comes to you only want someone who’s done this before because

[00:27:58] the future of your company sits in their hands right

[00:28:01] so i i feel like people should be aware of that trade-off right uh and i feel like continuing to

[00:28:07] invest in being someone who has it is not career limiting oh my god it is career extending you can

[00:28:13] always find work creating value and i’m seeing i’m trying to think about like 2017 geez i know

[00:28:21] you know can i tell you a little story about how that webcube came apart it was a love letter to a

[00:28:26] friend of mine who was a director of engineering at slack at the time he had a lot of experience with

[00:28:31] building and he was just miserable he was so unhappy and i was meeting up for drinks with him

[00:28:37] you know every other week or so we were both pretty miserable but i’m like your your solution

[00:28:42] is easy just go be a principal and he’s like and i wrote this blog post for him because i was like

[00:28:49] i see you becoming more powerful than you ever were before you’re in ic everyone knows you

[00:28:55] everyone trusts you you can write your ticket you get and he did he went on to be principal

[00:28:58] engineer and he spearheaded so many of the things that he did and he did it and he did it and he did it

[00:29:01] the slack technologies that we now love and take for like this a lot of the security stuff

[00:29:06] like multi-login stuff like he his career just like fucking exploded after that and so i feel

[00:29:13] like yeah obviously i was proven right and that gives me great joy i feel like he was he was like

[00:29:20] an early canary for like what a lot of people have experienced you honestly your career is unlikely

[00:29:26] to take off while you’re miserable part of the reason i was trying to go back to 2017 is like

[00:29:31] i was still we were still in the throes of like like hire everybody you can and pay what you have

[00:29:36] to and free lunch and um you know all of it oh such good free lunches um like we were in the

[00:29:45] in the throes of that and i think a lot of people didn’t the future was the future was granted

[00:29:50] like the future was known they would just keep doing this hyper growth yeah so many hyper growth

[00:29:57] companies again that blog post has turned out to be really prescient today

[00:30:01] when this is not a choice that people are making just because they’re miserable just

[00:30:06] air quotes because they’re miserable um it’s a choice that people are are having to make to

[00:30:12] pay bills yes um and you know you said like it makes you happy to be proven right i think

[00:30:17] like part of why i was so excited to talk to you is you seem to be pretty right about a lot of things

[00:30:24] in software engineering um you said that not me this is security

[00:30:31] i will say it and especially when you realize when you remember that like yeah that post was

[00:30:36] written in 2017 it seems like a few days ago to me um but uh yeah i think that i’m really

[00:30:44] i love the work that you do to speak out um about these things because i do think that

[00:30:51] you’re mostly right and i think that a lot of people know these things to be true but saying

[00:30:56] it is scary um for for whatever reason so what like what is it that makes it

[00:31:01] not scary for you to i think i have always gotten a lot of joy and pleasure out of being contrary

[00:31:12] honestly is it contrary if you’re right is it contrary i don’t know i don’t know it doesn’t

[00:31:19] it doesn’t bring me the joy to say something that everyone else is saying like why would you say it

[00:31:23] like being like so i i think i’ve mellowed as i’ve gotten older but i was very much in that

[00:31:28] you know but also i feel like

[00:31:31] those of us who come from the operations side of the house have always been a little bit more

[00:31:35] reality tethered than the people who are like starry-eyed about the future which is why i think

[00:31:41] it’s so unusual that i am a company founder ops engineers do not start companies because

[00:31:47] you need a certain amount of reality distortion field as a founder just a starry-eyed like the

[00:31:53] future and those of us ops sre are more likely to be like i hear your bright idea here’s how

[00:31:58] it’s going to fail but we’re doomed right and so i think it’s really important that we’re

[00:32:01] right that you’re doomed is runs deep in me and it’s a complete accident of history that i’ve

[00:32:06] turned out where i am and i’ve had like you know company doesn’t want to hear that we’re doomed so

[00:32:11] i really try to like you know uh but it is it is deeply weird and i just want to acknowledge that

[00:32:16] i just appreciate i appreciate your continued corrections um we are about to wrap up here so

[00:32:23] my last question to you is uh what is your what’s your current hot take about the state of the

[00:32:29] software engineering industry

[00:32:31] ah i mean how could it not be about ai right that’s all everyone’s talking about my hot unhot

[00:32:37] take uh depending on if you go to srecon then you’re probably like this is obvious uh but i i

[00:32:45] think nine times out of ten when you hear someone make a statement about ai you could substitute

[00:32:53] the word automation for ai and it would be just as true so there’s like not a lot of the stuff

[00:33:01] that ai is bringing to the industry is not new it’s just an acceleration it’s just we’re just

[00:33:06] leaning the complexity of systems that not 10 times out of 10 right like they’re the the

[00:33:12] introduction of uh non-determinism what does it mean to have an api now you know the mcp stuff i

[00:33:18] think is super interesting so much of it is just automation right and so the people who are

[00:33:26] predicting that we’re not going to need engineer oh you sweet summer child you know it we’re

[00:33:31] generating more code more worse code than ever uh you know and and so uh i i’m confident there

[00:33:40] will be jobs for software engineers in the future but but i do think that you know that being

[00:33:45] tethered to reality is more important than ever and and fred haber my co-worker fred haber and i

[00:33:51] gave a keynote at srecon this this spring where you know there are people on the product side

[00:33:56] who are just like off to the races everything’s going to change agi you know and then you know

[00:34:01] there are sre’s who are like uh none of it’s going to work that’s not true either and my

[00:34:08] challenge to those people was we want to be in the conversation we we need to be part of the

[00:34:16] conversation those of us who look on that you know what’s going to fail what isn’t going to work

[00:34:20] they need but they’re not going to bring us to the conversation if we’re just doom and gloom if

[00:34:25] we’re not acknowledging the potential if we’re not acknowledging the amazing things that we are

[00:34:31] right so like we need we have a responsibility to learn and use and try and play around and like

[00:34:38] come along be in the conversation so that the warnings that we issue land you know everyone’s

[00:34:45] a critic these days it’s not hard to be cynical i think what’s hard is to be a builder uh but to

[00:34:52] be a builder who is grounded in reality and who retains their ideals and their sense of ethical

[00:34:57] obligations to each other i feel like you just gave a talk to

[00:35:01] my impression of younger charity i think so i think i love it though and i think i think that’s

[00:35:09] like exactly and i think that’s been a big lesson to me too over the years is like you can’t be

[00:35:15] contrary and and be invited to the conversation you can’t be contrary for the sake of being

[00:35:20] contrary you have to be contrary while trying to move while trying to help get to the future you

[00:35:26] know yes yeah well on that note um thank you so much

[00:35:31] i cannot believe that the first time i got to talk to you uh was recorded for the whole world

[00:35:35] to hear so here we are i feel like we could have kept talking all day so oh my gosh i i want to

[00:35:41] like talk to you for another hour about all the things that we didn’t talk about in the notes

[00:35:44] yes at some point but this was really amazing thank you so much thanks for having me it’s

[00:35:51] really fun of course and that’s the show engineering unblocked is brought to you by

[00:35:56] swarmia the engineering intelligence platform trusted by some of the best software companies

[00:36:00] in the world see you next time

[00:36:01] you

Vox

Explorador