Charity Majors · charity.wtf
You Cannot Read Your Code And Know What It Does

One strange thing

In October 2019, Charity Majors laid out two companies and asked readers to find the difference.

Company X is three years old: a large, fast-growing multi-tenant platform on a big distributed system with spiky traffic, lots of user-submitted data, and a very green database. It ships the API about once a day and does a global deploy of all services every Tuesday. Deploys often involve firefighting and a rollback or two, and Tuesdays are frequently a whole day of shipping and reverting. Pager volume "isn't the worst" — it usually means getting woken up a couple of times a week — and roughly a third of deploys throw an alert that then has to be triaged to work out whose diff caused it.

Company Z is three years old: a large, fast-growing multi-tenant platform on a big distributed system with spiky traffic, lots of user-submitted data, and a very green home-built columnar storage engine. A merge to master automatically triggers a deploy of every affected service within 30 minutes. Deploys rarely page anyone, because most problems are caught visually by the engineer who made the change and fixed or reverted before an alert can fire. Roughly one alert per week outside working hours, and nobody is woken up more than a couple of times a year.

The two have an absurd amount in common. Both are platform products for developers. Both run highly elastic microservices in Go. Both take lots of spiky traffic. Both store user-defined data in a young, homegrown columnar engine. They even share four of the same developers.

Then the reveal: these are Majors' own last two jobs. X is Parse (2012–2016), Z is Honeycomb (2016–present). They built the infrastructure at both.

So whatever turns "twice a week" into "twice a year" cannot be the stack, is unlikely to be raw talent, and is almost certainly not luck. Majors thinks it has exactly one source, and that the industry systematically underinvests in it: the interval between an engineer writing a line of code and that engineer seeing what the line did to a real user.

Who this is

Charity Majors left home at fifteen, out of what they describe as a "fundamentalist and misogynist af" upbringing. Their first job title was System Administrator — as a teenager, working at a university, holding root on every machine on campus, in what they call the days before people learned they should definitely not do that.

From 2012 to 2016 they were at Parse, helping it grow from a handful of apps to over a million, and through an acquisition by Facebook. In 2016 they cofounded Honeycomb with Christine Yen and have been CTO since. They co-wrote two O'Reilly books, Database Reliability Engineering and Observability Engineering (second edition, 2026). The blog runs from 27 December 2015 to today, 127 posts, no visible dry spell, and moved from WordPress to Substack in December 2025 — for which they wrote a dedicated post whose reasoning is not ideological but ergonomic: WordPress "feels so heavyweight," Substack feels "more like writing an email," and they hoped that would make them post more. They also committed to never taking paid subscriptions.

On pronouns: in a 2025 post on exactly this subject, Majors writes that their pronouns are "she/her or they/them," and adds, "I've never felt any affinity with feminine pronouns or identity, but I don't care enough to correct anyone or assert a preference for they/them." This page uses they/them. Incidentally, the argument of that post is that making it safe to share pronouns is good and mandating that everyone share them is bad — and the first reason given is "I resent being forced to pick a side in public when I'm just trying to do my goddamn job." You will meet that sentence structure everywhere in this blog.

What they're fighting

Filing Charity Majors under "observability evangelist" is accurate but backwards — that's the conclusion, not the question. The thing they haven't put down in eleven years is much plainer, plain enough that almost nobody treats it as a problem:

You do not know what your code does.

Not in the sense that you might have an undiscovered bug. In a more basic sense: reading won't tell you, because code expresses intent rather than behavior; tests won't tell you, because tests only cover the cases you thought of. The only way to know is to put it in front of real users and go look.

You'll never know — not really — what the code you wrote does just by reading it. The only way to be sure is by instrumenting your code and watching real users run it in production. "In Praise of 'Normal' Engineers", June 2025

How they arrived at this matters more than the argument, because they were tortured by it for four years first.

