@charity-majors · 50 positions · 1 change of mind · On ppll ↗
Co-founder and CTO of Honeycomb, previously an infrastructure engineer at Parse, Facebook and Linden Lab. Co-author of "Database Reliability Engineering" and "Observability Engineering". Writes at charity.wtf about on-call, hierarchy, hiring and the engineer/manager pendulum.
Charity Majors did not write this page.
We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording.
Their own site.
Is this you? Claim it or ask us to remove it.Or tell us what is wrong here.
Each column is a stretch of time in which the same views came up; a new column starts when one appears or goes quiet. Quiet means nothing on it in our sources for that stretch, which is not the same as a change of mind; Dropped means they said they no longer hold it; tap the card for which claim and when. Revised means the view carries on but one of its claims was dropped. Each row is one view, in the same place all the way along. The number is how many claims in that stretch; we hold 4 in 2017, 0 in 2018, 0 in 2019, 0 in 2020, 0 in 2021, 8 in 2022, 0 in 2023, 13 in 2024, 0 in 2025, 26 in 2026.
Management and engineering are separate jobs; the best people move between them instead of doing both at once
Our label. 4 claims in Charity Majors's own words.
Their wordsManagement is highly interruptive, and great engineering — where you’re learning things — requires blocking out interruptions. You can’t do these two opposite things at once.
Their wordsgreat engineers really shouldn’t need to manage large teams to get promoted, and companies lose out on a critical skillset when they push all of their good engineers into management.
Their wordsThe best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches. The best individual contributors are the ones who have done time in management.
Their wordsBeing on call should not be a constant cycle of things breaking down and firefighting, or alerts going off at all hours. This is not ‘normal.’ These are telltale signs of a fragile system and lack of alert discipline.
Their wordsBut I also think that in my mind, 20 years of DevOps was really about one thing. Trying to create one feedback loop that connected people writing code to that code in production. And it failed.
Their wordsThat was always a bad idea because it's split brain. Half of you are writing the code and the other half are understanding it. I would argue that you can't really understand the code you write unless you're operating it.
Their wordsAs soon as you merge, it should be going out. You like you should have to stop the train to make your code not go into production as soon as you've merged.
Their wordsit's always weird to me just how much software engineers really seem to believe that the world exists in the repo. It doesn't. It's production, you know?
Their wordsBut if there’s one thing we know, it’s that for industries that are fueled by creativity and innovation, command-and-control leadership is poison.
Their wordsThe Tyranny of Structurelessness has yet to be overcome, and for those who still care about creating strong, transparent, equitable organizations, this work matters.
Their wordsOn the other hand, the manager-free experiments I’m aware of (e.g. holacracy at Medium and GitHub, or “Choose Your Own Work” at Linden Lab) have all been quietly abandoned or outgrown.
Their wordsIf you aren’t making building the organization someone’s number one job, it won’t be anyone’s number one job, which means it probably won’t get done very well.
Their wordsBut everything I have ever experienced leads me to believe that a fewer number of larger teams, each helmed by an experienced engineering manager, should way outperform this gaggle of tiny groups.
Their wordsBut hierarchy is not intrinsically authoritarian. Hierarchy did not originate as a political structure that humans invented for controlling and dominating one another, it is in fact a property of self-organizing systems, and it emerges for the benefit of the subsystems.
Their wordsEarlier this year I started writing a piece on why “hire great people and get out of their way” is such terrible, dangerous, counterproductive advice to give anyone in a leadership role.
Their wordsHere’s one small mental hack that makes a world of difference: remember that you are trying to hire the right people to join your team/org/company.
Not the “best” people.
The right people.
Their wordsyou want to hire people for their unique strengths, not their lack of weaknesses. If they’re strong where you need them to be strong, it’s okay if they aren’t equally superpowered at everything — that’s why we build teams, to supplement and balance each other out.
Their wordsYou should ALWAYS have as few employees as possible. Always. Hiring more people should never be the first lever you reach for, it’s what you do after exhausting your other options.
Their wordsYou can use AI as a shortcut to help you not have to think too much. And you can use AI to help you think more deeply and more rigorously. And both of those use cases have their place. But when it comes to your core job function, we primarily want the second one, right?
Their wordsHere's a baseline. Uh you cannot send anyone something you haven't read. And in fact, if it would take them longer to read it than it took you to make it, it's probably slop.
Their wordsAnother another thing we point out is just there is no human in the loop. You own the loop. The loop is yours. The loop is mine. It would not exist if it was not for me. So I am the owner, right?
Their wordsOkay, if I'm not going to read this code, how do I know it's going to perform within boundaries of the last code that I generated? That is conformance testing.
Their wordsIt's like they have all the wisdom of their most senior engineers looking at every single diff and that is fantastic. Which means that you don't have to worry about remembering and looking and nitpicking and all the things that we're not good at anyway
Their wordsLike that just does not seem like the ideal artifact. We should be able to store them somewhere. We should be able to have architecture diagrams that we can review and discuss that generate that code to spec.
Their wordsIt's like we need to hear the wins. We need to hear what's We need to hear about what's possible. We need to hear what's exciting. But you got to couple it with the costs.
Their wordsOne of the things that's ironic though is that both of these sides feel like they are the tiny minority and they're outmanned and they're being suppressed and they are standing up for what is truth and valor in the face of the big AI folks or the big skeptics.
Their wordsWhat I was saying in that piece though was, I think we were right to be skeptical that time. But now, I see the same thing playing out with would you be willing to ship it some code you didn't read? There's no point in arguing about if it will happen or when it will happen. Talk about what it would take.
Their wordsThe hardest thing about quantifying the value of junior engineers is that we don't know how to quantify the value of any engineer. So it's all vibes.
Their wordsWe can go fast. Let's do same thing faster, you know, just boom. And I've come to feel like that is a very immature description of what better is.