Parse was a backend-as-a-service: app developers worldwide threw their data models, queries and business logic at it, and Parse ran them. Which meant that most of the code running in Parse's production environment was not written by Parse. It was written by a million strangers, and it changed constantly. Any one of them could write a bad query and put Majors on the floor at 3am. And the monitoring available could tell them that overall latency was up — not which app, which user, which query.

They later described Parse in 2013 as "a trash fire." The turn came after the Facebook acquisition, when they started feeding datasets into an internal Facebook tool called Scuba. Scuba's interface was ugly, but it did the one thing nothing else did: it stored the full context of every request as one wide record, and let you slice it any way you liked — including in ways you only thought of at the moment you asked.

That is the hinge. Honeycomb is essentially "make Scuba into a product anyone can buy," and everything written since is an attempt to generalize one private experience into a public claim.

It's worth being precise about the shape of that claim. It is not "buy better monitoring." It is: you cannot understand a system you get no feedback from, and nearly every dysfunction in software — technical, organizational, and now AI-shaped — is the same thing wearing different clothes: a feedback loop stretched out or cut. And the second move is always identical: when you find a broken loop, don't add a rule. Shorten the loop.

The four ideas below are one screwdriver turning four screws.

The ideas, told as the discovery

01Ops is not a role. It is an emergent property.

May 2016, the first Serverlessconf in New York. The organizers invited Majors to speak. They turned it down, accepted, backed out, and accepted again at the last minute. The stated reason is blunt: they thought the attendees wouldn't want to hear what they had to say.

They had just come out of Parse. The room's slogans were "the future is serverless!" and "#NoOps!"

I've lived the other side of this fairytale. I've seen what happens when application developers think they don't have to care about the skills associated with operations engineering. When they forget that no matter how pretty the abstractions are, you're still dealing with dusty old concepts like "persistent state" and "queries" and "unavailability" and so forth. "WTF is operations? #serverless", May 2016

But they didn't stop at grumbling. They did something more interesting: they went home and redefined the word. That definition is the pivot of the whole essay.

At a macro level, operational excellence is not a role, it's an emergent property. It is how you get shit done. Same

The analogy offered is nasty and hard to escape: saying you have an ops team solely responsible for reliability is about as silly as saying "HR defines and owns our company culture!" Culture is emergent; everyone from the CEO to support contributes, and a couple of bad actors can spoil the bushel. Reliability works the same way.

Why does this matter? Because if ops is a role, then "make ops responsible for stability" is a sane org design. But if it is an emergent property, then carving it out and handing it to another team is itself an act of cutting a feedback loop — the people writing the code stop bearing its consequences, and therefore stop receiving information about it. This is the org-chart version of the root problem.

That October they demonstrated the method. A company called CleverTap published a write-up of losing data during a MongoDB upgrade, concluding that MongoDB was bad. Majors read it grinding their teeth, and enumerated what had actually been done: within three days, a major version upgrade and a storage engine swap, simultaneously, with zero secondaries left holding data in the old engine. Then this:

But *I* can criticize Mongo all day long. You children on hacker news who have never run it don't get to. If you don't know what the fuck you're talking about, if you're cargo culting other people's years-old complaints, just shut up already. "The Accidental DBA", October 2016

The constructive half is their own Parse experience. Moving from MMAPv1 to RocksDB, they ran hybrid replica sets for six to nine months, spent half a year capturing production workloads and replaying them, electing Rocks primaries and rolling back, keeping snapshots and secondaries of both engines for months. The governing principle: the closer you get to laying bits down on disk, the more conservative and afraid you should be. That sentence reappears verbatim in their 2026 writing.

Then, twenty years later, the reckoning. In January 2026 they published a piece on the Honeycomb blog titled "You Had One Job: Why Twenty Years of DevOps Has Failed to Do It." The verdict:

In retrospect, I think the entire DevOps movement was a mighty, twenty year battle to achieve one thing: a single feedback loop connecting devs with prod. On those grounds, it failed. quoted in "Bring Back Ops Pride", January 2026

And the reason for failure is not that engineers didn't care — it's that the tools weren't good enough. Connecting that loop with those tools could double, triple or quadruple the time it took to do the actual job of writing business logic, so rational people didn't do it.

That post also assigns blame. Why is "ops" a slur only in software, when business ops, marketing ops, sales ops and product ops are treated with ordinary respect?

Whose fault is it? Google. It's Google's fault. I know this, because I asked Google and it told me so. "Bring Back Ops Pride", January 2026

Underneath the joke is a serious claim. Google said traditional operations couldn't scale and had to become more like software engineering, which was the right message at the right moment. But a crucial distinction was lost in translation — people started reading it as developers (who write code: good) versus operators (who do things by hand: bad). Majors insists the real distinction is not whether you write code ("Dude, it's 2026: everyone writes software") but a separation of concerns: if your concern is new features and new revenue, you're a dev; if your concern is keeping core services serving customers in the face of all threats — including, top of the list, your own developers — you are in ops.

They also invert the industry's status ladder. Product engineering is typically simpler than infrastructure engineering, precisely because one of ops' core functions is to absorb the hardest technical problems and present product development with a surface that is simple and reliable. Not because product engineers are lesser, but because cognitive bandwidth is the scarcest resource in any engineering org.

The cost and pain of developing software is approximately zero compared to the operational cost of maintaining it over time. Same

02Fear is the biggest technical debt, and deploy interval is the master variable

April 2019. Someone tweeted an ASCII bunny holding a "Don't push to production" sign for Friday. Majors hadn't seen that sentiment in years and thought the zeitgeist had moved on. So they replied — and note how they later described their own reply:

So I responded with an equally hyperbolic and indefensible claim: "If you're scared of pushing to production on Fridays, I recommend reassigning all your developer cycles off of feature development and onto your CI/CD process and observability tooling for as long as it takes to ✨fix that✨." "Friday Deploy Freezes Are Exactly Like Murdering Puppies", May 2019

They assumed it would read as tongue-in-cheek. "I was wrong there too." The internet detonated.

What got detonated out is the point of the story. Forced to handle a tide of objections, Majors had to expand an intuition into a full argument, and it has three layers.

Layer one: the cost isn't Friday, it's the fear. They itemize the bill — engineers waiting until it's "safe," batching changes into bigger changes that are genuinely unsafe, debugging broken deploys with many changes glommed together, waiting nervously to get paged, working out whether now is a good time, and cleaning up afterwards. The conclusion: in many orgs, deploy anxiety is the single largest source of technical debt. And technical debt is not the same as bad code — tech debt hurts people.

Deploys are the heartbeat of your company. […] Every time your production pipeline stops, it is a heart attack. Same

Layer two: the loop is self-reinforcing, in the direction opposite to intuition. Intuition says slow down when uncertain. Citing the DORA research and Accelerate, Majors argues deploy velocity and low error rates are not in tension — improve one and the other improves too. So slowing down, batching, and pausing are actively making your own state worse. Both escapes are closed off: block merges on Fridays and you sacrifice a fifth of your output; block only deploys and you queue up a pile of changes to ship days later, long after the authors have lost half their context — so are you spending Monday on it, or Monday and Tuesday, or Monday through Wednesday?

Layer three, the one they actually want:

Policies (and enumerated exceptions to policies, and exceptions to exceptions) are a piss-poor substitute for judgment. Rules are blunt instruments that stunt your engineers' development and critical thinking skills. Same (quoting their own tweet)

They fully endorse good deploy hygiene: don't ship as you walk out the door on any day, don't ship big gnarly features right before the weekend, use feature flags to decouple deploys from releases. But they want habits, not bans — because bans are precisely what prevents judgment from developing.

The essay ends on something that clearly upset them: an alarming number of people privately admitted Friday freezes were useless or counterproductive but supported them anyway, as a symbolic gesture showing they cared about work/life balance. The response is the sharpest line in the whole affair:

Blocking Friday deploy is not a mark of moral virtue; it is a physical bash script patching over technical rot. And technical rot is bad because it HURTS PEOPLE. Same

Six months later someone published a long rebuttal (Majors called it "basically a very long subtweet"). This round is the template for their whole method. The first reaction isn't counterattack, it's "we are actually in violent agreement, almost entirely." Then they pick exactly one sentence to hit — the author had written that they'd always taken glee and pride in being extremely (overly?) protective of their engineers' work/life balance. The dismantling:

You just performed a substitution. You defined "not deploying on Friday" as synonymous with "protecting engineers' work/life balance." Whereas the entire argument is that the practices bundled with blocking Friday deploys are hurting your engineers. Majors, too, is extremely and even overly protective of their engineers' hours — and that is why we deploy on Fridays.

Then out come the two companies. X and Z, matched nearly line for line, four developers in common, one waking people twice a week and the other twice a year. The difference reduces to three things: observability; observability-driven development (instrument as you write, make "how will you know if this is broken?" a code-review habit, build the muscle memory of going to look after every deploy); and a single merge per deploy.

On that last one they give a purely cognitive argument that I think is the most persuasive passage in the piece. After you merge, exactly one of two things happens: either you promptly pull up a window and watch it roll out, checking whether the instrumentation says what you expected and whether anything looks weird — or you close the project and open a new one. And the moment you switch projects, your brain starts rapidly evicting all the rich context about what you had intended, overwriting it with the new project's details. That isn't a discipline failure, it's how brains work. So the price of deploying hours or days after merge is that you permanently lose the one person capable of spotting the problem at a glance.

They claim 80–90% of problems could be caught right there, before users notice and before alerts fire.

The counterintuitive part is the empirical finding, which they say surprised them and was not conventional wisdom at the time:

Our systems were more stable when we always shipped right after the changes were merged. Our systems were less stable when we carved out times to pause deployments. "Deploys: It's Not Actually About Fridays", October 2019

In 2025 this got pushed into a more general form. "In Praise of 'Normal' Engineers" attacks the "10x engineer" not on political grounds but on pipeline grounds:

Everyone uses the same software delivery pipeline. If it takes the slowest engineer at your company five hours to ship a single line of code, it's going to take the fastest engineer at your company five hours to ship a single line of code. "In Praise of 'Normal' Engineers", June 2025

Which yields what may be the single most portable standard in all their writing: a great engineering org is not one stocked with the best people, it's one where perfectly ordinary engineers can consistently do good work. Their own phrasing is less polite:

Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. Same

And they identify the failure mode in treating individual agency as the explanation: putting all the spotlight on individual ability lets your leaders off the hook for doing their jobs. Plus a quiet line carrying a lot of weight — "Talent may be evenly distributed across populations, but opportunity is not."

03Metrics discard the context at write time

This is the technical core, and the path in runs through the invoice, not the architecture.

In early 2024 Majors noticed something: everyone complains about costs, but when people talked about their observability bill there was a particular edge in their voices. The read was that this wasn't only about money:

I think it's because people are beginning to correctly intuit that the value they get out of their tooling has become radically decoupled from the price they are paying. "The Cost Crisis in Observability Tooling", January 2024

Note what "radically decoupled" means concretely. The happiest case is that price rises several times faster than value. For an alarming number of people, the value actually decreases as the bill goes up.

Then they went and counted — the signature move, turning a vague grievance into a number. The number is the multiplier: how many times are you paying to store data about the same request?

The evolutionary path is vividly told. Everybody has logs, so you spin up log aggregation. But logs are expensive and everyone wants dashboards, so you buy a metrics tool. Engineers want to instrument their applications, so you buy APM. You unbundle the monolith and can't understand anything without traces, so you buy tracing. Front-end says they need sessions and browser data, so you buy RUM.

Logs, metrics, APM, traces, RUM — the same request, stored five ways, in five places, paid for five times. And 5x is the modest end, because plenty of companies also run multiple overlapping tools in the same category.

Only after the counting does the architectural diagnosis arrive, and it lands on one specific phrase: at write time.

A "metric" consists of a single number, often with tags appended. All of the context of the request gets discarded at write time; each individual metric is emitted separately. This means you can never correlate one metric with another from the same request. Same

That sentence is the fulcrum. Because the context is discarded at write time, it is unrecoverable — no amount of later money or cleverness brings it back. At the moment of collection you have already decided which questions you will ever be able to ask. And the difficulty of debugging real systems is precisely that the question you need is the one you didn't think to ask.

In August 2024 came the move that drew the most fire: assigning version numbers. The three-pillars generation becomes "Observability 1.0"; tools built on arbitrarily-wide structured events with a single source of truth become "Observability 2.0." The justification is what semantic versioning was invented for — major version bumps are reserved for backwards-incompatible breaking changes:

You cannot simultaneously store your data across both multiple pillars and a single source of truth. Incompatible. Breaking change. "Is it time to version observability? Signs point to yes", August 2024

From that one storage change they derive a chain of consequences, and the two most interesting have nothing to do with technology and everything to do with who is allowed to debug.

In the 1.0 world you flip between dashboards pattern-matching with your eyeballs, leaning on intuition, experience and a mental model. Therefore — and this is the sharp bit — the best debuggers are always the engineers who have been there longest and seen the most. In the 2.0 world you don't need the perpetually out-of-date mental model; you interrogate the data and follow the breadcrumbs. Therefore the best debuggers are the people who are the most curious.

The other concerns the nature of questions:

When it comes to understanding your software, it's often harder to identify the question than the answer. Once you know what the question is, you probably know the answer too. Same

And a static 1.0 dashboard is only useful once you already know what you're after — "you need to know to look for it before you can find it."

The most counterintuitive passage identifies the psychological trap. Many teams believe they have to get a handle on 1.0 before they can adopt 2.0, which gets things exactly backwards, because 2.0 is simpler and cheaper.

Observability 1.0 *is* the hard way. It's so fucking hard. We've been doing it so long that we are blind to just how HARD it is. Same

The image offered is entire teams of engineers spending whole careers massaging cardinality to control costs. Then comes an almost gentle question — "What if you just .. didn't have to do that? What would you do with your lives?"

Worth recording: the essay ends by publicly calling for more 2.0 tools that are not Honeycomb, stating outright that "the world desperately needs an open source analogue to Honeycomb," and advising people to stop founding metrics-based observability startups because Datadog and Prometheus are the last winners on that road. It is the most persuasive step in the piece: someone selling 2.0 publicly wishing for more competitors selling 2.0.

04Code isn't understanding. It's a cache of understanding.

In 2026 the same blade went into AI. The posture of entry is worth noting: they were not initially excited. Honeycomb issued an AI mandate in August 2025, and Majors describes being all in on AI while not being "super excited about it, in my heart of hearts."

The first thing they did was diagnose the argument itself — and the diagnosis is, of course, a broken feedback loop.

The scene: at a conference, a speaker showcased astonishing results achieved by pure vibe coding, and managers in the hallway were excitedly saying they'd finally have proof to overcome their resistant engineers. But Majors knew other people at that company, who described the same projects as a horror show, with teams still grinding through cleanup months later.

The wins and costs are happening to two different groups of people. There is no natural feedback loop. […] It has become very easy to do things without context or mastery, and the downstream costs are often invisible to the person who incurs them. All they see is the win. "AI enthusiasts are in a race against time, AI skeptics are in a race against entropy", June 2026

They refuse to take a side, because both sides are right. The enthusiasts are not wrong: teams that sit this out could be out of business before the dust settles. The skeptics are also not wrong:

When you ship code faster than engineers can read it, in domains where nobody has full context, you are making withdrawals from a trust account that took years to build. Same

Two weeks later came the positive claim, which matches neither camp.

The hinge was reading Chad Fowler's writing on Phoenix Architectures. Two or three essays in, it clicked — they could predict what he'd say next. The line they credit with doing it is Fowler's: when regeneration is easy, code stops being an asset and starts acting as a cache — a materialized view of understanding, useful while current, disposable when stale.

Why did it land so fast? Because they had lived through a structurally identical transition. Their first title was sysadmin; they lived the shift from handcrafted server pets to immutable infrastructure. From the final chapter of Observability Engineering, 2nd edition:

The shift from handcrafted servers to immutable infrastructure taught us that mutability is the sworn enemy of understanding. Any artifact that is edited in place creates drift. Drift is what makes systems impossible to maintain. quoted in "AI demands more engineering discipline. Not less", June 2026

There is one detail here so concrete it functions as physical evidence for the whole philosophy: at Honeycomb, a cron job kills off the oldest Kafka node every Tuesday. Not a drill — routine. The stated reason: that is exactly why they are confident in their bootstrapping and rebalancing processes. Everything is repeatable, the data can be regenerated, and the commitments live elsewhere.

Then the inference:

The fact that we cannot regenerate our code in the same way is a sign that we do not understand it. We do not know which commitments we have made, we do not know which dependencies will break. We find them by breaking them, mostly. Same

Notice the elegance of that step. "We can't just throw the code away and rewrite it" used to be a virtue, a proper respect for complexity. It gets reclassified as a diagnosis — evidence of ignorance rather than evidence of prudence. Code becomes precious when it is the only place knowledge lives.

From there comes the conclusion that offends people. If code is cheap, engineering's center of gravity should shift from producing code to validating behavior — and those techniques already exist, having long been looked down on by software engineering, because they come from operations and QA. Behavioral tests, characterization tests, capture/replay, traffic splitters, observability. These don't test what ought to happen; they observe and encode what is happening.

Then the least forgiving line:

Human brains are not good at validation. The nitpickiness, the repetition. […] We are never going to beat the machine when it comes to validation — we are literally the weakest link! […] PLEASE do not rest your killer argument for humans in software on us being the best quality gate. Same

The real destination is to turn AI into an argument for the thing they've been arguing for a decade: nondeterministic systems require more engineering discipline, not less. They even confess the strategy — the industry has refused to invest in short feedback loops, instrumentation and production validation for years, and now that "every CEO in existence is chomping at the bit to get some of those AI cookies," maybe it finally will. Their phrasing: "Discipline first, cookies second."

And here is the number most worth remembering, because it is simultaneously their ambition and their confession:

The share of software engineering teams that work in short, fast feedback loops (the cardinal sign of discipline in my book) is, and always has been, appallingly small. Five percent, maybe? Definitely less than 10%. Same

In other words: eleven years of writing, wide citation, two O'Reilly books — and by their own estimate the adoption rate is under ten percent.

How they think

1. Deliberately float an indefensible claim, then use the objections it draws to locate the real weak points in your own argument. This isn't my inference; it's their own wording — "an equally hyperbolic and indefensible claim." They knew it was bait. What matters is the second half: having been detonated, they didn't defend. They swallowed six months of counterargument, reorganized, produced a far stronger essay, and explicitly wrote "I was wrong there too" inside it. Public argument is being used as peer review — crude, loud, and extremely fast. Which is itself a short feedback loop.

2. Convert a vague grievance into a countable number. Everyone complains observability is expensive — that's a mood. They asked: what's your multiplier? How many times are you paying to store the same request? Go look at your itemized bill. A question with a specific answer, and an answer that frightens people. The entire 2.0 argument starts from that number, not from architectural aesthetics.

3. Use your own two jobs as a controlled experiment. X and Z are persuasive because the variables really were held: same age, same architecture shape, same language, same homegrown storage engine, even four of the same people. This is vanishingly rare in software writing — most people can only offer you the story of the time it worked. They give you the time it didn't, and they were the contractor on both.

4. When people disagree, ask where the feedback loop broke, not who is right. This is the most portable move, and it isn't only technical. Why can't AI enthusiasts and skeptics talk? Not because either side is stupid, but because the wins and the costs land on different people, so no loop forms between them. Why don't developers care about reliability? Not irresponsibility — someone else carries the pager. The value of this move is that it converts a moral accusation into a systems-design problem, and systems-design problems can be fixed.

5. Write up your own failures in incident-review format. In 2018 they published career advice for women and were mobbed for a week. The response was a piece titled "Post-mortem: feminist advice meltdown (March 2nd)." It opens:

As of today it's been one week since I wrote some advice and the internet exploded in my face, so now it's time to do what I always do: post mortem that shit. "Post-mortem: feminist advice meltdown (March 2nd)", March 2018

It contains a "what happened" timeline (including an honest accounting of their own motives — they concede that they rejected one critic's feedback partly out of personal history, admitting "I can be a resentful little shit"), a categorized list of the feedback received, and then a ledger of NO REGRETS / REGRETS / SEMI-REGRETS, adjudicated item by item. They apologize (for being sloppy about their own gender questions) and refuse to apologize (for the advice itself), stating plainly that they are "disinclined to grovel before a howling mob." The format is lifted straight from incident review: separate what was actually done wrong from what merely turned out badly. Most people cannot do the second part.

6. Rename things, and know what you're fighting over. "Ops is not a role, it's an emergent property." "Management is not a promotion, it's a change of profession." "Observability 1.0 / 2.0." It is one move repeated. They understand perfectly well that definition is power — they've written that "three pillars" caught on partly because vendors "coincidentally" had metrics products, logging products and tracing products to sell. Their response isn't to complain about it but to go define something themselves. The ethics of that are delicate; see below.

Where they might be wrong

The biggest problem is one they stated better than their critics do. The correct answer to Observability 2.0 happens to be the product their company sells. They admitted as early as 2019 that fear of sounding like a vendor had stopped them from making the argument properly:

I think that I've been reluctant to hammer this home as much as I ought to, because I'm exquisitely sensitive about sounding like an obnoxious vendor trying to sell you things. (Which has absolutely been detrimental to my argument.) "Deploys: It's Not Actually About Fridays", October 2019

The confession is admirable but it doesn't dissolve the problem, it just states it clearly. Stamping a competitor's architecture with the version number "1.0" in 2024 is unambiguously a move over pricing power — semantic versioning sounds like neutral technical vocabulary, and its practical effect is to define someone else's product as last generation. They had just finished pointing out how vendors used "three pillars" to align with their own product lines; this is the same species of act, differing only in that they believe their own technical judgment is correct. It may well be correct. That is not a methodological difference. The genuine hedge is the public call for more non-Honeycomb 2.0 tooling — which is sincere, but raises their own cost rather than removing the conflict.

Second, the sample. Honeycomb is a developer-tools company they built from scratch whose customers are engineers, and it is not large. Part of why Company Z could have that feedback loop is that it was new, small, and had as its CTO the person who cared most about this in the world. The advice — "take some cycles off product and fix your fucking deploy pipeline" — presupposes you have the authority to make that call. Many engineers do not. Notably, the 2026 AI piece draws its boundary of applicability with real precision (explicitly not written for teams whose management is disconnected from engineering reality, nor for low-discipline low-trust teams, nor for tiny startups with no customers, nor for behemoths still fighting red tape for a model license) — but that boundary appears only in that one piece. Most of the writing carries the same volume without the qualifier, which is where they are most readily misread and most likely to give offense.

Third, an objection from a critic — and here I can only read the version they quoted. In 2019 someone published a long rebuttal to the Friday-deploy argument, and Majors reproduces this passage verbatim:

Lastly there is some strange argument that choosing not to deploy on Friday "Shouldn't be a source of glee and pride". That one I haven't figured out yet, because I have always had a lot of glee and pride in being extremely (overly?) protective of the work/life balance of the engineers who either work for me, or with me. quoted by Majors in "Deploys: It's Not Actually About Fridays" (original published on HackerNoon)

A disclosure: I was not able to open that original piece while writing this page — the network policy in this environment blocks that site, as it does the relevant Hacker News threads — so I can quote only the passage Majors reproduced, and cannot summarize the author's full argument on their behalf. Likewise, I have seen references to several technical objections to "Observability 2.0" (chiefly cost: wide events preserve full high cardinality and high dimensionality, so per-request data volume exceeds any single pillar, while metrics remain far cheaper for large-scale aggregation). I could not read any of those originals, so I report only the bibliographic fact and will not paraphrase arguments I haven't read.

Even so, the quoted passage is interesting on its own. The dismantling — you substituted "not deploying on Friday" for "protecting engineers" — is logically clean. But there is something inside that sentence they never quite address head-on: the critic is talking about what they can guarantee their people; Majors is talking about what the system ought to look like. A manager sitting inside the Company X they describe, with no authority to turn it into Company Z, has no place in the framework. All they are offered is: if that's the only lever you have, use it, but treat it like the ugly hack it is rather than a moral stance. That's a concession — but the volume of the original essay buries it. Majors later acknowledged as much, noting that they are not in fact the absolutist people were arguing against, and that this had been the most frustrating thing about the conversation.

Finally, the harshest criticism of them was written by them. In 2023 they revisited what they would once have filed under "proudest manager moments" — years of spending 50–75% of their total emotional bandwidth keeping one talented, high-strung report on the team, including one dramatic save when that person nearly quit. They reversed the verdict:

All that my coddling ultimately did was teach them the wrong lessons, and prevent them from learning the right ones. It delayed those lessons by a few years, and made learning them all the more painful when they finally came. "Helicopter Management", June 2023

The standard they extract is portable as-is: "If you haul someone over the finish line, that is not a success." What's worth noticing is how this self-criticism relates to the rest of the philosophy — it is the same error in organizational form. What they had been doing was using their own emotional labor to manually compensate for a broken feedback loop, instead of letting the person receive the feedback themselves. It took them years to see it in their own conduct, which is probably the most revealing thing on the whole blog: they ran an incident review on their own kindness.

Sources

• WTF is operations? #serverless (May 2016)The original definition of ops as an emergent property rather than a role, and why they nearly turned the talk down.
• The Engineer/Manager Pendulum (May 2017)The most self-cited post in the corpus: management as a change of profession, and swinging between engineering and management as a deliberate career path.
• Friday Deploy Freezes Are Exactly Like Murdering Puppies (May 2019)The full itemized bill for fear as technical debt, and "rules are a piss-poor substitute for judgment." Six months later, Deploys: It's Not Actually About Fridays carries the Company X / Company Z comparison.
• Is it time to version observability? Signs point to yes (August 2024)Observability 1.0 vs 2.0 line by line: storage, cost, who gets to debug, and why 1.0 is the hard way. The cost arithmetic is in The Cost Crisis in Observability Tooling.
• In Praise of "Normal" Engineers (June 2025)The pipeline-based rebuttal to the 10x engineer, and the standard: a great org is one where ordinary engineers can do great work.
• AI demands more engineering discipline. Not less (June 2026)Code as a materialized view of understanding, the Kafka node killed by cron every Tuesday, and the under-ten-percent number. Preceded by AI enthusiasts are in a race against time, AI skeptics are in a race against entropy.
• Helicopter Management (June 2023)Where they reclassify their proudest management achievement as a failure. See also the 2018 Post-mortem: feminist advice meltdown, which handles a public disaster in incident-review format.

Updates